Main Page | Modules | Data Structures | File List | Data Fields | Globals | Related Pages

voms poolgroup plugin


lcmaps_voms_poolgroup.mod -GROUPMAPFILE|-groupmapfile|-GROUPMAP|-groupmap <groupmapfile> -GROUPMAPDIR|-groupmapdir <groupmapdir> [-mapall] [-mapmin <group count>]


The poolgroup acquisition plugin is a 'VOMS-aware' plugin. It uses the VOMS information (acquired by the plugin lcmaps_voms.mod) to gather primary and secondary GIDs. This is accomplished by matching VO-GROUP-ROLE(-CAPABILITY) combinations in the so-called groupmapfile (gridmapfile style) and by finding the corresponding 'poolgroup' (similar to the 'poolaccount' procedure, see lcmaps_poolaccount.mod) Wildcards can be used in the groupmapfile to match VO-GROUP-ROLE combinations.

EXAMPLE 'groupmapfile':

"/VO=atlas/GROUP=mcprod" mcprod

"/VO=atlas/GROUP=mcprod" .atlas

"/VO=atlas/GROUP=dev" .atlas

"/VO=atlas/GROUP=*" .atlas

The VO-GROUP-ROLE combination "/VO=atlas/GROUP=mcprod" starts with an alfanumeric character (not ".") and indicates a localgroup entry in the groupmapfile (will be resolved by the lcmaps_voms_localgroup.mod). The VO-GROUP-ROLE combination "/VO=atlas/GROUP=*" indicates that all users from the Atlas VO with every other group than 'mcprod' will be mapped to the '.atlas' pool of (system) groups. Just like the poolaccount plugin this plugin will link an entry (in this case a VO-GROUP-ROLE combination) to a locally known group (a.k.a. poolgroup) in the groupmapdir directory. The difference with the poolaccount plugin is that there is not a Distinghuished Name but a VO-GROUP-ROLE combination and there is no poolaccount but poolgroup defined in de groupmapfile (similar to the gridmapfile). Instead of the gridmapdir the groupmapdir directory is used for the registration of thew mapping between poolgroups and the VO-GROUP-ROLE combination.

As you can see the in the example the 'mcprod' GROUP can be found by using the localgroup plugin and the poolgroup plugin. With the poolgroup plugin there can be made a mapping between "/VO=atlas/GROUP=mcprod" and the group 'atlas001' (based on the .atlas pool). The entry "/VO=atlas/GROUP=dev" will also result in a group from this '.atlas' pool, but a different one, e.g. 'atlas002'. Finally, we have random other groups not predefined in the groupmapfile, for example "/VO=atlas/GROUP=foo", which matches "/VO=atlas/GROUP=*" in the groupmapfile. This VO-GROUP combination will be mapped to a poolgroup (probably) called 'atlas003'.

The poolgroup plugin will try to match each VO-GROUP-ROLE combination that was found by the plugin lcmaps_voms.mod. The first VO-GROUP-ROLE combination will become the primary group, the others secondary groups. As the primary GID may be used for auditing and accounting purposes it is important that the user uses the correct ordering of VO-GROUP-ROLE combinations in his grid credential (X509 certificate).


-GROUPMAPFILE \<groupmapfile\>

See -groupmap

-groupmapfile \<groupmapfile\>

See -groupmap

-GROUPMAP \<groupmapfile\>

See -groupmap

-groupmap \<groupmapfile\>

If this option is set, it will override the default path to the groupmapfile. It is advised to use an absolute path to the groupmapfile to avoid usage of the wrong file(path).

-GROUPMAPDIR \<groupmapdir\>

See -groupmapdir

-groupmapdir \<groupmapdir\>

Here you can override the default directory path to the 'groupmapdir'. This directory is just like the gridmapdir and holds all the poolgroup mappings that has/will be made by linking filenames to a i-node indicating a mapping between a VO-GROUP-ROLE combination and a (system) group or GID.


If this parameter is set, the plugin only succeeds if it manages to map all voms data entries to (system) groups and find their GID. There is no communication between different plugins (like the voms_localgroup plugin) about the failures. A log entry will state the VO-GROUP-ROLE combination that made the plugin fail.


See -override_inconsistency


Moving a VO group from one pool to another should only be done by changing the groupmapfile indicating the new pool for this VO group. If a VO group has already been mapped previously to a poolaccount, there is a link present between this poolgroup and its VO-GROUP-ROLE combination. By default the voms_poolgroup plugin will fail if the pool designated by the gridmapfile doesn't match the previously mapped poolgroup 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.

-mapmin \<group count\>

This option will set a minimum amount of groups that have to be resolved for later mapping. If the minimum is not set then the minimum amount is set to '0' by default. If the plugin is not able to the required number of poolgroups it will fail. Note: if the minimum is set to zero or the minimum is not set the plugin will return a success if no other errors occur, even if no poolgroups were found.



See bugzilla for known errors (


lcmaps_voms.mod, lcmaps_voms_poolaccount.mod, lcmaps_voms_localgroup.mod, lcmaps_localaccount.mod, lcmaps_poolaccount.mod, lcmaps_posix_enf.mod, lcmaps_ldap_enf.mod,
Generated on Sun May 29 21:22:13 2005 for lcmaps by doxygen 1.3.5