Jan Pechanec wrote: >On Wed, 19 Mar 2008, James Carlson wrote: > > > >>Jeffrey Hutzelman writes: >> >> >>>So, my preference is for my platform-independent sshd_config to have the >>>same effect on the next Solaris port we do as it's had on every previous >>>platform since we started supporting ssh. >>> >>> >>The config-file-overrides-SMF but default-config-file-is-empty >>proposal I made gives you exactly that. >> >>I don't think it's necessarily the cleanest solution, as our clear >>direction in most other places is that SMF is authoritative and the >>legacy configuration files are not. What's happened to inetd.conf is >>in line with that broader system-level plan. >> >> > > I agree that if anyone comes and puts, for example, an existing >sshd_config from another system over /etc/ssh/sshd_config it should override >SMF. I see no problem having sshd_config containing only a comment stating >that by default, SMF is used, and that until the config contains at least >one keyword, SMF will continue to be used. > > I would like to say (it seems to me that Nico suggested that) that I >don't think that we should mix SMF and the config, it could be quite >confusing which means dangerous. If the config contains at least one >keyword, sshd should not consult SMF. This would have to be clearly >explained in default (empty) sshd_config. > >
While to use SMF may have been decided long ago, it doesn't mean I have to like it or what the result is of how it gets used, even if the debate is closed. Shipping config files that say "please look at SMF" is obnoxious (IMHO.) Files such as sshd_config are part documentation and part configuration. The documentation can be "why" for the configuration or relevant excerts from of sshd_config's man page or... SMF supports (at best) 50% of what these files are used for. What happens to the other 50% (or more)? Darren
