On 29/09/2013 20:31, Grant wrote: [snip]
>> There's one thing that we haven't touched on, and that's the hardware. >> Are they all identical hardware items, or at least compatible? Kernel >> builds and hardware-sensitive apps like mplayer are the top reasons >> you'd want to centralize things, but those are the very apps that will >> make sure life miserable trying to fins commonality that works in all >> cases. So do keep hardware needs in mind when making purchases. > > 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. OK > >> Personally, I wouldn't do the building and pushing on my own laptop, >> that turns me inot the central server and updates only happen when I'm >> in the office. I'd use a central build host and my laptop is just >> another client. Not all that important really, the build host is just an >> address from the client's point of view > > I don't think I'm making the connection here. The central server > can't do any unattended building and pushing, correct? So I would > need to be around either way I think. > > 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. No problem, just share your laptop's stuff with the workstations. Either share it directly, or upload your laptops configs and buildpks to a central fileserver where the workstations can access them (it comes down to the same thing really) > >>> OK, I'm thinking over how much variation there would be from laptop to >>> laptop: >>> >>> 1. /etc/runlevels/default/* would vary of course. >>> 2. /etc/conf.d/net would vary for the routers and my laptop which I >>> sometimes use as a router. >>> 3. /etc/hostapd/hostapd.conf under the same conditions as #2. >>> 4. Users and /home would vary but the office workstations could all be >>> identical in this regard. >>> >>> Am I missing anything? I can imagine everything else being totally >>> identical. >>> >>> What could I use to manage these differences? >> >> I'm sure there are numerous files in /etc/ with small niggling >> differences, you will find these as you go along. >> >> In a Linux world, these files actually do not subject themselves to >> centralization very well, they really do need a human with clue to make >> a decision whilst having access to the laptop in question. Every time >> we've brain-stormed this at work, we end up with only two realistic >> options: go to every machine and configure it there directly, or put >> individual per-host configs into puppet and push. It comes down to the >> same thing, the only difference is the location where stuff is stored. > > I'm sure I will need to carefully define those config differences. > Can I set up puppet (or similar) on my laptop and use it to push > config updates to all of the other laptops? That way the package I'm > using to push will be aware of config differences per system and push > everything correctly. You said not to use puppet, but does that apply > in this scenario? My warning about using Puppet on Gentoo should have come with a disclaimer: don't use puppet to make a Gentoo machine to emerge packages from source. You intend to push binary packages always, where the workstation doesn't have a choice in what it gets (you already decided that earlier). That will work well and from your workstation's POV is almost identical to how binary distros work. > >> I'm slowly coming to conclsuion that you are trying to solve a problem >> with Gentoo that binary distros already solved a very long time ago. You >> are forcing yourself to become the sole maintainer of GrantOS and do all >> the heavy lifting of packaging. But, Mint and friends already did all >> that work already and frankly, they are much better at it than you or I. > > Interesting. When I switched from Windows about 10 years ago I had > only a very brief run with Mandrake before I settled on Gentoo so I > don't *really* know what a binary distro is about. How would this > workflow be different on a binary distro? A binary distro would be the same as I described above. How those distros work is quite simple - their packages are archives like quickpkgs with pre- and post- install/uninstall scripts. These script do exactly the same thing as the various phase functions in portage - they define where to move files to, ownerships and permissions of them, and maybe a migration script if needed. The distro's package manager deals with all the details - you just tell it what you want installed and it goes ahead and does it. What the Puppet server does is tell the workstation it needs to install package XYZ. Code on the workstation then runs the package manager to do just that. For config files, there are numerous methods. You can simply drop a new config file to overwrite the old one, or add a new user by having useradd be run, or even change an existing config with sed. Whatever you need to happen within reason, Puppet has a way to do it from a central piece of software. 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) -- Alan McKinnon alan.mckin...@gmail.com
