SYNOPSIS
lcmaps_voms_poolaccount.mod [-gridmapfile|-GRIDMAPFILE|-gridmap|-GRIDMAP <location gridmapfile>] [-gridmapdir|-GRIDMAPDIR <location gridmapdir>] [-do_not_use_secondary_gids] [-do_not_require_primary_gid]
This poolaccount acquisition plugin is a 'VOMS-aware' modification of the 'poolaccount' plugin. The plugin tries to find a poolaccount (more specifically a UID) based on the VOMS information that has been retrieved by the plugin lcmaps_voms.mod from the user's grid credential. It will try to match a VO-GROUP-ROLE combination from the user's grid credential with an entry in a gridmapfile (most likely the traditional gridmapfile, used by the localaccount and poolaccount plugins) In this file VO-GROUP-ROLE combinations are listed with a poolaccount entry, as shown in the following example.
EXAMPLE:
"/VO=wilma/GROUP=*" .wilma
"/VO=fred/GROUP=*" .fred
If the first matching VO-GROUP-ROLE combination is "/VO=wilma/GROUP=*" the plugin will get a poolaccount from the '.test' pool. This could result in 'wilma001' as a poolaccount for this user. The linking between "/VO=wilma/GROUP=*", this user and a poolaccount must be made in the same directory as the for the 'poolaccount' plugin (the gridmapdir), otherwise it gives rise to inconsistancies when both are used on a site. The actual account assigned to the user is based on his VO information matched in the gridmapfile, the user's DN and the primary (and secondary) GIDs gathered so far. In the gridmapdir directory this is reflected in the leasename, which consists of the url-encoded DN + a concatenation of the gathered groupnames. So a lease name could look like this:
EXAMPLE DN with pool/localgroups attached: %2fo%3ddutchgrid%2fo%3dusers%2fo%3dnikhef%2fcn%3dmartijn%20steenbakkers%3apool001%3abogus1%3abogus2%3abogus3%3apool003%3apool004%3apool005
If a user changes his VO-GROUP-ROLE combinations (but not his VO), in this case he will be mapped to a different account (UID) within the same pool.
NOTE 1
This plugin should only be used in combination with the 'voms_localgroup' and/or 'voms_poolgroup' plugins.
NOTE 2
The options '-do_not_require_primary_gid' and '-do_not_use_secondary_gids' can not be used together, because at least one GID is needed.
OPTIONS
-GRIDMAPFILE <gridmapfile>
See -gridmap
-gridmapfile <gridmapfile>
See -gridmap
-GRIDMAP <gridmapfile>
See -gridmap
-gridmap <gridmapfile>
When this option is set it will override the default path to the gridmapfile. It is advised to use an absolute path to the gridmapfile to avoid usage of the wrong file(path).
-GRIDMAPDIR <gridmapdir>
See -gridmapdir
-gridmapdir <gridmapdir>
If this option is set, it will override the default path to the gridmapdir. It is advised to use an absolute path to the gridmapdir to avoid usage of the wrong path.
-do_not_use_secondary_gids
The determination of the poolaccount will not be based on the secondary GIDs found, but only on the user's DN, the VOMS info for the user and the primary GID that has been found. Cannot be used with -do_not_require_primary_gid.
-do_not_require_primary_gid
The determination of the poolaccount will not be based on the primary GID found, but only on the user's DN, the VOMS info for the user and the secondary GIDs found. Normally this option should not be used, but it can be useful for debugging. Cannot be used with -do_not_use_secondary_gids.
-OVERRIDE_INCONSISTENCY
See -override_inconsistency
-override_inconsistency
Moving a user from one pool to another (because of a VO change) should only be done by changing the gridmapfile indicating the new pool for this user. If a user has already been mapped previously to a poolaccount, there is a link present between this poolaccount and his DN. In the good old days prior to LCMAPS, a 'pool change' would still result in a mapping to the old pool account, neglecting the administrative changes in the gridmapfile. LCMAPS corrects this behaviour: By default the voms_poolaccount plugin will fail if the pool designated by the gridmapfile doesn't match the previously mapped voms_poolaccount leasename. If the site doesn't want a failure on this inconsistency it can turn on this parameter. When the inconsistency is detected the plugin will automatically unlink the previous mapping and will proceed by making a new lease from the new pool.
SEE ALSO
lcmaps_voms.mod, lcmaps_voms_localgroup.mod, lcmaps_voms_poolgroup.mod, lcmaps_localaccount.mod, lcmaps_poolaccount.mod, lcmaps_posix_enf.mod, lcmaps_ldap_enf.mod,
1.2.8.1 written by Dimitri van Heesch,
© 1997-2001