userid assignments

There are several type of non-baseos userids on the system

non-baseos system services

These get normal useradd -r (system userid) assignments, uid < 1000, gid < 1000 (check please).

sourceware services

... like search engines, gerrit, repository management jobs, etc.

Since these are maintained by sourceware users and/or overseers, these get normal userids (>= 1000), and gid 1003 ("shared").

personal accounts

These get normal userids (>= 1000), and one of the following gids to identify their general role:

  • 1000 (developer, the usual)

  • 1001 (absent or retired developers, reserving the userid)

    # usermod -g 1001 USERID

    This can be reversed with

    # usermod -g 1000 USERID

    For users who are likely gone forever, consider /sbin/nologin as the shell.

    # usermod -g 1001 -G "" -s /sbin/nologin USERID

Our accounts use no password (useradd -p x), no /etc/shadow record either: ssh-only logons. # getent passwd USERID; id USERID

group assignments

In addition to the primary gid, add any projects for which the user has commit/management access as supplementary groups. This way, it is trivial to take a census of who belongs in each project (by inspecting /etc/group only), and as people move from project to project, there's no need to change their gid.

It should be a rarity for a developer not to have a supplementary group for one of these projects. Such accounts should devolve to 'emeritus' at some point.

In addition, overseers are also members of the wheel group. Only these people should have /root/.ssh/authorized_keys access.

transition scripts

The following script takes as input a snapshot of the old-sourceware /etc/passwd and /etc/group files under /sourceware-root, and compares them to the local active one. It emits useradd, groupadd, usermod commands needed to bring the local system up to date with the old.

Generally, run grep on the output of this script, so as to experiment with individual userids, or restrict to a particular type of change. Simply running and piping to | sudo sh would be a bad idea.

% /home/fche/conversion/uid-merge.py