Re: [gentoo-user] Managing multiple systems with identical hardware

[wraeth <wraeth@privatdemail.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/12/13 11:16, Poison BL. wrote:
> On Thu, Dec 12, 2013 at 6:54 PM, Grant <emailgrant@gmail.com> wrote:
>> I'm about to embark on this (perilous?) journey and I'm wondering if 
>> anyone would make a comment on any of the questions in the last paragraph
>> below.  This is basically my plan for setting up a bunch of systems
>> (laptops) in an office which are hardware-identical to my own laptop and
>> creating a framework to manage them all with a bare minimum of time and
>> effort.
>> 
>> Thanks, Grant
>> 
>> 
>>>>>>>> I see what you desire now - essentially you want to clone
>>>>>>>> your laptop (or big chunks of it) over to your other
>>>>>>>> workstations.
>>> 
>>> I've been working on this and I think I have a good and simple plan.
>>> 
>>> My laptop roams around with me and is the "master" system.  The office 
>>> router is the "submaster" system.  All of the other office systems are 
>>> "minion" systems.  All of the systems are 100% hardware-identical 
>>> laptops.  All of the minions are 100% software-identical.
>>> 
>>> I install every package that any system needs on the master and create 
>>> an SSH keypair.  The only config files that change from their state on 
>>> the master are: /etc/conf.d/hostname, /etc/conf.d/net, 
>>> /etc/ssh/sshd_config, /etc/shorewall/*.  I write comments in those 
>>> files which serve as flags for scripted changes.
>>> 
>>> I write a script that is run from the master to the submaster, or from 
>>> the submaster to a minion.  If it's the former, rsync / is run with 
>>> exceptions (/usr/portage, /usr/local/portage, /var/log, /tmp, /home, 
>>> /root but /root/.ssh/id_rsa_script* is included), my personal user is 
>>> removed, a series of workstation users are created with useradd -m, 
>>> services are added or removed from /etc/runlevels/default, and config 
>>> files are changed according to comment flags.  If it's the latter, 
>>> rsync / is run without exceptions, services are added or removed from 
>>> /etc/runlevels/default, and config files are changed according to 
>>> comment flags.
>>> 
>>> All user info on the submaster and minions would be effectively reset 
>>> whenever the script is run and that's fine.  Root logins would have to 
>>> be allowed on the submaster and minions but only with the SSH key. 
>>> There are probably more paths to exclude when rsyncing master to 
>>> submaster.
>>> 
>>> That's it.  No matter how numerous the minions become, this should 
>>> allow me to keep everything running by administrating only my own 
>>> system, pushing that to the submaster, and having the submaster push to
>>> the minions.  I've been going over the nitty-gritty and everything 
>>> looks good.
>>> 
>>> What do you think?  Is there anything inherently wrong with rsyncing / 
>>> onto a running system?  If there are little or no changes to make, 
>>> about how much data would actually be transferred?  Is there a better 
>>> tool for this than rsync?  I know Funtoo uses git for syncing with 
>>> their portage tree.
>>> 
>>> - Grant
>> 
> 
> Only thing that comes immediately to mind in rsyncing an overwrite of / is
> that any process that's running that goes looking for libraries or other
> data after the rsync pulls the rug out from beneath it might behave
> erratically, crash, kick a puppy, write arbitrary data all over your drive.
> Also, it's somewhat important to be careful about the various
> not-really-there mounts, /dev, /sys, /proc... /run's probably touchy too,
> and /var has a few pieces that might be in use mid-sync and choke something
> along the way. My idea on that would be... build an initramfs that:
> 
> 1) boots to a script a) warns the user that it's hungry and that feeding it
> will be dangerous to any non-backed-up data, with prompt b) warns the user
> again, with prompt ('cause watching an rsync roll by that eats that
> document you just spent 3 weeks on isn't fun) 2) mounts / in a working
> directory 3) rsyncs the new data from the sub-master 4) kicks off a script
> to update a hardware keyed (mac address is good for this) set of settings
> (hostname, etc) 5) reboots into the new system.
> 
> For extra credit... sync /home back to the sub-master to prevent 
> overfeeding the beast.
> 

I'm also somewhat skeptical of rsyncing binaries and libraries on a running
system - it seems needlessly dangerous, particularly for things that have
complex deps.

A mixed alternative to this would be:

use rsync to manage distributing the system-wide configuration files for all
relevant packages (similar to what you're doing at the moment).  This could
include just the /etc directory (and/or other system-wide config directories)
leaving the user files untouched

instead of trying to rsync any binaries or libraries, use the master to build
a binary package ("--buildpkg") of whatever software is to be installed, with
the package directory shared over NFS or similar.  Then, on the slaves, set
emerge default opts to "--usepkg" or "--usepkgonly" with a cron job, leaving
the actual updating of applications on the slave systems to portage.

- -- 
wraeth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKqVh0ACgkQGYlqHeQRhkyaLgD9EkPdV4YjdSikEo2wj0DdPWLj
vaXpfs9H2HUI5bIhLVkA+gMZcz9o+s+m01atrHGNV8fmOg61hkBFEfe4s4yjqiV9
=oauw
-----END PGP SIGNATURE-----