[log in to unmask]" type="cite">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