On Mon, Sep 1, 2008 at 11:17, UNIX admin <tripivceta at hotmail.com> wrote: > Hi all, > > a question regarding the new IPS, that has been gnawing on me for a while now. > > First some context: I have a TON (and I mean HUNDREDS) of System V packages > that currently automate and completely encapsulate various system > configuration tasks. 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.
> For example, I have a package that automatically configures syslog.conf on a > firewall to log to a specific log file; a package that automatically modifies > $PKG_INSTALL_ROOT/etc/nsswitch.conf to use DNS; a package that automatically > adds user "oracle" and groups "dba" and "oinstall" to a system; a package to > configure the system's $PKG_INSTALL_ROOT/etc/inet/hostname to configure > "127.0.0.1" to also be a "localhost"; and so on. 1) CFengine can push a revised syslog.conf, and restart the service when it does so, so that the Right Thing happens. 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. Unless you're using DNS for something other than 'hosts'. 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. 4) This can be cfengined, but I'm not sure why you need this. > In other words, I have automated a whole bunch of system administration > tasks, thereby making them consistently repeatable via pkgadd(1M), as per the > Capability Maturity Model (CMM) level 2 and above. 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. 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. My two cents is that the package system should deliver static content, and perhaps a default config file, but one should not need a new version of the Apache package to modify the configuration file. Will
