Re: Looking for inspiration/advice/best practices on system upgrade
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.
Reply to: