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 F09331381F3 for ; Tue, 1 Oct 2013 18:37:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 81000E0B29; Tue, 1 Oct 2013 18:37:47 +0000 (UTC) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 4610FE0AD9 for ; Tue, 1 Oct 2013 18:37:46 +0000 (UTC) Received: from [212.54.42.134] (helo=smtp3.tb.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1VR4pN-0004Gb-ID for gentoo-user@lists.gentoo.org; Tue, 01 Oct 2013 20:37:45 +0200 Received: from 54698b76.cm-12-2c.dynamic.ziggo.nl ([84.105.139.118] helo=data.antarean.org) by smtp3.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1VR4pM-0003ws-Nn for gentoo-user@lists.gentoo.org; Tue, 01 Oct 2013 20:37:45 +0200 Received: from [10.20.13.57] (unknown [10.20.13.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPSA id 444844C for ; Tue, 1 Oct 2013 20:37:34 +0200 (CEST) User-Agent: K-9 Mail for Android 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> 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 Content-Type: multipart/alternative; boundary="----X4SPNNKAEVE58EXP23J4NBJUOI7YDU" Subject: Re: [gentoo-user] Managing multiple systems with identical hardware From: joost@antarean.org Date: Tue, 01 Oct 2013 20:37:42 +0200 To: gentoo-user@lists.gentoo.org Message-ID: <047f18f9-c4a4-4deb-a384-8f88126fd111@email.android.com> X-Ziggo-spambar: ---- X-Ziggo-spamscore: -4.8 X-Ziggo-spamreport: ALL_TRUSTED=-1,BAYES_00=-1.9,HTML_MESSAGE=0.001,NO_REAL_NAME=0.1,PROLO_TRUST_RDNS=-3,RDNS_DYNAMIC=0.982 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: 859f9a1f-de72-4645-8074-b851484e563a X-Archives-Hash: 17702f0ed108d35b3b6504f707f10f14 ------X4SPNNKAEVE58EXP23J4NBJUOI7YDU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alan McKinnon wrote: >On 30/09/2013 19:31, 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. >>=20 >> That sounds about right. >>=20 >>> 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) >>=20 >> 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. > >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. > >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. > > >>=20 >> I'm soaking up a lot of your time (again). I'll return with any real >> Gentoo questions I run into and to run down the final plan before I >> execute it. Thanks so much for your help. Not sure what I'd do >> without you. :) > >I'm sure Neil would step in if I'm hit by a bus >He'd say the same things, and use about 1/4 of the words it takes me >;-) > > >--=20 >Alan McKinnon >alan.mckinnon@gmail.com Grant, Additionally. You might want to consider sharing /etc/portage and /var/li= b/portage/world (the file) I do that between my build host and the other machines. (Along with the p= ortage tree, packages and distfiles) That way all workstations end up with the same packages each time you run= "emerge -vauDk world" on them. And like Alan said, it goes really quick. -- Joost --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. ------X4SPNNKAEVE58EXP23J4NBJUOI7YDU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Alan McKinnon <ala= n.mckinnon@gmail.com> wrote:
On 30/09/2013 19:31, 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 oth=
er
laptop needs.  That way I can fix any build problems and update a=
ny
config files right on my own system.  Then I would push config fi=
le
differences to all of the other laptops.  Then each laptop could<=
br />emerge its own stuff unattended.

I see what you de=
sire 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 downlo=
ad
some of the test appliances they have there and run them in vm so=
ftware.
Set up a server and a few clients, and start experimenting i=
n that
sandbox. You'll quickly get a feel for how it all hangs toget=
her (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 bas=
ed
on those portage configs.  I'm going to
bring this to the 'salt'
mailing list to see if it might be a good f=
it.  It seems like a much
lighter weight application.
Two general points I can add:

1. Sharing config files turn=
s out to be really hard. By far the easiest
way is to just share /et=
c 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* c=
reate a "share" directory inside /etc and symlink common
files in th=
ere, but that gets very tedious quickly.

Rather go for a centr=
alized repo solution that pushes configs out, you
must just find the=
 one that's right for you.

2. Binary packages are almost perfe=
ct for your needs IMHO, running
emerge gets very tedious quickly, an=
d your spec is that all workstations
have the same USE. You'd be ama=
zed how much time you save by doing this:

emerge -b on your la=
ptop 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.

3. (OK, three=
 points). Share your portage tree over the network. No
point in sync=
ing multiple times when you actually just need to do it once.

=


I'm soaking =
up a lot of your time (again).  I'll return with any real
Gentoo que=
stions I run into and to run down the final plan before I
execute it=
.  Thanks so much for your help.  Not sure what I'd do
without you. =
:)

I'm sure Neil would step in if I'm hit by a bus
He'd say the same things, and use about 1/4 of the words it takes me ;-)=


Grant,

Additionally. You might want to consider sharing /etc/portage and /var/li= b/portage/world (the file)
I do that between my build host and the other machines. (Along with the p= ortage tree, packages and distfiles)

That way all workstations end up with the same packages each time you run= "emerge -vauDk world" on them.

And like Alan said, it goes really quick.

--
Joost

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------X4SPNNKAEVE58EXP23J4NBJUOI7YDU--