[gentoo-dev] Re: Managing updates on many identical Gentoo systems

[Duncan <1i5t5.duncan@cox.net>]

Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted:

> I'm trying to design an update system for many identical Gentoo systems.
>  Using a binhost is obvious, but there are still problems with this
> approach.
> 
> Unless there's some magic I don't know about (and this is why I'm
> sending this email) each machine still needs to have the portage tree
> installed locally (1.5 GB) or somehow mounted by a network filesystem
> (which is not practical if the machines are not on a local network).
> Furthermore, each machine would have to run emerge locally to do the
> calculation of what packages need updating.
> 
> This procedure is redundant because each machine is housing the same
> data and doing the same dependence-tree calculation.

I had a gen-1.5 32-bit netbook for a number of years, that I updated 
using rsync from a 32-bit chroot on my main machine, no portage tree on 
the target netbook, tho I didn't worry about separating out build deps 
from run deps.

That was a single machine config, but it should be even easier if you're 
running nearly identical machines and thus don't need the separate chroot 
build image.

If you have temporary networking you can rsync directly machine to 
machine, as I did after I was fully setup, but at first I was sneaker-
netting it, rsyncing to a thumb drive from the build machine, that I 
would then plug into the target and rsync thumb drive to target.

The thumb drive was bootable, and I used it to do the first gentoo boots 
on the target as well, testing my config and updating as necessary as I 
went.  When I got everything I initially wanted booting from the thumb 
drive, I booted the thumb drive, wiped the initial Pingus Linux on the 
netbook and setup the partitioning, etc, then rsynced selected bits into 
the appropriate place on the target.

For multiple nearly identical machines you can exclude the non-identical 
bits from the primary rsync image, keeping the specific bits in 
individual images synced on top of the primary.  Of course you can sync 
in reverse as well to keep the non-identical bits updated, giving you a 
nice backup of each one as well. =:^)

Alternatives would include simply creating the thumb drive once and then 
cloning it enough times to give every machine a bootable thumb drive copy 
(using symlinking and/or mounts to handle the non-identical stuff, so 
simply toggling a symlink lets you switch machine layouts), or if the 
machines have enough memory, setting up a single thumb drive to boot and 
put everything in a tmpfs for the machine to run from, so you can use the 
same thumb drive to boot them all, effectively the sneakernet version of 
net-boot.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman