Andrey Rahmatullin <wrar@debian.org> writes:
> On Wed, Oct 06, 2021 at 12:03:16PM +0200, dude wrote:
>> what is the best practice for easy update & dist-upgrade:
>>
>> 1. in terms of speed and easy of distro updates, it makes sense to separate
>> * /root (software (programs) that can be re-downloaded) (on
>> separate single suepr fast SSD or NVMe)
>> * /home (non-reblacable unique data (massive amounts of space with
>> 8x4TB software mdadm RAID10))
> This is mostly irrelevant.
> Also "non-reblacable unique data" exists outside /home too, e.g. in /etc
> and /var.
>
>> 2. when a new Debian 12 is coming out
>> * how to re-play all those changes, installs, configs and programs
>> made to /root?
> Just don't reinstall. Debian recommends using apt and following the
> release notes to upgrade to the next version.
>
+1, one of the killer features of Debian is reliable and smooth
upgrades.
Given the / vs /root mixup, and the assumption that a new major release
requires a reinstall, I think Dude is a new Debian user.
>> 3. if things go wrong there is still this nice "show me all changes to
>> logs in beautiful colors" one liner
>> * (ccze is very much needed also in Debian 12 :) (tried many
>> alternatives)
>> * find /var/log/* -type f \( -name "*" \) ! -path '*.gz*' -exec
>> tail -n0 -f "$file" {} + | ccze
> (doesn't look like *changes* to logs for me, but whatever works for you)
>
>> 1. install a very basic Debian 11 template
>> 2. apply all changes (all changes will be recorded to a separate
>> partition (!?) or a local git repo!?) and saved as a "config
>> snapshot" that can be re applied as soon as Debian 12 template is
>> released :)?
> This is over-engineering, unless you are going for the "infrastructure as
> code" paradigm from the beginning (which is over-engineering for many
> use cases as well).
>
If the objective is just to install a set of packages, why not use 'dpkg
--get-selections' and 'dpkg --set-selections'? (hint: also learn how to
use apt-mark to save/restore the "automatically installed" state) Beyond
that, there are many more flexible alternatives like CFEngine, Ansible,
Propeller, Puppet, etc.
Another option is to create a custom task-foo package, or a metapackage.
Alternatively, one can also use a pre-upgrade btrfs snapshot of @rootfs
(including /etc and /var) to gain the ability to examine any/all changes
between the pre-upgrade and post-upgrade state. Providing staged
upgrades and/or easy rollbacks using this feature is one of my long-term
plans.
I'm not really sure what the actual problem is...hence the diversity of
potential solutions...
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature