Organising Virtual Organisations

In one version of the future of the grid, we will be awash with Virtual Organisations (VOs).

There will be VOs representing everything from whole institutions and research areas, through regional grids, right down to individual research groups.

Grid service providers will pick and choose the VOs that they are willing, able - or even paid - to support and each and every supported VO will have to be added to the system.

Adding support for a VO is not entirely simple...

Each Virtual Organisation needs a Virtual Organisation Membership Service (VOMS). Unsurprisingly, the VOMS maintains the list of who is in the VO and though the magic of digital certificates can act as the definitive source for this information.

The Grid service must 'know' about the VOMS server before it can support the VO. It must also be able to associate the VO with local usernames and groups. So for each VO, you must

• Add the contact details for the VOMS server to the directory /etc/grid-security/vomses
  
• Add the public key for the VOMS server to the directory /etc/grid-security/vomsdir.
• Create accounts and groups to be associated with the VO.
  This can be complicated where the grid site is part of a network where usernames and groups are managed centrally.
  
• Add entries to the LCMAPS gridmapfile and groupmapfile mapping VO membership to local usernames and groups.
  The exact location of LCMAPS configuration files depends on your local configuration - they could be within the $GLITE_LOCATION directory or within /etc/grid-security.
  
• If you are providing a 'pool' - a set of accounts set aside for a particular VO - add each account in the pool to the gridmapdir.
  
• Apply local tweaks - such as modifying the monitoring/osg-user-vo-map.txt used for configuration of some versions of the Virtual Data Toolkit - to reflect your local VO to account mapping.

This is the kind of task that really needs to be automated.

If you use the YAIM tools to manage your site, you can add the VO details to the vo.d directory and the user accounts to user configuration. Our colleagues at Glasgow Scotgrid use the widely used CFENGINE automation tool to prepare, configure and run YAIM when creating VOs.

The NGS provide a script called ngs-voms-configure with the VDT installer from the NGS area on NeSCForge.

Ngs-voms-configure was written at a time when NGS partner sites were expected to support a common set of recognised VOs. It collects lists of VOs from a central service, locates and downloads their certificates and (optionally) creates accounts and updates any files that need updating.

The ngs-voms-configure script needs to be modified if - for example - your site uses more sophisticated methods for creating accounts. It also has problems collecting certificates when there are strict outgoing firewall rules in place.

One of the current R+D projects is the ngs-vo-tool - which extended the automation provided by ngs-voms-configure for the brave new world of VOs everywhere.

We are planning to use 'VO Cards' - downloadable blobs of XML containing almost everything you need to know about a VO and allow the mappings between VO and local pool accounts to be defined in a configuration file that contains sections like...

[ngs.ac.uk]

vocard = http://cic.gridops.org/downloadRP.php?section=lavoisier&rpname=vocardPu
blic&vo=ngs.ac.uk

local_user = ngs0001-1000
local_group = ngspool

The script is being written in python, developed at Leeds and - as of a few minutes ago - the local repository is being mirrored to the NGS code repository at NeSCForge in a module called ngs-vo-tool.

It is not yet complete. When it is, we hope it will be of use in really organising virtual organisations .