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. > > > 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. > > > David
Thank you so much for chiming in. 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. 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.
