Lionel SPINELLI | 26 Jul 2012 17:17
Picon

Managing user password

Hello all,

I am a totally new manager of SGE, trying to configure my first grid. I have read tons of documentation but
there something very basic I don't understand (I think I am missing the basic logic).
Here it is : In the Administration guide, it is written : Assign required logins - Users must have identical
accounts on all hosts that they use within the Grid Engine system. No login is required on the machine where
sge_qmaster runs. For more information, see Configuring User Access.
I understand that, if I want a user called "tommy" submit a job from the submit host A (on which he has an
account named" tommy"), I have to get a user defined in the SGE called "tommy" (having acces to the right
queues) and also accounts called "tommy" on each machine composing my grid.
So I did. and all "tommy" accounts have the same password.
But when I try to submit a job, I got an error telling "error: can't open output file
"/home/tommy/simple.sh.o60": Permission denied

Obviously, if i use the -o and -e option of qsub to put the output and error logs to a shared disk without write
permissions, anything is ok.

So, how can i get my user "tommy" able to submit jobs that need to write temporary files (for instance) on the
account "tommy" ?

Thanks in advance

Lionel
Rayson Ho | 26 Jul 2012 17:27

Re: Managing user password

On Thu, Jul 26, 2012 at 11:17 AM, Lionel SPINELLI
<spinelli@...> wrote:
> But when I try to submit a job, I got an error telling "error: can't open output file
"/home/tommy/simple.sh.o60": Permission denied
>
> Obviously, if i use the -o and -e option of qsub to put the output and error logs to a shared disk without write
permissions, anything is ok.
>
> So, how can i get my user "tommy" able to submit jobs that need to write temporary files (for instance) on the
account "tommy" ?

Looks like tommy has different UID on different machines?

On each machine, run:

% id

and compare the UID...

Rayson

>
> Thanks in advance
>
> Lionel
>
>
> _______________________________________________
> users mailing list
> users@...
(Continue reading)

Reuti | 26 Jul 2012 17:32
Picon

Re: Managing user password

Am 26.07.2012 um 17:17 schrieb Lionel SPINELLI:

> I am a totally new manager of SGE, trying to configure my first grid. I have read tons of documentation but
there something very basic I don't understand (I think I am missing the basic logic).
> Here it is : In the Administration guide, it is written : Assign required logins - Users must have identical
accounts on all hosts that they use within the Grid Engine system. No login is required on the machine where
sge_qmaster runs. For more information, see Configuring User Access.
> I understand that, if I want a user called "tommy" submit a job from the submit host A (on which he has an
account named" tommy"), I have to get a user defined in the SGE called "tommy" (having acces to the right
queues) and also accounts called "tommy" on each machine composing my grid.
> So I did. and all "tommy" accounts have the same password.
> But when I try to submit a job, I got an error telling "error: can't open output file
"/home/tommy/simple.sh.o60": Permission denied
> 
> Obviously, if i use the -o and -e option of qsub to put the output and error logs to a shared disk without write
permissions, anything is ok.

Mmh - is it now shared with or without write permission? "... to a shared disk without write permissions, it
won't work".

-- Reuti

> So, how can i get my user "tommy" able to submit jobs that need to write temporary files (for instance) on the
account "tommy" ?
> 
> Thanks in advance
> 
> Lionel
> 
> 
(Continue reading)

Rayson Ho | 26 Jul 2012 17:37
Picon

Re: Managing user password

On Thu, Jul 26, 2012 at 11:32 AM, Reuti <reuti@...> wrote:
>> But when I try to submit a job, I got an error telling "error: can't open output file
"/home/tommy/simple.sh.o60": Permission denied
>>
>> Obviously, if i use the -o and -e option of qsub to put the output and error logs to a shared disk without
write permissions, anything is ok.
>
> Mmh - is it now shared with or without write permission? "... to a shared disk without write permissions, it
won't work".

I think Lionel means with...

AND BTW, Grid Engine does not need to login as the user with a
password, so you don't need the same password for tommy. Also,
different UIDs for each tommy account should also work, however that
writing to a shared disk works but a local disk fails (or vice versa?)
means that it can be the UID issue...

Rayson

>
> -- Reuti
>
>
>> So, how can i get my user "tommy" able to submit jobs that need to write temporary files (for instance) on
the account "tommy" ?
>>
>> Thanks in advance
>>
>> Lionel
(Continue reading)

Lionel SPINELLI | 26 Jul 2012 17:46
Picon

