Last modified: Tue Mar 3 14:34:42 GMT 2009

Under construction!

This section deals with the setting up, management and responsibilities of a VO (Virtual Organisation)

VO structure - roles and responsibilities

Member Roles
Member roles are what are actually in voms-proxy extended attributes (e.g. minos.vo.gridpp.ac.uk:/Role=lcgadmin). These roles are used to map to a user account with special privileges on the cluster you're running jobs on for example minosoft can install software.

Members can have none, 1 or more roles. Without roles they can just run jobs. Members with roles decide, when they run vomos-proxy-init which, if any, role they want their proxy to assume; a proxy cannot assume multiple roles. To switch roles they have to delete their old proxy with voms-proxy-destroy and create another.

The roles in the MINOS VO are:-

lcgadmin They install code on SE (Storage Element)
production They run production jobs
VO-Admin They manage the VO and deal with all security issues.

The assigned role is specified when creating the proxy e.g.:-

  voms-proxy-init -voms minos.vo.gridpp.ac.uk:/Role=lcgadmin

Establishing a VO

See @ New VO deployment
Request set-up with Alessandra.Forti@manchester.ac.uk,Serguei.Dolgobrodov@manchester.ac.uk,J.Coles@rl.ac.uk

Register the VO in compliance with current EGEE policy that requires VOs to be registered and approved. The complete information will become the main reference source for VO information (including VO manager, end-points, requirements etc.). See VO EGEE registration.

The process is slow and involves a number of people from then on. For now just look at Progress

Account Management

The basic tool is voms-admin with a CLI e.g.

  voms-admin --help-commands
  voms-admin --vo minos.vo.gridpp.ac.uk list-users --host voms01.gpp.hep.man.ac.uk

and a web interface https://voms.gridpp.ac.uk:8443/voms/minos.vo.gridpp.ac.uk

Useful files are for old middleware:-

  $EDG_LOCATION/etc/edg_wl_ui_cmd_var.conf
  $EDG_LOCATION/etc/minos.vo.gridpp.ac.uk/edg_wl_ui.conf

and new middleware:-

  $GLITE_WMS_CLIENT_CONFIG environment variable;
  $HOME/.glite/<vo>/glite_wms.conf, where <vo> is the user's VO name in lowercase;
  $GLITE_LOCATION/etc/<vo>/glite_wms.conf;
  $GLITE_LOCATION/etc/glite_wms.conf.

Useful info about :-

EGEE VO administrationt: Instruction for VO administrators
VOMS and proxies: VOMS Core Services

The basic tasks of a VO manager are:-

Register/unregister users. To register a user need e.g.:-
```
  DN:      "/C=UK/O=eScience/OU=Oxford/L=OeSC/CN=nick west"
  CA:      "/C=UK/O=eScienceCA/OU=Authority/CN=CA".
  CA URI:  Sergey: can leave this blank
           [If filled I think it should be
             http://ca.grid-support.ac.uk/pub/crl/escience-ca-crl.crl 
             (see X509v3 CRL Distribution Points	from openssl x509 -text -in usercert.pem)]
  CN:      nick west 
  Email.   n.west1@physics.ox.ac.uk
```
Mostly user registrations come in as requests that simply have to be accepted but the above is handy if the request shows as "Incomplete" which means that the email address confirmation for this request is not complete yet. A notification email has been sent to user to confirm his/her email address. but no reply received. If this situation arose due to a mailer problem at the user site then registering by hand allows the user access without having fix it.
Create or delete roles and groups/subgroups and assign users to them.
Ask all users to follow Grid Acceptable Use Policy
Inform CE managers of VOMS changes. For example when the current server certificate is updated as the old one is expiring.
Ensure the VO information recorded centrally at http://cic.gridops.org/ is up to date.
See VO EGEE registration.
Every 3 months reply to request for NA4 quarterly report giving number of "affected people" i.e. people who benefit from results of GRID computing. I currently set this at 10, but once the MC production is running on the GRID I'll have to estimate how must of the collaboration it benefits.
Ensure the RAL are kept informed of our short term (few weeks/months) CASTOR plans and problems
There is a wiki where this can be recorded.

Ensure the VO information recorded centrally at

http://www.gridpp.ac.uk/wiki/GridPP_approved_VOs

and the UB contact list at

https://www.gridpp.ac.uk/eb/MailList.html

are up to date.

Get notifications about service disruptions. To do this:-
1. Register with GOC (Grid Operations Centre) at https://goc.gridops.org/
2. Request notification of disruptions at CIC (Core Infrastructure centre) https://cic.gridops.org/index.php?section=rc&page=SDnotification
  See also Downtime Procedure: How can I be notified?
Comply with Virtual Organisation Operations Policy (Oct 2007: I don't understand items 2,3,6 - they look like they are covered by our VOMS so I have mailed David Kelsey).

Account Mapping

This section is just for information.

When a job that has been submitted to the GRID is allocated to a WN the associated proxy is used to mapped to a valid account on the machine. This mapping is configurable (by CE and SE managers) and takes account of the role that was selected when the proxy was created.

For the EGEE GRIS the configuration lines are:-

[Caution: this needs to be update to minos.vo.gridpp.ac.uk ]

# Map VO members (Role) minossgm
group vomss://voms.gridpp.ac.uk:8443/voms/minos?/minos/Role=lcgadmin minossgm

# Map VO members  (root Group) minos
group vomss://voms.gridpp.ac.uk:8443/voms/minos?/minos .minos

The first entry means that for a proxy assuming the lcgadmin role, the account is 'minossgm'. For proxies without roles the "account" is '.minos'. This is called a "pool account" and actually consists of a sequence of accounts minos01, minos02, ...minosnn. In our case nn = 20, but I bet that's configurable too. Once all the accounts have been allocated to proxies, new requests are satisfied by recycling the one that has been idle the longest. It does mean that you cannot guarantee that you will always get to be the same user. Ownership of local files won't be an issue; files on WNs don't persist after the job, but what about files written to an SE?

The above scheme is being revised so that roles also map to pool accounts but it's a separate pool with different privileges. This is to deal with a security/auditability issue that if two people were to submit jobs with the lcgadmin role they would be running as the same user and if they ran on the same host it would be very hard for to track who did what.

Group Account

Management of the VO, or of the production software (but not production work itself) may require interactive access to RAL Tier 1. Where a permitted user does not have, or prefers not to use, a personal account they may request to have their public SSH key be placed in the minosmc account subject to the following conditions:-

They have a legitimate need i.e. are either a VO or Production Manager.
They are not given the password (only known to the primary VO manager i.e. Nick West at the time of this writing).
They supply and maintain good contact information (email address and phone number) to the primary VO manager.
The primary VO manager is the contact point for all security incidents.
There is a maximum of 4 public keys (2 VO manager and 2 production managers) at any one time.

These rules were approved in March 2009 by Glenn Patrick, Jonathan Wheeler and Matt Hodges.

Security

To be supplied

Security is a very important issue for the GRID and the first duty of a VO manager is to ensure that all users agree to and abide by the Grid Acceptable Use Policy.

The FNAL VO

Fermilab has a VOMS and provide support for a number of experiments under the umbrella VO "fermilab". For MINOS, the VO name is:-

  /fermilab/minos

CEs that support VO also claim to support "minos" as well. For a while in 2006/7 we in the UK attempted to move our VOMS over to FNAL to avoid conflicts but eventually abandoned the attempt dues to problems with the LCG middleware:-

RBs will extract fermilab as the VO not fermilab/minos/ukminos so would be degenerate with all other Fermilab VOs.

Derek: "The LCG Resource Broker isn't VOMS aware so it can only use the vo and not the voms part, so it tries to match against resources for "fermilab". The new GLite WMS can match using voms (but would also match with the vo) but that hasn't yet been certified for production use."

The YAIM tools don't support structured VO names i.e. names with embedded slashes.

Derek: "The problem with the YAIM installation tools was that while trying to determine pool accounts it would fail if it the it couldn't find a match for "/VO=X/GROUP=/X" which we didn't have as we didn't want to support the fermilab "vo", plus other than a hardcoded special case which we have need to duplicate and maintain, the tools expected the "special users" - for software installation or production to be of the form "/VO=X/GROUP=/X/Y" or "/VO=X/GROUP=/X/Role=Z"

Experiment names are used as directory names so fermilab/minos/ukminos would create a directory tree.

In June 2007 we changed our VO name to

  minos.vo.gridpp.ac.uk

The remainder of this section contains notes collected when we still thought the move was possible, just in case there ever come in handy.

VO structure - roles and responsibilities

There are two types of roles:-

VO Admin Roles
These roles relate to management of the VO itself. There are the following roles (for more detail see https://voms.fnal.gov:8443/vomrs/vo-fermilab/vomrs,click on the "Manage VO Admin Roles" and click on "Show Help")

Member
Is a member of a group. For us there are 3 possible groups:-

  /fermilab/minos
  /fermilab/minos/ukminos
  /fermilab/minos/usminos

VO Representative
Approves or denies people who want to join the VO. Typically, there is a VO representative for each institution.
Group Manager
Manages the VO: adding and removing people and assigning them member roles.
Group Owner
Can create subgroups and can assign Group Owners and Group Managers to them. Is automaticall a Group Manager of the oned group.

Member Roles
Member roles are what are actually in voms-proxy extended attributes (e.g., /minos/ukminos/Role=minosoft). These roles are used to map to a user account with special privileges on the cluster you're running jobs on for example minosoft can install software.

Members can have none, 1 or more roles. Without roles they can just run jobs. Members with roles decide, when they run vomos-proxy-init which, if any, role they want their proxy to assume; a proxy cannot assume multiple roles. To switch rles they have to delete their old proxy with voms-proxy-destroy and create another.

The roles in the MINOS VO are:-

minossoft They install code on SE (Storage Element)
root Allows you to do root-type things (add/remove users/groups, etc.)
VOMS-Query Allows to query the VOMS server to see who else is in the VO (allows read-only access).

The assigned role is specified when creating the proxy e.g.:-

  voms-proxy-init -voms fermilab:/fermilab/minos/ukminos/Role=minossoft

To list members in the MINOS VO :-
https://voms.fnal.gov:8443/voms/fermilab/webui/admin/users/list?groupname=%2Ffermilab%2Fminos

For management:-
either: https://fermigrid2.fnal.gov:8443/vomrs/vo-fermilab/vomrs
or: https://voms.fnal.gov:8443/vomrs/vo-fermilab/vomrs

From here can manage accounts and subscribe to notification mail.

  
 Group 	                	Group roles 	           
/fermilab/minos 		minossoft, root, VOMS-Query
/fermilab/minos/ukminos 	minossoft, root, VOMS-Query 
/fermilab/minos/usminos 	minossoft, root, VOMS-Query

Useful info about :-

OSG VO administration:VoAdmins

Return to home page

Administration: Group Administration

Contents

VO structure - roles and responsibilities

Establishing a VO

Account Management

Account Mapping

Group Account

Security

The FNAL VO

VO structure - roles and responsibilities