This note hopes to assist the EGEE/LCG/OSG VO managers in installing, configuring and deploying gLite VOMS. The pre-glite VOMS version of this document is HERE.
Everything should be covered by the relevant section of the gLite installation guide.
Instructions on how to try the VOMS prototype server at NIKHEF can be found HERE.
gLite VOMS also runs on the CERN VOMS server lcg-voms.cern.ch, e.g. https://lcg-voms.cern.ch:8443/voms/dteam/
When we installed we didn't have the meta_package available so we kept the following notes if need be. You may also consult VOMS troubleshooting notes and pending VOMS-related bugs/tasks/patches.
The CERN/IT Grid Deployment (IT/GD) team is operating a VOMS server containing
the users of Virtual Organisations (VOs) Alice, Atlas, CMS, LHCb, SixT and
Dteam. New VO Registration Procedures are described in http://edms.cern.ch/document/503245.
VO Registration Security Policy is in http://edms.cern.ch/document/573348
http://cern.ch/dimou/lcg/voms/REFERENCES-NOTES#notes explains
what VOMS is and contains references to original design documentation.
Host: At CERN we installed glite-voms on host lcg-voms.cern.ch (dual-CPU box with 0.5 GB of memory and a 20 GB disk) which runs Scientific Linux (SL3). After sufficient testing of this glite-voms installation with the rest of the Grid services, we 'll move the main VOMS server voms.cern.ch to glite-voms as well. Then, all references to lcg-voms.cern.ch below will also apply to voms.cern.ch. 100MBytes in /var/lib/mysql per VO should be sufficient. Seven VOs are configured on the same host without providing a reliable service.
Naming: Select a user-friendly hostname or DNS-alias that
carries the name of your VO(s). Make sure a host certificate is issued for
this host alias that
your
users will use to open the VOMS web interface, typically:
https://VOMSHostname.Domain:8443/voms/YourVO,
e.g. https://lcg-voms.cern.ch:8443/voms/dteam .
Put the host certificate in the usual place at /etc/grid-security/hostcert.pem,
/etc/grid-security/hostkey.pem.
Connectivity: The host needs ports open on the firewall. It, therefore, must have an INCOMING IP address allocated. It must be accessible from outside your intranet via a SSL connection to port 8443. The port numbers (referenced later on in this document as <Port_number> ) you select to offer one vomsd instance per VO, should also be open on your firewall for access from outside your domain. This is indispensable for your VO members trying to get their credentials approved against the VODB via the voms-proxy-init command. Example: On lcg-voms.cern.ch and voms.cern.ch, ports 15000-15020 are open and VOs are defined on the following ports:
| VO Name | Port |
| alice | 15000 |
| atlas | 15001 |
| cms | 15002 |
| lhcb | 15003 |
| dteam | 15004 |
| sixt | 15005 |
| test | 15012 |
Processes needed:crond, sshd, edg-voms, tomcat5, mysqld (the present database choice).
User logins needed: This depends on the number of VOs that you configure on the same host. The users should be the VO managers and their deputies, when they type voms-admin commands from the shell instead of using the web interface. We estimate maximum 10 user logins for the lcg-voms.cern.ch VOMS server, where the LHC Experiments and DTEAM are hosted.
Expected concurrent operations:
These figures (estimated by the voms-admin developer Karoly Lorentey) can
comfortably handle a population of 100000 users. If they type voms-proxy-init during
the same hour, they resulting to roughly 30 VOMS operations per second. This
can be easily handled by no more than 5-10 concurrent database transactions,
which
in VOMS are very short-lived, each lasting no more than a few dozen milliseconds.
The default limit of no more than 5 concurrent database reads starts to fail
noticably only at about 70 operations per second on a slow machine. This limit
is configurable per VO in file:
/opt/glite/var/etc/voms-admin/your-vo/voms.service.properties.
Extract:
# An instance of the VOMS admin service won't create more than this # number of query connections to the database. The default is 5. voms.database.query.connections.max 5
Processes to run from cron:
13 8 * * * /usr/sbin/tmpwatch -f 240 /var/log/tomcat5 # Log update
#14 2,8,14,20 * * * /opt/glite/etc/cron/fetch-crl-cron #Certificate
Revokation
List update no more needed. With glite this is done via /etc/cron.d
14 1,7,13,21 * * * /opt/glite/etc/cron/cron-voms-ldap-sync #Contact
and fetch
LDAP contents IF your master VO DB are still in LDAP
The last of these processes consists of polling the contents of your LDAP directories (if you do have a LDAP-based VO before migrating to VOMS) to update your VOMS database. It will be obsolete when the LDAP directories will no more be updated (phase 4 of the migration steps, if you decide to follow them in that order).
Additional requirements:
Start with a clean Scientific Linux reinstall. I used
a barebone Scientific Linux 3.0.4, with no optional packages installed,
especially not MySQL or Tomcat.
MANUAL DEPENDENCIES
-----------------------------------------
Install the following packages manually, to prevent missing dependency
errors later:
For the security utils and the rest of the stuff:
apt-get install perl-DateManip
apt-get install perl-libwww-perl
apt-get install perl-libxml-enno
apt-get install PyXML
apt-get install 4Suite
For voms-admin-client:
apt-get install perl-SOAP-Lite
apt-get install perl-Crypt-SSLeay
MAGICAL AUTOINSTALL SCRIPT
---------------------------------------------------
Go to http://glite.web.cern.ch/glite/packages and select "gLite 1.0"
From the Releases section. You will get a list of links to gLite
deployment scripts. Scroll down to "gLite VOMS Server and
Administration Tools", and download the installation script for RH
Enterprise 3.0 systems. At the time of writing, the following
commands work fine:
wget http://glite.web.cern.ch/glite/packages/R1.0/R20050331/installers/glite-voms-server_installer.sh
sh ./glite-voms-server_installer.sh
Provided you installed the above dependencies, the script will
download and install everything. There should be no obvious problems.
SET THE MYSQL ROOT PASSWORD
----------------------------------------------------------
Set the MySQL root password to something of your choice.
service mysql start
mysqladmin -u root password 'your-password'
mysqladmin -u root -h localhost.localdomain password 'your-password'
INSTALL JAVA
-----------------------
Install Java. (I use Blackdown Java (http://blackdown.org) in this example.)
wget ftp://mirror.switch.ch/mirror/java-linux/JDK-1.4.2/i386/01/j2sdk-1.4.2-01-linux-i586.bin
mkdir /opt/java
cd /opt/java
sh ~/j2sdk-1.4.2-01-linux-i586.bin
Register Java.
update-alternatives --install /usr/bin/java java /opt/java/j2sdk1.4.2/bin/java
1000
update-alternatives --install /usr/bin/javac javac /opt/java/j2sdk1.4.2/bin/javac
1000
Set up Java paths.
mkdir /etc/java
echo 'export JAVA_HOME=/opt/java/j2sdk1.4.2' > /etc/java/java.conf
UPDATE THE RPMS
--------------------------------
(Before an official gLite release containing these versions.)
Upgrade glite-config to version 1.1.0 to fix broken mysql.py problem.
Upgrade the voms-related RPMs to the latest versions:
glite-voms-server-config-1.0.1
glite-security-voms-admin-server-1.0.4
glite-security-voms-admin-client-1.0.4
glite-security-voms-admin-interface-1.0.2 (same as in gLite 1.0)
(The autobuild system should generate the 1.0.4 RPMs real soon now.)
The client package was not installed by
glite-voms-server_installer.sh, it needs to be installed by hand.
CONFIGURE GLITE DEPENDENCIES
---------------------------------------------------------
Copy the gLite config templates to prepare for customization.
cd /opt/glite/etc/config
cp templates/*.xml .
Set the global configuration parameters.
cd /opt/glite/etc/config
edit glite-global.cfg.xml
Set site.config.url to ""
Set JAVA_HOME to "/opt/java/j2sdk1.4.2/"
Set up the gLite Security Utilities.
cd /opt/glite/etc/config
edit glite-security-utils.cfg.xml
Set cron.mailto to an address of your choice.
Run the Security Utilities configuration script.
/opt/glite/etc/config/scripts/glite-security-utils-config.py
(It should say "gLite Security Utilities configuration successfully completed".)
Set up RGMA.
cd /opt/glite/etc/config
edit glite-rgma-common.cfg.xml
Set rgma.server.hostname.
Set rgma.schema.hostname.
Set rgma.registry.hostname.
(I used `localhost' for all three.)
edit glite-rgma-servicetool.cfg.xml
Set rgma.servicetool.sitename. (I used `localhost'.)
rm glite-rgma-servicetool-serviceName.cfg.xml
(We don't need this.)
LOG OUT
---------------
Log out and log in again to have all gLite environment variables loaded.
CONFIGURE VOMS
------------------------------
Set up the VOMS server.
edit glite-voms-server.cfg.xml
Define as many VOs as you want. Example settings:
instance=fnord
voms.vo.name=fnord
voms.port.number=15000
voms.code=15000
vo.admin.email=Your email
vo.ca.URI=hostname:15000
R-GMA for the fnord VO:
rgma.servicetool.enable=false
rgma.servicetool.name=hostname_voname
rgma.servicetool.url_endpoint=https://hostname:8443/voms/fnord
rgma.servicetool.service_type="VOMS Server"
rgma.servicetool.service_version="1.0.3"
rgma.servicetool.publish_interval=20
rgma.servicetool.status_script="${GLITE_LOCATION}/etc/init.d/voms-admin status"
rgma.servicetool.status_interval=30
rgma.servicetool.url_wsdl="https://hostname:8443/voms/fnord/services/VOMSAdmin?wsdl"
rgma.servicetool.url_semantics="n/a"
voms.mysql.passwd=whatever
Run the VOMS configurator script.
/opt/glite/etc/config/scripts/glite-voms-server-config.py
Set yourself up as a VO admin:
voms-admin --vo [VONAME] create-user [certificate.pem]
voms-admin --vo [VONAME] add-member /[VONAME]/Role=VO-Admin [certificate.pem]
You are done! Go to https://server:8443/voms/VONAME with your
certificate loaded, and enjoy your new VOMS server. The core service
should also be running correctly on the port that you set it up on.
Subject: Re: VOMS-admin config files (fwd) ** Templates: Files & dirs in /opt/glite/etc/voms-admin => ls context-siblings.xml.template notification context.xml.template voms.database.properties.template databases voms.service.properties.template ldap-vo-config.xml web ldap-vo-config.xml.template ** For setting the parameters both for voms-admin (VO manager notification, VO access URL) and for voms-server (VO access port for the client etc), edit file: /opt/glite/etc/config/glite-voms-server.cfg.xml ** For tailoring your welcome page on your-server-host create the file: $GLITE_LOCATION_VAR/etc/voms-admin/VONAME/web/UserRequest/create.pp and include your customized text with HTML markup. (GLITE_LOCATION_VAR is normally set to /var/glite.) ** In case you syncronise with a LDAP "copy" of your VO: /opt/glite/etc/cron/cron-voms-ldap-sync runs from cron and executes /opt/glite//sbin/voms-ldap-sync according to config. in file /opt/glite/etc/voms-admin/ldap-vo-config.xml
--vo=dteam --port=15004
--code=1114127004
--dbname=voms_dteam
--username=dteam_que
--passfile=/opt/glite/etc/voms/dteam/voms.pass
--logfile=/voms.dteam
$GLITE_LOCATION/bin/voms-admin --vo [your-vo] create-user [usercert.pem] assign-role [your-vo] VO-Admin [usercert.pem]
NB! Administrator setting will be undone after synchronisation with a VO-LDAP server. Proper ACL setting is permanent.
$GLITE_LOCATION/sbin/voms-admin --url=http://localhost:8080/voms-admin/<your-vo> add-acl-entry
VO allow list [hostcert.pem]
NB! For recent voms-admin versions this
is not
necessary, provided that:
1. The remote host certificate is issued by a trusted
CA and
2. The VOMS server administrator has given the Global
ACL command allowing global list privileges, as explained below..
1) Listing the Global ACL /opt/glite/sbin/voms-admin --vo [your-vo] get-acl Global-ACL
2) General description of adding a new entry to the Global ACL
a) If there is a certificate available for the intended principal:
/opt/glite/sbin/voms-admin --vo
[your-vo]
add-acl-entry Global-ACL <ALLOW> <OPERATION> <CERTFILE>
b) Providing explicit CA and DN strings instead of a certificate:
/opt/glite/sbin/voms-admin --vo
[your-vo] --nousercert
add-acl-entry Global-ACL <ALLOW> <OPERATION> <DN> <CA>
(The above commands need to be typed in on a single line.)
In both cases, <ALLOW> is either 'allow' or 'deny' and <OPERATION>
is one of 'all', 'create', 'delete', 'add', 'remove', 'list',
'set-acl', 'get-acl', 'set-default-acl' or 'get-default-acl'.
3) Allowing any authenticated person or host to query VO membership
data (for grid-map file generation):
/opt/glite/sbin/voms-admin --vo [your-vo] --nousercert
add-acl-entry Global-ACL allow list
"/O=VOMS/O=System/CN=Any Authenticated User"
"/O=VOMS/O=System/CN=Dummy Certificate Authority"
(The above command needs to be typed in on a single line.)
For optimal usage of VOMS Groups and Roles it is recommended to:
More examples:
| VO | VOMS Group | VOMS Subgroup | VOMS Role |
| CMS | /cms | /cms/datatag | /cms/Role=admin |
| DTEAM | /dteam | /dteam/lcg1 | /dteam/Role=lcgadmin |
| ATLAS | /atlas | /atlas/usatlas | /atlas/lcgadmin |
Limitations to the number of VOMS Groups:
VOMS' enhanced functionality in terms
of fine-grain categorisation of users in Groups and Roles cannot be exploited
beyond a limited
set of 2-3
Group
and
Role values. This is due to the lack of an encapsulating Service that manages
ACL permissions and masks
the
limitations
of the Unix
file system. The problem is how to manage grid users (who may belong to many
VOMS Groups) and files on the computing resources (which can only belong to
one
Unix group).
Either the file creator has to change appropriately his/her group before writing
the file, or all files should be world-readable, which is not acceptable by
most VOs. Suppose a user was registered in VOMS with X valid Roles and
he presents his/her credentials to the resource fulfilling Y out of
those X.
The
process
has to run at a site, using a user account that must be present in /etc/group
as a member of all the local Unix groups that correspond to his/her present Y VOMS
Roles,
and only those. This means that the user account under which a job runs may
belong to any valid combination of groups in /etc/group, which makes their
maintenance
difficult to manage.
How Groups/Roles are used in the grid-map file:
This depends on the sequence in which these Groups/Roles appear in edg-mkgridmap.conf
file. The one listed first is the only one used. So, we list the one with most
privileges first so that users
appearing in
multiple
Groups and Roles will get the most privileged accounts on the service nodes.
Here is the edg-mkgridmap.conf
file
of the LHC Experiment VOs and DTEAM .
How Groups/Roles are used in LCMAPS (input
by Martijn Steenbakkers):
*All* VOMS attributes are mapped to (possibly different) groupnames and
the mapped user will be added to these groups. For determining the poolaccount
LCMAPS creates a
leasename of either
"<
DN>:<pgid>",
where <pgid> is the groupname that is the result of the mapping of the
first VOMS
attribute, or
"<
DN>:<pgid>[:<sgid1>[:<sgid2>.....[:<sgidN>]....]]",
where <sgid1..N> are the secondary groups that are the result of the
mapping of the
other VOMS attributes.
Which one is used depends on the LCMAPS configuration: if in lcmaps.db the
voms
poolaccount has the "-do_not_use_secondary_gids" flag set the first
type is used,
otherwise the latter.
Example:
With this entry in the gridmapfile:
"
/atlas" .atlas
and these entries in the groupmapfile
"
/atlas" atlas
"
/atlas" atlasmc
in the former case a user with the attributes "/atlas" and "/atlas/mc"
gets mapped to the account "atlas001" with gids "atlas" and "atlasmc" and
a second userwith only the attributes "/atlas" gets also mapped to
account "atlas001", but with onlygid "atlas".
In the latter case the first user gets mapped to "atlas001" with
gids "atlas" and
"
atlasmc" and the second one to "atlas002" with gid "atlas".
In the latter case the first user gets mapped to "atlas001" with
gids "atlas" and
"
atlasmc" and the second one to "atlas002" with gid "atlas".
So in the latter case you get a better isolation of different roles, but at
the cost of using (many?) more poolaccounts.
<!-- The name of the VO and the port that the C++ core service runs on. -->
<vo name="dteam" port="15004">
<ldap>
<!-- The hostname of the LDAP server. -->
<host>lcg-vo.cern.ch</host>
<!-- The base DN for listing people. -->
<people>ou=People,o=dteam,dc=lcg,dc=org</people>
<!-- Mapping LDAP groups to VO groups or VO roles. -->
<map dest="/dteam">ou=lcg1,o=dteam,dc=lcg,dc=org</map>
<map dest="Role=lcgadmin">ou=lcgadmin,o=dteam,dc=lcg,dc=org</map>
</ldap>
</vo>
All Computing and Storage Elements (CEs and SEs) as well as the Resource Broker
will need to become accepted clients of the VOMS server in order to run the
edg-mkgridmap
script
from the LCG2 RPM location for
Scientific Linux and RedHat7.3.
and generate the grid-map file from VOMS. The valid edg-mkgridmap.pl version
in June 2005 is 2.4.2.
The following procedure explains how these nodes (called remote_hosts
further on in this document) become eligible to access the VOMS server and
list the contents of the VOs defined there:
Alternative procedures:
A. No action needed: If the remote_host is certified by a trusted, i.e. present in /etc/grid-security/certificates Certification Authority (CA), then it can list the VO without extra action, provided Global ACL for list privileges is enabled.
B. Via ACLs: A good way to grant access to the compatibility interface for a remote_host is to change the ACL of the VO group (named /atlas, /dteam etc.). This can be done:
https://lcg-voms.cern.ch:8443/voms/dteam/webui/Admin/groups/editacl?groupname=%2Fdteam
Allow:allow
Operation: list
Admin DN, Admin CA: the remote_host 'DN & CA
voms-admin --url=http://localhost:8080/voms-admin/dteam add-acl-entry
/dteam allow list .remote_host .pem
D. Use voms-httpd: A section in the VOMS integration document prepared by Grid-IT explains the installation of this HTTP implementation of VOMS based on Apache and mod_perl and is linked from HERE.
Write the exact lines needed to configure your grid-map file generation. Example HERE.
LCG2 LCFGng and Manual Installation Guides contain instructions on how to introduce additional VOs to the service nodes. As of the LCG2 Release LCG-2-4-0 automatic mechanisms will be provided to update the necessary parameters in files:
ComputingElement-novoms-cfg.h
LCG-BDII-cfg.h
ResourceBroker-cfg.h
UserInterface-cfg.h
Users-cfg.h
flatfiles-dirs-SECLASSIC-cfg.h
lcginfo-seclassic-cfg.h
mkgridmap-cfg.h
poolaccounts-cfg.h
user-edguser-cfg.h
voswmgr-dirs-cfg.h
site-cfg.h.template
The LCG2 Release includes the hooks for all parameters necessary in the CEs, SEs, RB and gatekeeper files for LCAS/LCMAPS configuration. A detailed documentation on VOMS - LCAS/LCMAPS installation, prepared by Grid-IT is linked from HERE but, in June 2005, it has pre-glite content. You may go to http://cern.ch/glite/packages/ and select the rpms under gLite Security Utilities.
LCG2 Release 2_6_0 contains the voms-client code and the vomses directories for some VOs pre-configured. Here are the Release and configuration notes. If you need to start from scratch, then:
Download the
voms-client code can be found on the CERN LCG Rpm directory for
Scientific
Linux .
Configure
User Interface(UI) by
editing the file: /opt/edg/etc/vomses/[your-vo]-VOMSHost.Domain
The order of the parameters per line is "VO nickname", "hostname", "Port_number", "Host_Cert_Subject", "your-vo"
Example DTEAM configuration (in LCG2 Releases so far we still use $EDG_LOCATION
and not yet $GLITE_LOCATION): The file is "$EDG_LOCATION/etc/vomses/dteam-voms.cern.ch" containing
line:
"dteam" "voms.cern.ch" "15004" "/C=CH/O=CERN/OU=GRID/CN=host/voms.cern.ch" "dteam"
Syntax of the voms-proxy-init command: voms-proxy-init -voms [VO nickname]:/group/Role=[VOMS-Role]
Example
DTEAM voms-proxy-init command: voms-proxy-init -voms dteam:/dteam/Role=lcgadmin
EDG Security Installation Guide
The information in this document has profited from instructions edited by Chih-Chiang Chang and Min Tsai, documentation by Enrico Ferro and his colleagues, corrections by Karoly Lorentey, advice by Ian Neilson and comments by all of the Grid Deployment community. Thank You!
Maria Dimou IT/GD Grid Infrastructure Services.