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 827BC1381F3 for ; Tue, 1 Oct 2013 06:07:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2BB0AE0AFF; Tue, 1 Oct 2013 06:07:16 +0000 (UTC) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 21CB8E0A65 for ; Tue, 1 Oct 2013 06:07:14 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x19so4443614qcw.30 for ; Mon, 30 Sep 2013 23:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N8CbvkJZBXPUACnKsFvvDnaccxeihPJLWPq8z+ekWg4=; b=G+JWvX/LmmVLB/UgJvBiVlypMOg6SV7ODcdcQvFLXd7GLCymeC7IPvz3MXgm2ND7o5 Llw1SiEC0W9Yt3Cm1xJB+ZRYazq3SbY7wQ2s96HIvTTTW2cdhkotpZ9ETlWkHkMiJKGR L6hXJ+1akMnqE6F14vwQRE6XovLzZ0ZfzPVkelz7VY1Z41gEAjNz3naa+LOsyum931JF 9K1AtV/bLRlEN+DrGS6nLOh8B+1rt3LXvEXKjFuHLrGl4rQjjHdymMsVCjzo+mKT2BK6 h8LLzYLnUJ2GW177aCoIL96S8Ybgq3lIOMb/Q0SCRtHI+3QCp8y/sEqmcuh0TTIqE7iL DbIQ== 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 X-Received: by 10.49.30.66 with SMTP id q2mr33461744qeh.38.1380607634238; Mon, 30 Sep 2013 23:07:14 -0700 (PDT) Received: by 10.140.25.83 with HTTP; Mon, 30 Sep 2013 23:07:14 -0700 (PDT) In-Reply-To: <5249D186.8050808@gmail.com> References: <524358B0.1060000@gmail.com> <52449C1A.5000306@gmail.com> <5245E03A.2020605@gmail.com> <52489438.3090405@gmail.com> <5249D186.8050808@gmail.com> Date: Mon, 30 Sep 2013 23:07:14 -0700 Message-ID: Subject: Re: [gentoo-user] Managing multiple systems with identical hardware From: Grant To: Gentoo mailing list Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 5f1c0897-e662-403a-8785-59dc8b4309b3 X-Archives-Hash: ec3b9cd65a9a7633825e62be577c8f05 >>>> 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? > 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. > 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. - Grant