| SYSLOG.CONF(5) | File Formats Manual | SYSLOG.CONF(5) | 
syslog.conf —
syslog.conf file is the configuration file for the
  syslogd(8) program. It consists
  of extended options (lines with one key="value" assignment) and
  blocks of lines separated by program and
  hostname specifications, with each line containing two
  fields: the selector field which specifies the types of
  messages and priorities to which the line applies, and an
  action field which specifies the action to be taken if a
  message syslogd(8) receives
  matches the selection criteria. The selector field is
  separated from the action field by one or more tab
  characters.
The Selectors function are encoded as a facility, a period (‘.’), an optional set of comparison flags ([!] [<=>]), and a level, with no intervening white-space. Both the facility and the level are case insensitive.
The facility describes the part of the system
    generating the message, and is one of the following keywords: auth,
    authpriv, cron, ftp, daemon, kern, lpr, mail, mark, news, syslog, user, uucp
    and local0 through local7. These keywords (with the exception of mark)
    correspond to the similar “LOG_”
    values specified to the
    openlog(3) and
    syslog(3) library
  routines.
The comparison flags may be used to specify
    exactly what levels are logged. If unspecified, the default comparison is
    ‘>=’ (greater than or equal to), or, if the
    -U option is passed to
    syslogd(8), ‘=’
    (equal to). Comparison flags beginning with ‘!’ will have
    their logical sense inverted. Thus, ‘!=info’ means all levels
    except info and ‘!notice’ has the same meaning as
    ‘<notice’.
The level describes the severity of the message,
    and is a keyword from the following ordered list (higher to lower): emerg,
    alert, crit, err, warning, notice, info and debug. These keywords correspond
    to the similar (LOG_) values specified to the
    syslog(3) library routine.
Each block of lines is separated from the previous block by a
    program or hostname specification. A
    block will only log messages corresponding to the most recent
    program and hostname specifications
    given. Consider the case of a block that selects
    ‘pppd’ as the
    program, directly followed by a block that selects
    messages from the hostname
    ‘dialhost’. The second block will log
    only messages from the pppd(8)
    program from the host ‘dialhost’.
A program specification of the form
    ‘#!+prog1,prog2’ or
    ‘!+prog1,prog2’ will cause subsequent
    blocks to be applied to messages logged by the specified programs. A
    program specification of the form
    ‘#!-prog1,prog2’ or
    ‘!-prog1,prog2’ will cause subsequent
    blocks to be applied to messages logged by programs other than the ones
    specified. A program specification of the form
    ‘#!prog1,prog2’ or
    ‘!prog1,prog2’ is equivalent to
    ‘!+prog1,prog2’. Program selectors may
    also match kernel-generated messages. For example, a program specification
    of ‘!+subsys’ will match
    kernel-generated messages of the form ‘subsys: here
    is a message’. The special specification
    ‘!*’ will cause subsequent blocks to
    apply to all programs.
A hostname specification of the form
    ‘#+host1,host2’ or
    ‘+host1,host2’ will cause subsequent
    blocks to be applied to messages received from the specified hosts. A
    hostname specification of the form
    ‘#-host1,host2’ or
    ‘-host1,host2’ will cause subsequent
    blocks to be applied to messages from hosts other than the ones specified.
    If the hostname is given as ‘@’, the
    local hostname will be used. The special specification
    ‘+*’ will cause subsequent blocks to
    apply to all hosts.
