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 allocator never saw a staff line (2026-08-16)
uid-alloc.py picked the band from the group teachers, retired when the identity model collapsed
to staff / students on 2026-08-06. A staff line resolved to no band and was skipped without a
word, so nobody in that band has been allocated a number since — adrien.reynard, rostered
2026-08-14, still had none.
Fixing it exposed a second one in the same function: 23 names hold two rows (a live number and the
drifted conf/users duplicate the seed imported as reserved), and the lookup kept the last row
read, i.e. the duplicate. Claiming would have promoted it to canonical. It now prefers the
non-reserved row, prints AMBIG and touches nothing when the status cannot separate a pair. Same
last-wins lookup in --verify, where it would have reported a mismatch against the NAS for every
one of those names; that check now accepts any row carrying the number the NAS enforces.
The catch-up write that followed: adrien.reynard allocated 1101, the first free number in the
staff band, and his home created with it (create-home.sh, 65 homes on the NAS now);
marta.rende (10008), martin.tavernier (10010) and oscar.esteban (10500) claimed their
existing rows. Those three are staff sitting on a student-band number, which is permanent and not
to be renumbered.
Two numbers by design for a student who became staff (2026-08-10)
louis.heredero holds 10020 (student band, NAS home) and 25304 (live on chacha/disco as
mattech staff), previously logged as "undecided". Named as the general rule instead: a student who
becomes an assistant keeps both, since the student number's home is discarded anyway and the bands
don't overlap — see the principle.
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 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 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: 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.