>>>> 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

Reply via email to