public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Managing multiple systems with identical hardware
Date: Tue, 01 Oct 2013 08:20:14 +0200	[thread overview]
Message-ID: <524A699E.6080006@gmail.com> (raw)
In-Reply-To: <CAN0CFw0r8-4KgH0SxJwqE4gpuAm-Knuk-Tjtm3yb8H6Y6BD7tg@mail.gmail.com>

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



  reply	other threads:[~2013-10-01  6:48 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 21:18 [gentoo-user] Managing multiple systems with identical hardware Grant
2013-09-25 21:42 ` Alan McKinnon
2013-09-26  9:08   ` Grant
2013-09-26 20:42     ` Alan McKinnon
2013-09-27  4:33       ` Johann Schmitz
2013-09-27  5:34         ` Alan McKinnon
2013-09-27 10:37       ` Grant
2013-09-27 19:44         ` Alan McKinnon
2013-09-27 20:30           ` [gentoo-user] " James
2013-09-29 18:36             ` Grant
2013-09-29 20:39               ` Alan McKinnon
2013-09-29 18:31           ` [gentoo-user] " Grant
2013-09-29 19:06             ` Neil Bothwick
2013-09-29 20:57             ` Alan McKinnon
2013-09-30 17:31               ` Grant
2013-09-30 19:28                 ` thegeezer
2013-09-30 19:31                 ` Alan McKinnon
2013-09-30 19:53                   ` Frank Steinmetzger
2013-10-01  6:19                     ` Grant
2013-10-01 14:04                       ` Michael Orlitzky
2013-10-01 15:00                         ` Neil Bothwick
2013-09-30 21:02                   ` Neil Bothwick
2013-10-01  6:26                     ` Grant
2013-10-01  6:07                   ` Grant
2013-10-01  6:20                     ` Alan McKinnon [this message]
2013-10-02 18:54                       ` Grant
2013-12-12 23:54                         ` Grant
2013-12-13  0:16                           ` Poison BL.
2013-12-13  0:34                             ` wraeth
2013-12-13  2:06                               ` Grant
2013-12-13  9:12                                 ` Neil Bothwick
2013-12-13  1:49                             ` Grant
2013-12-13  7:57                               ` Alan McKinnon
2013-12-13  9:18                               ` Neil Bothwick
2013-12-13  7:52                           ` Alan McKinnon
2013-10-01  7:43                     ` Neil Bothwick
2013-10-01 18:37                   ` joost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=524A699E.6080006@gmail.com \
    --to=alan.mckinnon@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox