--On Tuesday, March 18, 2008 06:27:38 PM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> But one thing is clear: the architectural direction for Solaris is and > long has been to move away from configuration files whose admin > interface is $EDITOR. Sure, and I have no problem with that goal. The problem is that while an administrator of a standalone machine knows what change he wants to make, an administrator of a large number of machines knows what he wants the configuration to look like. The problem arises when you change the interface from one in which I can provide a file that says what the configuration should be to one in which I must provide a program that examines the current configuration and tries to figure out how it differs from what it should be. Such things are possible, but they are a lot of effort. An example I expect to have serious trouble with when we get around to dealing with Solaris 10 (soon, I suspect, as we're planning on deploying services in the next few months that will be built on features not found in Solaris 9) is inetd.conf. It turns out that Solaris 10 comes with a command you can run which will process inetd.conf and import the configuration into SMF. However, it doesn't work to change inetd.conf and run it again, because it doesn't do things like remove services which exist in SMF but are no longer in the inetd.conf file. Worse, Solaris comes with a number of inetd-managed services which are present in SMF but with different names than would be generated by the import tool. I suppose I should be fair. I don't hate SMF. I hate its configuration model, for the reasons described above. > It may be that we should consider always having a way to update > service configuration via files. Yes, please. > And we may need to know whether, for > example, having to run an adm command to read those is OK. That would be fine, as long as the command in question is idempotent and insures that any change made to the input will be reflected when the command is run again (this is important -- a distributed computing environment is not a static thing; things change, and it must be possible to apply updates to bring machines to the "current" configuration even when they have different start states). -- Jeff
