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 |