Am 31.03.2014 um 14:14 schrieb Tina Friedrich: > On 31/03/14 12:47, Reuti wrote: >> Hi, >> >> Am 31.03.2014 um 12:22 schrieb Tina Friedrich: >> >>> just double checking - there still is no way to use anything but a user's >>> primary group for ACLs etc? >>> >>> (Directly use, I mean. Without resorting to duplicating information in SGE >>> setup, or using a JSV, or wrapping qsub, or ...) >> >> yes. This is also the only group being recorded in the accounting file. >> Imagine that all secondary groups would be honored, it could be ambiguous >> regarding accounting for the jobs or even access to a set of nodes which are >> tied to a unix group in case a user has access to more than one. > > Would be nice if I had an easy way to enable them being used, at least for > access lists - I don't actually care about accounting - I can still > post-process > that if I need to - it's restricting access that I'm after.
In case a user has access to a set of nodes by two assigned secondary groups (and hence I assume he submits two different types of jobs at least): the submitted one might end up on a node where it shouldn't, instead only on one machine of the other groups assignment it should run on. Or can this never happen? Maybe I still didn't get your goal. >> Do you request a project during submission all the time to make it unique? > > Yes(ish); there's a default project set for people that don't specify one, > though, so that doesn't really help. Projects wouldn't really help as it's > something users can change - which I don't want. I need a non-modifiable (not > user modifiable anyway) way to restrict access to certain queues. > > Could sync the lists to ACLs via cron is possible (SGE won't mind if I change > an ACL every 15 minutes, right?), I'm not aware that there is any limit in SGE how often you may change any setting. For the (scripted) changes of SGE's main configuration or the scheduler's one there is a `sleep 1` necessary before you save the changed file though. > it just seems so superfluous to duplicate this information (and it, of > course, adds more opportunities for things going wrong). True, but there is no other way. Only the user and his primary group are stored in the job info AFAIK. It would mean to store either all secondary groups (the ones the user had at submission time presumably), or repeatedly requesting this information during scheduling. Although the latter would allow attaching another group to a user (and hence be more in the SGE style where you can request resources which will be available in the future), it would mean to generate a certain overhead. -- Reuti > Might end up being a wrapper or a JSV anyway, as that allows me to modify the > job. > > Tina > >> -- Reuti >> >> >>> Tina >>> >>> -- >>> Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd >>> Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 >>> >>> -- >>> This e-mail and any attachments may contain confidential, copyright and or >>> privileged material, and are for the use of the intended addressee only. If >>> you are not the intended addressee or an authorised recipient of the >>> addressee please notify us of receipt by returning the e-mail and do not >>> use, copy, retain, distribute or disclose the information in or attached to >>> the e-mail. >>> Any opinions expressed within this e-mail are those of the individual and >>> not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. >>> cannot guarantee that this e-mail or any attachments are free from viruses >>> and we cannot accept liability for any damage which you may sustain as a >>> result of software viruses which may be transmitted in or with the message. >>> Diamond Light Source Limited (company no. 4375679). Registered in England >>> and Wales with its registered office at Diamond House, Harwell Science and >>> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom >>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> https://gridengine.org/mailman/listinfo/users >> >> >> > > > -- > Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd > Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot > guarantee that this e-mail or any attachments are free from viruses and we > cannot accept liability for any damage which you may sustain as a result of > software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
