Philipp Kern <tr...@philkern.de> writes: > On 2009-05-06, Russ Allbery <r...@debian.org> wrote:
>> I think it's pretty unlikely that *most* Debian machines are done >> that way. There are a lot better tools for keeping large numbers of >> systems in sync these days than simple cloning from golden images, >> and a lot of drawbacks to the golden image approach. > > We do the same with ~12 clients. One master image that's declared > stable by rsyncing it using hardlinks[0] on the server and from there > rsynced to the clients which reboot automatically if there are pending > updates. After the rsyncing it does local profile-based "patching". > > I wonder about the drawbacks of this because it works really nice for > us. (Of course there's the downtime problem, but that's no problem > for us, as those are clients not servers.) If you start getting node variation, it turns into a headache. If you're in a situation where you're assured of no node variation, it works fairly well within that situation, but we want one solution that works for *all* types of servers we run, whether clusters or one-offs or smaller sets of load-balanced servers. You can also get a slow accumulation of cruft in your golden image over time, and if you don't keep good documentation, it's really easy to discover that you no longer know exactly how to rebuild your golden image if you need to (such as for a new OS release). > But why bother to do a complete reinstall everytime something changed > if you could just sync the delta. (And yes, I'm roughly aware that > there are something like softupdates in FAI too, but still.) We don't do it every time something changes; usually we use Puppet to push incremental changes. We rebuild systems whenever we repurpose them or whenever we do a major OS upgrade. I like rebuilding systems from first principles for exactly the same reason that I like recompiling the whole Debian archive. It tests your process. Having a complete process for building a system rather than a static system image that you may or may not be able to reproduce makes it much easier to migrate to new releases of the OS (because you can layer most of your policy on top of the new release), change any part of the process, etc. I've done this pretty much every different way you can with a lot of versions of UNIX: golden images, portions of the file system in network file systems, specific change application scripts, everything with native packages, mixes of native packaging and configuration management systems, etc. For a fairly heterogeneous mix of servers that may include some clusters of identical systems, I think FAI plus a good configuration management system like Puppet is the way to go. It makes me feel the most comfortable about the upgrade path, the testing of the whole system, and the robustness of the environment. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
