On 4/24/23 08:53, DdB wrote:
Hi list, while still on debian buster (old-old-stable soon), i am approaching the point, where i will be ready to upgrade. I do have backup(s) from different points in time, and can carry out restore to a VM, that is almost identical to my main system, that i can use as a playground for playing through the whole process. Also i can automatically set up a running duplicate of my system on bare metal in another partition, in order to allow investigation of the process without risking my current working environment. But i could not yet decide upon the right way to progress, 3 alternatives coming to mind: 1. Upgrade from current configuration using upgrade path tools (apt) and plan only one step (going to bullseye) at a time, eventually having to upgrade a second time later. 2. Install a fresh bullseye and try to manually make it as similar as can be to my current workhorse 3. Skip bullseye altogether and jump to bookworm right away. From my past experiences, i recall one problem, that i am still suffering from: the file group and user owners, that reside on a different disk set (on a ZFS pool, to be more precise). In order to alleviate the problem, i did at one point fetch an older /etc/group and passwd file from a backup and created a mess. I'd love to straigthen this out now. At the time, i did investigate (configuration management) tools, but found the effort was much too high for my liking, as i am the only real user on my system and also retired, making such a professional solution going way too far. I can be patient, but i would like to find the most reasonable path to get a more up-to-date system soon. Would anyone with more experience, than i have, give me their point-of-view/recommendations as food-for-thought, please? Thank you in advance DdB
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