| 923 | | Most of the configuration variables available for the UI, in particular those related to gsissh server, apply for VOBOX too. |
| 924 | | |
| 925 | | To control access to the VO box, see section on [#MappingofVOMSgroupsrolesintogrid-mapfile VOMS groups/roles mapping]. By default, only VO SW manager and production role can log into the VO box. |
| | 923 | The VOBOX is a machine '''dedicated to one VO''' running VO-specific services. In addition to the VO-specific services, this machine runs a service called ''proxy renewal'' in charge of renewing the grid proxy used by VO-specific services. |
| | 924 | |
| | 925 | This is critical for the security to restrict the number of people allowed access to the VOBOX. By default, only people with the VO SW manager role can log into the VO box. To change this configuration, refer to section on [#MappingofVOMSgroupsrolesintogrid-mapfile VOMS groups/roles mapping], but be sure you really need to allow other roles as it can give unwanted users access to privilege services. |
| | 926 | |
| | 927 | The configuration templates for the VOBOX enforce there is only one VO configured for acess to VOBOX specific services. This VO is declared using the `VOS` variable, as for other machine types. If you want to give other VOs access to the VOBOX for the management and operation of the VOBOX, you need to explicitly allow them using the variable `VOBOX_OPERATION_VOS`. This variable is a list of VOs considered as operation VOs. By default, this list is only VO `ops`. If the VOs listed in this variable are not listed in `VOS`, they are automatically added. |
| | 928 | |
| | 929 | In addition, most of the configuration variables available for the UI, in particular those related to gsissh server, apply for VOBOX too. |
| | 930 | |
