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