The notions of VO and "Group" in grid terms map to
the X.500 (LDAP) attributes "Organization" (O=value) and "OrganizationalUnit"
(OU=value) respectively.
root |
|||
O=registrar |
O=dteam |
||
OU=users |
OU=rules |
OU=lcg1 |
OU=people |
Setting-up a VO, practically, means configuring LDAP entries
reflecting our Directory Information Tree (DIT). Our LDAP daemon (slapd)
runs today
on host lxshare0251.cern.ch.
DNS aliases lcg-vo.cern.ch (for
the VO=lcg-vo, i.e. O=dteam) and lcg-registrar.cern.ch (for
the VO=lcg-registrar, i.e. O=registrar) are defined for this host as needed
for the 'group' entries in the gridmap
configuration file. These aliases give us the freedom to change (physically)
the server host, without needing to change any VO names.
In particular, the
alias lcg-registrar.cern.ch is
configured (in the apache configuration file) as a web server, in addition,
in order to accept client certificates.
We could, of course, define
these two VOs on separate physical LDAP servers.
The file /etc/openldap/slapd.conf (editable by root only)
This file must also contain the right values for the Distinguished Names
(DN) of all VOs registered on this LDAP server. For the
# Access to the LCG Deployment Team Virtual Organisation (VO-DTEAM) access to dn.subtree="ou=People,o=dteam,dc=lcg,dc=org" filter=(description=subject=*) attrs=description,entry by * read access to dn.subtree="ou=lcg1,o=dteam,dc=lcg,dc=org" by * read access to dn="o=dteam,dc=lcg,dc=org" by dn="cn=Manager,dc=root" write
The "access" lines define the access policy for
the directory entries. It is important to restrict world-readable data to
only that needed by the mkgridmap program, i.e. the one that builds the gridmap
file from a given configuration file.
LDAP database definition lines, in the same file, must also contain the right
values for O=dteam, namely:
suffix "dc=root" suffix "o=dteam,dc=lcg,dc=org" rootdn "cn=Manager,dc=root"
Relevant lines are present in this file for the access to O=registrar, as well, but they are not included here as they are outside the scope of this document. Please note that the Domain Components (DC) dc=lcg,dc=org are common in both VOs.
If/when any editing of this file is needed (must have root privileges) the slapd daemon must be restarted at the end of the editing session, in order to signal these changes to the LDAP server (as one does at the end of apache or sendmail configuration changes, and all such daemons). The relevant command is:
> service ldap restart
The standard output will inform you that the server restarted but you can verify it by checking the logs in /var/log/ldap (must have root privileges for this too). Any lines you may find in there referring to error=97 can be ignored, as they relate to IPv.6 support. Alternatively the server status is displayed with command:
> service ldap status
Another important system directory for the management of the actual VO data is /var/lib/ldap, which contains the actual LDAP database. /var/lib/ldap/backup is a directory that contains all of the LDAP tree dumped (as <vo_name>_YYYYMMDDHHMMSS.gz files, e.g. dteam_20030703095833.gz) by a cron job, which runs 4 times/day. These files are roughly kept for a month, at present, and then get purged automatically every two weeks. Configured to use the SUE purge feature in /usr/sue/lib/purge2.cfg .
. The backup of all files on tape is taken care of by ADSM, set-up by the host's system administrator.
To do this, the file /etc/openldap/bootstrap_dteam.ldif has to be edited. The necessary contents of this file are:
dn: o=dteam,dc=lcg,dc=org description: LCG Deployment Team VO objectclass: top objectclass: organization objectclass: domain dc: dteam o: dteam dn: ou=lcg1,o=dteam,dc=lcg,dc=org description: LCG Deployment Team VO Group objectclass: domain objectclass: organizationalUnit objectclass: groupofnames dc: lcg1 ou: lcg1 cn: lcg1 owner: cn=manager,dc=lcg,dc=org member: cn=Bootstrap user,ou=people,o=dteam,dc=lcg,dc=org dn: ou=people,o=dteam,dc=lcg,dc=org description: All LCG Deployment Team People objectclass: organizationalUnit ou: People
The command to add these entries in the LDAP database from this file is:
> ldapadd -W -x -D "cn=manager, dc=root" -f bootstrap_dteam.ldif
Method 1: Via the LDAP browser:
Adding members to the VO is possible via the LDAP browser/editor,
which can be downloaded from http://www.iit.edu/~gawojar/ldap/ . You
may need to enter the path to java in your environment (if you work in Unix)
in order to start the browser. E.g. lines:
setenv JAVA_HOME /afs/cern.ch/sw/java/i386_redhat73/jdk/sun-1.4.2 setenv PATH /afs/cern.ch/sw/java/i386_redhat73/jdk/sun-1.4.2:$PATH
in your $HOME/.tcshrc (if this is your preferred shell) will make sure that
you can start the ../ldapbrowser/lbe.sh script that launches the browser.
If you
work on Windows you may need to download java-related components
from the Sun site.
The following values are important to configure the connection of your LDAP browser:
Host: lcg-vo.cern.ch Base DN: o=dteam,dc=lcg,dc=org (Select SSL) User DN: cn=manager,dc=root
The VO update procedure is:
Edit --> Add
Attribute --> member.
It is important that the "Description" field contains the value of
the "Certificate
DN" as
it appears
in the email notification of the account creation, e.g:
cn=Maria Dimou,ou=people,o=dteam,dc=lcg,dc=org
Description: Subject=/O=Grid/O=CERN/OU=cern.ch/CN=Maria Dimou
Example taken from a confirmed registered account as sent by email to the VO administrator:
Family Name : Dimou Given Name : Maria Email : Maria.Dimou@cern.ch Institute : CERN Phone Number : +41 22 7673356 Certificate DN : /O=Grid/O=CERN/OU=cern.ch/CN=Maria Dimou Certificate CN : Maria Dimou
Method 2: Using a script for mass-updates:
Entering members in a group should better be done with a script to reduce
the risk of typing errors with individual entries via the LDAP browser/editor.
Saving the email notification of the account creation in a file, as new_member.pem and
then running script:
> cert2ldif.pl -vo dteam new_member.pem > new_member.ldif
should do the necessary to strip the unnecessary email headers and isolate the useful fields needed for the LDAP database update. The command to update the LDAP database in this case is:
> ldapadd -h lcg-vo.cern.ch -W -x -D "cn=Manager,dc=root" -f new_member.ldif
Once O=dteam is defined as a VO, the script group.pl will
populate the OU=lcg1 with 'member' lines.
A 2-column table will appear, where new members will only be present on the left
column, next to a small square box where you should click. This action authorises
the acceptance of this new member in the group lcg1.
Unfortunately, this script doesn't inform you about its successful completion,
so, you will have to run the script again, in order to verify that these members
are properly present on the right column as well, after successful addition in
the 'members' list.
The cert2ldif.pl and group.pl scripts can
be downloaded from http://cvs.infn.it/cgi-bin/cvsweb.cgi/Auth/VO/sbin/
NB!! You will need to edit cert2ldif.pl to substitute dc=eu-datagrid by dc=lcg
!!
NB!! You will need to edit group.pl to substitute dc=testbed1
by dc=lcg, as well as a number of other values as one can see in the 'diff' appended.
A working version of both these scripts are available from the CERN afs username
lcgreg and documented separately.
[lxshare0251] ~/lcg > diff group.pl.orig group.pl 19c19 < # --- > # Changed by Maria Dimou to adapt to o=dteam,dc=lcg,dc=org 2003-07-03 23c23,24 < use Net::LDAP qw(:all); # for all code --- > #use Net::LDAP qw(:all); # for all code > use Net::LDAP; # for all code 30c31,32 < my $BASE = "dc=testbed1,dc=org"; --- > #my $BASE = "dc=testbed1,dc=org"; > my $BASE = "dc=lcg,dc=org"; 38c40,41 < if (!$base ) { $base = "o=infn,c=it"; } --- > # if (!$base ) { $base = "o=infn,c=it"; } > if (!$base ) { $base = "dc=lcg,dc=org"; } 189c192,193 < my $mygroup = "group1"; --- > #my $mygroup = "group1"; > my $mygroup = "lcg1"; 191,192c195,196 < my $vobase = "dc=testbed1,dc=org"; < my $vobind = "cn=manager,dc=testbed1,dc=org"; --- > my $vobase = "o=dteam,dc=lcg,dc=org"; > my $vobind = "cn=manager,dc=root"; [lxshare0251] ~/lcg >
Maria Dimou, IT/GD, Grid Infrastructure Services