From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 700F713827E for ; Fri, 13 Dec 2013 00:34:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6940BE09B7; Fri, 13 Dec 2013 00:34:46 +0000 (UTC) Received: from mail.privatdemail.net (mail.privatdemail.net [217.139.17.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0D29DE099B for ; Fri, 13 Dec 2013 00:34:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.privatdemail.net (Postfix) with ESMTP id 6E4CC6B677 for ; Fri, 13 Dec 2013 02:34:43 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=privatdemail.net; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:mime-version:user-agent :from:from:date:date:message-id; s=pdm200902; t=1386894882; x= 1388709282; bh=6SlNxc/3PwkumAxVuZSInvnlDrQ0naXoKP0XALKxwPg=; b=K jw/PB4cEtB7KKfgOHewacf7M97eo1FmyrPy2T8hISgF84jwAulT6ovpGkMBGAkUK JTPMjmJAkIBFyuUYneN101DQRtRqUNldSTMoQ+II9cNKgEMgyvExsOB9NdmuPEwM K4dQH07SjlCADsNUFVIV2/J/vE99oVz+o/HaUXEATU= Received: from mail.privatdemail.net ([127.0.0.1]) by localhost (mail.privatdemail.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m71uUr-4JMEA for ; Fri, 13 Dec 2013 02:34:42 +0200 (EET) Message-ID: <52AA561D.10807@privatdemail.net> Date: Fri, 13 Dec 2013 11:34:37 +1100 From: wraeth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Managing multiple systems with identical hardware References: <524358B0.1060000@gmail.com> <52449C1A.5000306@gmail.com> <5245E03A.2020605@gmail.com> <52489438.3090405@gmail.com> <5249D186.8050808@gmail.com> <524A699E.6080006@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 12e6c392-31ee-4159-a296-d9f8eaa76513 X-Archives-Hash: 52a77557c081ea87ee2fea07701606cd -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 13/12/13 11:16, Poison BL. wrote: > On Thu, Dec 12, 2013 at 6:54 PM, Grant wrote: >> 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 >> > > Only thing that comes immediately to mind in rsyncing an overwrite of / is > that any process that's running that goes looking for libraries or other > data after the rsync pulls the rug out from beneath it might behave > erratically, crash, kick a puppy, write arbitrary data all over your drive. > Also, it's somewhat important to be careful about the various > not-really-there mounts, /dev, /sys, /proc... /run's probably touchy too, > and /var has a few pieces that might be in use mid-sync and choke something > along the way. My idea on that would be... build an initramfs that: > > 1) boots to a script a) warns the user that it's hungry and that feeding it > will be dangerous to any non-backed-up data, with prompt b) warns the user > again, with prompt ('cause watching an rsync roll by that eats that > document you just spent 3 weeks on isn't fun) 2) mounts / in a working > directory 3) rsyncs the new data from the sub-master 4) kicks off a script > to update a hardware keyed (mac address is good for this) set of settings > (hostname, etc) 5) reboots into the new system. > > For extra credit... sync /home back to the sub-master to prevent > overfeeding the beast. > 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. - -- wraeth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKqVh0ACgkQGYlqHeQRhkyaLgD9EkPdV4YjdSikEo2wj0DdPWLj vaXpfs9H2HUI5bIhLVkA+gMZcz9o+s+m01atrHGNV8fmOg61hkBFEfe4s4yjqiV9 =oauw -----END PGP SIGNATURE-----