Hi Tina, Am 31.03.2014 um 17:08 schrieb Tina Friedrich:
> On 31/03/14 15:05, Reuti wrote: >> 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. > > In my case - or for what I currently try to do - this would never be a > problem. There is no restriction in terms of nodes to submit to; there's only > a 'high priority' queue and a 'low priority' queue (high priority can suspend > low priority), and what I want is that only people in either group "staff", > or a number of different groups all called "*_valid_users", can submit to the > high priority queue. The "*_valid_users" groups potentially change every 20 > minutes. > > Basically, I'm trying to enforce that only users with current experiments or > staff have rights to force their job to suspend other queues (but these > groups need to have 'run now' rights on the cluster, 'put on top of queue' is > not sufficient.) Couldn't you skip the creation of secondary groups and use SGE's ACLs as the main ones? Or do you need the information somewhere else outside of SGE too? -- Reuti > (Also - currently, people suggest to use 'newgrp' to make another group the > primary prior to submitting to solve this. Same thing would apply, right? ) > >>>> 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. > > Yes, which a JSV does as well. Anyway; JSV or wrapper allow me to not only > reject but change the submit, so that might be the more convenient option > anyway. > > Tina > >> -- 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 >>> >>> >>> >> >> >> > > > -- > 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
