Re: [Condor-users] User impersonation

[Mark Silberstein <marks@xxxxxxxxxxxxxxxxxxxxxxx>]

I'm not sure I understood what exactly you want to achieve. Say, you
have a web portal. Your users invoke an application via this portal and
are not aware of Condor behind the curtain. Each invocation results in
multiple jobs submission to Condor. All jobs are submitted under the
same user ( right? ), and are run one after another. However you want to
have interleaving, i.e., if we mark all jobs of user1 as 1, user2 as 2
and etc, than the submission:
11112222 should run as 121212? Is it correct? 
If yes, I think there are several solutions. 
1) You have this "runas" command, which allows you to run things under
another user ID. so if you submit with this "runas" it should work the
way you want. The only problem is that you have to have all the users on
the submission machine and they should pass their password as a
parameter to runas.
2) Another way ( not sure if it works though) is to run multiple schedds
every time new user submits new jobs - one schedd per virtual user. If
it works, the only thing you need is a script to kill schedd after it
finishes all the jobs. If it works, it seems to be the easiest thing to
do.
3) And finally, you can play with job priority in the queue, 
periodically updating the queue according to the number of users  you
have.
I would be really interested to hear about your solution
Thanks
Mark
On Thu, 2004-06-24 at 10:28, Ralf Reinhardt wrote:
> Zachary Miller wrote:
> > On Wed, Jun 23, 2004 at 12:19:37PM +0200, Ralf Reinhardt wrote:
> > 
> >>Hi,
> >>Here is another problem from my small bioinformatics project.
> >>I have several users which want to share the cluster, but my frontend 
> >>only runs on a single account. It is very cumbersome to create and use 
> >>different accounts under XP.
> >>It would be much easier if there was a way to either let several jobs 
> >>run side by side for the same user or if condor_submit could be used 
> >>with user and password for lower security levels.
> >>Are there any solutions I have not found?
> > 
> > 
> > if your frontend is the only access your users have to the cluster, you can
> > enforce the concept of different "users" at that level.  however, if your end
> > users have the ability to actually run condor_submit, condor_q, and condor_rm,
> > etc. and talk directly to the condor_schedd, this will not work.
> > 
> > for example, say you have a web frontend running on some machine with a schedd.
> > that frontend can insert extra attributes into the job by putting something
> > like this in the submit file:
> > +webuser = zmiller
> > 
> > then the frontend can use the -constraint option to the condor tools to do
> > things on behalf of the webuser.  the web frontend is also responsible for
> > authenticating that user somehow, probably a password.
> > 
> 
> Nice idea, this way one can assign jobs or cluster to different users. 
> But that's not my problem (all submits are already stored in an 
> additional database). As long as only one user is submitting the 
> clusters, they will run one after the other and not side by side. Only 
> the order of execution can be changed. It would mean that some users 
> would have to wait quite some time until they get their first results 
> (and find out that they used the wrong method...). The problem is that 
> the users are sitting before their PCs and WAIT for the results. (I wish 
> i could redesign my users - it would make programming much more fun ;-))
> 
> Cheers  Ralf
> 
> 
> _______________________________________________
> Condor-users mailing list
> Condor-users@xxxxxxxxxxx
> http://lists.cs.wisc.edu/mailman/listinfo/condor-users