On Mon, 2004-09-13 at 21:36 +0100, Miles Sabin wrote: > > I think all my questions boil down to: looks great for the 95% of stuff > which stays the same, but how do you deal with the 5% of stuff which > varies? And can you do it in a way which is 95% less hassle than > treating the machines as completely separate entities? Right, for a sufficiently low number of machines, setting up an elaborate framework is going to be more annoying than just managing them all separately. Though we should try to make the framework easy enough to use that it makes sense even for a single machine, if we can. I think there are maybe a couple answers to your question. 1) Should there be some kind of OS 'layering' (words like 'profile' or 'inheritance' come to mind). This is possible today with something like RHN, which can describe a machine install as a set of RPMs and a set of config files. Today you can have RHN keep machines in sync directly by syncing their config files and package lists. In the future it might make sense if RHN could stage each profile to a file tree, and then the file tree could be mounted diskless (or synced on a file level) by the machines that have that profile. There are other setups people use for this too. A lot of customers we have really do not have package list profiles, though; they have one "profile" for the whole company, and only vary the machines by config file. Important caveat: part of enabling this in most cases is to provide apps via NFS rather than installing them on each system, so the RPM package list is just a core rather than all the apps. But the idea is that any system on the network can run any workload (workload = service, or even have desktop users log in). You then keep a central mapping that assigns workloads to specific machines, but you can change that mapping as required. This seems like the ideal, while in one sense "profiles" feels like a workaround. 2) How can you avoid a separate 'profile' to make small changes. This is a matter of pulling state out of the OS install and config files. We've been approaching this by saying there's a toolbox you can use. Here are some of the approaches in the toolbox: - dynamic/automatic configuration - look up configuration from a central place, e.g. a directory server, or even a file share - write scripts that examine the machine and determine its desired configuration based on hardware, network location, or by looking up configuration from a central place - move the configuration to be per-user rather than per-computer So some of this can be done out of the box in the OS; for example for desktops, NetworkManager helps address network configuration that varies between machines. A good kudzu helps avoid hardware config in general. etc. But you'd expect a local site to do some work as well. Anyway, to the extent that machines can vary by workload rather than by install profile, so there can be a single install profile, that seems desirable. I'm kind of sleepy so sorry if this answer is sort of muddled; but I think your questions really get to the heart of what we're trying to solve here. Havoc