RE : Managing user password

Hello,

thanks to all for you anwsers.

My sentence was confusing... my shared disk is a NAS on which there is no permission definitions (so
everybody can read/write).
So writing to the NAS is ok. Writting to the local disk fails (I am not surprised since I can't see how sge would
manage passwords since my users are all independantly created because I don't have any NIS or LDAP)...
Now I understand better : I need my users to be defined on a centralized point (LDAP or NIS) so they are shared
by all machines. Complex since the platform I try to manage is linux based and the rest of the IT system in the
lab is Microsoft based.

Thanks a lot for your responses... I will try to find a solution...

Lionel
________________________________________
De : Rayson Ho [rayrayson@...]
Date d'envoi : jeudi 26 juillet 2012 17:37
À : Reuti
Cc : Lionel SPINELLI; users@...
Objet : Re: [gridengine users] Managing user password

On Thu, Jul 26, 2012 at 11:32 AM, Reuti <reuti@...> wrote:
>> But when I try to submit a job, I got an error telling "error: can't open output file
"/home/tommy/simple.sh.o60": Permission denied
>>
>> Obviously, if i use the -o and -e option of qsub to put the output and error logs to a shared disk without
write permissions, anything is ok.
>
> Mmh - is it now shared with or without write permission? "... to a shared disk without write permissions, it
(Continue reading)

Reuti | 26 Jul 2012 17:49
Picon

Re: RE : Managing user password

Am 26.07.2012 um 17:46 schrieb Lionel SPINELLI:

> My sentence was confusing... my shared disk is a NAS on which there is no permission definitions (so
everybody can read/write).
> So writing to the NAS is ok. Writting to the local disk fails

You would need some file staging then, as nothing is transfered by SGE. Therefore often it's directly
written to the shared home directory.

> (I am not surprised since I can't see how sge would manage passwords since

Passwords are not used by SGE, the UID is important. Can you check the UID on both machines?

$ id tommy

-- Reuti

> my users are all independantly created because I don't have any NIS or LDAP)...
> Now I understand better : I need my users to be defined on a centralized point (LDAP or NIS) so they are shared
by all machines. Complex since the platform I try to manage is linux based and the rest of the IT system in the
lab is Microsoft based.
> 
> Thanks a lot for your responses... I will try to find a solution...
> 
> 
> Lionel
> ________________________________________
> De : Rayson Ho [rayrayson@...]
> Date d'envoi : jeudi 26 juillet 2012 17:37
> À : Reuti
(Continue reading)

Lionel SPINELLI | 26 Jul 2012 18:05
Picon

RE : RE : Managing user password


User ID are differents (1001 and 1002). In any case, I can't maintain users ID synchronisation for all the
users I have to create now and in the future... So, either I find a LDAP/NIS solution, or I ask users to create
scripts using only the shared disks.... I think these are the two only solutions (file staging seems not
required since I have shared disk solution)... Do you see any others?

Thanks

Lionel

________________________________________
De : Reuti [reuti@...]
Date d'envoi : jeudi 26 juillet 2012 17:50
À : Lionel SPINELLI
Cc : Rayson Ho; users@...
Objet : Re: RE : [gridengine users] Managing user password

Am 26.07.2012 um 17:46 schrieb Lionel SPINELLI:

> My sentence was confusing... my shared disk is a NAS on which there is no permission definitions (so
everybody can read/write).
> So writing to the NAS is ok. Writting to the local disk fails

You would need some file staging then, as nothing is transfered by SGE. Therefore often it's directly
written to the shared home directory.

> (I am not surprised since I can't see how sge would manage passwords since

Passwords are not used by SGE, the UID is important. Can you check the UID on both machines?

(Continue reading)

Picon

Re: RE : RE : Managing user password

hi
try to setup nis  it will make life simpler
regards

Sent from my iPad

On Jul 26, 2012, at 12:05, Lionel SPINELLI <spinelli <at> ciml.univ-mrs.fr> wrote:

> 
> User ID are differents (1001 and 1002). In any case, I can't maintain users ID synchronisation for all the
users I have to create now and in the future... So, either I find a LDAP/NIS solution, or I ask users to create
scripts using only the shared disks.... I think these are the two only solutions (file staging seems not
required since I have shared disk solution)... Do you see any others?
> 
> Thanks
> 
> Lionel
> 
> 
> ________________________________________
> De : Reuti [reuti <at> staff.uni-marburg.de]
> Date d'envoi : jeudi 26 juillet 2012 17:50
> À : Lionel SPINELLI
> Cc : Rayson Ho; users <at> gridengine.org
> Objet : Re: RE : [gridengine users] Managing user password
> 
> Am 26.07.2012 um 17:46 schrieb Lionel SPINELLI:
> 
>> My sentence was confusing... my shared disk is a NAS on which there is no permission definitions (so
everybody can read/write).
(Continue reading)

Rayson Ho | 26 Jul 2012 18:05
Picon

Re: RE : Managing user password

On Thu, Jul 26, 2012 at 11:46 AM, Lionel SPINELLI
<spinelli@...> wrote:
> Now I understand better : I need my users to be defined on a centralized point (LDAP or NIS) so they are shared
by all machines. Complex since the platform I try to manage is linux based and the rest of the IT system in the
lab is Microsoft based.

IIRC, you don't need to have a centralized user account management
system, and in fact even same account w/ different UIDs *should* work.
Grid Engine looks up the account information when it starts a job, so
really a sync UID is not absolutely needed, but it can be if you have
a shared filesystem that has ACLs that uses UID.

Instead of implementing a centralized user account system, which
*really* is lots of work, I think the best to approach is to find out
why it can't write to the local disk. You can submit a job that runs
"id", and output it to the shared FS, and check if the job is really
running as the job owner. And then you can login as tommy and run
something interactively and see if writing to the local disk is OK or
not, etc... basically standard Linux admin stuff - you got the idea.
:-)

Rayson

>
> Thanks a lot for your responses... I will try to find a solution...
>
>
> Lionel
> ________________________________________
> De : Rayson Ho [rayrayson@...]
(Continue reading)

Malcolm Cowe | 27 Jul 2012 01:30
Picon

Re: RE : Managing user password

A half-way house for user management is to maintain the accounts on one 
system and distribute the passwd files (passwd, shadow, group, etc.) 
using rsync or CF-Engine or Puppet.

Malcolm.

On 27/07/12 02:05, Rayson Ho wrote:
> On Thu, Jul 26, 2012 at 11:46 AM, Lionel SPINELLI
> <spinelli@...>  wrote:
>> Now I understand better : I need my users to be defined on a centralized point (LDAP or NIS) so they are
shared by all machines. Complex since the platform I try to manage is linux based and the rest of the IT
system in the lab is Microsoft based.
> IIRC, you don't need to have a centralized user account management
> system, and in fact even same account w/ different UIDs *should* work.
> Grid Engine looks up the account information when it starts a job, so
> really a sync UID is not absolutely needed, but it can be if you have
> a shared filesystem that has ACLs that uses UID.
>
> Instead of implementing a centralized user account system, which
> *really* is lots of work, I think the best to approach is to find out
> why it can't write to the local disk. You can submit a job that runs
> "id", and output it to the shared FS, and check if the job is really
> running as the job owner. And then you can login as tommy and run
> something interactively and see if writing to the local disk is OK or
> not, etc... basically standard Linux admin stuff - you got the idea.
> :-)
>
> Rayson
>
>
(Continue reading)

Lionel SPINELLI | 27 Jul 2012 16:05
Picon

RE : RE : Managing user password

Hello all,

I would like to get you in touch of my progress. I think I solved the issue.
The advise to search which user was logged when executing the job was good. This user was the user "gridamin"
which is the user used to install the exec daemon.
In fact, the problem was due to the fact this user did not get sudo rights.
Historically, when I have executed the install_execd script, I was logged as my user "gridadmin" I used for
the installation. However, this user was not sudo. Hence, the exec daemon did not get any rights to write in
other users home dir or to change user.
Now, I executed again the install_execd script with sudo and the daemon restarted. And when I submit a job
now with the user "tommy", the user used is "tommy" that can correctly write in /home/tommy. It seems that
the daemon change user. Note that UID are not synchronized on the machines and the things seems to work ok...

Thank a lot for your advises...

Lionel
________________________________________
De : users-bounces@...
[users-bounces@...] de la part de Malcolm Cowe [malkolm@...]
Date d'envoi : vendredi 27 juillet 2012 01:31
À : users@...
Objet : Re: [gridengine users] RE :  Managing user password

A half-way house for user management is to maintain the accounts on one
system and distribute the passwd files (passwd, shadow, group, etc.)
using rsync or CF-Engine or Puppet.

Malcolm.

On 27/07/12 02:05, Rayson Ho wrote:
(Continue reading)


Gmane