Gentoo Archives: gentoo-user

From: wraeth <wraeth@××××××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Managing multiple systems with identical hardware
Date: Fri, 13 Dec 2013 00:34:51
Message-Id: 52AA561D.10807@privatdemail.net
In Reply to: Re: [gentoo-user] Managing multiple systems with identical hardware by "Poison BL."
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-----

Replies

Subject Author
Re: [gentoo-user] Managing multiple systems with identical hardware Grant <emailgrant@×××××.com>