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 .

Joined up thinking in the NGS

Back in June, in the posting on the pitfalls of licensing on a Grid, I said that we were working on a new way of supporting those users who had licenses for applications such Amber, Castep, DL_POLY, GAMESS (US) and PC-GAMESS/Firefly.

It demonstrates how the various services that the NGS and its partner sites provide can be linked together to make using the Grid that little bit simpler.

Those who really don't have the time or inclination to wade though past postings only need to know:

• these applications are made available to existing license holders by various NGS partner sites.
• that the sites all have some kind of access control in place to enforce this.
  
• that we use groups within a virtual organisation (VO) called applications.ngs.ac.uk as a way of recording who has signed up for what- so the access control lists can be kept up to date.

If you have a certificate in your browser, you can visit https://voms.ngs.ac.uk/voms/applications.ngs.ac.uk to see what we think you can do.

Membership information within the applications.ngs.ac.uk VO has so far been managed by pointing and clicking and fiddling in the VO web interface. This is slow and error prone - especially for those of us who still prefer to communicate with computers by typing.

Now - thanks to the efforts of the NGS staff at Manchester - we can update the groups automatically from tags associated with entries in our User Account Service. - the definitive database of who is, and was, an NGS account holder.

For example, all NGS users who we know have signed the academic license for Castep will have the tag application-castep assigned to them. When we turn automatic updating on - hopefully on Monday 5 July - any user with this tag will be granted membership of the Castep group.

If you are an NGS user with a license for one of these applications please let the helpdesk know.