See syslog(3) for a further descriptions of both the facility and level keywords and their significance. It is preferred that selections be made based on facility rather than program, since the latter can vary in a networked environment. However, there are cases where a facility may be too broadly defined.
If a received message matches the specified facility, and the specified level comparison is true, and the first word in the message after the date matches the program, the action specified in the action field will be taken.
Multiple selectors may be specified for a single action by separating them with semicolon (‘;’) characters. It is important to note, however, that each selector can modify the ones preceding it.
Multiple facilities may be specified for a single level by separating them with comma (‘,’) characters.
An asterisk (‘*’) can be used to specify all facilities or all levels.
The special facility “mark” receives a message at priority “info” every 20 minutes (see syslogd(8)). This is not enabled by a facility field containing an asterisk.
The special level “none” disables a particular facility.
The action field of each line specifies the action to be taken when the selector field selects a message. There are five forms:
To ensure that kernel messages are written to disk promptly,
        syslogd(8) calls
        fsync(2) after writing
        messages from the kernel. Other messages are not synced explicitly. You
        may disable syncing of files specified to receive kernel messages by
        prefixing the pathname with a minus sign
        ‘-’. Note that use of this option
        may cause the loss of log information in the event of a system crash
        immediately following the write attempt. However, using this option may
        prove to be useful if your system's kernel is logging many messages.
Normally the priority and version is not written to file. In
        order to use syslog-sign you may prefix a pathname with the plus sign
        ‘+’. If both switches are used the
        order has to be ‘+-’.
SIGHUP,
      syslogd(8) will close the
      pipe to the process. If the process does not exit voluntarily, it will be
      sent a SIGTERM signal after a grace period of up
      to 60 seconds.
    The command will only be started once data arrives that should be piped to it. If the command exits, it will be restarted as necessary.
If it is desired that the subprocess should receive exactly one line of input, this can be achieved by exiting after reading and processing the single line. A wrapper script can be used to achieve this effect, if necessary. Note that this method can be very resource-intensive if many log messages are being piped through the filter.
Unless the command is a full pipeline, it may be useful to start the command with exec so that the invoking shell process does not wait for the command to complete. Note that the command is started with the UID of the syslogd(8) process, normally the superuser.
Just like with files a plus sign
        ‘+’ will leave the priority and
        version information intact.
Blank lines and lines whose first non-blank character is a hash (‘#’) character are ignored.
If no CA is used or no trust path between CA and server certificate exists, then hash value of the server's certificate is compared with the hash given in fingerprint and the hash of the certificate in cert. If the hashes are equal then the server is authenticated.
To detect later manipulation one has to keep a copy of the key used for signing (otherwise an attacker could alter the logs and sign them with his own key). If TLS is used with a DSA key then the same key will be used for signing. This is the recommended setup because it makes it easy to have copies of the certificate (with the public key) in backups. Otherwise new keys are generated on every restart and for certain verification it is necessary to have copies of all used keys. So logging only to a local file is not secure; at least the used keys should be logged to another host.
# Log all kernel messages, authentication messages of # level notice or higher and anything of level err or # higher to the console. # Don't log private authentication messages! *.err;kern.*;auth.notice;authpriv.none /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages # Log daemon messages at debug level only daemon.=debug /var/log/daemon.debug # The authpriv file has restricted access. # Write logs with priority for later verification with syslog-sign. authpriv.* +/var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Everybody gets emergency messages, plus log them on another # machine. *.emerg * *.emerg @arpa.berkeley.edu # Log all messages of level info or higher to another # machine using TLS with an alternative portname and a # fingerprint for authentication *.info @[logserver]:1234(fingerprint="SHA1:01:02:...") # Root and Eric get alert and higher messages. *.alert root,eric # Save mail and news errors of level err and higher in a # special file. mail,news.err /var/log/spoolerr # Pipe all authentication messages to a filter. auth.* |exec /usr/local/sbin/authfilter # Log kernel messages to a separate file without syncing each message. kern.* -/var/log/kernlog # Save ftpd transactions along with mail and news. !ftpd *.* /var/log/spoolerr # Send all error messages from a RAID array through a filter. !raid0 kern.err |exec /usr/local/sbin/raidfilter # Save pppd messages from dialhost to a separate file. !pppd +dialhost *.* /var/log/dialhost-pppd # Save non-local log messages from all programs to a separate file. !* -@ *.* /var/log/foreign # Generate digital signatures for all messages # to each file or network destination. sign_sg=3
syslog.conf file appeared in
  4.3BSD, along with
  syslogd(8).
| November 9, 2013 | NetBSD 10.0 |