> To my mind, the packaging system is the wrong place to deliver > site-specific configuration changes. It should be for binaries and > support files, things that will not change over time. A system like > GNU CFengine or Puppet should be used to modify these things. I use > CFengine at work, and while it works quite nicely I think I'd look at > the alternatives before I used it elsewhere. The parser is quite > fragile, but once you discover its idiosyncrasies it's livable-with.
Perhaps there is some context missing: the packages are managed as logical groups, via component IDs, and the component IDs are managed in a central software deployment server. The software deployment server is capable of deploying the package or packages to unlimited number of systems in parallel, the only bottleneck being the network itself. My take on systems like cfengine and puppet is that they are inherently complex and that they are ad-hoc and dynamic, the very thing I want to avoid. Ad-hoc is the antithesis of stability. And I want all my systems to look alike, and behave alike. Where they cannot behave alike because of some host specific configuration, I want a very iron-fisted, precise revision control, and, very importantly, I want modularity, where components can be managed in logical entities. This is the very thing that puppet and cfengine do not do - they work on individual files, directories -- although there is concept of profiles, there is no true implementation of modularity, and the worst drawback in my experience is that there is no consistency, and no encapsulation. pkgadd(1M) and pkgrm(1M) allow me to encapsulate, and make consistent, any discrete change I could ever effect on any system. Consistency is key. Also, by making my changes through the software management subsystem, I can use standard OS interfaces like pkgchk(1M) to do the kind of consistency checking that cfengine does explicitly and ad-hoc. I really, extremely dislike ad-hoc. cfengine is a different modus operandi, different architecture, different philosophy. It's based on events and actions, not processes, and that, in my experience, is a severe, severe error. > 1) CFengine can push a revised syslog.conf, and restart the service > when it does so, so that the Right Thing happens. And in doing so, will damage the system's consistency. There is no repeatability. > 2) nsswitch.conf should be configured properly post-Jumpstart (if > Jumpstart is what you're using); tell it to use DNS then, ignoring > missing-host warnings if they occur, and it'll use DNS after install. Which is what is currently done, but resolv.conf for a particular LAN comes onto the system via pkgadd(1M). That way, I can maintain iron-fisted control, and can ask the OS to tell me, which exact revision of the software component it has, via system commands - no extra software or configuration to do that is necessary. Remember, software components may contain multiple packages. > 3) The packages that install Oracle/whatever should take care of their > own users. There are actions defined for adding and removing users in > IPS packages. So you see, in that particular case, I can rely on the OS via a consistent, simple interface, to do the requested thing. No extra software will be necessary. That is exactly what I want. Now if there were only some way I could affect my own "actions"... > CFengine takes this a step further, by allowing different actions to > be taken on different machines. Suppose you define a "webservers" > group; then you can enable Apache on those machines, and disable it on > all the others. Or a "interactive" group that customers log into; on > those boxes the firewall rules can be different. That is way, waaay too interactive for my taste. All I have to do now is pick a software component, say "deploy" on those 2200 servers, and I have firewalls, ready to serve. Pick another software component, on another 3700 servers, and two-three minutes after pkgadd(1M) on those systems, I have 3700 servers with Oracle databases, ready to serve, configured exactly identically, down to the last byte. DNS, web servers, proxies, even storage and clusters... you name it, I will have it, in a matter of seconds, completely configured and serving data. You see, I don't allow anybody to ever modify files interactively. That's a guaranteed way to get oneself fired, with just enough time to pick one's personal belongings and be escorted out of the building. > You can define these > groups by the hostname of the box. I've even built rules for > 'nismaster' and 'nisslaves' that cause NIS to be installed properly on > the boxes named, and reference each other. I use an LDAP directory server. Which comes as a component which first deploys packages that configure the cluster non-interactively, then deploys the LDAP packages themselves (config package, binary package). After that, one can immediately begin using the server via the web browser; data, if any exists, is automatically fetched from either hierarchichal storage or tape. package postinstall makes sure this happens, in a reliable and interface-consistent way. And that's why if equivalents of "preinstall", "postinstall", "preremove", "postremove", and class action scripts aren't available in IPS, I'm going to have a big problem, on tens of thousands of systems. No, all of my networks are going to have a big problem. I'm not saying that IPS should provide identical mechanisms; "actions" would be just fine, as long as the package developer is allowed to develop their own actions. > My two cents is that the package system should deliver static content, Which, in my environment, is exactly what happens. Even if my packages deliver empty log files, which they do, they're marked with "v" for "volatile", so that system's consistency wouldn't be compromised. The rule is: there is not a single file on the system, that the OS doesn't know about. > and perhaps a default config file, but one should not need a new > version of the Apache package to modify the configuration file. That's exactly what I want, and how it works today: any configuration changes MUST come through a new package. But in order to be able to deploy such a package, it must go through a rigorous, automated test process in a test environment first, after passing tests, it must be approved, only then will it be able to be recognized as "available" by the software deployment server. _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx
