POSIX identity
uid and gid numbers, why they are permanent, and how to adopt the ones a fleet already uses.
A person needs a uid before a Linux host can own files as them.
cardinal posix assign user alonfils # the next number
cardinal posix assign group engineers
cardinal posix show user alonfils # the passwd line
cardinal posix set alonfils -home /home/arthur -shell /bin/zsh
cardinal posix list
A number becomes permanent when a host is first told it, not when it is assigned. Until then it can still be changed, which is what the adoption below does. After that every file that account creates records it, and the filesystem rather than the directory is the authority on what it means: changing it then would move files rather than edit a row, so Cardinal refuses.
Numbers are never released or reused either way.
Adopting numbers a machine already has
The one finding that blocks a migration is a uid or gid that disagrees. The moment Cardinal wins, every file that account owns is reattributed, so the answer is to take the numbers the fleet already uses rather than renumber the filesystem:
cardinal posix adopt alonfils 1035
At fleet scale the input is the reports shadow mode produces, so nothing has to be transcribed:
cardinal-agent shadow -server https://id.example.com -json > web-01.json
cardinal posix adopt -from web-01.json,web-02.json # shows the changes
cardinal posix adopt -from web-01.json,web-02.json -yes # applies them
Adoption is refused once a number has been served to a host. It is on a filesystem by then, and changing it moves files rather than editing a row.
How a host learns it
Not by asking at login. cardinal-agent serves POSIX identity over systemd's
io.systemd.UserDatabase varlink interface, which nss-systemd consumes: the
supported modern replacement for nss_ldap, and no C module to write. See
the agent.