9.5. syslog Systemhendelser

9.5. `syslog` Systemhendelser

9.5.1. Prinsipp og mekanisme

rsyslogd-bakgrunnsprosessen er ansvarlig for innsamling av servicemeldinger som kommer fra programmer og kjernen, og deretter ekspedere dem til loggfiler (vanligvis lagret i /var/log/-mappen). Den adlyder oppsettsfilen /etc/rsyslog.conf.

Hver loggmelding er forbundet med en delsystemapplikasjon (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, etc.);
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 handlingene 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);
sende meldingen til en eksisterende navngitt kanal (example: |/dev/xconsole);
sende meldingen til en eller flere brukere, hvis de er logget inn (eksempel:root,rhertzog);
sende meldingen til alle innloggede brukere (eksempel: *);
skrive meldingen i en tekstkonsoll (eksempel: /dev/tty8).

SIKKERHET Å videresende logger

Det er en god idé å spille inn de viktigste loggene på en annen maskin (kanskje avsatt til dette formålet), siden dette vil hindre enhver mulig inntrenger fra å fjerne sporene av inntrengningen deres (med mindre, selvfølgelig, de også kompromitterer denne andre tjeneren). Videre har du, ved et stort problem (for eksempel et kjernekrasj), logger tilgjengelig på en annen maskin, noe som øker dine sjanser til å bestemme rekkefølgen av hendelser som forårsaket ulykken.

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).