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.mckin...@gmail.com
