Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Managing multiple systems with identical hardware
Date: Fri, 13 Dec 2013 07:57:26
Message-Id: 52AABDDF.70600@gmail.com
In Reply to: Re: [gentoo-user] Managing multiple systems with identical hardware by Grant
1 On 13/12/2013 03:49, Grant wrote:
2 >>> I'm about to embark on this (perilous?) journey and I'm wondering if
3 >>> anyone would make a comment on any of the questions in the last
4 >>> paragraph below. This is basically my plan for setting up a bunch of
5 >>> systems (laptops) in an office which are hardware-identical to my own
6 >>> laptop and creating a framework to manage them all with a bare minimum
7 >>> of time and effort.
8 >>>
9 >>> Thanks,
10 >>> Grant
11 >>>
12 >>>
13 >>>>>>>>> I see what you desire now - essentially you want to clone your laptop
14 >>>>>>>>> (or big chunks of it) over to your other workstations.
15 >>>>
16 >>>> I've been working on this and I think I have a good and simple plan.
17 >>>>
18 >>>> My laptop roams around with me and is the "master" system. The office
19 >>>> router is the "submaster" system. All of the other office systems are
20 >>>> "minion" systems. All of the systems are 100% hardware-identical
21 >>>> laptops. All of the minions are 100% software-identical.
22 >>>>
23 >>>> I install every package that any system needs on the master and create
24 >>>> an SSH keypair. The only config files that change from their state on
25 >>>> the master are: /etc/conf.d/hostname, /etc/conf.d/net,
26 >>>> /etc/ssh/sshd_config, /etc/shorewall/*. I write comments in those
27 >>>> files which serve as flags for scripted changes.
28 >>>>
29 >>>> I write a script that is run from the master to the submaster, or from
30 >>>> the submaster to a minion. If it's the former, rsync / is run with
31 >>>> exceptions (/usr/portage, /usr/local/portage, /var/log, /tmp, /home,
32 >>>> /root but /root/.ssh/id_rsa_script* is included), my personal user is
33 >>>> removed, a series of workstation users are created with useradd -m,
34 >>>> services are added or removed from /etc/runlevels/default, and config
35 >>>> files are changed according to comment flags. If it's the latter,
36 >>>> rsync / is run without exceptions, services are added or removed from
37 >>>> /etc/runlevels/default, and config files are changed according to
38 >>>> comment flags.
39 >>>>
40 >>>> All user info on the submaster and minions would be effectively reset
41 >>>> whenever the script is run and that's fine. Root logins would have to
42 >>>> be allowed on the submaster and minions but only with the SSH key.
43 >>>> There are probably more paths to exclude when rsyncing master to
44 >>>> submaster.
45 >>>>
46 >>>> That's it. No matter how numerous the minions become, this should
47 >>>> allow me to keep everything running by administrating only my own
48 >>>> system, pushing that to the submaster, and having the submaster push
49 >>>> to the minions. I've been going over the nitty-gritty and everything
50 >>>> looks good.
51 >>>>
52 >>>> What do you think? Is there anything inherently wrong with rsyncing /
53 >>>> onto a running system? If there are little or no changes to make,
54 >>>> about how much data would actually be transferred? Is there a better
55 >>>> tool for this than rsync? I know Funtoo uses git for syncing with
56 >>>> their portage tree.
57 >>>>
58 >>>> - Grant
59 >>>
60 >>
61 >> Only thing that comes immediately to mind in rsyncing an overwrite of
62 >> / is that any process that's running that goes looking for libraries
63 >> or other data after the rsync pulls the rug out from beneath it might
64 >> behave erratically, crash, kick a puppy, write arbitrary data all over
65 >> your drive. Also, it's somewhat important to be careful about the
66 >> various not-really-there mounts, /dev, /sys, /proc... /run's probably
67 >> touchy too, and /var has a few pieces that might be in use mid-sync
68 >> and choke something along the way. My idea on that would be... build
69 >> an initramfs that:
70 >
71 > What if the push is done while no one is logged in to the system(s)
72 > being updated? I could also exclude /dev, /sys, /proc, and /run and
73 > reboot after the update. If that's not good enough, what if I boot
74 > the systems being updated into read-only mode before updating them?
75 > I'm hoping to keep the process as simple as possible.
76
77
78 Consider what happens when you run "emerge apache" on a system running
79 apache. The universe doesn't explode and all kittens in the world don't
80 spontaneously die :-)
81
82 How is your scheme essentially any different? Presumably you have
83 already excluded virtual mounts using the appropriate magic switches.
84
85 Things like dbus might get upset by being updated, but you have to deal
86 with that on a portage machine anyway and one usually logs out and in to
87 fix that, or reboot if the system bus is affected.
88
89 You probably want to reboot each laptop after a full update
90
91
92
93 >
94 > - Grant
95 >
96 >
97 >> 1) boots to a script
98 >> a) warns the user that it's hungry and that feeding it will be
99 >> dangerous to any non-backed-up data, with prompt
100 >> b) warns the user again, with prompt ('cause watching an rsync roll
101 >> by that eats that document you just spent 3 weeks on isn't fun)
102 >> 2) mounts / in a working directory
103 >> 3) rsyncs the new data from the sub-master
104 >> 4) kicks off a script to update a hardware keyed (mac address is good
105 >> for this) set of settings (hostname, etc)
106 >> 5) reboots into the new system.
107 >>
108 >> For extra credit... sync /home back to the sub-master to prevent
109 >> overfeeding the beast.
110 >>
111 >> --
112 >> Poison [BLX]
113 >> Joshua M. Murphy
114 >
115 >
116 >
117
118
119 --
120 Alan McKinnon
121 alan.mckinnon@×××××.com