Hi Gonçalo,
> > I've been trying to help a site admin to set up some correct mappings
> > for several groups VO. However, this doesn't seem possible. Basically,
> > the site admins started with:
> >
> > 1) groups.conf:
> >
> > "/VO=vo.up.pt/GROUP=/vo.up.pt":uporto:10000::
> > "/VO=vo.up.pt/GROUP=/vo.up.pt/feup":uportofe:10001::
> > "/VO=vo.up.pt/GROUP=/vo.up.pt/fcup":uportofc:10002::
> > "/VO=vo.up.pt/GROUP=/vo.up.pt/training":uportotr:10003::
>
> Note that all of the above are mapped to the common pool accounts,
> since the flag field is empty! This is a valid use case. See below.
>
> > "/VO=vo.up.pt/GROUP=/vo.up.pt/ROLE=VO-Admin":uportosgm:10020:sgm:
> > "/VO=vo.up.pt/GROUP=/vo.up.pt/ROLE=production":uportoprd:10019:prd:
> >
> > 2) users.conf:
> >
> > 10001:uporto001:10000:uporto:vo.up.pt:uprt:
> > 10002:uporto002:10000:uporto:vo.up.pt:uprt:
> > (...)
> > 10051:uportofe001:10001:uportofe:vo.up.pt:upfe:
> > 10052:uportofe002:10001:uportofe:vo.up.pt:upfe:
> > (...)
> > 10151:uportotr001:10003:uportotr:vo.up.pt:uptr:
> > 10152:uportotr002:10003:uportotr:vo.up.pt:uptr:
> > (...)
> > 10999:uportosgm:10020:uportosgm:vo.up.pt:sgm:
> > 10998:uportoprd:10019:uportoprd:vo.up.pt:prd:
> >
> > which seems as a completely coherent configuration according to the
> > docs. However, after running yaim to configure the node, they would end
> > with a /etc/grid-security/voms-grid.mapfile as:
> >
> > "/vo.up.pt/Role=NULL/Capability=NULL" .uportotr
> > "/vo.up.pt" .uportotr
> > "/vo.up.pt/feup/Role=NULL/Capability=NULL" .uportoftr
> | ^
> | typo?
>
> > "/vo.up.pt/feup" .uportotr
> > "/vo.up.pt/fcup/Role=NULL/Capability=NULL" .uportotr
> > "/vo.up.pt/fcup" .uportotr
> > "/vo.up.pt/training/Role=NULL/Capability=NULL" .uportotr
> > "/vo.up.pt/training" .uportotr
> > "/vo.up.pt/Role=VO-Admin/Capability=NULL" uportosgm
> > "/vo.up.pt/Role=VO-Admin" uportosgm
> > "/vo.up.pt/Role=production/Capability=NULL" uportoprd
> > "/vo.up.pt/Role=production" uportoprd
> >
> > It seems the guilty function is config_vomsmap which is not able to
> > recognize the different groups and just picks the last one (uportotr).
>
> No, the behavior is correct. As noted above, the 4 groups are all
> mapped to ordinary pool accounts, because that is what was "asked"!
Well, there is a misfeature: to determine the prefix of the common accounts
it looks for the most "popular" prefix of accounts without flags.
In this case it ended up with the prefix for the last group.
But even if the algorithm were changed, it still would not do what you want.
You already found the correct solution instead.
|