Reuti,

> And by using "ACL DEPT" several users were assigned to multiple departments 
> or are they still unambiguously assigned to only one?

All of the users manifesting multiple departments in the aRCO DB and
"accounting" log are all within multiple userset lists which have been
defined as the type "ACL DEPT".  We do not have any userset lists
solely of the type "DEPT".  They are all either "ACL" or "ACL DEPT".

For example, the sanitized user "sge-user" I listed previously was
logged in 3 departments.  I'll paste sanitized output below:

>>>> 9241 sge-user qchem
>>>> 6        sge-user cas.chem.hlw
>>>> 3        sge-user qchem_dev

# qconf -su qchem
name    qchem
type    ACL DEPT
fshare  0
oticket 0
entries user1,user2,user3,user4,user5,user6,user7,user8,user9, \
        user10,user11,sge-user,user12,user13,user14,user15,user16, \
        .... more users....

# qconf -su qchem_dev
name    qchem_dev
type    ACL DEPT
fshare  0
oticket 0
entries user1,user2,user3,sge-user,user4,user5

# qconf -su cas.chem.hlw
name    cas.chem.hlw
type    ACL DEPT
fshare  100
oticket 0
entries user1,user2,user3,user4,user5,user6,user7,sge-user, \
        ... more users... \

John DeSantis

2014-10-16 4:49 GMT-04:00 Reuti <re...@staff.uni-marburg.de>:
> Am 15.10.2014 um 22:01 schrieb John Desantis:
>
>> Reuti,
>>
>>>> These users do belong to several userset lists each with a type
>>>> defined as "ACL DEPT".  From what I've read, users can only belong to
>>>> 1 department but multiple ACL's.
>>>
>>> You refer to this sentence from the man page?
>>
>> I was reading from the SGE N1 admin guide, too.
>>
>> "Departments are used for the configuration of the functional policy
>> and the override
>> policy. Departments differ from access lists in that a user can be a
>> member of only one
>> department, whereas one user can be included in multiple access lists. "
>>
>> Is there anything special one should know (not explained in the
>> documentation) when using the userset list type "ACL DEPT"?
>
> And by using "ACL DEPT" several users were assigned to multiple departments 
> or are they still unambiguously assigned to only one?
>
> -- Reuti
>
>
>> Thanks,
>> John DeSantis
>>
>>
>> 2014-10-15 15:43 GMT-04:00 Reuti <re...@staff.uni-marburg.de>:
>>> Am 15.10.2014 um 20:12 schrieb John Desantis:
>>>
>>>> Looking at our "accounting" file and aRCO DB, we're seeing some users
>>>> with multiple departments listed on completed jobs.  We can also
>>>> confirm this via `qstat -u \* -ext` for said users.
>>>>
>>>> These users do belong to several userset lists each with a type
>>>> defined as "ACL DEPT".  From what I've read, users can only belong to
>>>> 1 department but multiple ACL's.
>>>
>>> You refer to this sentence from the man page?
>>>
>>> When using departments, each user or group enlisted may only be enlisted in 
>>> one department, in order to ensure  a  unique assignment  of  jobs  to  
>>> departments.
>>>
>>> -- Reuti
>>>
>>>> The man page for access_list states
>>>> that "ACL" and "DEPT" can both be used together.
>>>> The only ACL that we're using now is the beloved "xusers" for
>>>> temporary banning, otherwise the user_lists is set to NONE on all
>>>> queues and execution hosts.
>>>>
>>>> Has anyone else with a similar configuration seen this before? Does
>>>> this behavior have anything to do with functional tickets being
>>>> exhausted from a department (qstat -ext did show 'fticket' values !=
>>>> 0)?  I'll paste some sanitized output below.
>>>>
>>>> #jobs #user #department
>>>>
>>>> 9241 sge-user qchem
>>>> 6        sge-user cas.chem.hlw
>>>> 3        sge-user qchem_dev
>>>>
>>>> 3093 sge-user2 cas_chem
>>>> 1        sge-user2 cas.chem.hlw
>>>>
>>>> 47      sge-user3 rogers
>>>> 3         sge-user3 gaussian
>>>>
>>>> Thank you!
>>>> John DeSantis
>>>> _______________________________________________
>>>> users mailing list
>>>> users@gridengine.org
>>>> https://gridengine.org/mailman/listinfo/users
>>>
>
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users

Reply via email to