Re: [Condor-users] condor-submit -remote

["Matt Hope" <matthew.hope@xxxxxxxxx>]

On 5/31/07, Kewley, J (John) <j.kewley@xxxxxxxx> wrote:
> > It sounds like what you want is CLAIMTOBE authentication.  This
> > basically gives you host-based security for remote user
> > authentication.
> > Example:
> >
> > SEC_DEFAULT_AUTHENTICATION_METHODS = FS, CLAIMTOBE
>
> Hmm, from the manual:
> "Claim To Be authentication accepts any identity claimed by the client.
>  As such, it does not authenticate. It is included in Condor and in the
>  list of authentication methods for testing purposes only."
>
> scary!
>
> And "the powers that be" suggest that I should use a single submission
> point to improve security! Maybe I'll just get them to ssh onto it, but then
> I suspect file transfer would be a pain.

The moment you start doing that sort of thing you might want to
consider wrapping the submission process in your own system. The
initial pain is swiftly offset by the ability to alter aspects of the
system (like multiple submission machines abstracted into one) or
adding useful tracing/log control and the like

> Is there a section in the manual on remote submission (as opposed to
> Grid submission)? I presume that files can be transferred if neccessary?

The docs for condor_submit list most parts - note some significant limitations:

1) You cannot make use of submitting on hold. the remote submission
makes use of the hold mechanism to ensure that the job does not start
before the relevant files have made it across. I find this a *real*
pain since we currently deliberately slow release jobs so there are no
more than about 40 idle jobs at once (with possibly thousands of held
jobs).
If you are using a single submit point you may find the pain of not
being able to do this considerable.

2) At the moment multiple processes within a cluster seem to trigger
multiple file transfers - this is slow if you have  large executable
or input files as well as using up much more space on the remote
machine's spool.

3) the authentication you have already covered.

I reckon that abstracting the remote submission away by providing your
own mechanism for it is worthwhile if you have a sufficiently
restrictive set of possible jobs that this can be adequately
parametrised by a very small subset of the possibilities within
condor_submit and the mechanism to send executable and input files to
the submission host is something you can effectively manage via
straight file copying rather than reimplementing a file transfer
mechanism.

That last bit is just my opinion though. I have not yet had to do this
(though it is on my list of potential infrastructure changes so I have
given it some thought)

Matt