2 - Raspberry PI Community Projects

sign (=), it corresponds to precisely and only the priority indicated (auth.=notice only concerns
messages from auth with notice priority).
Each element in the list on the selector overrides previous elements. It is thus possible to restrict
a set or to exclude certain elements from it. For example, kern.info;kern.!err means messages
from the kernel with priority between info and warn. The none priority indicates the empty
set (no priorities), and may serve to exclude a subsystem from a set of messages. Thus, *.crit;
kern.none indicates all the messages of priority equal to or higher than crit not coming from
the kernel.
9.5.2.2. Syntax of Actions
BACK TO BASICS
The named pipe, a persistent
pipe
A named pipe is a particular type of file that operates like a traditional pipe
(the pipe that you make with the “|” symbol on the command line), but via a
file. This mechanism has the advantage of being able to relate two unrelated
processes. Anything wrien to a named pipe blocks the process that writes
until another process aempts to read the data wrien. This second process
reads the data wrien by the first, which can then resume execution.
Such a file is created with the mkfifo command.
The various possible actions are:
• add the message to a file (example: /var/log/messages);
• send the message to a remote syslog server (example: @log.falcot.com);
• send the message to an existing named pipe (example: |/dev/xconsole);
• send the message to one or more users, if they are logged in (example: root,rhertzog);
• send the message to all logged in users (example: *);
• write the message in a text console (example: /dev/y8).
SECURITY
Forwarding logs
It is a good idea to record the most important logs on a separate machine (perhaps
dedicated for this purpose), since this will prevent any possible intruder
from removing traces of their intrusion (unless, of course, they also compromise
this other server). Furthermore, in the event of a major problem (such
as a kernel crash), you have the logs available on another machine, which increases
your chances of determining the sequence of events that caused the
crash.
To accept log messages sent by other machines, you must reconfigure rsyslog:
in practice, it is sufficient to activate the ready-for-use entries in /etc/
rsyslog.conf ($ModLoad imudp and $UDPServerRun 514).
202 The Debian Administrator's Handbook