>>> 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 >>> > I'm also somewhat skeptical of rsyncing binaries and libraries on a running > system - it seems needlessly dangerous, particularly for things that have > complex deps. > > A mixed alternative to this would be: > > use rsync to manage distributing the system-wide configuration files for all > relevant packages (similar to what you're doing at the moment). This could > include just the /etc directory (and/or other system-wide config directories) > leaving the user files untouched > > instead of trying to rsync any binaries or libraries, use the master to build > a binary package ("--buildpkg") of whatever software is to be installed, with > the package directory shared over NFS or similar. Then, on the slaves, set > emerge default opts to "--usepkg" or "--usepkgonly" with a cron job, leaving > the actual updating of applications on the slave systems to portage.
I may end up using portage instead of rsync but I think I'd like to try rsync first. Am I setting myself up for failure? - Grant