LHC Computer Grid - Rollout [mailto:[log in to unmask]] said:
> I though both files where somehow related (some kind of check which
> sees if enabled group is at groups.conf too). For that reason I
> was modifying both files for the test.
They are certainly related, in rather complicated ways as this discussion is showing! But still there are two different things going on, one is about which VOs/groups/roles have access to the CE, i.e. can submit jobs, and the other about which unix groups they get mapped to when they run. Jeff's code has to be able to connect them together because it queries the batch system info by unix group, but it has to publish it by VO and/or FQAN. The simple default is just to have unix group = VO name and then everything is easy, but that is often not enough.
> Does it mean that adding, i.e, 'atlas' will 'allow' all (defined and
> not defined) ROLES?
It seems this is more complicated than I thought; as far as the information publishing goes VO:atlas means the whole of atlas, whatever groups or roles are defined, but if it's also used to configure the batch system then it needs to know about everything which has its own unix group.
> But I don't know what would happen if I reconfigure our site without
> that option enabled.
As far as I know most sites don't use it, these seem to be the only CEs publishing DENY rules:
ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=grid '(&(objectclass=gluevoview)(GlueCEAccessControlBaseRule=*DENY*))' | grep GlueChunkKey: | cut -d= -f2 | cut -d: -f1 | sort | uniq
atlasce01.na.infn.it
atlasce-cream.na.infn.it
cccreamceli07.in2p3.fr
cccreamceli08.in2p3.fr
cccreamceli09.in2p3.fr
cccreamceli10.in2p3.fr
ce2.ui.savba.sk
ce3.ui.savba.sk
ce4.ui.savba.sk
creamce01.ciemat.es
creamce02.ciemat.es
cream.grid.tuke.sk
dangus.itpa.lt
egeece01.ifca.es
egeece02.ifca.es
egeece03.ifca.es
grid4.mif.vu.lt
gridce01.ifca.es
gridce02.ifca.es
ifaece02.pic.es
ifaece03.pic.es
mw05.ecdf.ed.ac.uk
Stephen
|