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
