[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] Win32 Version more questions(Newbie)



On Thu, 30 Dec 2004 11:17:54 -0500 (EST), N <nnoydb@xxxxxxxxxx> wrote:
> 
> 
> My intention it to invoke condor_submit from a .NET application running the
> webservices engine.  The calling process will pass a "user environment" object 
> containg information abt the user including the (cluster) password and user ID 
> (encrypted, signed and ascii armored using the clusters pgp public key).  Using 
> the USER_JOB_WRAPPER facility the "job launcher" will decrypt and verify the 
> PGP environment XML.  It will then invoke the process using the win32 
> CreateProcessAsUser. If the user does not exist or does not have the correct 
> permissions the CreateProcess will fail and a error will be returned to the user via 
> webservices objects.  This can be done without the .NET webservice via simple 
> wrapper batch file for condor_submit.  This will perserve the security but raises 
> the problem of the user supplying the "unencrypted password"
> 
> Your comments and or ideas?

invoking condor_submit from .Net is no probs and the parsing the
output is reasonably simple.

If you are submitting everything from a single location then you may
find it becomes a bottleneck (depends on the size of your farm and the
length of your jobs)

the initially created process has no path/environment information
execpt what you supply so I suggest that unless you have total control
over the execute nodes then you will have all sorts of trouble (get it
setup working on one, ghost a working build then copy it).

It is pretty easy to get total local access by making the reuse-vmX
users local admins. this keeps your domain sourced data secure but
lets you do whatever you like on the local machine - use only if you
have complete faith in your users not to mess with it. It sounds like
you don't though...

A theoretically possible (though annoying) alternative to to create a
vm type per user and have each one linked to a particular user, then
use store_cred to keep the credentials in sync and go with that.
hideous to maintain and likely to have unforseen problems so more as a
thought than a serious solution.

As to the create as user - good luck I hope it works!

Matt