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

Re: Request for review

On Fri, Apr 27, 2012 at 08:02:51PM +0100, Justin B Rye wrote:
> > I think standardizing on 'Personal Condor' is more appropriate as this
> > exact term is used in Condor's documentation -- although admittedly not
> > in 100% of all cases.
> Hang on, what did I have in my revised package description?

I standardized that too. ;-)

> > Hmm, so obviously the description below didn't do it for you, so it must
> > be lacking a key hint. UID domain in Condor is a hybrid. First, it is a
> > domain - something the condor sends e-mails to. But it also serves as a
> > label. If the domain(-label) is identical across two machines (say
> > submit and execute node) it assumes that UID 1000 on both machines actually
> > refers to the same human user.
> And presumably UID 1001 etc (my desktop machine doesn't even have a
> UID 1000 account).  Presumably the point is that incoming jobs are
> only stamped with a UID, not a username, so even if each workstation
> in my devel department has users alice, bob, and charlie, Condor can
> only keep them straight if they have corresponding numbers, and that's
> only likely if they're in the same LDAP system.
> And if I want to tell Condor that my devel and ops departments have
> separate LDAP systems with non-corresponding UIDs, I signal that by
> giving them different non-zero-length labels... which can't be "DEVEL"
> and "OPS" - they have to be valid mail domains that Condor can send
> email to, right?  That seems a strange requirement.

It is even more complicated


I think the tricky question is how much of that complexity needs to be
reflected in this question. The deconf-based configuration only serves
the purpose of getting condor running quickly in some standard cases.
If you are running two LDAPs you probably want to just deploy a custom
condor config.

> But putting these questions aside, basically it's another label system
> like the one for network file systems, but this time dealing with user
> account directory systems.  Here's an attempt to describe that setup:
>  Template: condor/uiddomain
>  Type: string
>  _Description: user directory domain label:
>   This label is a string that Condor uses to decide if a submitting
>   machine and an execute machine share the same directory of user accounts
>   (that is, whether UID 1000 on one machine is the same person as UID 1000
>   on the other). If the labels on the two machines match, Condor will run
>   each job under the UID that submitted the job, and send emails about
>   them to user@DOMAIN (using this label as the value of DOMAIN). If not,
>   Condor will run all jobs as user "nobody". Leaving it blank will cause
>   Condor to run all jobs on this machine as user "nobody".
>   .
>   Any domain format supported by Condor can be used, including macro
>   expressions. Example: $(FULL_HOSTNAME)

I like it!

> > The example here is using FULL_HOSTNAME, which is a condor macro that
> > resolves to something that should be unique across machines, hence email
> > gets sent to the local machine and Condor does not attempt to run jobs
> > matching the users account that submitted them.
> So mail still gets sent to somebody even if jobs are run as nobody?
> Maybe I need to extract the bit about sending mail to user@DOMAIN and
> explain it more carefully later on.

Yes, the last sentence in the text linked above states:

|  When Condor sends e-mail about a job, Condor sends the e-mail to
|  user@UID_DOMAIN. If $(UID_DOMAIN)   is set to ``none'' or it is
|  undefined, the e-mail is sent to user@submitmachinename.



Michael Hanke

Reply to: