UIDs — history & operations

Dated operations on the UID register, newest first. The mechanism, the bands and the reasoning live on the main page; this is what was actually done, and to whom.

The wiring made to actually work (2026-08-06)

The wiring below had never run. It called read_csv as a lookup plugin — it is a module, and the only CSV lookup is ansible.builtin.csvfile — and its uid_register / uid_register_path variables matched the ^uid_.* pattern that 00_setup merges for its uniqueness check, so the merge died on mixed types for every inventory, register or not.

Fixed with the module plus an indexing task, and by renaming the variables to uidmap / uidmap_path: anything named uid_* in that role has to be a list of user entries. Verified offline against the real conf/ with a throwaway inventory of non-existent hosts, both with and without a register.

The register seeded, and what it caught (2026-08-05)

uid-map.csv built from stat on the 66 homes, plus the numbers that own files only on the Calypso nodes. 21 of the 66 are held by someone on the roster; the rest are reserved.

A first pass burned only the numbers with a NAS home, and the allocator immediately offered 10000 — held by a test.test account on calypso0. Comparing against all three reachable nodes found eight more numbers in the same position, seven of them real people with a node account and no NAS home. Without that pass a future student would have been handed a number whose files already belonged to someone else, which is the exact failure the register exists to prevent.

calypso3–7 were powered down, so the burned list is as complete as the fleet allowed.

A home renumbered out of the DSM range (2026-08-05)

One student home was owned by 1027, which is the IscAdmin account in the NAS's own /etc/passwd. DSM therefore rendered it as owned by the administrator, and an IscAdmin session had owner rights over it. Moved to 1100, the first number in the teachers band, on the NAS and on the three Calypso nodes in one pass — renumbering only one side would have created precisely the drift the register removes.

This is why 1024–1099 is a hole in the bands: DSM allocates its own accounts upward from 1024, so the range will keep producing collisions.

Seven departed accounts removed (2026-08-05)

Seven people with Calypso accounts but no NAS home, plus a test.test leftover, were confirmed gone. Removed from the nodes (userdel -r), from conf/authorized_keys/, and from the register, which frees their numbers. Their /home trees held only the skeleton — three files each, no user data — and the last two copies in the carnaval pre-install rescue on rumba were dropped as well; the other 203 rescued homes were untouched.

An eighth key, for someone who had left earlier, was removed on the same pass: it owned nothing anywhere — no register row, no home, no node account, absent from conf/users.

They were not recreated by Ansible. They appeared in no conf/users list — leftovers from an older configuration. The two test accounts titi and tutu are in a list and do come back on every run, which is why their numbers stay burned.

Ansible wired to the register (2026-08-05)

roles/00_setup/tasks/01_users.yml reads uid-map.csv and its number wins over any id: in conf/users. Opt-in per inventory; only calypso_rack.yml opts in. (As written that day it could not run at all — fixed 2026-08-06.)

Applying it would renumber 13 accounts on the rack — one person carried three different numbers across the NAS, the nodes and uid-admin.yml. uid-alloc.py --check-ansible lists them. It has not been applied, and should not be: once the current cohort finishes, every Calypso node is rebuilt as a carnaval node, which wipes the /etc/passwd that carries the drift. Renumbering an installation that is about to be reinstalled buys nothing.

That rebuild is what makes the register matter rather than what makes it moot: the new nodes have to create their accounts from something, and the register is the only source that agrees with the home ownership NFS compares.