IZ129: Bidirectional usermapping limits utility

[mjagdis]

[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