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

Daniel Templeton Dan.Templeton at Sun.COM
Tue Jun 20 15:31:09 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,

By "next release," I mean the next major release, which will likely be 
called 6.5.

There is no direct DRMAA support for -A, but you can always slip it in 
with the native specification (JobTemplate.setNativeSpecification()).

Daniel

Langston, Chris wrote:
> Thanks, David. Just to be sure, when you say next release; do you mean
> major release; as in, version 7?
>
> The DRMAA approach would definitely be the cleanest for our needs, but
> if we have to wait...we have to wait. In the meantime, it looks like
> Mark Olesen's work-around could be a temporary solution.
>
> BTW: Is there any DRMAA that is equivalent to the -A switch. I couldn't
> find it, unless I overlooked it.
>
> -----Original Message-----
> From: Dan.Templeton at Sun.COM [mailto:Dan.Templeton at Sun.COM] 
> Sent: Monday, June 19, 2006 8:08 AM
> To: users at gridengine.sunsource.net
> Subject: Re: [GE users] Application Server Submitting on Behalf of a
> User
>
> 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
>
> ---------------------------------------------------------------------
> 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