On Tue 25 Apr 2023 at 09:11:23 (+0200), DdB wrote: > Am 25.04.2023 um 02:18 schrieb David Christensen: > > I have a SOHO network with FreeBSD servers and Debian, Windows, macOS, > > and iOS clients. The hardware is anywhere from new to 16 years old. > > Where possible, I install a 2.5" SATA 6 Gbps trayless mobile racks in > > the computers and use 2.5" SATA 6 Gbps SSD for system drives. With FOSS > > OS, I try to install the system such that it will boot and run in > > several computers. > > > > > > For each system, I keep notes, console sessions, system configuration > > files, etc., in a version control system (VCS): > > > > * RCS was my first FOSS VCS. Learning and using RCS was worthwhile. The > > key advantage of RCS is that it works when the network is down. The key > > disadvantage is that RCS works on files individually. > > > > * CVS works on directories of files, has a central repository, and > > allows network access to the repository. The repository can be accessed > > from the local machine when the network is down. CVS meets my software > > development and system administration needs. > > > > * Git is even more powerful, and popular with FOSS projects. > > > > > > Configuration management systems, such as Ansible and Puppet, are beyond > > my needs. > > > > > > When an OS new major version is released, I typically wait a year or two > > for it to stabilize (or for the previous version to be EOL'd). I then > > use another computer, insert a zeroed SSD, do a fresh install, configure > > the system (manually), and migrate the data. Before, during, and after, > > I document my work, check in files, validate data, back up, archive, and > > image. One advantage of this approach is that you are certain that > > there is no leftover cruft wasting space or waiting to bite you. > > > > > > debian-11.6.0-amd64-netinst assigns UID/GID in the range 0 through 999 > > for system accounts, plus 1000 for the default user account, plus 65534 > > for the "nobody" account. That leaves 1001 through 65533 for everything > > else. I made a list of the accounts I add to systems many years ago and > > use those values on all of my systems. LDAP and related are services > > that centralize this kind of information.
The problem lies with the user accounts 101–999 (and releated groups), which are system accounts created in a somewhat random manner as packages are installed on each system. Those ≤100 are fixed by Debian (IIRC in package base-passwd), and those ≥1000 are easily kept consistent by good administration practice. > > I would not attempt to "Straightening out" passwd(5) or group(5). I > > would a make a list of accounts (as above), do the fresh build (as > > above), and translate the data during migration -- e.g. rsync(1) to new > > directory names, rename(1) to new file names, chown(1) to new UID/GID, > > etc.. Doing the migration/translation by hand is tedious, but may be > > feasible if the data is organized by username. If you can write > > scripts, correct scripts can save time and reduce errors (incorrect > > scripts are another matter). STFW might turn up suitable power tools, > > such as backup/restore tools with username/groupname/UID/GID translation. > > > > > > On machines with correct passwd(5) and group(5) but > > username/groupname/UID/GID that do not match the new account list, I > > would create new accounts per the new account list, move/translate the > > data, and then delete the obsolete accounts. > > > > > > Practicing on a VM is a reasonable idea. > > Quite a relief to hear, that it may make sense to avoid hassling with > passwd/group and to just straighten out permissions from the files on > the zfs pool(s) AFTER a fresh install. Just an observation (I know nothing about ZFS): AFAICT there are two occurrences of "permission" in this thread, both in your own text, whereas your problem seems to be one of ownerships. Decades ago, I made the mistake of transferring a file from one system to another (probably passwd.client), and ended up with a broken email system as the file was now owned by lpadmin or some such. But only the ownerships were wrong, not the permission bits. I have toyed with the idea of keeping my other PCs in sync with a master PC by preemptively creating users/groups as packages are installed on the master. This would only be practical with fresh installs of a new release. > Furthermore, i am taking away, that it may be a bit too early for the > final move to bookworm yet (in my case). > > But most of all, i am taking the suggestion to use Version control for > the documentation. I am already using git for the scripts, that i wrote, > which doesnt necessarily need a network connection. But to include > system configuration directly (i guess, you mean /etc + ssh-sessions + > individual command history + hand-written jotter/notebooks/logfiles) > could be a sensible move going forward. Up to this point, i did include > only a selected few config files, by hard-linking them from my git > workspace. > > What you are doing in terms of standardisation for your machines > corresponds to how i am using VM's, which allows myself to trust some > user/directories/files to exist and be respected. This allows to clone + > reconfigure some of them instead of recreating each one individually. > > I am going to pursue my goal along those lines and start playing with > the (Simulation-) VM first. Thank you again for those valuable hints. > > And finally: Since i tend to only have minimal configuration on the VM > host, and specialise mostly in the vm workspaces, the reinstall will > most likely not be all that hard. Cheers, David.
