On 13/12/2013 03:49, Grant 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:
> 
> What if the push is done while no one is logged in to the system(s)
> being updated?  I could also exclude /dev, /sys, /proc, and /run and
> reboot after the update.  If that's not good enough, what if I boot
> the systems being updated into read-only mode before updating them?
> I'm hoping to keep the process as simple as possible.


Consider what happens when you run "emerge apache" on a system running
apache. The universe doesn't explode and all kittens in the world don't
spontaneously die :-)

How is your scheme essentially any different? Presumably you have
already excluded virtual mounts using the appropriate magic switches.

Things like dbus might get upset by being updated, but you have to deal
with that on a portage machine anyway and one usually logs out and in to
fix that, or reboot if the system bus is affected.

You probably want to reboot each laptop after a full update



> 
> - Grant
> 
> 
>> 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.
>>
>> --
>> Poison [BLX]
>> Joshua M. Murphy
> 
> 
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com


Reply via email to