Opened 19 years ago
Last modified 10 years ago
#13 new patch
IZ129: Bidirectional usermapping limits utility
Reported by: | mjagdis | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sge | Version: | current |
Severity: | minor | Keywords: | PC Linux qmaster |
Cc: |
Description
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=129]
Issue #: 129 Platform: PC Reporter: mjagdis (Mike Jagdis) Component: gridengine OS: Linux Subcomponent: qmaster Version: current CC: None defined Status: NEW Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: andreas (andreas) QA Contact: ernst URL: * Summary: Bidirectional usermapping limits utility Status whiteboard: Attachments: Date/filename: Description: Submitted by: Wed Jan 23 16:40:00 -0700 2002: ge2.diff Disable check for duplicate entries in user mapping (text/plain) Mike Jagdis Issue 129 blocks: Votes for issue 129: Opened: Wed Jan 23 16:39:00 -0700 2002 ------------------------ I have many users (user1...usern) on the submit hosts and just one user (execuser) on the exec hosts (hey, I don't get to admin these boxes :-( ). So, umaps are the answer. Or should be. If I create a umap for cluster user user1 with the entry "execuser exec_hosts" (where exec_hosts is a host group consisting of all the exec hosts) this is fine. But when I try and add a similar entry for another user I get an error telling me that the second entry creates a ambiguous/duplicate mapping. Looking at the code this is because the *reverse* mapping for execuser is ambiguous. The same also happens if I create a umap for cluster user execuser and try and list more than one submit user under it. The problem seems to be that the same umaps are used in *both* directions. It seems to me that they need to include a flag to indicate whether the mapping should be applied as incoming or outgoing - they can't be both unless you have one-to-one mapping throughout. Anyway, I temporarily fixed my problem (first case - cluster users are real submit users, mapping is on outgoing) by commenting out the check for ambiguous/duplicate mappings during the umap load. Looking at the actual usage it appears that if an incoming user can be mapped to more than one name then all possible mappings are simply ignored - which is fine by me. But this is not the right fix - it just works for me. ------- Additional comments from Mike Jagdis Wed Jan 23 16:40:35 -0700 2002 ------- Created an attachment (id=3) Disable check for duplicate entries in user mapping ------- Additional comments from crei Tue Jan 29 09:33:38 -0700 2002 ------- Mike, thanks for your advice. The incoming/outgoing solution seems to be ok, but I have to work in into usermapping again ... Is the implementation of a new aimk option, e.g. aimk -umap-nodupmapcheck to disable the check for duplicate incoming mapping ok for you ? ------- Additional comments from Mike Jagdis Tue Jan 29 15:57:13 -0700 2002 ------- Yes, that's what I did with "#if 0" and it's working fine. Mind you, it occurs to me that if a cluster user is mapped to a user on the exec host then it would be nice if the executing job could do a qsub and have the job queued as the original cluster user rather than the exec host user. But that's just icing and not worth delaying beta2 over :-) ------- Additional comments from crei Mon Feb 4 03:42:00 -0700 2002 ------- The compiler definition NO_USER_MAPPING_AMBIGUOUS_IN_CHECK will now disable the mapping check for incoming mapping requests. (like suggested). Please call aimk in the following way: aimk -DNO_USER_MAPPING_AMBIGUOUS_IN_CHECK The issue will stay open in order to remind on the still not enhanced bidirectional usermapping feature. ------- Additional comments from andy Mon Feb 18 05:46:33 -0700 2002 ------- Changing this Issue to an "Enhancement" request, because it's not a bug of the current implementation. The current usermapping feature is not a part of the standard build procecure of the Grid Engine project and needs to be regarded as a work in progress. ------- Additional comments from sgrell Mon Dec 12 03:12:38 -0700 2005 ------- Changed subcomponent. Stephan
Attachments (1)
Change History (2)
Changed 10 years ago by dlove
comment:1 Changed 10 years ago by dlove
- Severity set to minor
- Type changed from enhancement to patch
Note: See
TracTickets for help on using
tickets.