Creating Pool Accounts With LDAP
The LDAP directory structure
The list of valid users of the NDPF is kept in a central LDAP directory, currently hosted on teugel.nikhef.nl. This directory contains both the "local" users as well as all poolaccounts and all automount map entries. The structure of the directory is:
+ dc=farmnet,dc=nikhef,dc=nl | + ou=Managers + ou=LocalGroups (contains all groups!) + ou=LocalUsers + ou=Poolaccounts | + ou=dteam + ou=ops ... + ou=automount | + ou=auto.home + ou=lcgprod | + ou=auto.sedata + ou=auto.share + ou=auto.stage + ou=auto.sedata2
The ou=Poolaccounts entry contains the hierarchy of pool account groups. Per pool account group, there is a separate ou, which contains the actual list of pool accounts. Each account is named by its uid, and is of objectClass "posixAccount". For each account named here, there should be a corresponding entry in the ou=pool,ou=auto.home,ou=automount branch of the tree as well (of objectClass "automount").
Creating accounts for a new VO
To use the scripts, login on the fileserver "hooimijt.nikhef.nl", and make sure that /export/perm/adm/bin is in your path (it contains all the relevant scripts), or go there. Also, make sure you know your LDAP manager password.
You need to:
- add the accounts to the LDAP directory
- create the homedirectories for these users on hooimijt
- add the inodes to the gridmapdir
(and of course add the VO itself to the proper Quattor profiles for the selected facilities, but this is outside the scope of this page).
Note: do not forget to create inodes in the gridmapdir on the DPM and the LFC hosts.
Generating the LDIF
Adding users to the directory needs two commands (or one pipe). The gen_poolacc_ldif script generates ldif files, that need to be piped in to "ldapadd" to be inserted in the directory.
Its use is best explained by an example:
./gen_poolacc_ldif -c --vo atlas -g 2002 -b 43000 -n 200
will spit out lots of ldif, like
dn: uid=atlas000, ou=PoolAccounts, dc=farmnet,dc=nikhef,dc=nl objectclass: top objectclass: posixAccount cn: PoolAccount 0 of atlas uid: atlas000 uidNumber: 43000 gidNumber: 2002 homeDirectory: /home/atlas000 ...
The -c option (for "create") additionally generates the organizationalUnit definitions inside the poolaccounts tree under which the new uids will be created. If you are extending an existing set of poolaccounts, this options must be omitted. But, if you leave it in by accident, the ldapadd command below will trigger an error and terminate without damage being done (and, conversely, omitting -c on initial creation will also trigger an error).
The LDIF output must be added to the directory with the ldapadd command:
ldapadd -H ldaps://teugel.nikhef.nl/ -W -x -D "cn=My Name,ou=managers,dc=farmnet,dc=nikhef,dc=nl"
Valid managers are "David Groep", "Jeff Templon@nikhef.nl", "Ronald Starink", "Sven Gabriel", "Tristan Suerink" and "backup" (the last one can only read, though). The two commands can be combined in a single pipe.
In due course, the new accounts will appear on the farm, and you can check their presence with the "id" and "ls" commands:
id -a atlas000 ls -l /home/atlas000/
There may be a slight delay if the system you are trying this on is running nscd, or is looking at a slave LDAP server (stalkaars-0[13].farm.nikhef.nl, hooimijt instead of teugel).
The number of digits appended to the vo name is three (3) by default, but can be changed with the -l option. And, of course, the "voname" specified here is completely unrelated to the VO name in the information system or used in the GlueAccessControlBaseRules.
Extending an existing poolaccount range
You can also extend an existing range, by specifying a "start" value to gen_poolacc_ldif, but remember: the "base" value must remain the same. So, to generate an additional 100 atlas accounts, the command would be
./gen_poolacc_ldif --vo atlas -g 2002 -b 43000 -n 300 -s 200
to start at 200 and ensure that there are 300 accounts in total.
Generating the home directories
Once the accounts have been added to the directory, you can create the home directories on schuur. This must be done as root, and on schuur itself. The command to use is make_poolacc_dir, which takes one argument: the uid prefix to select on. By default, it will generate a shell script that tries to (re)create the homedirectories for all poolaccounts, so beware.
Note: at the moment, the script make_poolacc_dir is found at schuur in /root/bin.
To generate the home directories for the "phicos" VO, use:
./make_poolacc_dir --uid=phicos > /tmp/schapen sh /tmp/schapen
To so the same for the additional 100 atlas accounts created from "atlas200" to "atlas299", use:
./make_poolacc_dir --uid=atlas2 > /tmp/lam sh /tmp/lam
The current version of make_poolacc_dir ensures that the .ssh directory contains an empty "authorized_keys" file and is immutable ("chattr =i .ssh").
Creating the inodes
Creating the inodes is done with populate_gridmapdir. Run this script as root on hooimijt. The populate_gridmapdir script is even more trivial than the other two: it extracts all uid's from the ou=Poolaccounts,dc=farmnet,dc=nikhef,dc=nl tree and prepends it with "/export/perm/share/gridmapdir":
./populate_gridmapdir
results in
/export/perm/share/gridmapdir/alice000 /export/perm/share/gridmapdir/alice001 /export/perm/share/gridmapdir/alice002 /export/perm/share/gridmapdir/alice003 /export/perm/share/gridmapdir/alice004 ...
To filter out the new ones, use grep, and pipe the results through xargs so as to touch the files:
./populate_gridmapdir | grep atlas2 | xargs touch
will do the job for the 100 additional atlas accounts, for instance.
Repairing an empty gridmapdir
For this you need the backup file that's generated nightly by the poolmaplog script from cron. The file format is simple:
uid subjectDN_in_lowercase ...
btu for use in the gridmapdir the special chars (so painstackingly converted to readable format by poolmaplog) must be concerted back. This is the task of the repair-pool script. As far as I know, these are the special characters:
% / <space> = ( ) - . @
the repair-pool script will translate these to URL-escaped characters (ie. "=" becomes "%3D" -- note that we must thus convert any %-signs first!)
The script will automatically relink the poolaccounts to the proper DN for those accounts that were in use (i.e. has a DN assigned to them). You should only attempt repair if the pooldir is empty!
./repair-pool < /export/perm/share/gridmapdir/.poolmap.20050816
and watch the results.
Migrating the poolaccounts in the LDAP directory
When the poolaccounts are migrated to a new system (schuur.nikhef.nl), the LDAP directory needs to be updated to reflect the new location. To this end, a new script is now available on hooimijt:/export/perm/adm/bin:
./migrate_poolacc_dir_ldap [--uid=uidpattern]
which generates LDIF output with the directory updates. You can apply the LDIF modification with the command
ldapmodify -x -W -D "cn=Your Name,ou=Managers,dc=farmnet,dc=nikhef,dc=nl" -H ldap://trog.nikhef.nl/ -f ldif_file
The default is to expect the poolaccount home to be on
schuur.nikhef.nl:/project/share/pool/prefix/loginname
It will look for appropriately named poolaccounts under ou=pool,ou=auto.home,ou=automount,dc=farmnet,dc=nikhef,dc=nl
PS: also the gen_poolacc_dir script has been changed to use the new poolaccount homedirectory format. The output of this gen_poolacc_dir scfipt is a shell script to be executed on the physical filesystem-hosting node.