Re: Request for review
More attempts to understand the "User ID domain" bit...
Since the shared-FS label part seems easier to understand, would it be
possible to reorder the debconf questions so that it's asked first?
>> (Oh, and I'm standardising on "personal Condor installation")
> 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?
>> But what
>> on earth is a "UID domain"? How does a User ID (like "1000") have a
>> domain (like "example.org")?
> 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.
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:
_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)
>> (Unfortunately this means I don't get to see the example, so the
>> concept of "UID domain" is still unclear to me.)
> 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.
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package