VOM(R)S Configuration

Before trying to configure anything, please read VomsNodes and VomsCernSetup !

Long connection string

(DESCRIPTION= (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr4-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr3-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr2-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr1-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr5-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr6-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr7-v.cern.ch)(PORT = 10121)) (ADDRESS = (PROTOCOL = TCP)(HOST = lcgr8-v.cern.ch)(PORT = 10121)) (ENABLE=BROKEN) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = lcg_voms.cern.ch) (FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC)(RETRIES = 200)(DELAY = 15)) ) )

VOMS/VOMS-Admin configuration

Configuration files

All configuration files for VOMS-Core and VOMS-Admin are stored on a remote host voms-conf.cern.ch. This situation can certainly be improved...

But the solution MUST be compliant with these rules:

  • Files must be stored in a safe way (with backups, raid, etc.)
  • Files must be stored in a secure way (read/write accesses must be reduced to a minimal set of persons), because they contain passwords (for DB)

A possible solution could be AFS, must be investigated...

Configuring a node

Please have a look to VomsNodes page, and if there is no DB schema update, try first to apply new configuration on a node out of production service (slave of lcg-voms, one of the nodes of voms which was previously removed from the alias), in order to be sure that the new configuration won't break the service, and that the intervention is as transparent as possible for the users.

  1. Make sure that:
    • the necessary rpms are installed on the host as listed in VomsCernSetup
    • the hostcert and key are present in directory /etc/grid-security
    • the configuration files have been updated accordingly
  2. Run the following commands to configure VOMS-Core and VOMS-admin at the same time:
    1. /opt/glite/etc/config/scripts/glite-voms-server-config.py -c, to check that configuration looks fine (this don't modify anything, it's just a check!). If it detects an error, try to fix it, and run this command again while there are errors.
    2. /opt/glite/etc/config/scripts/glite-voms-server-config.py --configure, to really (re)configure things. At the end, a message will be printed, saying that you have to run /opt/glite/etc/config/scripts/glite-voms-server-config.py --start, to start daemons. But, before doing it...
  3. Fix some values thanks to small scripts. See next paragraph for more details about them.
  4. Start services
    1. source /etc/glite/profile.d/glite_setenv.sh to update the environment.
    2. service gLite restart You must run this because the '--configure' option stops voms-admin and edg-voms processes when starting.

List of scripts

In general the script names are like fix-action.pl and undo-action.pl to undo it. I am now migrating all these scripts to the RPM CERN-CC-VOMS-hacks so they can be installed easily. Maintained in CVS.

Disable VOMS-Admin registration

Scripts: /usr/sbin/fix-glite-security-voms-admin-server-2.0.8-1.sh This is in the VOMS-hacks RPM above.

By default, it is possible to register through VOMS-admin, but at CERN, VOMRS should be used. Hence, to prevent users (and VO-admins) to be confused, it is important to disable it.

There was an option in VOMS-admin 1.2.x, which disappeared in VOMS-admin 2.0.x. It should appear again in VOMS-admin 2.0.13, so these scripts will become obsolete soon.

The script should be run once after the installation of glite-security-voms-admin-server-2.0.8-1. It unpacks the .war file patches it and repacks it. voms-admin should be restarted afterwards.

Fix the VOMS server URI in VOMS proxies

Scripts: fix-vomsconf_uri.pl and undo-vomsconf_uri.pl

By default, in VOMS proxies, there is a field which is set to the VOMS server hostname. This field is used by the client to get the corresponding X509 certificate, and to check that the VOMS server signature is correct. VOMS servers take the system host name (eg. voms101.cern.ch) as the default value. But, in the CERN case, we don't want to show the physical host name, but the alias (eg. voms.cern.ch).

For that, we have to add an option in files _/opt/glite/etc/voms/{voname}/voms.conf, to specify the URI we want to show.

The new version of the gLite configuration script will be able to handle this option, so this script will be obsolete soon.

This script doesn't need to be edited to adjust some values, but it works only for CERN-specific DN syntax. So, if you want to use it for non-CERN host, you will have to adapt it.

Fix the VOMS server hostname in files vomses

Scripts: fix-vomses.pl

VOMS-admin can show the line to add in files vomses (actually this function disappeared in VOMS-admin 2.0, and will be back in the next version 2.0.13). For that it automatically a vomses file for each VO, but with the physical hostname.

This script will modify these files to put the alias name (taken from the host certificate).

This script doesn't need to be edited to adjust some values, but it works only for CERN-specific DN syntax. So, if you want to use it for non-CERN host, you will have to adapt it.

Define specific VOMS proxy timeout (for some VOs only)

Scripts: fix-timeout.pl

For more details about these specific timeouts, see the corresponding paragraph (below on this page).

With the new version of the gLite configuration script, you won't have to run it each time to reconfigure things, but only on a fresh installation. This scripts needs to be edited only if another VO wants a specific timeout configuration. But note that such a change MUST be approved by OSCT first. The VO-admin has to send a request to project-egee-osct@cernNOSPAMPLEASE.ch, explaining why using proxy renewal mechanism is not possible.

Grant required privileges to _W oracle accounts

Script: /usr/sbin/fix-oracle-w-accounts.sh

This is in the VOMS-hacks RPM above.

At CERN, services must use _W accounts to connect to the DB. These accounts have no password expiricy, but have limited DB privileges (not able to change the DB schema). "Normal" accounts have full privileges, but the number of simultaneous connections is limited to 10. They have to be used only by humans, or temporarly for DB schema update. The configuration script will create the DB for the normal accounts, but then you have to grant some privileges to _W accounts, to allow VOMS-Core and VOMS-admin to use them.

The command has online which is possibly more up to date than this page.

# ./fix-oracle-w-accounts.sh -h

Usage: ./fix-oracle-w-accounts.sh -p <pass> -c <connectString> -o <owner> -d <TNS_ADMIN dir> [ -v ] [ -a ] || -h

        Given oracle contact details this scripts creates the _W accounts as needed 
        at CERN after any schema upgrade.

         -p Oracle account password, e.g -p OrangesAndLemons
         -o Oracle account owner, e.g -p LCG_VOMS_VALIDATION_20
         -d Oracle tnsnames.ora location, e.g. -d /opt/glite/etc/voms
         -c Oracle connect string, e.g. -c lcg_voms_int11r.cern.ch
         -a Without this option nothing is changed in the database. With the option the changes are made to the DB.
         -v Be Verbose
         -h Print this help.

Examples:
        ./fix-oracle-w-accounts.sh -h
        ./fix-oracle-w-accounts.sh -v -p OrangesAndLemons -o LCG_VOMS_VALIDATION_20 -d /opt/glite/etc/voms -c lcg_voms_int11r.cern.ch
        ./fix-oracle-w-accounts.sh -v -p OrangesAndLemons -o LCG_VOMS_VALIDATION_20 -d /opt/glite/etc/voms -c lcg_voms_int11r.cern.ch -a
Author:
         Steve Traylen <steve.traylen@cern.ch>

Use _W accounts in VOMS-Core and VOMS-Admin

Scripts: fix-voms_w_accounts.pl and undo-voms_w_accounts.pl

The gLite configuration script needs accounts without _W, in order to be able to create/update the DB schema if needed. But then VOMS-Core and VOMS-admin need to use _W accounts. This scripts will go through all relevant configuration files, and add the _W suffix to the DB username.

This scripts doesn't need to be edited to adjust values, unless your installation paths aren't the standard ones.

Specific timeout VOMS configuration for ATLAS, CMS, LHCb

These 3 VOs have a specific configuration of VOMS extensions timeout.

You just have to add the following line into the file '/opt/glite/etc/voms/<VO>/voms.conf

  • For ATLAS : '--timeout=345600' (96 hrs)
  • For CMS : '--timeout=691200' (192 hrs)
  • For LHCb : '--timeout=604800' (168 hrs)
  • For ALICE : 'timeout=259200' (72 hrs)
Then, if the VOMS server are already started, you have to restart them '/opt/glite/etc/init.d/voms restart'

VOMRS configuration (only for lcg-voms.cern.ch nodes)

The VOMRS rpm is on VomsCernSetup. General installation instructions can be found on http://goc.grid.sinica.edu.tw/gocwiki/VOMRS_FAQ

One important thing to note is that there is no configuration script to configure all VOs at once, and so no configuration files are stored remotely.

The configuration files for VOMRS are:

  • /opt/vomrs-1.3/var/etc/*
  • /var/lib/tomcat5/conf/Catalina/localhost/vomrs_*.xml

These files are host-independent, so you can easily copy them across different nodes, to not running vomrs_configure each time.

Configuration of a new VO

  1. run /opt/vomrs-1.3/sbin/vomrs_configure, and answer all questions
  2. service vomrs start

Obviously, you can also copy files from another VO, and just replacing the VO name (and certainly some other values, like VO AUP, etc).

The files /opt/vomrs-1.3/var/etc/vomrs_*/vomrs.xm must belong to tomcat (user and group). It it is not the case, run chown tomcat:tomcat /opt/vomrs-1.3/var/etc/vomrs_*/vomrs.xml

List of scripts

Note that scripts are written with PERL. You have to edit them to adjust some values before running them, no possibility to do it with command line options. In general the script names are like fix-action.pl and undo-action.pl to undo it.

Grant required privileges to _W oracle accounts

Same as for VOMS _W accounts above.

CA rollover

Script: fix-carollover.pl

A CA rollover can be peinful for both users and VO-admin (need to register and approve new certificates, or register again in some cases).

During the last UK CA rollover, this script was used to add for each UK user their new certificate (from the new CA) to the VOMRS DB, in an approved state directly. So users and VO-admins need to do nothing.

This script need to be edited to adjust DB usernames and password, old and new CA DN, the date and eventually the reason.

Fix Host Alias in vomrs.xml files.

The configure_vomrs script uses the canonical host name to generate vomrs.xml in var/etc/vo. The script /usr/sbin/vomrs-1.3-1f-vomrs_configure.py.sh in the CERN-CC-hacks rpm corrects this. It should be run once after a reinstall of a vomrs service before the configuration of new VOs.

Things to be done.

  • Implement tomcat to be on at boot, don't rely on lemon.
  • Implement a SetToDesiredState script for the voms services.

-- Main.dimou - 27 Mar 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatgz scripts.tar.gz r1 manage 3.8 K 2008-03-18 - 16:51 RemiMollon Several useful small scripts
Edit | Attach | Watch | Print version | History: r30 | r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r25 - 2008-05-07 - SteveTraylen
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback