subject: ssh non-intuitive logging setting. (priority names)

[Ishikawa]

Hi, thank you for the clarification.

Markus Friedl wrote:

> On Sat, Jan 06, 2001 at 01:52:06AM +0900, Ishikawa wrote:
> >    QUIET   <-> priority 0
> >    FATAL   <-> priority 1
> >    ERROR   <-> priority 2
> >    INFO    <-> priority 3
> >    VERBOSE <->          4
> >    DEBUG1  <->          5
> >    DEBUG2  <->          6
> >    DEBUG3  <->          7
>
> this mapping order is due to the history of openssh.
> ssh-1.2.12 used
>         debug(), log(), error() and fatal()
> calls (in order of importance) with the following options
>         QuietMode (only fatal() is logged, not sure about error())
>         FascistLogging (debug,log,error and fatal)
> and standard mode: log,error and fatal.
>
> in fact, you had only 3 different levels and we tried to change
> that.  additionaly, log() was far to chatty so i split all the calls:
> openssh now uses log() and for less important messages verbose().
>

Great work.

>
> so now we have:
>         QUIET           nothing
>         FATAL           fatal
>         ERROR           fatal+error
>         INFO            fatal+error+log (since Loglevel=LOG sounds strange)
>         VERBOSE         fatal+error+log+verbose
>         DEBUG           fatal+error+log+verbose+debug
>
> later we added some more debug levels.
> this is the reason for the current log levels.

Thank you for the clarification.
The above mapping of QUIET <-> nothing, etc. is the kind of info
that would be useful in the documentation.


> > For my initial purpose, after experimenting with syslog.conf and
> > the setting in sshd_config,
> > I put the following in sshd_config.
> >
> >   SyslogFacility AUTH
> >   LogLevel DEBUG2
>
> you probably want LogLevel VERBOSE

Strange thing is that the DEBUG2 setting doesn't seem too chatty
and I left the setting as is for now. I will investigate a little more.
Come to think of it,  only when the login fails or other error conditions
such as key doesn't match the expected value, the output would
be different. But under normal conditions, it is acceptable.
I will tune it to my needs.

>
> > PS: Is it possible someone
> > broke log.c and ssh.h to the point that the original
> > intent of keeping sync with UNIX priority names
> > no longer works?
> > The mis-use (in my eyes) of macronames uncovered during
> > this investigation suggested something like this happened.
>
> where? what do you mean.

I didn't know the history of log message mechanism very well and
after looking at the source code I was confused by the log priority
level name mappings.
I thought by mistake that  the mapping with the usual
UNIX priority names were lost by accident.
(Like for examples, an unexpected shuffle of lines in
the enum definition in ssh.h.)
Your description of history convinced me it is not the case.


>
> the macros don't need the cleanup. probably
> all the loging should be replace and _then_ we
> could cleanup the macro names.
>
> perhaps move from
>         fatal(), error() log(), verbose(), debug1(), debug2(), debug3()
> to
>         sshlog(CRIT, ...);
>         sshlog(ERR, ...);
>         sshlog(NOTICE, ...);
>         sshlog(INFO, ...);
>         sshlog(DEBUG1, ...);
>         sshlog(DEBUG2, ...);
>         sshlog(DEBUG3, ...);
>
> or even more levels, similar to syslog.
>
> comments?

In principle, I would go with the more levels to make the
priority levels match the use in syslog,
and hopefully the same priority names.
A common interoperability to use
UNIX priority names is a good thing to avoid the type of
confusion Andrew Stribblehill mentioned
in the case of priority level usage in TCP wrapper and sshd.

Frankly, when you mention
"You probably want LogLevel VERBOSE" I had to
go back and forth in the message and think hard about which
priority level I would need to use in syslog.conf.
A common usage will cut down the extra mental power.
Oh well. Am I getting old or what ;-)

(We could possibly simply rename
    fatal() -> crit()
    error() -> err()
    log()    -> notice()
    ...
 provided no naming conflicts occur.
Or as you suggest use ssh logging function directly.

I take that syslog() was not directly used since there
were portability issues.)