Hi Yves,
>>The idea is that you potentially asked for special privileges (e.g. sgm
>>or prd), so the service must not silently map you to an ordinary account.
>>
>>Instead it must signal that your primary FQAN is not supported (usually
>>this means the service has not been configured correctly).
>
>
> I do not get an error message that something went wrong with the
> mapping.
But you wrote this:
> - voms-proxy --voms desy:/desy/test
> and /desy/test not configured at the CE (I am however a member of that
> group in the DESY voms server.)
> -> VOMS mapping ignored, instead etc/grid-security/grid-mapfile applied
In /var/log/globus-gatekeeper.log you will see an error logged when LCMAPS
tried to honor your VOMS proxy. When that failed, it fell back on trying
the standard grid-mapfile (because it is configured to do so).
>>So, to allow for "/desy/test" you either need to have explicit patterns
>>for that, or you can define a wildcard as you did.
>
>
> OK, if I introduce a wildcard, the roles (sgm or prd) are ignored. Could
> that be a bug, or did I misconfigure anything?
That is not a bug. A wildcard should be put after the cases for which you
want to define explicit mappings.
> It should be possible to have a correct mapping without specifying all
> groups from within a VO.
Yes, for example:
--------------------------------------------------------------
"/VO=desy/GROUP=/desy/ROLE=lcgadmin/Capability=NULL" desysm
"/VO=desy/GROUP=/desy/ROLE=lcgadmin" desysm
"/VO=desy/GROUP=/desy/ROLE=production/Capability=NULL" desypr
"/VO=desy/GROUP=/desy/ROLE=production" desypr
"/VO=desy/GROUP=/desy/test/Role=NULL/Capability=NULL" desytest
"/VO=desy/GROUP=/desy/test" desytest
"/VO=desy/GROUP=/desy/*" .desy
"/VO=desy/GROUP=/desy/Role=NULL/Capability=NULL" .desy
"/VO=desy/GROUP=/desy" .desy
--------------------------------------------------------------
|