Hi,
> Hi Antonio,
>
> [...]
>
>>> Solution was removing "/" from groups.conf:
>>> "supernemo.vo.eu-egee.org"::::
>> Did you check if this has an effect in authorization with
>> lcas/lcmaps? How do the resulting mapfiles look?
> nop, I didn't. We only knew about original problem, nothing else. But's
> it's easy to test.
>
> [...]
>
>>> 1.-) from /opt/glite/yaim/examples/groups.conf.README this syntax is
>>> not mentioned:
>>> Examples:
>>>
>>> "/my-VO/ROLE=lcgadmin":::sgm:
>>> "/my-VO/ROLE=production":::prd:
>>> "/my-VO/foobar/ROLE=admin":::foobar_admin:
>>> "/my-VO/foobar/*":::foobar_group:
>>> "/my-VO/foobar":::foobar_group:
>>> "/my-VO/*"::::
>>> "/my-VO"::::
>> I would argue groups.conf should remain as it was, and either the
>> yaim function to generate lcg-info-dynamic-scheduler.conf should be
>> patched or lcg-info-dynamic-scheduler should understand the leading
>> slash (I'd vote for this).
> Yes, probably groups.conf is fine and scripts that depen on them should
> be revised. But maybe changing groups.conf is easier. It's only my
> opinion
If it doesn't break lcmaps...
Also I think that if all lines are preceding by a slash, but one, some
sites will eventually get misconfigured because they will add the slash...
>
>>> 2.-) "/supernemo.vo.eu-egee.org/*"::::
>>> should match whatever ROLE not previously mentioned. If this is not
>>> true, and after seeing many warning about wildcards, isn't better to
>>> remove "*" syntax in yaim?
>> The '*' syntax is used in authorization also (not only in gip). As I
>> understand it, if you remove the '*' and a user of a supported VO
>> comes with a role that is not explicitely listed in your mapfile (and
>> so groups.conf), then he would not be authorized. (but I might be
>> wrong...)
> Yes, I understand it as you, but if wildcards
> cause problems or unknow behaves, why support them?
Well, I'm not totally aware of what problems widcards cause nowadays,
but you may not desire to explicitely mention all roles and groups of
big VOs, especially when they are added frequently...
Although I think you can get the '*' behaviour with an unprivileged
grid-mapfile as fall-back for VOMS authorization failures, but I don't
know if you need to tune your lcmaps policy for that (also there are
sites which don't like to support non-voms proxies and so couldn't use
this).
Cheers,
Antonio
>> Cheers,
>> Antonio
> Cheers,
> Arnau
|