Initial notes by DanielAllen

Present: Dave Gawley, DanielAllen, Ray Butterworth, and Steven Nickerson.

Since two of the three participants with live projects (Mike P and Chris C) were in SGI Ultrix training, we held off our regularly scheduled program till next week. Instead:

Discussion with Ray about users and groups.

Dave and I had a question about the proper way to handle user/group names and IDs which are necessary for an architecture (such as debian linux) but which aren't listed in the standard passwd/group files.

Ray's response question: do we need a specific name, or a specific name and ID? Dave/Daniel's answer: the former. We can deal with a different ID.

Ray showed us 'idregistry'. (see manpages 8). This is used to maintain and query an id-database daemon on general.math.

Following usages are useful for our purpose:

idregistry request <user> will tell you if the id or name is in use, returning 'UNKNOWN' if it doesn't exist.

idregistry request <group> type=group will do the same for groups.

idregistry require <uid> will do the same; but if it doesn't previously exist it will first create the user/id/group/gid in the database.

idregistry report will verify a list of "name:id" pairs.

parameter: Conformance=strict requires that all created users and groups will "automatically conform to the registry host's standard IDs; otherwise the account or group will not be created".

[But I'm not sure how Conformance is used in practice.]

Once we have our IDs registered, we can safely add them to our regional master host. (Such as student.cs for lws000.student.cs).

Passwords are propagated from one machine to another via spread-passwd (which should be in crontab)

Followup email with Ray

Date: Fri, 10 Jun 2005 09:49:54 -0400 (EDT)
From: Ray Butterworth 
To: drallen@cs.uwaterloo.ca
Subject: Re:  xhier 101 notes
>  From drallen@cs.uwaterloo.ca Thu Jun  9 17:23:26 2005
...

> The notes I took during the session were spotty enough that I don't
> know when to use Conformance=strict with idregistry.

It's a matter of policy, but in general the answer is always.

"strict" is what Bill and Dave wanted all hosts to (eventually) use, so that is what the config/admin setting is for the CSCF administration. So for all new machines in your administration you should never have to do anything to configure this option, as that's the default.

It's set to "advisory" for older hosts that didn't conform at the time the registry was set up, with the idea that new accounts on those machines would get created with the correct numbers, and many of the old accounts would eventually go away, making the eventual renumbering task easier.

> My guess is that 'strict' affects other tools which create users and
> groups, which will first check the idregistry db for whether the
> user/group had been created with Conformance=strict? ...and if the ID
> doesn't match the name, refuse to create the user or group?

With "none", nothing special happens.

Otherwise, programs that create new passwd or group entries check the registry to determine what the appropriate number is and use that if possible. If it's not possible, with "advisory" the program silently creates the entry with a different randomly chosen number, and with "strict" the program would fail and exit with a hard error.

There's also a daily cron job that, on "strict" and "advisory" hosts, reports all the non-vendor passwd entries to the registry. On "strict" machines, if the registry detects a mismatch, the cronjob mails an error message to "accounts" and records any errors in two log files: /software/accounts/logs/id_{user,group}_report.

Whenever Jennifer (or whoever) runs an "accounts-client" update for a machine, the update checks those log files and if there are any recorded errors on a "strict" machine, refuses to make any further changes to the passwd or group files until the problems are cleaned up.

> ...and that's why you asked at the beginning if we needed a specific ID,
> or only a name? If we needed the ID we could create it with
> Conformance=strict?

No, I was more concerned with distinguishing between entries that are of type "vendor" and of type "xhier".

All passwd entries have a corresponding line in the file /software/accounts/data/users, where one of the fields marks each entry as being sponsored by "vendor", "xhier", or "sponsor-cscf". i.e. it records the reason for the existence of the passwd entry.

The "sponsor-cscf" accounts are those controlled by Jennifer. The "xhier" accounts are those that correspond to an entry in some /software/*/export/passwd file. The "vendor" accounts are those that came with the basic OS installation.

"vendor" entries will already have the same standard id numbers on all machines of that architecture. So anything that checks for conformance will ignore these.

The biggest complication is with Linux. Sometimes packages are installed directly without their being part of an xhier package. If the linux package needs a special passwd entry, a corresponding export/passwd entry needs to be created in the linux-os package (or whatever it's called), so that the data/users file can record the account's reason for existence.

So, to go back closer to your original question, the "vendor" accounts are those that are required by something external to UW to have specific id numbers, while the "xhier" accounts are any other software related accounts.

[...]

The only time you need to think is when you manually add a new line to /etc/passwd: ask idregistry for the appropriate id number, and make sure that the userid is listed in some */export/passwd file.

And if you think it's not appropriate to add something to an export/passwd file, it's likely that you shouldn't be creating the passwd entry either (e.g. accounts for users should be maintained by Jennifer).

Diversion on configuring passwords/accounts...

[I need to ask ray what this was really about; sorry]

Files are in /software/accounts/config/$HIERARCHY/$FILES

xh-options -a -p accounts -c $FILES

-a means print list of known or set options to stdout

-p accounts refers the following -c to the accounts package

-c translates to the matching subdirectory of $HIERARCHY

$HIERARCHY is determined by:

share > arch > regional > admin > local

-- DanielAllen - 09 Jun 2005