On Mon, Mar 17, 2008 at 06:55:54PM -0400, Jeffrey Hutzelman wrote:
> --On Monday, March 17, 2008 02:29:56 PM -0500 Nicolas Williams
> <Nicolas.Williams at sun.com> wrote:
>
> >Here's a thought:
> >
> > - sshd should be able to read any of the sshd_config(4) params from
> > SMF.
>
> Yes. Provided that the ability to read them from /etc/ssh/sshd_config does
> not go away.
It wouldn't go away, no.
> I'm inclined to prefer that parameters set in the config file (especially
> one given explicitly on the command line) take precedence over those found
> in SMF. In fact, I believe this is necessary in order to satisfy the
> principle of least surprise. Similarly, the as-shipped sshd_config should
> contain a comment to the effect that parameters may be set in SMF.
I was inclined to think the opposite... (so that a single config file
could be shared by multiple instances with overrides in SMF for
parameters that differ).
> >This could be implemented as follows:
> >
> > [...]
>
> This sounds fine; particularly, using the process_server_config_line()
> abstraction seems like the right thing to do.
>
> In the case of multiple property values, I would suggest concatenating them
> with space or comma separators and using the resulting string.
> Unfortunately, the choice of which separator to use depends on the
> parameter in question; directives like AcceptEnv and
> {Allow,Deny}{Users,Groups} require spaces, while Ciphers and Protocol
> require commas. I suppose one could simply normalize the parsers for these
> at the same time SMF support is added.
>
> The Subsystem directive requires special treatment, since it is used
> multiple times to declare multiple subsystems. This could be done by
> treating a multi-valued subsystem property specially, or by using a
> completely different approach for representing subsystems in smf.
Oh, very good points! Thanks!
> >Potential problems:
> >
> > [...]
>
> I think case-insensitivity is essential. Again, it is required by the
I was inclined to believe that. Now I'm convinced.
> principle of least surprise, since the existing sshd_config file is
> case-insensitive with respect to parameter names (and values in many case,
> but as you note, that is process_server_config_line()'s problem).
>
> [...]
>
> > - Performance -- there's ~80 keywords, so does this mean ~80
> > door_call()s to SMF? or can libscf get them all in one go?.
>
> Oh, I really hope so. A multiple-lookup interface to SMF would IMHO be a
> clear example of optimization which is _not_ premature.
>
> > If the former, will those ~80 door_call()s significantly slow down
> > sshd startup? I suspect this will not be a big deal, but you never
> > know.
>
> It would offend my sense of asthetics :-)
Me too :)
Thanks,
Nico
--
