9.5. syslog Systemhendelser

9.5. `syslog` Systemhendelser

9.5.1. Prinsipp og mekanisme

Starting with Debian Bookworm, the rsyslog package is no longer installed by default, which in the past provided the default logging functionality. Instead, the log is provided by systemd's journal, which can be accessed by the journalctl(5) command.

There are situations, where it is necessary or desired to install rsyslog, though, e.g. to send all log messages to a central server. After installation, the rsyslogd daemon is responsible for collecting service messages coming from applications and the kernel, then dispatching them into log files (usually stored in the /var/log/ directory). It obeys the /etc/rsyslog.conf configuration file.

Hver loggmelding er forbundet med et programdelsystem (kalt «facility» i dokumentasjonen):

auth og authpriv: for autentisering;
cron: kommer fra aktivitetsplanleggingstjenester,cron og atd;
daemon: påvirker en bakgrunnsprosess uten noen spesiell klassifisering (DNS, NTP og så videre);
ftp: gjelder FTP-tjeneren;
kern: melding kommer fra kjernen;
lpr: kommer fra skriver-delsystemet;
mail: kommer fra e-post-delsystemet (the e-mail-subsystem);
news: Usenet delsystem-melding (spesielt fra en NNTP - Network News Transfer Protocol - tjener som styrer nyhetsgrupper);
syslog: meldinger fra syslogd-tjeneren selv;
user: brukermeldinger (generisk);
uucp: meldinger fra UUCP-tjeneren (Unix til Unix Copy Program, en gammel protokoll som særlig brukes til å distribuere e-postmeldinger);
local0 til local7: reservert for lokal bruk.

Hver melding er også knyttet til et prioritetsnivå. Her er listen i synkende rekkefølge:

emerg: «Hjelp!» Det er krise, systemet er sannsynligvis ubrukelig.
alert: skynd deg, enhver forsinkelse kan være farlig, det må handles umiddelbart;
crit: forholdene er kritiske;
err: feil;
warn: advarsel (mulig fare);
notice: forholdene er normale, men budskapet er viktig;
info: informativt budskap;
debug: feilsøkingsbudskap.

9.5.2. Oppsettsfilen

Syntaksen til /etc/rsyslog.conf-filen er beskrevet detaljert i rsyslog.conf(5)-manualsiden, men det er også HTML-dokumentasjon tilgjengelig i rsyslog-doc-pakken (/usr/share/doc/rsyslog-doc/html/index.html). Det gjennomgående prinsippet er å skrive «selector» og «action»-par. «Selector» definerer alle relevante meldinger, og handlingen beskriver hvordan man skal håndtere dem.

9.5.2.1. Syntaksen til velgeren (Selector)

Selektoren (velgeren) er en semikolon-delt liste med subsystem.prioritet-par (for eksempel: auth.notice;mail.info). En stjerne kan representere alle delsystemer, eller alle prioriteringer (eksempler: *.alert, eller mail.*). En stjerne kan representere alle delsystemer, eller alle prioriteringer (eksempler: auth,mail.info). Den indikerte prioriteten dekker også meldinger med tilsvarende, eller høyere prioritet; på den måten auth.alert indikerer auth subsystem-meldingene til alert, eller emerg-prioritet. Prefiks med et utropstegn (!), indikerer det motsatte, med andre ord de strengt tatt lavere prioriteringer; auth.!notice, og indikerer dermed meldinger utstedt fra auth, med info eller debug-prioritet. Prefiks med et likhetstegn (=), tilsvarer presist og bare den angitte prioriteten (auth.=notice, gjelder bare meldinger fra auth med notice-prioritet).

Hvert element i Selektor-listen overstyrer tidligere elementer. Dermed er det mulig å avgrense et sett, eller å utestenge visse elementer fra den. For eksempel betyr kern.info;kern.!err meldinger fra kjernen med prioritet mellom info og warn. none-prioritet indikerer det tomme settet (ingen prioriteringer), og kan tjene til å utelukke et delsystem fra et sett med meldinger. Dermed indikerer *.crit;kern.none alle meldingene med prioritet lik eller høyere enn crit, som ikke kommer fra kjernen.

9.5.2.2. Syntaks for handlinger

DET GRUNNLEGGENDE Den navngitte kanalen (named pipe), en vedvarende kanal

En navngitt kanal er en spesiell type fil som virker som en tradisjonell kanal (kanalen som du lager med «|» -symbolet på kommandolinjen), men via en fil. Denne mekanismen har fordelen av å kunne forholde seg til to ikke-relaterte prosesser. Alt som er skrevet til en navngitt kanal blokkerer prosessen som skriver frem til en annen fremgangsmåte forsøker å lese de data som er skrevet. Denne andre prosessen leser de dataene som er skrevet av den første, som så kan gjenoppta kjøringen.

En slik fil er laget med mkfifo-kommandoen.

De forskjellige mulige handlinger er:

å legge til en melding til en fil (eksempel: /var/log/messages);
sende meldingen til en ekstern syslog-tjener (eksempel: @log.falcot.com);
send meldingen til en eksisterende navngitt kanal (eksempelvis: |/dev/xconsole);
send meldingen til én eller flere brukere, hvis de er innlogget (eksempelvis:root,rhertzog);
send meldingen til alle innloggede brukere (eksempelvis: *);
skriv meldingen i en tekstkonsoll (eksempelvis: /dev/tty8).

SIKKERHET Videresending av logger

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 or a hard-drive failure), you have the logs available on another machine, which increases your chances of determining the sequence of events that caused the crash.

For å godta loggmeldinger sendt fra andre maskiner må du sette opp rsyslog: I praksis, er det tilstrekkelig å aktivere de ferdig-til-bruk oppføringene i /etc/rsyslog.conf ($ModLoad imudp og $UDPServerRun 514).