* Peter Tribble <peter.tribble at gmail.com> [2007-10-07 14:02]: > [Liane] > > - I'd recommend introducing a command to manipulate and query the > > filesystem configuration. I expect some of the concerns about > > moving away from vfstab would be alleviated by a solid (and easily > > scriptable) command to query and manipulate that data. > > Absolutely. It's not just vfstab - I would oppose moving any > configuration file into the SMF repository until we have a > much better way of extracting the configuration out of the > repository. This would tell me: (i) all the properties that > currently exist, (ii) which of those aren't default, and (iii) > what the history has been. Putting configuration into SMF > avoids the morass of configuration files, but the morass of > configuration files is trivially easy to back up, compare with > originals, and put under SCM control.
I certainly wouldn't block "moving any configuration file" without a lot more information about how you see service developers and/or site administrators identifying the defaults (ii) and utilizing the history (iii). ((i) being done, of course.) smf(5) is taking snapshots and backups, so all kinds of past configuration settings are in principle available, but substantially more details are needed. The templates work will identify some aspects of default (and legitimate) values, but perhaps not all. Enhanced profiles makes configuration deviations easier to call out, but possibly not easy enough. (That said, I wouldn't move famous configuration files like vfstab until a specific story for each configuration migration has been constructed.) Finally, svccfg export (and archive) output can be placed under SCM control and managed, just like the existing files. Site practices can incorporate that capability immediately. - Stephen
