[GE users] Application Server Submitting on Behalf of a User

Daniel Templeton Dan.Templeton at Sun.COM
Mon Jun 19 14:08:21 BST 2006


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Chris,

Unfortunately, right now there isn't a good solution to your problem.  
You're left with the brute force solutions of having the server switch 
its EUID to do the job submissions or forking a sudo of qsub.

With the next release, the infrastructure around identifying the 
submitting user will be greatly improved, and in a following release, 
DRMAA will most likely be extended to use that infrastructure to enable 
exactly what you've described.

Daniel

Langston, Chris wrote:
> Thanks for the reply, Reuti. 
>
> The end result I'm trying to achieve is for the process to be owned by
> the end user and not the submitting application user. The user is
> interfacing with a server (thru the Java application) which in turns
> runs the job. That means, to SGE the job looks like it is being
> submitted by the application server ID. I need for the scheduling and
> priority to be dictated by SGE, but I want user to have control over
> their own jobs (delete, suspend, resume...) and one or two power users
> to have ownership of a queue so that they can control all the jobs in
> that queue. Priority of a job is set not only by the type of job, but by
> who submitted it. I haven't found anything in any documentation anywhere
> that lets a server application (running under its own ID) be able to
> submit a job as the end user. Any help is greatly appreciated.
>
> -----Original Message-----
> From: Reuti [mailto:reuti at staff.uni-marburg.de] 
> Sent: Friday, June 16, 2006 5:58 PM
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] Application Server Submitting on Behalf of a
> User
>
> Am 16.06.2006 um 23:18 schrieb Langston, Chris:
>
>   
>> Hi All,
>>
>> This is my first time requesting information from this mailing  
>> list, so
>> please bear with me. My challenge is; how to submit jobs from a server
>> to SGE on behalf of a user. Currently, users are running a Java
>> application on their Windows desktop to execute a server side C++
>> program using RMI. The program is scheduled using a home-grown
>> scheduling software that is being replaced with SGE (v6.0u7).
>> Authentication is currently handled thru an authentication server.
>>
>> Here's my dilemma: I'm looking for a light-weight solution to  
>> submit to
>> the grid (I've looked at the Grid Engine Portal and that solution -
>> although not completely out of the question - is too heavy  
>> (overkill) -
>> requiring too many other pieces to be put in place to get it to work.
>>
>> Does anyone know of a small, elegant solution to have a server  
>> (running
>> as the server ID) submit a job to SGE on behalf of a user (after
>> authentication)?
>>     
>
> I'm not really sure whether this is a possible way for you, but we  
> here want to give the users the option to use the cluster without any  
> knowledge of the underlying queuing system. So for various programs  
> we have some scripts prepared, which will create the job script on- 
> the-fly, submit it and delete it afterwards again. The user only has  
> to prepare their input file for the executable porgram and that's all.
>
> Scribble of the idea (real scripts have error checking and some  
> options):
>
> #!/bin/sh
> # subcalc <inputfile>
> #
> exec 3>~/temp.sh
> cat >&3 <<-EOF
> 	#!/bin/sh
> 	#$ -N Demojob
> 	#$ -m ea
> 	/opt/the_binary < $1
> 	EOF
> exec 3>&-
> qsub ~/temp.sh
> rm ~/temp.sh
>
> So the user only has to give the comand:
>
> subcalc my_input_file
>
> and  this is all. This you could put in one ssh command line from a  
> windows machine.
>
> ssh myserver subcalc my_input_file
>
> Only problem: where is the inputfile. (Be aware that the indention is  
> one TAB.) But anyway: let me know, if this would be an option for you  
> and I can send you some of our real scripts.
>
> HTH - Reuti
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list