[GE users] Mapping of usernames that differ between submit and exec hosts?
ben at salilab.org
Tue May 26 18:28:35 BST 2009
>> I want to set up a submit host for an SGE (6.1) cluster, but have run
>> into a problem: although each user has the same UID on the cluster and
>> on our submit host, some users have different names on the two systems
>> (e.g. user foo with uid 11000 on the submit host corresponds to user
>> on the cluster with uid 11000). Is there any way in SGE to alias or
> User mapping worked in 5.3, but AFAIK never got working again in 6.x,
> but I haven't tried if for several years now:
Thanks for the reference! But if I understand that correctly, the
mapping is done by the qmaster process. I don't think that would work in
our case, since we use CSP. So whenever we run qsub, qstat etc. on the
submit host, it tries to read a client certificate from
/var/sgeCA/sge_qmaster/$SGE_CELL/userkeys/foo/ but really it should be
trying to read from the bar directory. So doesn't the submit host also
need to know about the user mapping? (I could just rename the foo
directory to bar, but then we get GDI errors.)
Would it be sufficient to install modified qsub, qstat, qhost binaries
on the submit host that do the user mapping? Presumably all of them at
some point call getpwuid(3) or similar to map the calling user ID to a
user name, and all we have to do is use a mapping file on the submit
host to return the user name as known to SGE instead. This would also be
preferable for us since the qmaster is not under our control (below).
Are there obvious problems with this approach?
As for the usernames being different in the first place but the UIDs
being the same, that is easy to explain. The SGE setup is a shared
facility, not under our control. Our own systems and the shared facility
live in different Kerberos realms, so it is entirely possible that a
user with accounts in both realms has different usernames - and of
course it would be foolish for us to trust or burden the shared facility
with account management on our systems (many of our users do not use or
require access to SGE anyway). But it is comparatively straightforward
to reserve a UID range for our use, so that our storage can be mounted
on the cluster and our systems can submit jobs to that cluster.
ben at salilab.org http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle
To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
More information about the gridengine-users