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
http://research.cs.wisc.edu/condor/manual/v6.2/3_3Configuring_Condor.html#sec:Shared-Filesystem-Config-File-Entries
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.
Thanks,
Michael
--
Michael Hanke
http://mih.voxindeserto.de
Reply to: