The concept of organising users into Virtual Organisations (VOs) is well-established in the science grid community. VOs form the technical link between researchers across institutes, countries and supporting compute centres, by handing out secure membership tokens that may be used to acquire access to compute resources. This eases the burden on system administrators of establishing trust relationships with individual users for every research project, and helps to properly account resource use to the right project.
The remaining burden for system administrators is to set up several files that detail which VOs are supported, how membership tokens can be obtained and verified, and what user and group accounts should be used locally for users of these VOs.
The vo-support package implements several modules to help automate these tasks. The actual VO-specific data is provided by other packages, which either contain just a single VOs data, or for a whole bunch of VOs together. The vo-support package contains the helper functions for package maintainers to configure VO support in the post-install phase of the package management (for RPM and Debian based packages) and command-line tools to selectively turn on or off support for individual VOs.
Configuring a Grid Site is not a trivial task. Not only because grid middleware is fairly complicated and less well known by system admistrators, but also because it has a more indirect idea about what ‘users’ are.
On traditional cluster systems, user accounts are kept either locally (/etc/passwd) or in some networked way extending throughout the organisation (such as Windows domains, LDAP, or NIS). For Grids this no longer works. As research organisations collaborate world-wide, their combined user base becomes too large to be ‘known’ by any individual site. That is why users are authenticated by membership of so-called Virtual Organisations.
The translation from this ‘membership card’ to a locally known entity involves a couple of technicalities and configuration details. The vo-support packages provide the structure to ease the installation and maintenance tasks of supporting VO users on local systems.
This structure is organised as a collection of system packages around a common set of scripts. The main reasons for this approach are:
- package management is very robust and reliable,
- it integrates well with typical administrative tasks.
The purpose is to make VO configuration as easy as installing the right packages and tweaking just a couple of configuration files.
The information per VO is kept in
/usr/share/vo-support/vos/<VO name>/
and the configuration of VOs locally is stored in:
/etc/vo-support/vos/<VO name>.conf
VOs that are configured but disabled have a configuration file that’s been renamed to
/etc/vo-support/vos/<VO name>.conf-disabled
The modules (individual scripts to tune one aspect of VO support) are installed in
/usr/share/vo-support/modules/
The data is stored in one directory per VO, and may have the following files:
| AUP | acceptable use policy |
| info | general information |
| {VOMS server hostname}.lsc | the LSC file(s) for each VOMS server |
| {VO}.conf | example configuration file |
| vomses/{VO name}-{VOMS server hostname}.ch | vomses data (needed to obtain VOMS proxies |
The info file contains general information about the VO. There is
currently no strict file format, but the vo-support-egi package
generates info files from the XML data of the EGI operations portal
in a specific format. Here’s the example for the ‘ops’ VO:
Name: ops Last Change: 2012-12-07T10:27:45+0000 Validation Date: 2011-05-30T10:24:30+0000 Scope: Global Support Procedure: Discipline: Infrastructure Enrollment URL: https://lcg-voms.cern.ch:8443/vo/ops/vomrs Homepage URL: https://wiki.egi.eu/wiki/OPS_vo Description: The goal of the VO is to facilitate the operations of the LCG/EGEE Grid infrastructure, which includes running official monitoring, re- certification and performance evaluation tools. Additionally the VO will be used for interoperations with other grid infrastructures.
The site-specific details for VO support are expressed in
configuration files, one per VO, in /etc/vo-support/vos/. These files
are named <vo>.conf and are in INI file format, with sections for
each Fully Qualified Domain Names (FQANS)
that the VO uses.
The values in these files are used by specific modules (see
below). The vo-config program can be used to retrieve
configuration data.
The following modules are common VO-related configuration tasks. Some of them require additional, site-local configuration.
Each supported VO has a directory in /etc/grid-security/vomsdir, which contains the so-called LSC files. Each file contains the X.509 DNs of the host and (chain of) CA(s) of one of the VO’s VOMS servers. This data is required to verify the VOMS attributes which come with a user’s security token (the proof of membership). The LSC files are static, and provided by the individual VO packages. The module will copy these files from usr/share/vo-support/vos.
The /etc/vomses directory contain VOMS server connection data per VO, as used by the VOMS utilities (such as voms-proxy-init). This data is also static and provided by the individual VO packages. The module will copy these files from usr/share/vo-support/vos.
The /etc/grid-security directory contains a couple of files (voms-grid-mapfile and groupmapfile) that establish the mapping between the FQANs as found in user security tokens and the local user, pool account, and local group; these files are used by the LCMAPS and ARGUS frameworks.
The related settings are site-local and found in each individual VO configuration file, per FQAN section.
Pool accounts are generic user accounts with a common prefix and a numeric suffix (e.g. ops042). Users that are mapped to a pool will be allotted a free account from the pool, and this fact is recorded in the gridmapdir by making a link between files named after the pool account and the user’s DN. These mappings are persistent so the same user will be mapped on the same pool account.
The use of pool accounts is a site-local matter, and relates to the grid-mapfile; the amount of pool accounts to use and the pool prefix is set in the local configuration files.
The site-specific details for VO support are expressed in
configuration files, one per VO, in /etc/vo-support/vos/. These files
are named <vo>.conf and are in INI file format, with sections for
each FQAN. Settings that are global to the VO go in the top section
called [DEFAULT], but this section header may be omitted. Any
settings preceding the first FQAN is considered to be in the
[DEFAULT] section.
# example configuration file for pvier SoftwareDir = /data/esia/pvier DefaultSE = tbn18.nikhef.nl
:
[/pvier] poolaccounts = 30 poolprefix = pvier groupmapping = pvier
:
[/pvier/Role=lcgadmin] poolprefix = pvsgm poolaccounts = 10
The vo-support package features two utilities, vo-config and vo-support.
This utility interacts with the configuration files in /etc/vo-config. There are two functions currently implemented:
- get-fqans; this function retrieves the fqans for a VO;
- get-vo-params; this funtion retrieves a configuration value for a given VO and FQAN.
This utility implements the following functions:
- list-vos; lists VOs on the system (from /usr/share/vo-support);
- list-modules; list the installed modules (from /usr/share/vo-support/modules);
- run-module; run a module for a given VO;
- configure-vo and deconfigure-vo; these functions are meant to be used by package maintainer scripts for packages that install VO data
- add-module and remove-module; these functions are meant to be used by package maintainer scripts for packages that install modules.
Packages that install new VO data and/or VO support modules will have to deal with configuration on installation and removal of the package.
In short, when a new VO is installed, the currently active modules must be run for this VO. On removal of a VO, the modules must be run before removal.
Likewise, new modules need to be run for every VO on the system on installation and removal.
There are some subtleties, however, when dealing with configuration of VOs. As a rule, the maintainer scripts must not overwrite the manual configuration changes done by the system administrator.
The packager of a new VO should consider whether installing the package should automatically enable the VO, if no configuration for the VO is present. For packages for a single VO, this is probably alright, as that would be the single purpose of the packages. But when packaging bundles of VOs, consider leaving the choice to the administrator.
For RPM packaging, the following code snippet can be used as part of the %post section:
if [ $1 -ge 1 ]; then
if [ -f %{sysconfdir}/vo-support/%{vo}.conf ]; then
if [ -f /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh ]; then
. /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh
configure_vo %{myvo}
fi
fi
fi
For Debian packaging, the code is similar.
case "$1" in
configure)
if [ -f /etc/vo-support/${vo}.conf ]; then
if [ -f /usr/lib/vo-support/scriptlets/maintainerscript-helpers.sh ]; then
. /usr/lib/vo-support/dpkg-maintainer-script-helpers.sh
configure_vo ${vo}
fi
fi
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
A new module should but something like this in the %post scriptlet:
if [ $1 -ge 1 ]; then
if [ -f /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh ]; then
. /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh
add_module %{mymodule}
fi
fi
For Debian, this is the equivalent:
case "$1" in
configure)
if [ -f /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh ]; then
. /usr/share/vo-support/scriptlets/maintainerscript-helpers.sh
add_module ${mymodule}
fi
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esacFor removal, examples can be found in the maintainerscript-helpers.sh file.
To install the package, simply typing
make install
should suffice.
The vo-config and vo-support scripts are written in Perl, and depend on the perl module Site::Configuration::VO.
Downloading the EGI VO info can be done through the portal; visit https://operations-portal.egi.eu/vo/search and click on the action menu button on the right to download the voIDCard (called XML feed). To get all the VO information, use this URL. This is not advertised so it may change or disappear in the future.
This software is Copyright 2012, 2013 De Stichting voor Fundamenteel Onderzoek der Materie (FOM), the Netherlands, and was written by Dennis van Dok <[email protected]> at FOM/Nikhef, with the exception of the shunit2 shell script, which is Copyright 2008 Kate Ward.
This is free software. For the license terms of this software, see the full text of the licence files in this package. All files are licensed under the Apache License, Version 2.0 with the exception of shunit2, which is licensed under the GNU Lesser General Public License.
This README is licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.