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 226611381F3 for ; Tue, 1 Oct 2013 06:48:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B21A4E0AAA; Tue, 1 Oct 2013 06:48:32 +0000 (UTC) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8D07CE0A53 for ; Tue, 1 Oct 2013 06:48:26 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hm2so5033753wib.16 for ; Mon, 30 Sep 2013 23:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TyXIOUpauLoesL32DdTbq7aCQMwhNwlbo47mTQsIzIU=; b=Bmmz2jXoljOhjsOrj6l0nNxvgFTEl2SIbSpww/yqjhCZcw09tXFjKout7HBrR59tfF pR9xMo5N6gjiux8HJS3flRODYjWfhSgyk/WBIyzP39Po1XVVHTMO2V9j1dDkcuMVI1/v 7tbylM0BehC5eNNuThf5Q6kvuey5LXPH/KFr+sa+jcb1aHYd73XrRp58uDnm+BjCgdNR pFjQirazeAjksDrC5UAEmHdZFFv4E2pgcTVTjYtm9dmiWlBHqArTBYnSk08+Qe7yW9jx HxqxS13J4TEY0QLSsVDulzUhTEP2S/82VXUl3w2uSzxs4iQbuNoyErJYWs8z5mEyxKqt K9Lg== X-Received: by 10.180.74.209 with SMTP id w17mr16923226wiv.7.1380608686875; Mon, 30 Sep 2013 23:24:46 -0700 (PDT) Received: from [172.20.0.40] (196-210-102-121.dynamic.isadsl.co.za. [196.210.102.121]) by mx.google.com with ESMTPSA id i8sm2716550wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 23:24:46 -0700 (PDT) Message-ID: <524A699E.6080006@gmail.com> Date: Tue, 01 Oct 2013 08:20:14 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: f001d8d5-83c4-404d-9fe0-a24ebd6d387e X-Archives-Hash: f7e68bb0a21fcc5bee047b76083e9ad6 On 01/10/2013 08:07, Grant wrote: >>>>> Keeping all of the laptops 100% identical as far as hardware is >>>>> central to this plan. I know I'm setting myself up for big problems >>>>> otherwise. >>>>> >>>>> I'm hoping I can emerge every package on my laptop that every other >>>>> laptop needs. That way I can fix any build problems and update any >>>>> config files right on my own system. Then I would push config file >>>>> differences to all of the other laptops. Then each laptop could >>>>> emerge its own stuff unattended. >>>> >>>> I see what you desire now - essentially you want to clone your laptop >>>> (or big chunks of it) over to your other workstations. >>> >>> That sounds about right. >>> >>>> To get a feel for how it works, visit puppet's web site and download >>>> some of the test appliances they have there and run them in vm software. >>>> Set up a server and a few clients, and start experimenting in that >>>> sandbox. You'll quickly get a feel for how it all hangs together (it's >>>> hard to describe in text how puppet gets the job done, so much easier to >>>> do it for real and watch the results) >>> >>> Puppet seems like overkill for what I need. I think all I really need >>> is something to manage config file differences and user accounts. At >>> this point I'm thinking I shouldn't push packages themselves, but >>> portage config files and then let each laptop emerge unattended based >>> on those portage configs. I'm going to bring this to the 'salt' >>> mailing list to see if it might be a good fit. It seems like a much >>> lighter weight application. >> >> Two general points I can add: >> >> 1. Sharing config files turns out to be really hard. By far the easiest >> way is to just share /etc but that is an all or nothing approach, and >> you just need one file to be different to break it. Like /etc/hostname >> >> You *could* create a "share" directory inside /etc and symlink common >> files in there, but that gets very tedious quickly. >> >> Rather go for a centralized repo solution that pushes configs out, you >> must just find the one that's right for you. > > Does using puppet or salt to push configs from my laptop qualify as a > centralized repo solution? yes > >> 2. Binary packages are almost perfect for your needs IMHO, running >> emerge gets very tedious quickly, and your spec is that all workstations >> have the same USE. You'd be amazed how much time you save by doing this: >> >> emerge -b on your laptop and share your /var/packages >> emerge -K on the workstations when your laptop is on the network >> >> step 2 goes amazingly quickly - eyeball the list to be emerged, they >> should all be purple, press enter. About a minute or two per >> workstation, as opposed to however many hours the build took. > > The thing is my laptop goes with me all over the place and is very > rarely on the same network as the bulk of the laptop clients. Most of > the time I'm on a tethered and metered cell phone connection > somewhere. Build time itself really isn't a big deal. I can have the > clients update overnight. Whether the clients emerge or emerge -K is > the same amount of admnistrative work I would think. I see. So you give up the efficiency of binpkgs to get a system that at least works reliably. Within those constraints that probably is the best option. > >> 3. (OK, three points). Share your portage tree over the network. No >> point in syncing multiple times when you actually just need to do it once. > > Yep, I figure each physical location should designate one system to > host the portage tree and distfiles. -- Alan McKinnon alan.mckinnon@gmail.com