Nicolas Williams wrote:
>> But putting it in their will make certain things worse: such as the
>> familiarity with other OSes.
>
> Again, the config file wouldn't go away; the purpose of this proposal is
> to make it easier to setup new instances that differ very little from
> the default instance, not to completely change how sshd is configured.
For some reason I've only caught the tail end of this discussion, but
I'd like to chime in on "configuration in SMF":
While configuration outside SMF can be modified with -- as an earlier
poster stated -- "any of a number of tools", each service requires a
different combination of "any of a number of tools". Managing
changes to your system in a uniform fashion isn't easy unless you
have developed/accumulated infrastructure to do so. We'd like it to
be easy for everyone. Forcing everyone to reinvent these mechanisms
simply doesn't make sense.
I don't know the details of Nico's statement about the config file
not going away. One way to achieve this is to have a basic
configuration in SMF that satisfies most customer needs and can be
carried forward compatibly. When a service is started, that
configuration is written to a private configuration file to be used
just by the service instance. For people who need the flexibility or
compatibility offered by a configuration file, the service would also
permit specifying a configuration file that would be used in place of
any SMF-based configuration (which would default to the default
configuration file location).
The advantages of this approach are:
You can apply SMF configuration management mechanisms to your
service (and any future configuration management mechanism that are
created).
It doesn't require modifications to your third-party or open source
software.
It behavior is transparent to the administrator. The configuration
is communicated through a file format that is supposedly well-known.
(This also simplifies customizing a "basic" configuration originally
defined in SMF.)
You have 100% compatibility with old configuration mechanisms.
All configuration sources are authoritative (i.e. you don't have
the confusion of configuration being stored in two places at once).
Dave
