1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 13/12/13 11:16, Poison BL. wrote: |
5 |
> On Thu, Dec 12, 2013 at 6:54 PM, Grant <emailgrant@×××××.com> wrote: |
6 |
>> I'm about to embark on this (perilous?) journey and I'm wondering if |
7 |
>> anyone would make a comment on any of the questions in the last paragraph |
8 |
>> below. This is basically my plan for setting up a bunch of systems |
9 |
>> (laptops) in an office which are hardware-identical to my own laptop and |
10 |
>> creating a framework to manage them all with a bare minimum of time and |
11 |
>> effort. |
12 |
>> |
13 |
>> Thanks, Grant |
14 |
>> |
15 |
>> |
16 |
>>>>>>>> I see what you desire now - essentially you want to clone |
17 |
>>>>>>>> your laptop (or big chunks of it) over to your other |
18 |
>>>>>>>> workstations. |
19 |
>>> |
20 |
>>> I've been working on this and I think I have a good and simple plan. |
21 |
>>> |
22 |
>>> My laptop roams around with me and is the "master" system. The office |
23 |
>>> router is the "submaster" system. All of the other office systems are |
24 |
>>> "minion" systems. All of the systems are 100% hardware-identical |
25 |
>>> laptops. All of the minions are 100% software-identical. |
26 |
>>> |
27 |
>>> I install every package that any system needs on the master and create |
28 |
>>> an SSH keypair. The only config files that change from their state on |
29 |
>>> the master are: /etc/conf.d/hostname, /etc/conf.d/net, |
30 |
>>> /etc/ssh/sshd_config, /etc/shorewall/*. I write comments in those |
31 |
>>> files which serve as flags for scripted changes. |
32 |
>>> |
33 |
>>> I write a script that is run from the master to the submaster, or from |
34 |
>>> the submaster to a minion. If it's the former, rsync / is run with |
35 |
>>> exceptions (/usr/portage, /usr/local/portage, /var/log, /tmp, /home, |
36 |
>>> /root but /root/.ssh/id_rsa_script* is included), my personal user is |
37 |
>>> removed, a series of workstation users are created with useradd -m, |
38 |
>>> services are added or removed from /etc/runlevels/default, and config |
39 |
>>> files are changed according to comment flags. If it's the latter, |
40 |
>>> rsync / is run without exceptions, services are added or removed from |
41 |
>>> /etc/runlevels/default, and config files are changed according to |
42 |
>>> comment flags. |
43 |
>>> |
44 |
>>> All user info on the submaster and minions would be effectively reset |
45 |
>>> whenever the script is run and that's fine. Root logins would have to |
46 |
>>> be allowed on the submaster and minions but only with the SSH key. |
47 |
>>> There are probably more paths to exclude when rsyncing master to |
48 |
>>> submaster. |
49 |
>>> |
50 |
>>> That's it. No matter how numerous the minions become, this should |
51 |
>>> allow me to keep everything running by administrating only my own |
52 |
>>> system, pushing that to the submaster, and having the submaster push to |
53 |
>>> the minions. I've been going over the nitty-gritty and everything |
54 |
>>> looks good. |
55 |
>>> |
56 |
>>> What do you think? Is there anything inherently wrong with rsyncing / |
57 |
>>> onto a running system? If there are little or no changes to make, |
58 |
>>> about how much data would actually be transferred? Is there a better |
59 |
>>> tool for this than rsync? I know Funtoo uses git for syncing with |
60 |
>>> their portage tree. |
61 |
>>> |
62 |
>>> - Grant |
63 |
>> |
64 |
> |
65 |
> Only thing that comes immediately to mind in rsyncing an overwrite of / is |
66 |
> that any process that's running that goes looking for libraries or other |
67 |
> data after the rsync pulls the rug out from beneath it might behave |
68 |
> erratically, crash, kick a puppy, write arbitrary data all over your drive. |
69 |
> Also, it's somewhat important to be careful about the various |
70 |
> not-really-there mounts, /dev, /sys, /proc... /run's probably touchy too, |
71 |
> and /var has a few pieces that might be in use mid-sync and choke something |
72 |
> along the way. My idea on that would be... build an initramfs that: |
73 |
> |
74 |
> 1) boots to a script a) warns the user that it's hungry and that feeding it |
75 |
> will be dangerous to any non-backed-up data, with prompt b) warns the user |
76 |
> again, with prompt ('cause watching an rsync roll by that eats that |
77 |
> document you just spent 3 weeks on isn't fun) 2) mounts / in a working |
78 |
> directory 3) rsyncs the new data from the sub-master 4) kicks off a script |
79 |
> to update a hardware keyed (mac address is good for this) set of settings |
80 |
> (hostname, etc) 5) reboots into the new system. |
81 |
> |
82 |
> For extra credit... sync /home back to the sub-master to prevent |
83 |
> overfeeding the beast. |
84 |
> |
85 |
|
86 |
I'm also somewhat skeptical of rsyncing binaries and libraries on a running |
87 |
system - it seems needlessly dangerous, particularly for things that have |
88 |
complex deps. |
89 |
|
90 |
A mixed alternative to this would be: |
91 |
|
92 |
use rsync to manage distributing the system-wide configuration files for all |
93 |
relevant packages (similar to what you're doing at the moment). This could |
94 |
include just the /etc directory (and/or other system-wide config directories) |
95 |
leaving the user files untouched |
96 |
|
97 |
instead of trying to rsync any binaries or libraries, use the master to build |
98 |
a binary package ("--buildpkg") of whatever software is to be installed, with |
99 |
the package directory shared over NFS or similar. Then, on the slaves, set |
100 |
emerge default opts to "--usepkg" or "--usepkgonly" with a cron job, leaving |
101 |
the actual updating of applications on the slave systems to portage. |
102 |
|
103 |
- -- |
104 |
wraeth |
105 |
-----BEGIN PGP SIGNATURE----- |
106 |
Version: GnuPG v2.0.22 (GNU/Linux) |
107 |
|
108 |
iF4EAREIAAYFAlKqVh0ACgkQGYlqHeQRhkyaLgD9EkPdV4YjdSikEo2wj0DdPWLj |
109 |
vaXpfs9H2HUI5bIhLVkA+gMZcz9o+s+m01atrHGNV8fmOg61hkBFEfe4s4yjqiV9 |
110 |
=oauw |
111 |
-----END PGP SIGNATURE----- |