Introduction

I ventured to write this book in English because …
it will be more easily read in poor English,
than in good German by 90% of my intended readers.
— HANS J. STETTER, Analysis of Discretization Methods for
Ordinary Differential Equations (1973)

There is not much I could add to Mr. Stetter’s thought, except, maybe, that the number to quote probably tends more to 99% in this case than to the 90% Mr. Stetter notes. So please pardon those errors in language use that I have not yet been able to fix or even see. Suggestions for corrections and improvements are always welcome.

This book offers a cookbook-approach to configuring rsyslog. While the official documentation focusses on concepts, components and configuration statements, this book takes a completely different approach. It will not tell you about rsyslog concepts. Instead, it will offer a wide-range of recipies for configuring rsyslog so that it performs some specific task.

The individual recipies are presented with a problem description, some key facts (if necessary), required rsyslog version and the necessary configuration statements. These statements do their job, but not more. I tried to make the configurations reusable and free of side-effects. So you should be able to combine some of these recipies to form a final configuration that works exactly like you need it – just from applying the recipies. The core idea is that this should work just like in real cooking – there, you combine several recipies to create a great five-course meal. However, in cooking there are some recipies that you usually can not combine well within a single meal. The rsyslog equivalent is configurations with side effects, which may not always avoidable. If one of the configurations here has side-effects, you will be warned. It then probably is better to think twice before combining it.

When I initially started to write this book, I provided only excerpts of rsyslog.conf that showed which lines you had to add. Quickly, I received feedback that this is inadequate to make the recipies easy to use – because everyone still needed to guess where to place the excerpts. Or, even worse, place them at the wrong spots, not knowing that sequence of statements is important in rsyslog.conf.

To solve this issue, I now use a “standard” syslog config, just like can be found on many systems. Your’s may not be exactly the same, but I guess the standard config helps you find where the configuration samples need to go into. As a reference point, this is the “standard” config that all samples build on:

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none      /var/log/messages

# The authpriv file has restricted access.

authpriv.*                                    /var/log/secure

# Log all the mail messages in one place.

mail.*                                        /var/log/maillog

# Log cron stuff

cron.*                                        /var/log/cron

# Everybody gets emergency messages

*.emerg                                       *

# Save news errors of level crit and higher in a special file.

uucp,news.crit                                /var/log/spooler

# Save boot messages also to boot.log

local7.*                                      /var/log/boot.log

I was hesitant at first to use a real-life sample – repeating it in any recipe requires much space. However, I have convinced myself that this space is well spent, facilitating the adoption of the samples. Only occasionally, when I give some counter-examples, I spare myself from reproducing the full standard rsyslog.conf, hoping that the context makes clear what is meant.

In each recipe, a full rsyslog.conf, based on above example, is specified. The recipe-specific alterations to the config file are given in a different typeface, so that they can be easily identified.