[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Win32 Version more questions(Newbie)
- Date: Thu, 30 Dec 2004 17:18:29 +0000
- From: matthew hope <matthew.hope@xxxxxxxxx>
- Subject: 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!