-----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 <emailgr...@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-----
