discuss server gets random UID

[jweiss]

installing the debathena-discuss-server package ended up with discuss in the password file using a random UID, and not 32000 (the UID discuss has in hesiod/moira/etc, and the one I expected it to use).

As an aside, the UID assigned happened to conflict with something else in hesiod, but I understand that's a hard problem, and am willing to ignore it.

[andersk]

This is the way that all Debian packages handle UIDs, save the very few UIDs that were globally allocated by the Debian project in /usr/share/base-passwd/passwd.master. Is there a special reason that the numeric value of the local discuss UID is important to you?

[jweiss]

Mostly that I think of moira as the system of record for UIDs and it does have one allocated for discuss. Certainly I wouldn't expect me to get a different UID when logging into a DebAthena? machine, tho I'll certainly admit that theres a difference between a user and a system account. That said, I certainly expect it to work just fine with the random uid.

Assuming this is addressed and not "wontfixed" the gid (5002) should be dealt with too for consistency.

[mitchb]

I suspect the real difficulty here is that while we could
use the moira-assigned ID safely for discuss on machines
with a metapackage that involves supporting Athena accounts,
forcing it to be a fixed ID that's not allocated by the
base-passwd folks in Debian on a machine with just the -clients
metapackage (or no metapackage) could interfere with whatever
local UID assignment scheme is in use.

It does seem fairly poor to me that it got you an ID that
overlapped with something in moira, though.

[jdreed]

Is this ticket anything different than #299? I mean, there's nothing really we can do here, right? Local system UIDs are always going to clobber Hesiod ones.

I mean, adduser does support the --uid option, presumably adduser would DTRT if a UID was specified. (As it happens, 32000 is outside the range of both system accounts and user accounts, according to /etc/adduser.conf)

[quentin]

More generally, on systems which are using Athena accounts, it seems like it would be useful if adduser would check in Hesiod for a user of the same name, and use that uid iff it is not already taken on the local machine. Since NSS_NONLOCAL_IGNORE is set for adduser, this logic should probably be added to the adduser/addgroup wrapper scripts.

It seems like this could also solve the mit group problem at the same time, at least for cluster machines that can arrange for the package to be installed early enough.

[andersk]

The plan as of  a while  ago was to try to renumber the Moira UIDs and GIDs that are likely to conflict with local ones. Really, that’s the only way we’re going to fully solve this.

Changing the behavior of adduser depending on Hesiod does nothing to help the general problem (most system users and groups exist before Debathena was installed, except possibly on cluster machines where we can (theoretically) fully control the installation process). It also raises unclear security questions.

But as far as I can tell, none of this is a issue for discuss-server in particular.

[andersk]

See also #299.

[jdreed]

This is another "Debathena is not Athena 9" bug report, to which the answer is "You're right, it's not." If someone is particularly inclined to modify adduser, they can check if a system user is being added with the same username as a Moira user and print informational text to STDERR, but I don't think any more is necessary. I think we've mostly given up on pretending that daemons should use their entries in Moira.

Documented:  http://kb.mit.edu/confluence/x/bCAYCQ