On Mon, 23 Apr 2007, Maarten Litmaath wrote:
> Alexander Piavka wrote:
>
> > but who should be responible for running 'dpns-entergrpmap --group "$VO/Role=lcgadmin"'
> > YAIM or the group is auto created then sgm user tries to access the dpm,
> > (and this is why only atlas/Role=lcgadmin & ops/Role=lcgadmin were created)?
>
> Exactly: the virtual UIDs and GIDs are created automatically.
>
> The problem is that DPM < 1.6.4 only takes the first FQAN of
> the VOMS proxy into account: if it is something other than the VO,
> explicit ACLs must be present to enable access.
How do i know to which FQAN in my proxy will be considered first?
is it the first attribute: printed in the VO extension information
by voms-proxy-info --all ?
#voms-proxy-info --all | grep attribute
attribute : /dteam/Role=NULL/Capability=NULL
attribute : /dteam/see/Role=NULL/Capability=NULL
attribute : /dteam/see/IL/Role=NULL/Capability=NULL
>
> > Also yesterday i've upgraded to yaim-3.0.1-x
> > and added new VOs to the site
> > and there were errors ,at most of the node types, during configuration like:
> > group atlasprd,atlas does not exists
> > *althought i have wiped out all the existing vo accounts on all nodes
> > before configuration from /etc/group /etc/gshadow /etc/passwd /etc/shadow and /home/*)
> > these errors were present only for the new VOs i've added.
> >
> > The users.conf has enties like:
> > 43001:atlassgm001:43001,43000:atlassgm,atlas:atlas:sgm:
> > 43002:atlassgm002:43001,43000:atlassgm,atlas:atlas:sgm:
> > 43003:atlassgm003:43001,43000:atlassgm,atlas:atlas:sgm:
> > 43004:atlasprd001:43004,43000:atlasprd,atlas:atlas:prd:
> > 43005:atlasprd002:43004,43000:atlasprd,atlas:atlas:prd:
> > 43006:atlasprd003:43004,43000:atlasprd,atlas:atlas:prd:
> > 43007:atlas001:43000:atlas:atlas::
> > ...
> >
> > The unix group were correctly defined
> > atlas:x:43000:atlas001,atlas002,atlas003,atlas004,...,atlasprd001,atlasprd002,atlasprd003,atlassgm001,atlassgm002,atlassgm003
> > atlasprd:x:43004:
> > atlassgm:x:43001:
> >
> > but at least on gCE the groupmapfile has different entries for old and new VOs
> > ----------------------------------
> > old vo
> > # fgrep dteam groupmapfile
> > "/dteam/Role=lcgadmin/Capability=NULL" dteamsgm
> > "/dteam/Role=lcgadmin" dteamsgm
> > "/dteam/Role=production/Capability=NULL" dteamprd
> > "/dteam/Role=production" dteamprd
> > "/dteam/Role=NULL/Capability=NULL" dteam
> > "/dteam" dteam
> > /dteam dteam
> > /dteam/* dteam
> >
> > new vo
> > # fgrep atlas groupmapfile
> > "/atlas/Role=lcgadmin/Capability=NULL" atlassgm
> > "/atlas/Role=lcgadmin" atlassgm
> > "/atlas/Role=production/Capability=NULL" atlasprd
> > "/atlas/Role=production" atlasprd
> > "/atlas/Role=NULL/Capability=NULL" atlas
> > "/atlas" atlas
> > /atlas atlassgm,atlas
> > /atlas/* atlassgm,atlas
> > ----------------------------------
> >
> > and it looks like the
> > /atlas atlassgm,atlas
> > /atlas/* atlassgm,atlas
> > are not correct, and were created probably since yaim does not split the
> > group field :atlassgm,atlas: from entries like
> > 43001:atlassgm001:43001,43000:atlassgm,atlas:atlas:sgm:
> > 40001:dteamsgm001:40001,40000:dteamsgm,dteam:dteam:sgm:
> > and thus the error messages like:
> > group atlasprd,atlas does not exists
> > during configuration
>
> Do you happen to have functions defined in the "local" subdirectory
> that override what yaim-3.0.1 provides?
>
only apel functions , and couple of others fixing some unrelated bugs,
which i diff each time yaim is upgraded. So this is not the problem.
I can try to see that yaim code actually does, if i find some time.
ps. what is the difference between
"/dteam" dteam
and
/dteam dteam
in groupmapfile?
Thanks
Alex
|