How to install a new VO on the production DB Last Update: 2006-05-26 by Maria Dimou Original written by: Karoly Lorentey This procedure may be used to set up a new VOMS server host, and also to install a new VO on an existing host. It is only necessary for data in the production Oracle DB at CERN with multiple listeners. The host voms101.cern.ch (alias voms.cern.ch) is not affected by this procedure because it uses one listener on the pre-production db grid8.cern.ch. BEWARE! All this is for gLite 3.0 only. We expect that some of the workarounds described here will become unnecessary or even downright harmful in later releases. This is especially relevant for the voms.massage script. (1) NB! The CERN VOMS servers keep their configuration files on a remote host. Make sure the file /opt/glite/etc/config/glite-global.cfg.xml contains a valid site.config.url parameter. It is valid if you can open it. It might not work with Explorer and still be valid. The master and slave CERN VOMS servers' site config file on lxb2051.cern.ch is: .../glite3.proddb.newHW/voms.config.xml The configuration sets up VOs to use the normal (_w-less) accounts on the production database. As the XML config does not yet support the long connection strings, the configuration is for a single database host, not the entire high availability cluster. If you want to create a new VO, you'll simply need to add it to the site config. (2) Log in to the VOMS server host. Make sure there are no defined VOs yet. If the command ls -l /var/glite/etc/voms-admin/*/voms.database.properties finds any files, then execute step (3) else continue with step (4). (glite-voms-server-config.py is unable to reconfigure existing VOs due to bug #10434.) (3) Stop the gLite service and Remove all existing VO definitions by running glite-voms-server-config.py with the "--vo=VOName --remove" option. Don't worry, this will not touch the database. /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=alice --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=atlas --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=cms --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=dteam --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=geant4 --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=lhcb --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=ops --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=sixt --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=test --remove /opt/glite/etc/config/scripts/glite-voms-server-config.py --vo=unosat --remove (4) Run glite-voms-server-config.py with the --configure option. /opt/glite/etc/config/scripts/glite-voms-server-config.py --configure It will not run successfully, and create all configured VOs due to the 'enableD' variable in the gliteRgmaServicetool.py script. (5) Logout to update env. Alternatively, just run /etc/glite/profile.d/glite_setenv.csh or (if you use the bash shell) /etc/glite/profile.d/glite_setenv.sh (6) Run the /opt/glite/sbin/voms.massage script, packaged in the voms-tools rpm (see https://uimon.cern.ch/twiki/bin/view/LCG/VomsCernSetup). The script will fix the Oracle library paths, fix the above var. typo (both fixed in rpm glite-VOMS_oracle-2.3.0-1) and set up the VOs to use the production database cluster (instead of a single unreliable database host, as described in the site config). It will also automatically set up the *_W accounts with the correct grants and change the core service to use the _W accounts. The voms.massage script will change/create the following files: /opt/glite/etc/voms/tnsnames.ora /etc/glite/profile.d/glite_setenv.sh /etc/glite/profile.d/glite_setenv.csh /opt/glite/etc/voms/*/voms.conf /var/glite/etc/voms-admin/*/voms.database.properties (7) Logout to update env. (8) Login again and run 'service gLite start'