En liste over vanlige UNIX/LINUX-demoner i Windows OS kalles tjenester som kan brukes i forskjellige UNIX/LINUX-modifikasjoner. UNIX/LINUX-demonnavn slutter ofte med bokstaven d som en forkortelse for engelsk. demon. Du kan sjekke om prosessen/demonen kjører ved å bruke top- eller ps aux-kommandoen.

Nedenfor er en liste over navnene på de vanligste demonene og deres Kort beskrivelse. Listen over UNIX/LINUX-demoner nedenfor er ikke fullstendig/uttømmende, og UNIX/LINUX-systemet ditt kan ha en, alle eller flere av dem tilstede eller fraværende avhengig av versjon/type/modifikasjon/konfigurasjon av UNIX/LINUX-systemet og installert det er programvare på den.

Prosess/Daemon	Prosess/demonbeskrivelse
revidert	auditd er en revisjonskomponent for Linux-systemer. Opprettholder en revisjonslogg på disk, som kan vises ved hjelp av ausearch- og aureport-kommandoene. Audictl-kommandoen lar deg konfigurere revisjonsregler. Ved oppstart lastes dessuten reglene i filen /etc/audit.rules. Noen parametere for selve daemonen kan konfigureres i filen auditd.conf.
sur	acpid (ACPI event daemon) - en demon for å svare på ACPI-hendelser, for eksempel å svare på å trykke på strømknappen eller lukke lokket på den bærbare datamaskinen. Strømstyring og interaksjon mellom Linux og BIOS via ACPI (Advanced Configuration and Power Interface) og APM. ACPI "sleep"-moduser: S1 - alt sover, CPU i minimal aktivitetsmodus; S3 - "Suspend to RAM" - alt går i dvale, CPU-en slår seg av; S4 - "Suspend to Disk" er tilstandsdumpen lagret på disk, systemet er slått av, etter at systemet er slått på, gjenopprettes det fra forrige sted; S5 - programvaren slås av. http://acpid.sourceforge.net/
atd	utfører jobbkøen ved (1)
autofs	Automatisk montering av bordformat. Automount-tabeller (kartfiler) kan være filer eller NIS-tabeller som refereres til av master-automount-tabellen (se auto.master(5)). Tabellene beskriver plasseringen filsystemer, som automatisk monteres til basemonteringspunktene (sett i auto.master-filen). Dette dokumentet beskriver soltabellformatet for andre formater (f.eks. hesiod) dette dokumentet er ikke aktuelt. Tabeller kan redigeres i farten - disse endringene vil bli tatt i betraktning i neste operasjon med denne tabellen. Dette gjelder imidlertid ikke hovedtabellen auto.master!
biod	Fungerer sammen med ekstern nfsd for å løse NFS-klientforespørsler.
certmonger	Certmonger-demonen overvåker og sjekker sertifikater for utløp, og kan valgfritt fornye sertifikater ved hjelp av en CA. Den kan administrere hele registreringsprosessen fra nøkkelgenerering til registrering og fornyelse.
cgconfig	Dette skriptet kjører cgconfigparser-verktøyet, som analyserer og konfigurerer kontrollgruppens filsystem (cgroup). For analyse brukes konfigurasjonsfilen /etc/cgconfig.conf og parameterne som er definert i den.
cgred	Daemon administrerer cgroup-regler :)
cpufreq	Skriptet laster inn kjernemoduler for å kontrollere prosessorfrekvensen.
cpuspeed	Endrer CPU-frekvensen for å spare energi. Mange moderne bærbare og stasjonære PC-er støtter denne teknologien. Den kan brukes av brukere med Pentium-M, Centrino, AMD PowerNow, Transmetta, Intel SpeedStep, Athlon-64, Athlon-X2, Intel Core 2-prosessorer. Bærbare datamaskiner anbefales å la denne demonen være aktivert. Deaktiver denne demonen hvis du vil at CPU-en skal bruke en fast frekvensverdi.
krone
cupsd	Utskriftsserver. Som tilgang til eksterne skrivere, tilgang til lokale, tilgang utenfra til lokale.
dbus	Interprosess kommunikasjonssystem ( En bredere analog av CORBA og DCOP)
dbus-demon	Daemon for å jobbe med databussen
dhcpd	Daemon for dynamisk å bestemme TCP/IP-konfigurasjon for klienter.
dnsmasq	En demon som cacher DNS-navn og gir en DHCP-server.
tidligsyslog	Å kjøre syslog-daemonen gir logging.
earlyxdm	Starter X-serveren
esound	Lyddemon, med støtte for ekstern tilgang til lydkortet
esd	Lydserver for Enlightenment-vindusbehandleren og GNOME-miljøet. ESD blander lydstrømmene til flere programmer som kjører samtidig og sender den resulterende strømmen til lydkortet. Tilhører esound-pakken.
fam	FAM ( Filendringsovervåking) - filendringsmonitor. FAM-demonen brukes av skrivebordsmiljøer som GNOME, Xfce og KDE for å spore og vise endringer som er gjort i filsystemet. Inkludert i fam-pakken. Har en beskrivelse på wiki.archlinux.org.
viftekontroll	CPU-kjøler rotasjonshastighetskontroll. En del av lm_sensors.
fbset	Skriptet som kreves for at rammebufferen skal fungere. Konfigurerer driften, inkludert lasting av kjernemoduler.
festival	En demon som lar tekstleseprogrammer fungere.
fingerd	Gir et nettverksgrensesnitt for fingerprotokollen, for bruk med fingerkommandoen.
firstboot	Tjenesten er kun spesifikk for Fedora. Den kjører bare én gang etter installasjonen etter installasjonsoppsett (angi root-passordet, legger til brukere osv.). Kan deaktiveres etter systeminstallasjon.
ftpd	Tjeneste for overføring av filer via FTP-protokoll.
funksjoner	Et av Arch Linux-systemets initialiseringsskript. Den beskriver funksjonene som overstyrer verdiene som brukes ved lasting til runlevel 3. Skriptet brukes kun hvis brukeren bruker runlevel 5. Det er en del av initscripts.
gpm	Musserver for konsoll og xterm. Inneholdt i pakken med samme navn.
gpsd	Grensesnitt for kommunikasjon med GPS-utstyr. De fleste brukere kan slå den av.
Haldaemon, hal	HAL står for Hardware Abstraction Layer. En kritisk tjeneste for å samle informasjon om utstyr fra ulike kilder. Det anbefales å la det være aktivert.
stoppe	Slå av og start skriptet på nytt.
stopp.lokal	Et skript hvis kommandoer må utføres før en avslutning eller omstart starter.
helsed	Stiller inn driftstemperaturområdet til hovedkortet/prosessoren og kjølehastighetene. Det er en av lm_sensors-komponentene.
heimdal-kdc	Nøkkeldistribusjonssenter. Inkludert i heimdalspakken.
httpd	Apache Web Server Daemon.
i det	Et Unix-program som skaper alle andre prosesser. Som standard har init-demonen 7 utførelsesnivåer, som hver kjører et forhåndsdefinert sett med systemtjenester. Løpenivåer: 0 - Systemavslutning 1 - Enbruker driftsmodus 2-5 - Multi-user driftsmoduser for systemet Flere detaljer om kjørenivåer: less /etc/inittab
inetd	Overvåker nettverksforespørsler. Hvis forespørselen er gyldig, starter en bakgrunnsprosess for å betjene forespørselen. Noen systemer bruker en utvidet versjon - xinetd
iptables	Standard brannmur i Linux. Spesielt anbefalt for direkte kontakt til Internett (via kabel, DSL, T1). Anbefales ikke hvis du i tillegg bruker en maskinvarebrannmur (Netgear, Linksys, D-Link, etc.).
ip6-tabeller	iptables-tjenesten fungerer ved hjelp av IPv6-protokollen. Hvis du har deaktivert IPv6-støtte, bør denne tjenesten være deaktivert. Ellers anbefales det å la det være aktivert.
irda	IrDA er nødvendig for å støtte enheter som opererer via infrarød ( bærbare datamaskiner, PDAer, mobiltelefoner, kalkulatorer (oversetterens notat: kalkulatorer? o_O), etc. De fleste brukere kan slå den av.
irexecd	Demon for infrarød. Leveres med lirc-utils.
irqbalance, irq_balancer	I multiprosessorsystemer brukes det til å distribuere avbrudd mellom prosessorer. Brukere som ikke har multiprosessor datamaskiner/bærbare datamaskiner kan deaktivere denne demonen/tjenesten. Aktivering av denne tjenesten på en enkelt prosessordatamaskin vil ikke ha noen effekt. På nye datamaskiner med mer enn én prosessor (Intel Core 2 Duo, AMD X2), må denne tjenesten være aktivert.
ivman	Daemonen er ansvarlig for automontering av enheter i systemet (CDer, USB-stasjoner, etc.)
jackd, jack-lyd-tilkoblingssett	Lydserver
jexec	Gir støtte for å starte og kjøre applikasjoner i java - JAR. Vil være tilgjengelig hvis du installerer Java fra Sun. Dette er valgfritt og kan deaktiveres.
joystick	Et skript som laster inn kjernemoduler for at joysticken skal fungere.
kadmind	Daemon for å bestemme kontoene som har tilgang til Kerberos-databasen og deres tilgangsnivå. Det er en av komponentene i heimdalspakken.
kdump	kdump - vis kjernesporingsdata. Kommandoen viser kjernesporingsfilene produsert med ktrace(1) i lesbart format. Som standard vises filen ktrace.out i gjeldende katalog.
kbd	Sette opp tastaturet i den virtuelle terminalen.
kdm	KDM ( KDE Display Manager) er et av programmene i kdebase-pakken ( inkludert i KDE), som gir muligheten til å logge på via et grafisk grensesnitt.
kpasswd	Daemon for å endre passord i Kerberos. Det er en av komponentene i heimdalspakken.
ksysguardd	KDE-demon for systemovervåking.
libvirtd	Daemon for å administrere QEMU gjestemaskiner og nettverk.
libvirt-gjester	Et skript som setter gjesteoperativsystemer i hvilemodus når de slås av og vekker dem når de lastes inn.
lircd	LIRC-demonen dekrypterer signaler som kommer fra den infrarøde porten. Leveres med lirc-utils.
lircmd	LIRC-demon som oversetter musesignaler. Leveres med lirc-utils.
lvm2-skjerm	Daemon for overvåking av LVM (Logical Volume Management). Anbefalt hvis du bruker LVM, ellers la den være deaktivert.
lpd	"Line Printer Daemon" - protokollen brukes til å administrere utskriftsspolen.
mdadm	Daemonen overvåker MD-enheter (programvare-RAID i Linux).
mdmonitor og mdmpd	Disse to demonene brukes i lagringssystemer med RAID-arrayer (redundant rekke rimelige/uavhengige disker). Mdmonitor starter, stopper og starter på nytt mdadm (multipath device monitoring and management), en RAID-overvåkings- ogte. Du trenger bare å kjøre denne tjenesten hvis systemet ditt har RAID-enheter.
meldingsbuss	Interprosess kommunikasjonstjeneste for Linux. Kritisk komponent fordi den er koblet til D-BUS. Det anbefales sterkt å la det være aktivert.
mikrokode_ctl, mikrokode.ctl	En tjeneste som lar deg oppdatere fastvaren til en Intel-prosessor (Pentium Pro, PII, Celeron, PIII, Xeon, Pentium 4, og så videre). Oppdateringer registreres hver gang du laster ned. Skal bare være aktivert hvis du har en Intel-prosessor.
mcelog, mcelogd	For å overvåke maskinvareproblemer i 64-bit Linux-bygg er det praktisk å bruke mcelog-pakken, som analyserer MCE (Machine Check Exception) status i AMD og Intel CPUer, noe som kan indikere problemer med minne og CPU cache, datautvekslingsfeil mellom CPU-en og hovedkortets brikkesett.
mpd	Musikkspiller Daemon - musikkspillerå ha en klient-server-arkitektur som spiller musikk fra en spesifisert katalog.
flerveis	Brukes til å overvåke Multi-Path-enheter, det vil si stasjoner som kan nås av mer enn én kontroller eller metode.
mysqld, mysql	MySQL Database Daemon
nfsd	NFS-operatørforespørselsprosess for klientsystemer. Historisk sett støtter hver nfsd-demon én forespørsel om gangen, så flere kopier blir lansert.
netkonsoll	Lar deg eksportere konsollen til en annen maskin over nettverket. Kan være deaktivert som standard.
netfs	Under oppstart monterer den automatisk filsystemer tilgjengelig over nettverket ( NFS, Samba og andre). De fleste stasjonære og/eller bærbare brukere kan slå den av.
Nettverk	Daemon ansvarlig for å lage og konfigurere lokale nettverksgrensesnitt (LAN)
nettverksfjernere	Samme som den forrige, men øker i tillegg trådløse grensesnitt
nfs, nfslock	Tjenestene gir et standard nettverksfilsystem for Unix/Linux- og BSD-operativsystemer. Hvis du trenger å åpne tilgang via NFS, la den være aktivert, ellers kan du slå den av.
nginx	nginx er en webserver og e-postproxy-server som kjører på Unix-lignende operativsystemer.
nmbd	Samba brukes. Se Samba nedenfor.
nscd	Serverdemon som cacher navn og passord som brukes av tjenester som NIS, NIS+, LDAP, hesiod. Kan slås av.
nslcd	lokal LDAP-navnetjenestedemon.
ntpd	NTP-demon som styrer tidssynkronisering over nettverket. xntpd er utstyrt med versjon 3 av NTP-standarden.
ntpdate
oddjobd	oddjobd-demonen tilbyr com.redhat.oddjob-tjenesten på den systemomfattende meldingsbussen. Hvert anlegg som oddjobd tilbyr er gitt som en separat D-Bus-metode.
openntpd	Server og klient for tidssynkronisering.
openvpn	Gir en sikker metode for å lage en VPN. Til tilleggsinformasjon se OpenVPN. Kan bli deaktivert hvis den ikke brukes av NetworkManager.
pcmcia	Gir støtte for pcmcia standard utvidelseskort. Brukes vanligvis bare på bærbare datamaskiner.
pcscd	Gir støtte for kortlesere og smartkort. Hvis du ikke har kortleser eller smartkort, kan du slå av denne tjenesten. Ofte tilgjengelig på bærbare datamaskiner.
portreserve	Hindrer tilgang til ekte porter for ulike RPC-tjenester og prioriterer reserverte applikasjoner. Mer detaljert informasjon finnes på portreserve man-siden. Det anbefales å la det være aktivert.
strømbrudd	Dette skriptet kjøres når meldinger fra UPS oppdages
postfix	Postfix e-postbehandlingsprogram
pppd	Point-to-Point Protocol Daemon
ppp	Skript for å jobbe med pppd-demonen.
psact	Administrerer Linux-kjerneprosesser. Engasjert i overvåking.
rense-kjerner	Manus til automatisk sletting gamle kjerner ( konfigurert i /etc/zypp.conf)
quota_nld	kvote netlink melding daemon
rå	Skriptet laster inn rå enhetsmoduler.
rdisk	Network gateway discovery daemon, rdisc, fungerer som en ICMP Gateway Discovery Protocol-klient. rdisc kalles ved oppstart for å hente nettverkets rutingtabeller med standard gatewayer.
rdato	tjenesten er nødvendig for å synkronisere datamaskinen med tidsserveren ved oppstart operativsystem. Kan deaktiveres.
gjenopprettekond	Brukes til å gjenopprette kontekst og overvåke SELinux-policy relatert til filer. Tjenesten er ikke nødvendig, men anbefales ved bruk av SELinux.
rngd	rngd - Sjekk og mate tilfeldige data fra maskinvareenhet til tilfeldig kjerneenhet. Bokstavelig talt kan det oversettes som en demon som sjekker og mottar tilfeldige data fra maskinvareenheter for kjernen til tilfeldige enheter - hvor smart det er :), tilfeldig tallgenerator-demon, på russisk demonen for å generere tilfeldige tall.
rpcbind	Daemon for å administrere RPC-er som brukes av andre tjenester (som NFS eller NIS). Fungerer på samme måte som portmap. Kan deaktiveres hvis det ikke er andre tjenester som er avhengige av det.
rpcgssd, rpcidmapd, rpcsvcgssd	NFS v4 (Network File System) brukes. Deaktiver hvis du ikke trenger NFS v4. http://ru.wikipedia.org/wiki/Network_File_System
rsyslog	rsyslog tjener til praktisk innsamling og behandling av systemlogger og posisjonerer seg som en utvidet syslogd-modul for Unix-systemer og Linux, som fokuserer på sikkerhet og pålitelighet, og som også har avansert multi-threading. Rsyslog tilbyr et bredt spekter av funksjoner, som du kan finne ved å klikke på lenken - RSyslog-funksjoner. http://www.rsyslog.com/module-Static_Docs-view-f-features.html.phtml
rsync	rsync( Ekstern synkronisering) er et program for UNIX-lignende operativsystemer som synkroniserer kataloger og filer flere steder samtidig som trafikken minimeres, ved bruk av datakoding om nødvendig. rsync ble opprettet som en erstatning for rcp og scp. Les mer...
saslauthd	SASL-autentiseringsserverdemon. SASL ( Enkelt autentiserings- og sikkerhetslag) gir muligheten til å autentisere i protokoller basert på eksterne tilkoblinger.
samba, smbd	Samba server daemon.
sendmail	Gir støtte for lokal IMAP- eller POP3-tjeneste, la den være aktivert. Tjenesten kan være nyttig for å varsle om aktiviteten til ulike demoner/tjenester, som kan leveres via cron eller sending av e-post fra PHP-skript.
sensord	Daemonen fra lm_sensors samler informasjon fra ulike sensorer.
sensorer	Et skript som om nødvendig laster inn de nødvendige kjernemodulene for å fungere med lm_sensors.
strandvegg	Skript for å administrere shorewall-brannmuren.
slank	Innloggingsansvarlig for X'er.
smartd	SMART-demonen overvåker disker. Brukes til å forutsi feil og overvåke stasjoner eller harddiskproblemer. Vanligvis trenger ikke brukere denne demonen, men det anbefales fortsatt (spesielt for servere) å la den være aktivert.
smb	SAMBA-demonen er nødvendig for å åpne fellesen nettverkstilgang til filer på Linux for Windows-brukere. Må være aktivert hvis du har Windows-maskiner på nettverket som må gis tilgang til filer.
smolt	En demon som sender informasjon månedlig for å samle inn statistikk for å hjelpe utviklere. Statistikk er tilgjengelig for alle. Brukere som ønsker å hjelpe utviklere må aktivere denne tjenesten.
snmpd, snmptrapd	Gi SNMP-støtte ( Enkell), som kan brukes til å administrere og konfigurere enheter som nettverkshuber, servere, skrivere osv. og så videre. Kan deaktiveres, men kan være nødvendig for å kjøre HP Print Services ( hplip).
akkar	Squid proxy-demon.
sshd	Lytter etter sikre shell-forespørsler fra klienter. SSH lar andre brukere logge på over nettverket fra en annen datamaskin og kjøre applikasjoner på datamaskinen din, vanligvis brukt for ekstern administrasjon. Dette kan være en potensiell sikkerhetsrisiko. På arbeidsstasjoner som ikke krever ekstern tilgang, er det lurt å slå den av.
sssd	SSSD ( System Security Services Daemon) gir tilgang til eksterne autentiseringsmekanismer. Dette visker ut grensen mellom nettverk og lokal autentisering og tillater bruk av ulike mekanismer. Informasjon om brukere overføres av en database kalt et domene og kan være en datakilde for ekstern autentisering. Flere mekanismer er tillatt, slik at flere servere kan implementere forskjellige navneområder. Den mottatte informasjonen leveres til eksterne applikasjoner ved bruk av standard NSS- og PAM-grensesnitt. SSSD kjører som et sett med tjenester som er uavhengig av applikasjonen som kaller dem, så applikasjoner trenger ikke å starte sine egne tilkoblinger til eksterne domener, og de trenger heller ikke vite hvilken demon/tjeneste som er i bruk. Lokal bufring av gruppeinformasjon og identitetsdata tillater uavhengig av datakilden ( LDAP, NIS, IPA, DB, Samba, etc.) fortsetter å jobbe offline, noe som totalt sett forbedrer produktiviteten. SSSD kan tillate flere leverandører av samme type ( for eksempel LDAP).
svnserve	svn server daemon.
sysstat	Sysstat-pakken inneholder verktøy for å overvåke systemytelse og ressurser som brukes.
bytte	Kopierer den lokale prosessen til bytteplass for å fikse den fysiske minnesiden for kjernen. Også kalt skjema.
syslogd	Systemprosess for opptak av ulike systemmeldinger.
syncd	Synkroniserer med jevne mellomrom med systemminne etablert systemfiler.
syslog-ng	Daemonen fører systemlogger.
udev-post	Systemenhetsbehandler brukt av udev. Som standard støtter udev et stort antall regler, atferd og tillatelser for enheter. Ved å bruke denne tjenesten kan du trygt administrere regler. Det anbefales å la det være aktivert.
vhand	Frigjør minnesider for bruk av andre prosesser. Også kjent som "side stjele daemon".
vsftpd	vsftpd ( Very Secure FTP Daemon - Very Secure FTP Daemon) - FTP-server som støtter IPv6 og SSL. vsftpd brukes som standard på mange UNIX-lignende operativsystemer, betjener også de offisielle depotene ftp.openbsd.org, ftp.freebsd.org, ftp.debian.org, ftp.redhat.com og brukes på den offisielle Linux-kjerne-FTP server.
webmin	Systemadministrasjonstjeneste via nettleser ( nettgrensesnitt).
winbind	En tjeneste som hjelper deg å skille på nettverket datamaskinnavn under Windows-kontroll. Kan brukes til å kontrollere kontoer Windows med Linux-kontoer. Vanligvis trenger de fleste brukere ikke denne demonen og kan la den være deaktivert.
wpa_supplicant	Tjenesten er nødvendig å jobbe med trådløse kort, som brukes til å koble til tilgangspunkter ( VPN- eller Radius-servere) krever WPA-kryptering. De fleste brukere kan la den være deaktivert.
xfsd	Serverer X11-fonter for eksterne klienter.
yam	tjeneste for oppdatering av RPM-pakker installert på systemet. Brukes primært i Fedora Core.
ypbind	Tjenesten brukes til NIS-autentisering over nettverket. Hvis NIS-autentisering ikke brukes, kan du deaktivere den.
zvbid	En tjeneste som gir tilgang fra V4L- eller V4L2-enheter til flere applikasjoner. For eksempel kan et kort for å fange Hauppage bruke denne tjenesten, i andre tilfeller kan den slås av.

Hvis listen ovenfor over UNIX/Linux-demoner/tjenester ikke fungerer på systemet ditt, da for å få hjelp om en slik tjeneste bruk mann name_daemon, og hvis det ikke er informasjon om den løpende tjenesten der, da skriv i kommentarfeltet og sammen vil vi samle informasjon om en slik tjeneste og legge til listen over UNIX/Linux-demoner/tjenester gitt her.

Hvis det ikke er noen beskrivelse av tjenesten i mann name_daemon-hjelpen, da daemonen/tjenesten kan være et virus, i dette tilfellet, søk etter den kjørbare filen der navn_daemon er og send den for analyse til et viruslaboratorium - dette kan gjøres uten å installere et antivirus via nettgrensesnittet, for eksempel http://vms.drweb.com/online/, http://www.esetnod32.ru/.support/scanner/ eller https://www.virustotal.com/.

Laster ned UNIX/LINUX-demoner/tjenester automatisk

Nedenfor er detaljerte instruksjoner for å administrere oppstart av demoner/tjenester i de vanligste modifikasjonene/versjonene av UNIX-lignende OS som f.eks CentOS Linux, Debian Linux og BSD type OS. I andre modifikasjoner/versjoner av UNIX-lignende operativsystemer har administrasjonen av autoloading av demoner/tjenester en lignende prosedyre, selv om den kan ha noen mindre eller til og med radikale forskjeller!

Laster automatisk demoner/tjenester på CentOS Linux

CentOS har definerte belastningsnivåer i henhold til System V-prinsippet og er malt i filen /etc/inittab, les mindre /etc/inittab .

Katalogene for hvert lastenivå er navngitt og plassert i katalogen /etc/rc.d.

I hver av katalogene som tilsvarer et bestemt belastningsnivå er det skript, eller rettere sagt lenker til dem, med instruksjoner for å starte daemonen/programmet/tjenesten, og selve skriptene med instruksjoner for å starte daemonen/programmet/tjenesten ligger i /etc-katalogen /rc.d/init.d

Et eksempel på skript som kontrollerer lanseringen av en demon/program/tjeneste kan sees ved å kjøre mindre /etc/rc.d/init.d/mysqld eller mindre /etc/rc.d/init.d/sshd . Vanligvis vises skript som kontrollerer lanseringen av en demon/program/tjeneste i /etc/rc.d/init.d/ og er koblet til kataloger på kjørenivå etter programvareinstallasjon, og statusen deres er av/på for hvert løpsnivå kontrollert av chkconfig-verktøyet.

Du kan se hvilke demoner som kjører på forskjellige kjørenivåer med kommandoen chkconfig --list. Du kan aktivere demonen til å kjøre automatisk i alle kjøringsnivåene ved å bruke kommandoen chkconfig --level 345 mysqld on , og slå av chkconfig --level 345 mysqld henholdsvis av, chkconfig –del service_ name for å slette en tjeneste, chkconfig service_name på |av for å aktivere eller deaktivere en tjeneste på alle nivåer.

Når det gjelder å legge til skript til oppstart, da Til automatisk nedlasting skript serveres av /etc/rc.local, i /etc/rc.local er det nok å legge til hele banen til skriptet, for eksempel: /root/scripts/script.sh eller /bin/sh /root/scripts/script.sh . Hvis det ikke er noe oppstartskontrollskript i /etc/rc.d/init.d/ etter installasjon av programvaren ønsket program, da er det lettere å legge til initialiserings-/lanseringslinjen til /etc/rc.local.

Det er et verktøy kalt ntsysv for å administrere kjørenivåer, man ntsysv.

Laster automatisk demoner/tjenester på Debian Linux

Katalogene for hvert oppstartsnivå i Debian Linux er også navngitt rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d Men, plassert ikke lenger i /etc/rc.d-katalogen, men i roten til /etc-katalogen

Det var skript med instruksjoner for å starte daemonen/programmet/tjenesten, eller rettere sagt symbolske lenker til dem er plassert i /etc/rc?.d-katalogene hvor er tegnet? tilsvarer belastningsnivået, og Selve skriptene med instruksjoner for å starte daemonen/programmet/tjenesten ligger i katalogen /etc/init.d. Et eksempel på en slik skipt, basert på hvilken du kan skrive din egen, finner du i filen mindre /etc/init.d/skeleton.

Nedenfor vil vi gi en forklaring på tjenesteinformasjonen som brukes i skriptmalen /etc/init.d/skeleton:

• Gir: Beskriver objektene levert av dette skriptet (arg1, agr2, ...) på en slik måte at når skriptet kjøres med argumentstart, anses disse objektene å eksistere, og derfor andre skript i init som krever eksistensen av disse objekter vil kunne starte på et mer sent stadium. Vanligvis kan du bruke navnet på skriptet som objektet, men du kan også bruke navnet på tjenesten det erstatter. Virtuelle objekter er ikke angitt her. De er definert utenfor init.d-skriptene
• Nødvendig-start: Angir objekter som må eksistere for å kjøre skriptet. Om nødvendig kan du bruke virtuelle objekter som beskrevet nedenfor. Hvis objekter ikke er spesifisert, kan skriptet startes umiddelbart etter start, uten å måtte koble til lokale filsystemer, starte systemloggen, etc.
• Nødvendig stopp: Spesifiserer objektene som brukes av tjenesten, levert av skriptet. Objektet som leveres av dette skriptet må fullføres før objektene som er oppført her fullføres for å unngå konflikter. Vanligvis er de samme objektene angitt her som i Required-Start
• Bør-starte: Spesifiserer objektene som, hvis de eksisterer, skal startes før tjenesten som tilbys av dette skriptet. Dette åpner for svake avhengigheter som ikke fører til at tjenesten mislykkes hvis objekter ikke er tilgjengelige. Du kan bruke virtuelle objekter etter behov, som beskrevet nedenfor.
• Bør-Stopp: Spesifiserer objekter som, hvis de eksisterer, skal stoppes etter av denne tjenesten. Vanligvis er de samme objektene spesifisert her som i Bør-Start
• Standard-start: Angir kjørenivåene der skriptet skal startes (stoppes) som standard. For eksempel, hvis tjenesten skal startes på bare nivå 3, 4 og 5, spesifiser "Standard-Start: 3 4 5" og "Standard-Stopp: 0 1 2 6".
• Kort beskrivelse: Angir en kort beskrivelse av skripthandlingen. Begrenset til én linje.
• Beskrivelse: Angir en mer detaljert beskrivelse av skripthandlingen. Kan være på flere linjer, i så fall må hver beskrivelseslinje begynne med et #-tegn etterfulgt av et tabulatortegn eller minst 2 mellomrom. Beskrivelsen slutter før en linje som ikke samsvarer med denne betingelsen.
• X-Start-Before, X-Stop-After: Spesifiserer inverse avhengigheter som har samme betydning som om de var spesifisert i bør-start og bør-stopp i pakkene som er spesifisert her.

Nøkkelordene gir, påkrevd- og bør- er viktige for å spore avhengigheter. Resten blir ikke brukt. Kjørenivåer brukes av programmet som standard for å organisere skript ( for eksempel insserv) for å holde styr på hvilken katalog rc?.d oppdatere når en tjeneste først legges til og skal gjenspeile formålet med tjenesten. Her er noen "virtuelle" objekter:

• $local_fs- Alle lokale filsystemer er tilkoblet. Alle skript som skriver til /var/ bør avhenge av dette med mindre de allerede er avhengige av $remote_fs
• $nettverk- lavnivånettverk, dvs. nettverkskort, kan innebære at PCMCIA kjører
• $navngitt- Demoner som kan gi domenenavnoppløsning antas å kjøre. For eksempel DNS, NIS+ eller LDAP
• $portmap- Demoner som leverer SunRPC/ONCRPC portmapping-tjenesten som spesifisert i 1833 (hvis noen)
• $remote_fs- Alle filsystemer er tilkoblet. Skript som må kjøres under en systemavslutning før et kill-signal sendes til alle prosesser, må avhenge av $remote_fs.
• $syslog- systemloggen fungerer
• $tid- riktig systemtid er satt, for eksempel ntp eller rdate, eller RTC
• $all- Kjører skriptet så sist som mulig

Daemon autoloading i Debian Linux styres ved hjelp av verktøyet update-rc.d, beskrevet i man update-rc.d . Update-rc.d-verktøyet oppretter eller sletter ikke annet enn symbolkoblinger i /etc/rc?.d til de såkalte init-skriptene som styrer start og stopp av daemonen/programmet/tjenesten, som ligger i katalogen /etc/init.d.

Hvis skriptet for autostart av daemonen/tjenesten opprettes manuelt ved å bruke malen /etc/init.d/skeleton, så må du først plassere den i katalogen /etc/init.d, deretter opprette en symbolsk lenke til dette skriptet i katalogen /etc/rc?.d, hvor? - runlevel nummer ( systembelastningsnivå). Den symbolske lenken skal se slik ut: S№№script_name, hvor No. er startordrenummeret, hvis du vil legge igjen en symbolsk lenke, men ikke kjøre skriptet midlertidig, bør den symbolske koblingen endres til denne tilstanden script_name.

Før noe utførelsesnivå kan behandles, blir alle skript som begynner med bokstaven " utført først. K" (disse skriptene stopper tjenester), og deretter kjøres alle skript som begynner med bokstaven S" (disse skriptene starter tjenester). Det tosifrede tallet etter bokstaven "S" eller "K" indikerer rekkefølgen skriptene vil bli utført i. Skript med et lavere tall kjøres først, for eksempel: S01script_name vil starte først, og S09script_name vil bli lansert som niende.

For å lage en symbolsk lenke, bruk programmet ln -s file1 file2 , Hvor nøkkel -s snakker om å lage en symbolsk lenke, fil 1 peker på en eksisterende fil, og fil 2 navnet på den nye lenken, men i stedet for å lage symbolske lenker manuelt, kan du bruke verktøyet update-rc.d, som er designet spesielt for å lage symbolske lenker i /etc/rc?.d til skript fra /etc/init. d.

Update-rc.d-syntaksen er slik: legger til med standard parametere update-rc.d defaults , fjerning og stopp av daemon/service update-rc.d -f fjern && update-rc.d stopp 20 2 3 4 5 . Start og stopp av demoner/tjenester kan kontrolleres gjennom tjenestenavnet start|stop|restart script.

Ærlig talt er update-rc.d et relativt ugjennomsiktig verktøy, Chkconfig-verktøyet er mer praktisk, som ikke er tilgjengelig som standard på Debian Linux. For å installere det, må vi legge til flere depoter, det anbefales å bare bruke offisielle Debian Linux-pakkelager, til slutten av listen vi /etc/apt/sources.list, eksempel sources.list i Debian GNU/Linux 6.0.5 _Squeeze_ - Offisiell i386:

# # deb cdrom:/ squeeze main deb cdrom:/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-updates , tidligere kjent som "flyktig" # Et nettverksspeil ble ikke valgt under installasjonen. Følgende oppføringer # er gitt som eksempler, men du bør endre dem etter behov # for din valgfritt speil. # # deb http://ftp.debian.org/debian/ squeeze-updates main # deb-src http://ftp.debian.org/debian/ squeeze-updates main deb http://backports.debian.org/ debian-backports squeeze-backports main deb http://ftp.debian.org/debian/ squeeze main #deb http://repo.yandex.ru/debian squeeze main contrib #deb http://mirror.yandex.ru/ debian squeeze main contrib #deb http://mirror.yandex.ru/debian-multimedia/ squeeze main contrib

Oppdater deretter listen over pakker med apt-get update og installer chkconfig apt-get install chkconfig , og som et alternativ kan du i tillegg installere sysv-rc-conf apt-get install sysv-rc-conf . Hvordan bruke chkconfig-verktøyet ble nevnt ovenfor, se i tillegg man sysv-rc-conf og man chkconfig.

Når du legger til Debian Linux-depoter, vær oppmerksom på programvarepolicyene som gjelder for hvert av områdene som hoved, bidrag og ikke-gratis:

• hoved-: - Pakkene i dette området er en del av den komplette Debian Linux-distribusjonen, og ingen av pakkene i hovedområdet krever programvare fra utenfor dette området for å fungere fullt ut. Alle kan fritt bruke, dele, endre og distribuere pakker fra hovedområdet.
• bidra: - Pakker fra dette området kan distribueres fritt, men noen av deres avhengigheter er kanskje ikke gratis.
• ikke-fri: - inneholder pakker som ikke kan distribueres gratis i henhold til DSFG, og pakker fra området kan inneholde feil som ikke tas i betraktning ved utvikling og oppdatering av Debian Linux.

For å kjøre andre skript og programmer automatisk i Debian Linux, kan du bruke den gode gamle /etc/rc.local.

Systemadministratorer og vanlige Linux-brukere må ofte se på loggfiler for å feilsøke problemer. Faktisk er dette det første en systemadministrator bør gjøre når det oppstår feil i systemet.

Selve Linux-operativsystemet og de kjørende applikasjonene genererer ulike typer meldinger som logges i ulike loggfiler. Linux bruker spesiell programvare, filer og kataloger for å lagre loggfiler. Å vite hvilke filer som inneholder loggene over hvilke programmer vil hjelpe deg å spare tid og løse problemet raskere.

I denne artikkelen vil vi se på hoveddelene av Linux-loggingssystemet, loggfiler, samt verktøy som du kan se Linux-logger med.

De fleste filer Linux-logger er plassert i mappen /var/log/ Du kan liste opp loggfilene for systemet ditt ved å bruke ls-kommandoen:

Rw-r--r-- 1 rotrot 52198 10. mai 11:03 alternatives.log
drwxr-x--- 2 rotrot 4096 14. november 15:07 apache2
drwxr-xr-x 2 rotrot 4096 25. april 12:31 apparmor
drwx------ 2 rotrot 4096 5. mai 10:15 revisjon
-rw-r--r-- 1 rotrot 33100 10. mai 10:33 boot.log

Nedenfor vil vi se på 20 forskjellige Linux-loggfiler som ligger i /var/log/-katalogen. Noen av disse loggene finnes bare på visse distribusjoner, for eksempel finnes dpkg.log kun på Debian-baserte systemer.

/var/log/meldinger- inneholder globale Linux-systemlogger, inkludert de som registreres ved systemoppstart. Flere typer meldinger er registrert i denne loggen: post, cron, ulike tjenester, kjerne, autentisering og andre.

/var/log/dmesg- inneholder meldinger mottatt fra kjernen. Logger mange meldinger under oppstartsfasen, de viser informasjon om maskinvareenheter som initialiseres under oppstartsprosessen. Du kan si at dette er en annen logg over Linux-systemet. Antall meldinger i loggen er begrenset, og når filen er full, vil de gamle overskrives med hver ny melding. Du kan også se meldinger fra denne loggen ved å bruke dmseg-kommandoen.

/var/log/auth.log- inneholder informasjon om brukerautorisasjon i systemet, inkludert brukerpålogginger og autentiseringsmekanismer som ble brukt.

/var/log/boot.log- Inneholder informasjon som logges når systemet starter opp.

/var/log/daemon.log- Inkluderer meldinger fra forskjellige bakgrunnsdemoner

/var/log/kern.log- Inneholder også meldinger fra kjernen, nyttig i feilsøking av feil i tilpassede moduler innebygd i kjernen.

/var/log/lastlog- Viser informasjon om siste økt for alle brukere. Dette er en ikke-tekstfil, og du må bruke lastlog-kommandoen for å se den.

/var/log/maillog /var/log/mail.log- logger av e-postserveren som kjører på systemet.

/var/log/user.log- Informasjon fra alle logger på brukernivå.

/var/log/Xorg.x.log- X server meldingslogg.

/var/log/alternatives.log- Informasjon om driften av update-alternatives-programmet. Dette er symbolske lenker til standardkommandoer eller biblioteker.

/var/log/btmp- Logg Linux-fil inneholder informasjon om mislykkede påloggingsforsøk. For å se filen er det praktisk å bruke kommandoen last -f /var/log/btmp

/var/log/kopper- Alle meldinger knyttet til utskrift og skrivere.

/var/log/anaconda.log- alle meldinger som tas opp under installasjonen er lagret i denne filen

/var/log/yum.log- Logger all informasjon om pakkeinstallasjoner ved hjelp av Yum.

/var/log/cron- Når Cron-demonen begynner å kjøre et program, skriver den en rapport og meldinger fra selve programmet i denne filen.

/var/log/secure- inneholder informasjon knyttet til autentisering og autorisasjon. For eksempel logger SSHd alt her, inkludert mislykkede påloggingsforsøk.

/var/log/wtmp eller /var/log/utmp - Linux-systemlogger , inneholde en logg over brukerpålogginger. Ved å bruke wtmp-kommandoen kan du finne ut hvem som er pålogget og når.

/var/log/faillog- Logg linux-systemer, inneholder mislykkede påloggingsforsøk. Bruk faillog-kommandoen for å vise innholdet i denne filen.

/var/log/mysqld.log- Linux-loggfiler fra MySQL-databaseserveren.

/var/log/httpd/ eller /var/log/apache2- loggfiler av linux11 Apache webserver. Tilgangslogger er i access_log-filen, og feillogger er i error_log

/var/log/lighttpd/ - linux logger lighttpd webserver

/var/log/conman/- ConMan-klientloggfiler,

/var/log/mail/- denne katalogen inneholder flere e-postserverlogger

/var/log/prelink/- Prelink-programmet kobler biblioteker og kjørbare filer for å fremskynde nedlastingsprosessen. /var/log/prelink/prelink.log inneholder informasjon om .so-filer som ble endret av programmet.

/var/log/audit/- Inneholder informasjon generert av den reviderte daemonen.

/var/log/setroubleshoot/ - SE Linux bruker setroubleshootd-demonen (SE Trouble Shoot Daemon) for å rapportere sikkerhetsproblemer. Denne loggen inneholder meldinger fra dette programmet.

/var/log/samba/- inneholder informasjon og logger fra Samba-filserveren som brukes til å koble til delte mapper Windows.

/var/log/sa/- Inneholder .cap-filer samlet av Sysstat-pakken.

/var/log/sssd/- Brukes av systemsikkerhetsdemonen som administrerer fjerntilgang til kataloger og autentiseringsmekanismer.

Vise logger i Linux

For å se logger på Linux er det praktisk å bruke flere kommandolinjeverktøy Linux-strenger. Det kan være hvem som helst tekstredigerer, eller spesiell nytte. Mest sannsynlig vil du trenge superbrukerrettigheter for å se logger i Linux. Her er kommandoene som oftest brukes til disse formålene:

• zgrep
• zmore

Jeg vil ikke gå i detalj på hver av disse kommandoene, siden de fleste av dem allerede er diskutert i detalj på nettstedet vårt. Men jeg skal gi noen eksempler. Å se Linux-logger er veldig enkelt:

Vi ser på loggen /var/log/messages, med muligheten til å bla:

mindre /var/log/meldinger

Se Linux-logger i sanntid:

hale -f /var/log/meldinger

Åpne dmesg-loggfilen:

cat /var/log/dmesg

Første linjer med dmesg:

head /var/log/dmesg

Vi sender bare ut feil fra /var/log/messages:

grep -i feil /var/log/meldinger

I tillegg kan du se logger på Linux ved hjelp av grafiske verktøy. Systemprogram Log Viewer kan brukes til praktisk visning og overvåkingssystemlogger på en bærbar PC eller personlig datamaskin med Linux.

Du kan installere programmet på et hvilket som helst system med en X-server installert. En hvilken som helst grafisk testeditor kan også brukes til å vise logger.

konklusjoner

I /var/log-katalogen kan du finne all nødvendig informasjon om driften av Linux. Fra dagens artikkel har du lært nok til å vite hvor du skal lete og hva du skal se etter. Nå vil visning av logger i Linux ikke føre til problemer. Hvis du har spørsmål, spør i kommentarene!

Hver av nybegynnere Linux-brukere møter før eller siden noen problemer med å sette opp og organisere funksjonen til systemet deres. Og hver av nykommerne har nesten helt sikkert hørt råd fra mer erfarne brukere: "Se på loggene." Rådene er gode, men en nybegynner må fortsatt vite: hva logger er og hvor du skal lete etter dem! Så i denne artikkelen vil jeg prøve å fortelle deg hva du skal se og hvor.

I programmeringsslang er "logger" arbeidsprotokoller som vedlikeholdes både av selve operativsystemet og uavhengig av mange programmer. Ordet "journal" brukes ofte som et synonym for ordet "protokoll" i denne forstand. Det er to hovedsituasjoner der behovet for å analysere en protokoll oppstår: når noe i systemet ikke fungerer som vi forventet (problemløsning), og når det er mistanke om at systemet har blitt hacket av en angriper og vi må finne ut hva som skjedde, hvordan det ble gjort, og hva som må gjøres for å eliminere konsekvensene av invasjonen.

En av de mest kjente tilfellene med bruk av loggfiler for å oppdage en angripers inntrenging er historien om fangsten av den berømte hackeren Kevin Mitnick av datasikkerhetsspesialisten Tsuomo Shimomura. Her er ett avsnitt fra en artikkel som beskriver hvordan dette skjedde.

"På juledag, da Shimomura gikk på ski i Nevada i ferien, brøt noen (vi vet allerede hvem) seg inn i hans supersikre hjemmedatamaskin i Solana Beach, California, og begynte å kopiere filene hans - hundrevis av klassifiserte filer. En doktorgradsstudent ved Supercomputing Center i San Diego, der Shimomura jobbet, la merke til endringer i systemets «logg»-filer og skjønte raskt hva som skjedde. Alt dette var mulig takket være det faktum at Shimomura installerte et program på datamaskinen sin som automatisk kopierer "journal"-oppføringer til en duplikat datamaskin i San Diego. Studenten ringte Shimomura, som skyndte seg hjem for å gjøre inventar over de stjålne gjenstandene."

Jeg vil ikke fortelle hele historien her, det er viktig for oss å bare merke seg at analysen av systemets driftsprotokoller fungerte som grunnlag for suksessen til etterforskningen av mishandling. Du finner en mer detaljert beskrivelse av hvordan slike undersøkelser gjennomføres i artikkelen. Men for å kunne dra nytte av resultatene av logging, må du forstå hvordan protokoller lages, hvor de lagres og hva som kan trekkes ut fra dem. Denne artikkelen er viet vurderingen av alle disse spørsmålene.

Hvordan meldinger for protokollen genereres

Vi må starte med det faktum at når programmerere oppretter programmer på C-språket, har programmerere muligheten til å sette inn anrop til spesielle funksjoner om nødvendig openlog, setlogmask, syslog Og closelog, inkludert i standardbiblioteket til C-språket. Disse funksjonene brukes til å sende meldinger om visse hendelser under programkjøring til en spesiell systemdemon syslogd, utfører systemprotokollen. Funksjon åpen logg etablerer en forbindelse med en demon syslogd, funksjon syslog genererer en spesifikk melding som skal registreres i protokollen, og funksjonen closelog lukker en åpen forbindelse.

Meldinger generert av funksjonen syslog, består av flere felt atskilt med mellomrom. Hver melding begynner med et felt PRI, som i kodet form inneholder informasjon om meldingens kategori (innretning) og alvorlighetsgrad (alvorlighetsnivå) eller prioritet (prioritet) til meldingen.

Kategori (anlegg) er informasjon om hvilken klasse denne meldingen tilhører. Kategorien er kodet med et tall fra 0 til 23. Følgende kategorier finnes (de er definert i filen /usr/include/sys/syslog.h):

Tabell 1.

Numerisk verdi	Symbol	Dekoding
0	kern	Kjernemeldinger
1	bruker	Designet for ulike meldinger fra brukerprogrammer (meldinger fra brukerprogrammer).
2	post	Meldinger fra postsystemet.
3	demon	Meldinger fra disse systemdemonene som, i motsetning til FTP eller LPR, ikke har kategorier dedikert spesifikt til dem.
4	auth	Alt relatert til brukerautorisasjon, som innlogging og su (sikkerhet/tilgangsrettigheter)
5	syslog	Loggsystemet kan logge meldinger fra seg selv.
6	lpr	Meldinger fra utskriftssystemet.
7	nyheter	Meldinger fra nyhetsserveren. (Nettnytt, USENET)
8	uucp	UNIX-til-UNIX Copy Protocol-meldinger. Det er en del av UNIX-historien, og du vil sannsynligvis aldri trenge det (selv om noe post fortsatt leveres via UUCP).
9	cron	Meldinger fra systemplanleggeren.
10	authpriv	Samme som auth, men meldinger i denne kategorien skrives til en fil som bare noen brukere kan lese (kanskje denne kategorien er valgt fordi meldinger som tilhører den kan inneholde tydelige brukerpassord som ikke skal ses av fremmede, og derfor må loggfiler ha passende tilgangsrettigheter).
11	ftp	Ved å bruke denne kategorien kan du konfigurere FTP-serveren din slik at den registrerer aktivitetene.
fra 12 til 15	-	Reservert for systembruk.
fra 16 til 23	lokal0 - lokal7	Reserverte kategorier for bruk av systemadministratoren. Local7-kategorien brukes vanligvis for meldinger som genereres under systemoppstart.

Kategori auth har et foreldet synonymt navn sikkerhet, som ikke anbefales. I tillegg er det en spesiell kategori merke(som ikke har noen digital ekvivalent), som tildeles individuelle meldinger generert av demonen selv syslogd. Denne kategorien brukes til å plassere spesielle merker i protokollen med et spesifisert tidsintervall (hvert 20. minutt som standard), som for eksempel gjør det mulig å finne ut med 20 minutters nøyaktighet når datamaskinen frøs.

Merk at kategorien generelt ikke har noe å gjøre med navnet på programmet som sender meldinger til demonen syslogd. Som de sier, enhver tilfeldighet er ren tilfeldighet. Dessuten kan noen programmer generere meldinger i forskjellige kategorier. For eksempel en demon telnetd i tilfelle mislykkede loggingsforsøk, genererer kategorimeldinger authpriv, og i andre tilfeller kategoriserer meldingene deres demon.

Den andre parameteren som feltverdien dannes på grunnlag av PRI, er meldingens nivå eller prioritet (prioritet), det vil si informasjon om graden av viktighet av meldingen. Det er 8 viktige nivåer som standard (de er også definert i filen /usr/include/sys/syslog.h), som er kodet med tall fra 0 til 7:

Tabell 2.

Numerisk verdi	Symbol	Dekoding
0	dukke opp(gammelt navn PANIC)	Nødsituasjon. Systemet er ute av drift.
1	varsling	Angst! Umiddelbar inngripen er nødvendig.
2	crit	Kritisk feil(kritisk tilstand).
3	feil(gammelt navn FEIL)	Feilmelding.
4	advarsel(gammelt navn ADVARSEL)	Advarsel.
5	legge merke til	Informasjon om en normal, men viktig hendelse.
6	info	Kunngjøring.
7	feilsøke	Meldinger generert under feilsøking.

Felt PRI Meldingen er dannet som følger: den numeriske verdien av kategorien multipliseres med 8 og legges til den numeriske verdien av prioriteten, det resulterende tallet er omsluttet av vinkelparenteser og skrevet i feltet.

Følger feltet PRI Meldingen inneholder følgende felt:

• TIDSSTIMPEL- meldingsgenereringstid,
• VERTNAVN- vertsnavn eller IP-adresse i desimalnotasjon,
• MSG- vilkårlig meldingstekst - en tekststreng (informasjons) i US-ASCII-kode (0x20 - 0x7e).

Tid (lokal!) skrives i formatet: 13. feb 21:12:06. Hvis dagnummeret er et enkelt siffer, plasseres et ekstra mellomrom (ikke 0!) foran det. Vær oppmerksom på at det ikke er årstall og sone i datoen, noe som må tas i betraktning ved organisering av langtidslagring av loggfiler. For at tiden i meldingen skal være korrekt, må den synkroniseres (for eksempel ved hjelp av NTP-protokollen).

Vertsnavnet er inkludert i meldingen for å unngå forvirring mellom meldinger fra forskjellige verter, siden, som vist nedenfor, kan logging forekomme på en av de dedikerte datamaskinene på nettverket. Vertsnavnet er det enkle nettverksnavnet til datamaskinen, uten å spesifisere domenet. Hvis en datamaskin har flere grensesnitt med forskjellige IP-adresser, kan hvilken som helst av dem brukes som vertsnavn eller adresse.

Meldingstekst ( MSG) inneholder vanligvis en etikett ( STIKKORD), som indikerer programmet eller prosessen som utstedte meldingen, og brødteksten i meldingen ( INNHOLD). Etiketten kan inneholde latinske bokstaver og tall. Vanligvis er etiketten et enkelt programnavn, noen ganger supplert med en prosessidentifikator omsluttet av firkantede parenteser. Brødteksten i meldingen er atskilt fra etiketten med spesialtegn - i Linux er disse vanligvis et kolon og et mellomrom.

Behandler meldinger av syslogd-demonen

Alle meldinger generert av individuelle programmer som bruker funksjonen syslog, sendt via stikkontakt /dev/log systemdemon syslogd, som er ansvarlig for å behandle disse meldingene. Det må sies at det faktisk lanseres to loggdemoner i systemet - syslogd Og klogd. Begge demonene er inkludert i pakken sysklogd, den nyeste versjonen som du finner på nettstedet.

Daemon klogd er ansvarlig for logging av hendelser som oppstår i systemkjernen. Behovet for en egen demon klogd på grunn av at kjernen ikke kan bruke standardfunksjonen syslog. Faktum er det standard biblioteker(inkludert biblioteket der funksjonen er plassert syslog) er kun beregnet for bruk av vanlige applikasjoner. Siden kjernen også trenger lignende funksjoner, inkluderer den sine egne biblioteker som ikke er tilgjengelige for applikasjoner. Derfor bruker kjernen sin egen meldingsgenereringsmekanisme. Daemon klogd er designet for å organisere behandlingen av disse meldingene. I prinsippet kan han utføre slik behandling helt uavhengig og uavhengig av syslogd, for eksempel ved å logge disse meldingene til en fil, men i de fleste tilfeller brukes standardinnstillingen klogd, der alle meldinger fra kjernen videresendes til samme demon syslogd.

For å sikre at demonene syslogd Og klogd kjører på systemet ditt, kjør kommandoen ps -ax | grep-loggen. Denne kommandoen ga meg følgende resultat:

$ ps -ax | grep-loggen 569? S 0:00 syslogd -m 0 574 ? S 0:00 klogd -x 1013 ? S 0:00 pålogging -- kos 1191 ? S 0:00 kalarmd --login De to første linjene indikerer at loggingsdemoner kjører i systemet.

Behandler meldinger av daemonen syslogd er at det hele tiden overvåker utseendet til meldinger og sammenligner hver innkommende oppføring med reglene som er i filen /etc/syslog.conf. Hver regel er skrevet som en fillinje /etc/syslog.conf, bestående av to felt. Det venstre feltet ("velger") spesifiserer en eller flere maler som meldinger velges etter. Mønstre er atskilt med semikolon (se eksempelfil nedenfor /etc/syslog.conf). Det høyre feltet ("handling") bestemmer rekkefølgen som valgte meldinger behandles i. Felt er atskilt med ett eller flere mellomrom eller tabulatortegn.

Hvert mønster i "velger"-feltet har formen "category.level" (det vil si "facility.priority"). Verdiene i "kategori"-feltet kan være:

• et av de konvensjonelle navnene på kategoriene oppført i tabell 1,
• flere slike navn (i dette tilfellet er de atskilt med komma)
• eller *-symbolet (som betyr "alle kategorier").

Verdiene til "nivå"-feltet kan være:

• ett av nivånavnene oppført i tabell 2,
• symbol * (ta opp alle meldinger i denne kategorien, uavhengig av nivå),
• eller ord ingen(ikke ta opp meldinger i denne kategorien).

Å spesifisere en bestemt verdi i "nivå"-feltet tolkes som "alle verdier dette nivået og høyere". Hvis du trenger å ta opp meldinger på bare ett nivå, må du sette et likhetstegn ("=") foran den angitte verdien. Hvis du vil ta opp meldinger på alle nivåer unntatt det angitte, satt foran navnet på nivået Utropstegn("!"). Å plassere disse to skiltene samtidig tolkes som "ikke ta opp meldinger på spesifisert nivå eller høyere."

Det er ingen forskjell mellom store og små bokstaver i "velger"-feltet. Du kan også bruke tall (se /usr/include/syslog.h). I tillegg til kategoriene som er oppført i tabell 1, kan du angi merke(vanlige tidsstempler) og sikkerhet(foreldet synonym for auth). I tillegg til prioritetsverdiene som er oppført i tabell 2, kan du bruke varsle(synonym for advarsel), feil(synonym for feil), panikk(synonym for dukke opp).

Når det blir funnet samsvar mellom kategorien og nivået til en mottatt melding og et av mønstrene i "velger"-feltet til en streng, syslogd behandler posten i samsvar med handlingen spesifisert i "handling"-feltet på denne linjen.

"Handling"-feltet kan inneholde

• navnet på en vanlig fil (loggfil), og den fullstendige banen til filen må spesifiseres, fra roten "/", og hvis den angitte filen ikke eksisterer, syslogd skaper det,
• navnet på det navngitte røret - FIFO; i dette tilfellet plasseres en vertikal strek ("|") foran navnet, og selve kanalen må opprettes før start syslogd team mkfifo,
• peker på en terminal eller konsoll (som i enhet: /dev/tty1),
• en indikasjon på den eksterne verten (innledet av @-symbolet),
• eller en liste over brukere (atskilt med komma) hvis terminaler en melding vil bli sendt i henhold til denne regelen. I stedet for en liste over brukere, kan du sette en stjerne (*), som vil bety at meldinger sendes til alle brukere som jobber i dette øyeblikket i systemet.

Oftest inneholder "handling"-feltet fortsatt navnet på loggfilen. Dessuten kan du sette et minustegn ("-") foran filnavnet, noe som betyr at systemet kan lagre filen i bufferbufferen, i stedet for å tømme den etter å ha skrevet hver melding til disken. Dette setter selvfølgelig fart på arbeidet, spesielt hvis mange store meldinger skrives til protokollen, men det kan føre til at noen meldinger går tapt ved en uventet systemkrasj, det vil si akkurat når slike meldinger er spesielt nødvendige . Du kan også spesifisere en skriver - /dev/lp0 - som en enhet i "action"-feltet. Dette alternativet for "handling" er tilrådelig å bruke i tilfeller der spesielt viktige systemer er involvert. Protokoller som skrives ut kan ikke slettes eller endres av hackere, så dette er en god bruk for en gammel matriseskriver.

I tillegg til linjene med reglene i filen /etc/syslog.conf kan inneholde tomme linjer og kommentarlinjer som begynner med #-symbolet. Mer om filstruktur /etc/syslog.conf Du kan lese man-siden for syslog.conf for ganske mange eksempler på regeloppføringer i denne filen. Merk at når du spesifiserer "category.level"-par i filen syslog.conf kan ikke bruke numeriske verdier, gitt i tabellene 1 og 2, er kun deres konvensjonelle navn tillatt.

Hvis en melding samsvarer med mønstrene til to eller flere strenger, vil den bli behandlet i henhold til hver av disse reglene (det vil si at meldingsbehandlingen ikke stopper ved første suksess). Dette betyr at et vilkårlig antall handlinger kan utføres for én melding. Derfor kan du skrive meldingen til en loggfil og sende den til brukeren(e) eller til en ekstern vert.

I tillegg, hvis "selektor"-feltet viser (atskilt med semikolon) flere "category.level"-par, kan påfølgende par overstyre de forrige. Du kan se et eksempel på slik kansellering i fillisten nedenfor /etc/syslog.conf: Alle meldinger hvis nivå er lik eller høyere enn info skrives til /var/log/messages-filen, men meldinger fra mail-, authpriv- og cron-kategoriene hoppes over (ikke skrevet).

Oppføring 1. Fil /etc/syslog.conf fra et system bygget på Red Hat Linux 7.1-distribusjonen (jeg oversatte bare kommentarene i denne filen til russisk og fremhevet reglene med fet skrift).

# Skriv ut alle meldinger fra kjernen til konsollen. #kern.* /dev/konsoll# Logg alle meldinger på infonivå eller høyere, # unntatt e-postsystemmeldinger som inneholder # sensitiv informasjon fra autentiseringsmeldinger og cron daemon-meldinger. *.info;mail.none;authpriv.none;cron.none /var/log/messages# Skriv meldinger som inneholder sensitiv # autentiseringsinformasjon til en separat fil, uavhengig av nivå. authpriv.* /var/log/secure# Alle meldinger fra postsystemet bør også registreres separat. mail.* /var/log/maillog# Logg handlingene til cron-demonen. cron.* /var/log/cron# Nødmeldinger bør mottas umiddelbart # av alle brukere av systemet *.eerg*# Skriv meldinger fra nyhetstjenester på crit-nivå og høyere til en egen fil. uucp,news.crit /var/log/spooler# Meldinger som sendes under oppstartsfasen, kopieres til boot.log-filen local7.* /var/log/boot.log

Som du kan se, skrives de fleste meldinger ganske enkelt til forskjellige loggfiler som ligger i katalogen /var/log eller dens underkataloger, med hovedsystemloggfilen i Red Hat Linux som filen /var/log/meldinger. Den inkluderer ikke bare meldinger fra kategoriene mail, authpriv og cron (som separate filer er tildelt). La oss ta en titt på denne filen og bruke eksemplet for å se hva som er registrert i loggfiler.

Loggfil /var/log/messages

Det er selvfølgelig ikke mulig å snakke her om innholdet i hver linje i denne filen. For at leseren skal få en ide om hvilken informasjon som finnes i protokollen, presenterer vi individuelle meldingslinjer med svært korte kommentarer.

Hver linje i loggfilen inneholder en enkelt meldingspost, bestående av følgende meldingsfelt, atskilt med mellomrom:

• dato i standard tekstformat (felt TIDSSTIMPEL fra meldingen syslog),
• vertsnavn (felt VERTNAVN fra meldingen syslog)
• meldingstekst (felt STIKKORD Og INNHOLD fra meldingen syslog)

For det første er det verdt å merke seg at hvis datamaskinen din ikke kjører 24/7, men er slått av om natten, så kan du i denne filen finne registreringer av flere "arbeidssykluser" som starter med at datamaskinen starter opp og slutter med å slå den av. En slik syklus begynner med en melding om lanseringen av loggdemoner (dette er forståelig, meldinger ble ikke registrert før de ble lansert):

17. sep 08:32:56 kos3 syslogd 1.4-0: omstart. 17. sep 08:32:56 kos3 syslog: start av syslogd lyktes 17. september 08:32:56 kos3 kjerne: klogd 1.4-0, loggkilde = /proc/kmsg startet. 17. sep 08:32:56 kos3-kjerne: Inspiserer /boot/System.map-2.4.2-2 17. sep. 08:32:56 kos3 syslog: start av klogd lyktes

- Hvilken kjerneversjon brukes: 17. september 08:32:56 kos3 kjerne: Linux versjon 2.4.2-2 ( [e-postbeskyttet]) (gcc versjon 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Søn 8. april 20:41:30 EDT 2001

- Hvilke parametere kjørte kjernen med: Sep 17 08:32:56 kos3 kjerne: Kjerne kommandolinje: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2

- Informasjon om prosessortype og kapasitet tilfeldig tilgang minne: Sep 17 08:32:56 kos3 kjerne: Oppdaget 1594,849 MHz prosessor. 17. sep 08:32:56 kos3 kjerne: Minne: 125652k/130560k tilgjengelig (1365k kjernekode, 4200k reservert, 92k data, 236k init, 0k highmem) 17. september 08:32:56: kos3 kjerne: CPU , L1 D cache: 8K Sep 17 08:32:56 kos3 kjerne: CPU: L2 cache: 256K Sep 17 08:32:56 kos3 kjerne: CPU: Intel(R) Pentium(R) 4 CPU 1,60GHz stepping 02

- Informasjon om diskminne(inkludert informasjon om diskgeometri, diskpartisjonsstruktur og avbrudd brukt): 17. september 08:32:56 kos3-kjerne: hda: MAXTOR 6L020J1, ATA-DISK-stasjon 17. september 08:32:56 kos3-kjerne: hdc: SAMSUNG CD-ROM SC -148C, ATAPI CD/DVD-ROM-stasjon 17. september 08:32:56 kos3 kjerne: ide0 ved 0x1f0-0x1f7,0x3f6 på irq 14. september 17. 08:32:56 kos3 kjerne: ide1 ved 0x170-0x37 på 5x170-0x37 17. sep 08:32:56 kos3 kjerne: hda: 40132503 sektorer (20548 MB) m/1819KiB Cache, CHS=2498/255/63, UDMA(100) 17. sep 08:32:56 kos3 kjerne: 17 sjekk: Sep 08:32:56 kos3 kjerne: hda: hda1 hda2 hda3 hda4< hda5 hda6 hda7 >17. sep 08:32:56 kos3-kjerne: Diskettstasjon(er): fd0 er 1,44M

- Informasjon om eksterne enheter: Sep 17 08:32:56 kos3 kjerne: usb-uhci.c: USB UHCI ved I/O 0x1820, IRQ 11 Sep 17 08:32:56 kos3 kjerne: usb-uhci.c: Oppdaget 2 porter 17 Sep 08: 32:56 kos3 kjerne: ttyS00 ved 0x03f8 (irq = 4) er en 16550A 17. sep 08:32:56 kos3 kjerne: ttyS01 ved 0x02f8 (irq = 3) er en 16550A 8. september: 32:5 kjerne 8:32:06 kos3: Intel(R) 8255x-basert Ethernet Adapter Sep 17 08:32:56 kos3 kjerne: Intel(R) PRO/100 Fast Ethernet Adapter - Lastbar driver, ver 1.5.6 Sep 17 08:32:56 kos3 kjerne: PCI: Funnet IRQ 11 for enhet 02:08.0

- Informasjon om lansering av individuelle tjenester: 17. september 08:32:56 kos3-kjerne: NET4: Linux TCP/IP 1.0 for NET4.0 17. sep. 08:32:56 kos3-kjerne: IP-protokoller: ICMP, UDP, TCP, IGMP 17. sep 08:32:56 kos3 kjerne: NET4: Unix domene sockets 1.0/SMP for Linux NET4.0. 17. sep 08:32:56 kos3 kjerne: parport0: PC-stil ved 0x378 (0x778) 17. sep 08:32:56 kos3 kjerne: parport0: irq 7 oppdaget 17. sep 08:32:42 kos3 rc.sysinit: Slår på bruker og gruppekvoter for lokale filsystemer: vellykket 17. sep 08:32:43 kos3 rc.sysinit: Aktiverer bytteplass: lyktes 17. sep 08:32:44 kos3 init: Går inn i kjørenivå: 3. september 17 08:32:45 kosing kudzu /etc/fstab lyktes 17. sep 08:32:55 kos3 kudzu: lyktes 17. sep. 08:32:55 kos3 nettverk: Sette nettverksparametere: lyktes 17. sep 08:32:55 kos3 nettverk: Heve grensesnitt lo: suksess08p 32:56 kos3-nettverk: Aktiverer grensesnitt eth0: lyktes 17. sep. 08:32:56 kos3-tastatur: Laster tastaturoppsett: 17. sep 08:32:56 kos3-tastatur: Laster systemfont: 17. sep. 08:32:56 kosalisering3 tilfeldig: I tilfeldig tallgenerator: lyktes 17. sep. 08:32:41 kos3 rc.sysinit: Konfigurering av kjerneparametere: lyktes. 17. sep. 08:32:41 kos3 rc.sysinit: Innstilling av standardfont (cyr-sun16): vellykket 08:32:37: 41 kos3 rc.sysinit: Aktivering av byttepartisjoner: lyktes 17. sep. 08:32:41 kos3 rc.sysinit: Innstilling av vertsnavn kos3: lyktes. 17. sep. 08:33:03 kos3 xinetd: startende xinetd lyktes 0. sep. : start gpm lyktes 17. sep 08:33:05 kos3 crond: start crond lyktes 17. sep 08:33:06 kos3 xfs: lytter på port 7100 17. sep 08:33:06 kos3 xfs: start xfs lyktes

- Informasjon om montering av filsystemer: Sep 17 08:32:56 kos3 kjerne: VFS: Montert rot (ext2 filsystem) skrivebeskyttet. 17. sep 08:32:56 kos3-kjerne: Legger til swap: 265032k swap-space (prioritet -1) 17. sep 08:32:56 kos3-kjerne: MSDOS FS: Bruker kodeside 866 17. september 08:32:56 kosOS FS-kjerne: MSD : IO charset koi8-r 17. sep. 08:32:41 kos3 rc.sysinit: Montering av USB-filsystem: vellykket 17. sep. 08:32:41 kos3 rc.sysinit: Kontroll av rotfilsystem lyktes. 17. sep. 08:32:413it. kossin. : Remontering av rotfilsystem i lese-skrivemodus: lyktes 17. september 08:32:41 kos3 rc.sysinit: Montering av proc-filsystem: lyktes 17. september 08:32:41 kos3 fsck: /: clean, 30407/16005270/30407/16005270/3 blokkerer 17. september 08:32:42 kos3 fsck: /HOME: clean, 6573/432864 filer, 689090/863722 blokkerer 17. sep. 08:32:42 kos3 fsck: /usr: clean, 55105/3299508, 28528 sep. 17 08:32:42 kos3 rc.sysinit: Kontroll av filsystemer lyktes

- Noen feilmeldinger: Sep 17 08:32:42 kos3 mount: SMB-tilkobling mislyktes Sep 17 08:32:42 kos3 mount: Pakkesending mislyktes til 10.104.129.245(137) ERRNO=Nettverk er utilgjengelig 17. sep 08:32: kos3-montering: mount: /dev/sda4: ukjent enhet 17. september 08:32:59 kos3-montering: feil ved tilkobling til 192.168.36.20:139 (Ingen rute til vert) 17. september 08:32:59 kos3-montering: mount: / dev /sda4: ukjent enhet

- Meldinger om brukerlogging: 17. sep 08:33:14 kos3 login(pam_unix): økt åpnet for bruker kos av LOGIN(uid=0) 17. sep 08:33:14 kos3 -- kos: LOGG PÅ tty1 BY kos 17. sep 08:41:39 kos3 su(pam_unix): autentiseringsfeil; logname=kos uid=500 euid=0 tty= ruser= rhost= bruker=root

- Og til slutt, meldinger tatt opp når datamaskinen er slått av, for eksempel: 17. september 10:30:07 kos3 rc: Stopping av keytable: lyktes 17. sep. 10:30:07 kos3 Font Server: terminating 17. sep. 10:30:08 kos3 xfs: stopp xfs lyktes Sep 17 10:30:08 kos3 gpm: stop gpm lyktes Sep 17 10:30:08 kos3 xinetd: Exiting... Sep 17 10:30:10 kos3 rpc.statd: Un-fanget signal 15, registrere og avslutte. 17. sep 10:30:11 kos3-kjerne: Kjernelogging (proc) stoppet. 17. sep 10:30:11 kos3-kjerne: Kjerneloggdaemon avsluttes. 17. sep 10:30:12 kos3 syslog: stopping av klogd lyktes 17. sep. 10:30:12 kos3 avslutter på signal 15

Oppføringene i andre protokollfiler nevnt i filen har omtrent samme struktur /etc/syslog.conf.

logger- og tailf-kommandoer

Fra den forrige beskrivelsen kan vi konkludere med at utstedelsen av alle meldinger for systemlogger bør spesifiseres av programmereren på stadiet av programopprettelsen. Dette er ikke helt sant. Brukeren har også mulighet til å sende en melding til demonen syslogd. Det er en kommando for dette i Linux logger, som gjør det mulig å sende en melding fra kommandolinjen (sh, bash, etc.). Det er en del av util-linux-pakken. Naturligvis er denne kommandoen først og fremst ment å gi loggingsmuligheter når brukeren lager ulike typer shell-skript. Men den kan også startes direkte fra kommandolinjen, for eksempel for å gjøre deg kjent med egenskapene til loggingssystemet. Kommandostartformat: logger [-isd] [-f fil] [-p PRI] [-t TAG] [-u socket] Kommandolinjealternativene har følgende betydning:

• -Jeg- ta med prosessnummeret i meldingen
• -s- duplikatmelding til stderr
• -d- bruk datagrammodus når du sender meldinger (i stedet for vanlig streaming)
• -f filnavn- lagre melding til spesifisert fil(standard er /var/log/meldinger)
• -p anlegg.nivå- angi kategori og prioritet for meldingen (standard: user.notice)
• -t STIKKORD - angi TAG-feltet
• -u stikkontakt- send en melding til den angitte kontakten i stedet for å ringe syslogd
• MSG- Meldingstekst

Send flere meldinger ved hjelp av programmet logger og beundre resultatet i filen /var/log/meldinger(med mindre du endrer standardverdien, selvfølgelig).

Forresten, det er en veldig interessant måte å se meldinger skrevet til en fil på /var/log/meldinger team logger. Denne metoden er basert på bruken spesialprogram hale. Åpne et terminalvindu, få superbrukerrettigheter (med kommandoen su) og kjør kommandoen i dette vinduet
tailf /var/log/meldinger
Etter det, bytt til en annen terminal og kjør kommandoen der logger free_text. Meldingen din vil umiddelbart vises i vinduet der programmet kjører hale. Det vil si at ved hjelp av dette programmet kan systemadministratoren overvåke opptak av nye meldinger i protokollen i sanntid. Ekte, Systemadministrator det er knapt tid til å overvåke oppførselen til systemet på denne måten (unntatt kanskje nødsituasjoner). Derfor er det utviklet spesielle programmer for å analysere protokoller. Men mer om dem nedenfor, men la oss foreløpig gå videre til spørsmålet om hvordan vi organiserer overvåking av en ekstern datamaskin (husker du hvordan du fanget angriperen Shimomura?).

Nettverkslogging

Som nevnt kan loggingsystemmeldinger sendes av daemonen syslogd til den eksterne verten. Men noen må godta ham der. Det viser seg at den samme demonen gjør dette syslogd, kjører på denne eksterne verten. Mer presist, syslogd på hvilken som helst datamaskin kan lytte ikke bare til /dev/log-kontakten (og dermed akseptere meldinger fra lokale kilder), men også til port 514/UDP, som sikrer at meldinger mottas fra andre datamaskiner på det lokale nettverket (og deres påfølgende opptak til lokal fil). Dette gjør det mulig å lage en "loggingsserver", som kan være veldig praktisk for en systemadministrator (alle hendelser på nettverket overvåkes på ett sted), og øker også nettverkssikkerheten, siden meldinger om en hackers penetrering av en av nettverksverter kan ikke umiddelbart rapporteres fjernet fra protokollen av denne hackeren.

For å organisere slik "nettverkslogging" må det imidlertid gjøres noen ekstra innsats.

For det første, siden port 514/UDP brukes til å sende og motta meldinger over nettverket, må den være tilgjengelig på begge datamaskiner (klient og server). For å gjøre dette i filen /etc/tjenester linjen må være til stede på begge datamaskinene
syslog 514/udp
Hvis en slik linje inn /etc/tjenester fraværende, syslogd kan verken motta meldinger eller sende dem til nettverket fordi det ikke kan åpne UDP-porten. Hvis en slik situasjon oppstår, syslogd slutter umiddelbart å skrive meldinger, selv til den lokale loggen. Samtidig, som laget viser ps, forblir den i minnet og til og med lagrer meldinger i noen buffere, fordi hvis linjen " syslog 514/udp" gjenopprett til fil /etc/tjenester på klienten, deretter ved i det minste Noen av de "manglende" meldingene vises fortsatt i loggen (etter omstart syslogd).

For det andre, når du starter demonen syslogd alternativet må spesifiseres på serveren -r, som gir funksjoner for ekstern logging (standard daemon syslogd venter kun på meldinger fra den lokale kontakten). Hvordan og hvor du skal sette dette alternativet vil bli diskutert nedenfor, i delen om å starte daemonen syslogd.

Vel, og for det tredje må innstillingene i filene korrigeres tilsvarende /etc/syslog.conf på begge datamaskinene. Hvis du for eksempel vil omdirigere alle meldinger til loggserveren, må du skrive inn en fil på klientdatamaskinen /etc/syslog.conf en linje som dette:
*.* @vertsnavn
Hvis under starten av demonen syslogd serveren vil være utilgjengelig (for eksempel er den koblet fra nettverket for øyeblikket) eller det vil ikke være mulig å finne den ved navn (DNS-tjenesten fungerte ikke som den skal) syslogd gjør 10 flere forsøk på å finne serveren, og bare hvis serveren ikke kan bli funnet etter det, slutter den å prøve og sender en tilsvarende melding.

Hvis du har flere domener på nettverket ditt som betjenes av en enkelt loggingsserver, ikke bli overrasket over at loggen på serveren vil inkludere de fulle navnene på klientene (inkludert domenet). Riktignok ved oppstart syslogd alternativer kan brukes -s domeneliste eller -l vertsliste, som gir erstatning av fullstendige vertsnavn i protokollen med deres korte navn (uten å spesifisere domenet).

Ikke glem etter å ha justert start- og filalternativene /etc/syslog.conf start demonen på nytt fordi, i motsetning til cron, sysklogd leser ikke konfigurasjonsfiler på nytt automatisk.

syslogd daemon oppstartsalternativer

Siden vi berørte spørsmålet om innstilling av daemon-lanseringsparametere i forrige underavsnitt syslogd, la oss se på dette problemet mer detaljert. Som allerede nevnt, lanseres begge loggingsdemonene på systeminitieringsstadiet, og mer spesifikt, gjennom et skript /etc/rc.d/init.d/syslog(som for oppstartsskript for andre tjenester, opprettes symbolske lenker i /etc/rc.d/rc?.d/-katalogene). For å angi lanseringsparametrene er det imidlertid ikke nødvendig å justere dette skriptet, fordi fra og med versjon 7.2 i Red Hat-distribusjonen, leses lanseringsalternativene for begge demonene fra en separat konfigurasjonsfil /etc/sysconfig/syslog. Her er en kort liste over mulige parametere for daemonen syslogd.

Startparametere syslogd:

• -en stikkontakt- Spesifiserer en ekstra kontakt som demonen vil lytte på syslogd. Du kan spesifisere opptil 19 sockets (flere er mulig, men for dette må du rekompilere pakken). Dette alternativet brukes i tilfeller der en annen demon (for eksempel ftp eller http) kjører i et begrenset miljø (chrooting).
• -d- Feilsøkingsmodus. I dette tilfellet går ikke demonen inn bakgrunnsmodus og sender ut alle meldinger til gjeldende terminal.
• -f config-filnavn Angir navnet på en alternativ konfigurasjonsfil som skal brukes i stedet for standardfilen /etc/syslog.conf.
• -h Standard i sysklogd Det er forbudt å overføre meldinger mottatt over nettverket til en annen datamaskin. Dette gjøres for å forhindre endeløse overføringer av meldinger rundt ringen. Alternativet -h lar deg endre den vanlige oppførselen og sørge for at meldinger mottatt fra eksterne verter blir overført videre over nettverket (og sørge for mulig looping selv).
• -l vertsliste- Spesifiserer en liste over verter hvis navn ikke skal skrives med et fullstendig domenenavn (FQDN - Full Qualified Domain Name); navn i listen er atskilt med kolon.
• -m minutter Lansert uten dette alternativet sysklogd regelmessig (hvert 20. minutt) registrerer kategorimeldinger i protokollen merke, altså rett og slett tidsstempler. Bruker alternativet -m du kan enten endre intervallet mellom merkene, eller helt avbryte utstedelsen av slike meldinger, som du må sette intervallet til null for: -m 0.
• -n Ikke visne inn i bakgrunnen; dette alternativet er nødvendig i tilfeller der syslogd er startet og kontrollert av en prosess i det.
• -p stikkontakt Spesifiserer en alternativ UNIX-kontakt (i stedet for standarden som lytter /dev/log). Vennligst merk: alternativ -en spesifiserer ekstra stikkontakter, og -s– alternativ!
• -r Tillat å motta meldinger fra eksterne verter. Vi snakket om dette i forrige avsnitt, så jeg utelater detaljene.
• -s domeneliste Angir en liste over domener hvis navn ikke trenger å logges sammen med vertsnavnet (det vil si at for disse domenene vil bare vertsnavnet logges i stedet for det fullstendige domenenavnet (FQDN). Navnene i listen er atskilt med et kolon Navnet på domenet som syslogd-serveren er plassert i, trenger ikke å være inkludert i denne listen (navnet er fjernet som standard).
• -v Vis versjon og fullfør arbeid.
• -x Forby å bestemme et vertsnavn etter adressen, forhindrer dødlås når du arbeider på samme vert med en DNS-server.

Etter å ha startet demonen syslogd en statusfil opprettes /var/lock/subsys/syslog null lengde, og en fil med et prosessidentifikasjonsnummer /var/run/syslogd.pid.

Ved å bruke kommandoen
kill -SIGNAL `cat /var/run/syslogd.pid`
du kan sende til demonen syslogd ett av følgende signaler:

• SIGHUP - start daemonen på nytt (reinitialisering); alle åpne filer lukkes, demonen starter på nytt og leser konfigurasjonsfilen på nytt.
• SIGTERM - avstengning.
• SIGINT, SIGQUIT - hvis feilsøkingsmodus er aktivert (alternativ -d), ignoreres signaler ellers slås av.
• SIGUSR1 - aktiver/deaktiver feilsøkingsmodus (fungerer bare hvis daemonen ble startet med -d-bryteren).

Daemon klogd har ikke færre lanseringsmuligheter enn syslogd, men vi vil ikke presentere dem her, og henviser leseren til den tilsvarende man-siden (brukeren bør ikke bry seg med å konfigurere klogd, er det bedre å la det være i tilstanden der det ble produsert av distribusjonsutviklerne).

dmesg-filen og dmesg-kommandoen

Som allerede nevnt, loggfilene nevnt i filen /etc/syslog.conf vanligvis plassert i en katalog /var/log og dens underkataloger. Men hvis vi ser inn i denne katalogen, vil vi finne flere filer der /etc/syslog.conf ble ikke nevnt. La oss se på formålet deres. La oss starte med filen dmesg.

Først må vi nevne at Linux har en kommando med samme navn. Hvis du sammenligner utdataene til denne kommandoen (når den kjøres uten parametere) med innholdet i filen /var/log/dmesg, vil du finne at de er veldig like, men ikke identiske (direkter utdataene fra kommandoen til en fil dmesg2 og sammenligne filene dmesg Og dmesg2). Mer presist, filen /var/log/dmesg en til en sammenfaller med begynnelsen av utdataene som vi får fra kommandoen dmesg. Som det følger av , har kjernen en ringbuffer som meldinger fra kjerneloggingsdemonen skrives inn i. De meldingene som skrives til denne bufferen under nedlastingsprosessen utgjør innholdet i filen /var/log/dmesg. Tilsynelatende er denne filen generert etter at systemet starter opp.

Hvis du ser på filoppføringen på nytt /etc/syslog.conf, vil du se at alle meldingene i kategorien kern utstedes også til konsollen. Men der løper de raskt over skjermen og man rekker nesten ikke å lese og forstå dem. Men de er lagret i en fil /var/log/dmesg og er dermed tilgjengelige for rolig refleksjon (hvis nedlastingsprosessen er fullført). Etter at oppstartsprosessen er fullført, fortsetter skrivingen av meldinger fra kjernen til ringbufferen. Når kommandoen utføres dmesg, vises den nåværende tilstanden til bufferen. Derfor inneholder utdataene fra denne kommandoen flere meldinger enn filen /var/log/dmesg: i utdataene til denne kommandoen ser du også meldingene som kjernen sender ut etter at oppstartsprosessen er fullført.

Alle meldinger fra /var/log/dmesg finner du i filen /var/log/meldinger, bare der veksler de med meldinger fra andre programmer. Det er bare én vesentlig forskjell: i filen dmesg tid og kilde for meldingen (vertsnavn og meldingskategori) er ikke spesifisert. Verten her er alltid "lokal", og starten på tidstellingen bestemmes av siste omstart av datamaskinen.

lastlog, wtmp og utmp-filer

Foruten filen dmesg i katalogen /var/log/ det er to filer til som ikke er nevnt i /etc/syslog.conf, men direkte relatert til logging - dette er filer siste logg Og wtmp. Men se på dem på samme måte som vi så på filen /var/log/meldinger gir ikke mening - du vil ikke forstå noe. Faktum er at informasjonen i disse filene er registrert i et spesielt format, og det må sees ved hjelp av spesielle programvare. Men først må vi si noen ord om formålet med disse filene.

Fil siste logg lagrer informasjon om brukerens siste pålogging. Jeg vet ikke om du la merke til at når du skriver inn brukernavn og passord, vises noe slikt som følgende melding på skjermen:

Localhost-pålogging: kos Passord: Siste pålogging: Ons 9. okt 19:25:53 på tty1 Disse tre linjene genereres av verktøyet Logg Inn, som, etter å ha fastslått at brukeren har påloggingsrettigheter, får tilgang til filen /var/log/lastlog, henter informasjon om brukerens tidligere vellykkede pålogging derfra, viser den på skjermen og oppdaterer deretter posten i filen siste logg. Du kan undertrykke denne meldingen ved å opprette en tom .hushlogin-fil i hjemmekatalogen din. Det anbefales imidlertid ikke å gjøre dette, tvert imot, du bør være spesielt oppmerksom på innholdet i denne meldingen for ikke å gå glipp av tilfeller når noen andre logget inn under ditt navn.

I motsetning til filen /var/log/lastlog, som inneholder tidsregistreringer siste pålogging for hver bruker, i filen /var/log/wtmp blir husket Alle pålogginger og utlogginger av brukere siden opprettelsen av denne filen. Samme som i filen siste logg, oppføringer i /var/log/wtmp er laget i et spesielt format, slik at de kun kan vises ved hjelp av spesielle kommandoer. Men før vi snakker om disse kommandoene, la oss si at det er en annen fil som inneholder brukerloggingsposter - dette er filen /var/run/utmp. Denne filen inneholder informasjon om hvilke brukere som for øyeblikket jobber i systemet.

Nå kan du snakke om hvordan du kan se informasjon om brukere som jobber eller tidligere har jobbet i systemet. Hovedkommandoen for dette er kommandoen siste. Den viser alle poster fra en fil /var/log/wtmp, hvorved brukerens navn er angitt, en indikasjon på terminalen som brukeren jobbet fra, tidspunktet brukeren logget på systemet og tidspunktet han logget ut av systemet, samt varigheten av brukerens økt i systemet. Hvis brukerens arbeid bare ble avbrutt fordi selve systemet ble slått av, er det ordet "ned" i stedet for brukerens utgangstid (fra disse linjene er det enkelt å bestemme tiden systemet stoppet). Omstartstiden vises på separate linjer som starter med ordet "reboot".

Team sisteb som et lag siste, men viser informasjon om mislykkede brukerpåloggingsforsøk. Det skal imidlertid bemerkes at denne kommandoen bare vil fungere hvis filen eksisterer /var/log/btmp. Ingen av programmene som er omtalt her lager imidlertid loggfiler, så hvis noen av dem slettes, avsluttes opptaket.

Team siste logg formaterer og viser innholdet i filen /var/log/lastlog. Brukernavnet, terminalnavnet som brukeren logget på og siste påloggingstidspunkt vil vises. Som standard (når kommandoen legges inn uten parametere) filelementene /var/log/lastlog vil vises i rekkefølge med bruker-ID-nummer. Hvis du spesifiserer alternativet -u påloggingsnavn, vil bare siste påloggingstidspunkt for den angitte brukeren vises. Ved å spesifisere parameteren -t days vil du kun motta poster for de siste dagene av dagene. Hvis brukeren ikke har logget på systemet i det hele tatt, vil i stedet for terminalnavnet og siste påloggingstidspunkt, strengen "**Aldri logget inn**" bli indikert.

Når du utfører kommandoen siste logg På en treg datamaskin kan det i noen tilfeller se ut til at kommandoen sitter fast. Dette skjer på grunn av det faktum at selv om bare to brukere er registrert i systemet (root og bruker), i filen /var/log/lastlog det er fortsatt plass til at så mange brukere som mulig kan jobbe med systemet. Derfor i filen /var/log/lastlog Det kan være store hull mellom ID-numrene til brukere som jobber i systemet. For når du ser på slike intervaller, viser ikke programmet informasjon på skjermen, og inntrykket av "frysing" oppstår.

For å vise informasjon om hvem som for øyeblikket jobber med systemet, bruk kommandoene w, WHO Og brukere. Team brukere brukes når du kun vil vite hvilken bruker som jobber i systemet for øyeblikket, men ikke er interessert i hvilken terminal de koblet fra og hva de gjør. Hvis du vil vite hvem som logget på fra hvilken terminal, bruk kommandoen WHO. Denne kommandoen skriver ut informasjon fra en fil /var/run/utmp. Du kan tvinge den til å sende ut data fra en fil /var/log/wtmp(eller en hvilken som helst annen fil det er fornuftig for) hvis du spesifiserer navnet på denne filen i kommandolinje. Men i utgangen vil du fortsatt bare se brukernavnet, en indikasjon på terminalen brukeren logget på fra, påloggingstiden og, i tilfelle pålogging med ekstern datamaskin, navnet på denne datamaskinen.

Kommandoen gir betydelig mer informasjon w. I utgangen vil du se gjeldende tid, hvor lenge systemet har kjørt, hvor mange brukere som jobber i systemet for øyeblikket og gjennomsnittlig systembelastning for det siste minuttet, 5 og 15 minutter. Deretter skrives det ut for hver bruker:

Brukernavn,

terminal navn,

ekstern vertsnavn

tid som har gått siden pålogging,

tiden denne terminalen ikke brukes (tomgangstid),

total tid brukt av alle prosesser startet fra av denne terminalen(JCPU-kolonne),

tiden som den siste prosessen startet av brukeren kjører (PCPU-graf),

informasjon om hvilket program som for øyeblikket kjøres av brukeren (i form av en kommandolinje for å starte en kommando med alle parametere).

Som allerede nevnt, laget w viser informasjon som er lagret i en fil utmp. Forresten, manualen Mann stater som vanlige brukere må nektes skrivetilgang til filen utmp, siden mange systemprogrammer (av noen uforklarlige grunner) avhenger av integriteten. Du risikerer å forvirre systemstatistikkfiler og gjøre endringer i systemfiler hvis du lar en bruker skrive til utmp-filen.

Loggfiler for andre programmer

I tillegg til filene som vi allerede har snakket om, er det andre protokollfiler som er opprettet av separate programmer. De mest typiske eksemplene er protokollene til demoner samba, ftpd eller httpd som utføres i separate filer. Noen av disse programmene lager sine protokoller i underkataloger til katalogen /var/log/, andre lagrer protokoller andre steder. Og strukturen til disse filene kan avvike betydelig fra strukturen til filene som er opprettet av systemet syslog. La meg gi deg et eksempel på noen få linjer fra serverprotokollen Apache kjører på datamaskinen min: 192.168.36.21 - - "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0 . 0) Gecko/20020530" 192.168.36.21 - - "GET /icons/back.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0 ) Gecko/20020530" 192.168.36.21 - - "GET /icons/folder.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko / 20020530" 192.168.36.21 - - "GET /icons/text.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530 " 192.168.36.21 - - "GET /ve/papers/new/log/protok_lovim.htm HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 (X11; U ; Linux i686; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /bugtraq.css HTTP/1.1" 404 279 "http://linux/ve/papers/new/log/ protok_lovim.htm" " Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/bug1.gif HTTP/1.1" 404 280 " http://linux /ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/title.gif HTTP/1.1" 404 281 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla /5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" Som du kan se, er strukturen til denne protokollfilen vesentlig forskjellig fra det vi så i systemprotokollene.

Samba-serveren, i tillegg til hovedserverdriftsprotokollen, oppretter i en underkatalog /var/log/samba en hel serie med loggfiler for forskjellige tilfeller, spesielt separate filer for hver av brukerne som har lov til å bruke ressursene som tilbys av denne serveren. Følgende to oppføringer er hentet fra en slik fil:

Smbd/service.c:make_connection(550) linux (192.168.36.10) koble til offentlig tjeneste som bruker kos (uid=500, gid=500) (pid 1366) smbd/service.c:close_cnum(550) linux (192.168. 36.10) lukket tilkobling til offentlig tjeneste Eksemplene ovenfor viser at hvis du kan lese litt engelsk og har en viss forståelse av strukturen til poster, kan du trekke ut mye fra loggfiler nyttig informasjon. Bare det må trekkes ut fra hele forekomster av "avfallsstein" - enorme sekvensielle protokollfiler, som er en ikke-triviell oppgave. Derfor er det utviklet spesielle programvareverktøy for protokollanalyse.

Verktøy for behandling av protokoller

Det er utviklet ganske mange forskjellige programmer og skript for å analysere protokoller. Jeg skal begrense meg Kort beskrivelse to slike midler: loggklokke Og fargeprøve.

loggklokke er et Perl-skript inkludert i standard Red Hat Linux-distribusjon. Bare under utarbeidelsen av denne artikkelen ble versjon 4.1 av dette programmet lagt ut på utviklerens nettsted (og han er Kirk Bauer).

Hovedideen bak dette programmet er at loggfilen sendes gjennom et filter, som velger fra loggen alle linjer (det vil si meldinger) som tilfredsstiller et gitt kriterium. Resultater sendes pr e-post til den angitte brukeren (som standard - root). Filtre kan skrives på et hvilket som helst programmeringsspråk, men forfatteren av pakken foretrekker Perl. Filtre bør skrives for å lese data fra stdin og sende ut resultatet til stdout.

Grunnleggende bruk loggklokke består av å inkludere en lenke til hovedskriptet ( /etc/log.d/scripts/logwatch.pl) til katalogen /etc/cron.daily, som forårsaker daglig kjøring loggklokke med standardinnstillinger. Linken får et navn som starter med "00" (f.eks. 00-logwatch) slik at skriptet kjører før logrotate.

Men du kan også kjøre skriptet fra kommandolinjen. Selvfølgelig, hvis du ikke har endret informasjonsutgangsparameteren, bør resultatet av operasjonen ses etter i superbrukerens postboks. Hvis du vil se disse resultatene på skjermen, må du angi parameteren på kommandolinjen --skrive ut- gi en rapport til stdout.

Generelt skriptoppstartsformat:

/etc/log.d/scripts/logwatch.pl [--detalj nivå ] [--loggfil magasin-gruppe ] [--service tjenestenavn ] [--print] [--mailto adresse ] [--lagre filnavn ] [--arkiver] [--område dato-intervall ]

Standardparametrene er lagret i filen /etc/log.d/logwatch.conf, kommentarene som hjelper deg å forstå betydningen av kommandolinjeparametrene:

• LogDir - katalog i forhold til hvilke filnavn som vurderes;
• MailTo - hvem skal rapporten sendes til;
• Skriv ut - i stedet for å sende rapporten per post, skriv den ut til stdout;
• Lagre - i stedet for å sende rapporten per post, lagre den i den angitte filen;
• Arkiver - prosess ikke bare gjeldende versjoner logger, men også gamle kopier laget av logrotate;
• Range - behandle det angitte tidsintervallet: Alle, i dag, i går (dagens kalenderdag i går);
• Detalj - rapport detaljnivå: fra 0 til 10 eller lav, middels, høy;
• Tjeneste - Alle eller filternavn fra /etc/log.d/scripts/services/ (flere filtre kan spesifiseres);
• LogFile - Alle eller navnet på en logggruppe (flere grupper kan spesifiseres).

Mer informasjon om manuset loggklokke finner du i.

Artikkelen beskriver et annet skript for behandling av loggfiler, som er inkludert i Mandrake Linux-distribusjonen. Dette skriptet kalles fargeprøve("Simple WATCHer") og er også skrevet i Perl.

Arbeidsledelse fargeprøve utføres ved å bruke en enkelt konfigurasjonsfil, som standard $HOME/.swatchrc. Denne filen inneholder eksempeltekst (i skjemaet vanlig uttrykk), hvilken fargeprøve vil søke i loggfiler. Etter hvert slikt eksempel er en handling indikert som fargeprøve må iverksette tiltak hvis den møter tekst som samsvarer med mønsteret.

Du vil for eksempel bli advart hver gang et bufferoverflyt-angrep blir forsøkt på webserveren din når et veldig langt filnavn blir bedt om. Og det vet du i slike tilfeller i loggfilen /var/apache/error.log Det vises en melding som inneholder ordene "Filnavnet er for langt". I dette tilfellet, til filen din .swatchrc Følgende instruksjon må settes inn:

Se etter /Filnavn for langt/ mail [e-postbeskyttet], subject=BufferOverflow_attempt

Jeg vil ikke gi en mer detaljert beskrivelse av programmet her. fargeprøve. En entusiastisk artikkel er dedikert til det, og selve programmet finner du på nettsiden. Jeg vil bare påpeke, og fargeprøve, Og loggklokke implementere en ganske primitiv algoritme for å behandle protokollfiler, som koker ned til å søke i protokollen etter en gitt streng med tegn (signatur). I mellomtiden, for det første, indikerer tilstedeværelsen av en slik linje ofte ikke et inntrenging fra en angriper, og for det andre kan en kompetent angriper sørge for å slette spor av hans aktiviteter. En annen åpenbar ulempe med produktene som er vurdert, er at de fungerer i "utsatt modus", siden de bare kjører etter en tidsplan. Og kampen mot inntrengere må utføres "i sanntid", og umiddelbart reagere på forsøk på å trenge inn i systemet. Derfor tilbyr kommersielle produkter overvåkingssystemer som opererer kontinuerlig og implementerer "intelligente" protokollanalysealgoritmer. Disse algoritmene er basert på statistisk analyse av meldingsflyt og identifisering av statistisk signifikante avvik i systemet fra dets normale oppførsel.

Som avslutning på denne delen merker jeg meg at nettstedet SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) gir en liste over lenker til nettstedene til ulike programvareverktøy for behandling av protokoller med en kort beskrivelse beskrivelse av disse verktøyene. Du kan eksperimentere med forskjellige programmer og velge det som passer deg.

Roterende loggfiler

Du forstår selvfølgelig at hvis systemet brukes intensivt, vokser loggfilene raskt. Noe som resulterer i sløsing med diskplass. Og problemet med å "temme" protokollene oppstår. I Red Hat Linux løses dette problemet med skript logrotere, som ligger i katalogen /etc/cron.daily, og derfor lanseres av daemonen cron daglig. Dette skriptet lar deg behandle ikke bare systemlogger syslog, men også andre programmer.

Manus logrotere overvåker veksten av loggfiler og gir såkalt rotasjon av disse filene hvis de overskrider den angitte størrelsen (eller etter et spesifisert tidsintervall). Rotasjon er ikke annet enn sekvensiell kopiering av tidligere versjoner av arkivfiler omtrent som følger:

meldinger.2 -> meldinger.3

meldinger.1 -> meldinger.2

meldinger.0 -> meldinger.1

meldinger -> meldinger.0
og lage en ny meldingsfil for å ta opp påfølgende meldinger.

Liste over filer som skal behandles av skriptet logrotere og parametrene for denne behandlingen bestemmes av konfigurasjonsfiler, som det kan være flere av. Navnene på konfigurasjonsfilene er spesifisert på kommandolinjen for skriptstart (se nedenfor for oppstartsparametere). På Red Hat Linux, som standard, er konfigurasjonsfilene for logrotere fil brukes /etc/logrotate.conf, som kan se omtrent slik ut:

Ukentlig rotering 4 opprette komprimering inkluderer /etc/logrotate.d /var/log/wtmp /var/log/lastlog (månedlig opprette 0664 root utmp rotere 1 )

Denne filen er som en hvilken som helst konfigurasjonsfil for et skript logrotere består av flere seksjoner. Den første delen definerer globale parametere (én per linje) som angir standardparametere for alle logger. De følgende avsnittene definerer lokale parametere for en serie loggfiler. Navnene på disse filene er oppført i den første linjen i seksjonen, og deretter spesifiseres lokale parametere i krøllete klammeparenteser, som bare er gyldige når de spesifiserte filene behandles (også én parameter per linje). Loggfilnavn kan siteres i henhold til shell-regler hvis de inneholder mellomrom eller andre spesialtegn. Du kan spesifisere flere filnavn eller filnavnmønstre atskilt med mellomrom (mønstre følger også skallregler). Behandling av hver seksjon behandles som en enkelt handling. Linjer som begynner med "#"-symbolet er kommentarer. Lokale parametere har forrang over globale.

Eksempelkonfigurasjonsfilen beskriver først globale parametere, og deretter, i en egen seksjon, parametere for å behandle filene /var/log/wtmp og /var/log/lastlog. I tillegg er det gitt en lenke til katalogen blant de globale parameterne /etc/logrotate.d, der hver pakke skriver lokale parametere for sine logger.

I den globale parameterdelen angir du først en av følgende parametere som bestemmer filrotasjonskriteriet:

daglig- endringer i versjoner i serien skjer daglig,

ukentlig- versjoner endres ukentlig,

månedlig- versjoner endres månedlig,

størrelse byte - en versjonsendring skjer hvis loggstørrelsen overskrider det angitte antallet byte; du kan bruke suffiksene "k" - kilobyte - og "M" - megabyte)

og parameter inkludere, etterfulgt av navnet på en annen (ekstra) konfigurasjonsfil eller til og med navnet på en katalog. I sistnevnte tilfelle anses alle filer i den angitte katalogen, bortsett fra underkataloger, spesialfiler og filer med suffikser fra listen over unntak, som konfigurasjonsfiler for skriptet logrotere(direktiv inkludere kan ikke brukes i en seksjon som spesifiserer behandlingsparametere for en gruppe filer).

Parameter rotere Antall kan finnes blant både globale og lokale parametere og bestemmer hvor mange gamle versjoner som skal lagres; hvis tallet er 0, opprettes ikke arkiverte versjoner av protokollen.

Hvis parameteren er spesifisert komprimere, så komprimeres eldre versjoner ved hjelp av gzip, og hvis spesifisert nocompress- de krymper ikke. Parameter compresscmd lar deg spesifisere hvilket komprimeringsprogram som skal brukes (gzip som standard), og uncompresscmd spesifiserer dekompresjonsprogrammet (standard - ungzip). komprimeringer setter komprimeringsprogramparametere; standard er "-9", dvs. maksimal komprimering for gzip. Ved å bruke parameteren komprimeringsekst du kan endre suffikset for komprimerte filer, og Utvidelse suffiks spesifiserer suffikset som legges til filnavn under rotasjon (før komprimeringssuffikset).

Blant søkeord, som finnes i konfigurasjonsfiler, bør vi spesielt merke oss ordene etterrotere Og forrotere, som fungerer som åpningsparenteser for inkludering i konfigurasjonsfiler for skallskript. Alle linjer i konfigurasjonsfilen fra linjen etterrotereå linje sluttskrift utføres som shell-kommandoer etter prosessen med å endre loggfilversjonen. Følgelig alle linjer fra linjen forrotereå linje sluttskrift kjøres før loggfilene roteres. Ved å bruke disse skriptene kan du organisere ulike prosedyrer for behandling av loggfiler under rotasjon.

Ved å bruke andre parametere i konfigurasjonsfilen kan du omdefinere tilgangsrettigheter til loggfiler (hvis denne parameteren ikke er spesifisert, brukes attributtene til den gamle loggfilen); angi hvem du skal sende meldinger til om feil i loggingssystemets funksjon; send en arkivert kopi av loggen til den angitte brukeren; angi katalogen som logger skal flyttes til under versjonsendringer (katalogen må være på samme fysiske enhet som /var/log) eller angi en liste over ekskluderingssuffikser for katalogen inkludere. Detaljert beskrivelse Du finner disse funksjonene og parameterne (så vel som de som ikke ble nevnt) med kommandoen mann logrotere.

Som allerede nevnt, ekstra konfigurasjonsfiler logrotere kan spesifiseres på kommandolinjen for scriptstart. Du kan spesifisere et vilkårlig antall konfigurasjonsfil- eller katalognavn. Navnene på filer og kataloger i denne listen er atskilt med mellomrom. Rekkefølgen navnene er oppført i betyr noe fordi alternativene som er oppført i det følgende konfigurasjonsfil, overlapper verdiene til parameterne spesifisert i forrige fil. Rekkefølgen på filene i konfigurasjonskatalogen er ikke definert.

I tillegg kan du spesifisere følgende parametere på oppstartskommandolinjen:

• -d- feilsøkingsmodus, ingen reelle endringer er gjort,
• -f- gjøre endringer, selv om logrotere ser ikke behovet - brukes når det er endringer i listen over behandlede logger,
• mann loggklokke
• Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
• RFC 3164. C. Lonvick, The BSD Syslog Protocol, august 2001.
• RFC 3195. D. New, M. Rose, pålitelig levering for syslog, november 2001.
• Per. S. Lapshansky, "Demonen ser på systemet"
• Denis Kolisnichenko,

Handlingene til syslogd-demonen kontrolleres av konfigurasjonsfilen /etc/syslog.conf. Dette er en enkel tekstfil der tomme linjer og linjer med # i første posisjon ignoreres. Filformatet er som følger:

<селектор> <действие>.

For eksempel,

mail.err /var/log/mail.errors

Denne linjen vil sikre at alle e-postleveringsfeil blir registrert i filen /var/log/mail.errors.

Viktig: Bruk kun tasten som skilletegn mellom velgeren og handlingen . Å bruke mellomrom vil være en feil som ikke er lett å oppdage.

Som du allerede har lagt merke til, er velgeren skrevet i en sammensatt form. I generelt syn det ser ut som et middelnivå

Dessuten i felten<селектор>kan inneholde en eller flere velgere, atskilt med semikolon. En velger kan inneholde en gruppe fasiliteter atskilt med komma. Velgeren kan inneholde tegnene * og ingen, som betyr henholdsvis "alt" og "ingenting".

Eksempler på valg:

betyr handlingsnivå

betyr 1, betyr 2. handlingsnivå

betyr 1. nivå 1 betyr 2. nivå 2 handling

*.handlingsnivå

*.nivå;betyr.ingen handling

Følgende tabeller viser hovedfunksjonene i syslog-funksjonene og alvorlighetsgradene.

Verktøyprogrammer som bruker det

kjerne Systemkjernen

bruker Brukerprosesser

e-postsystem

daemon Systemdemoner

auth sikkerhets- og autoritetssystemer

lpr Utskriftssystem

nyheter Telekonferansesystem

cron Cron-demonen

lokal0-7 Åtte nivåer av lokal melding

syslog Interne syslog-systemmeldinger

ftp ftpd daemon

*Alle de ovennevnte betyr

Nivå Nivå verdi

akutte nødsituasjoner

varsle Hastesituasjoner

crit Kritiske stater

feil Feilforhold

advarsel Advarsler

varsel Uvanlige forhold

Info Informasjonsmeldinger

debug Feilsøkingsinformasjon

Nivåene er oppført i synkende rekkefølge. Dette betyr at nivåene angir den minste betydningen en melding må ha for å kunne logges i syslog-systemet.

Felt<действие>indikerer hva som skal gjøres med den mottatte meldingen.

Handlingsbeskrivelse

filnavn Skriv meldingen til en fil på den lokale maskinen

@maskinnavn Videresend en melding til syslogd-demonen på den angitte maskinen

@IP_address Det samme, bare IP-adressen til maskinen er spesifisert

bruker1, Vis en melding på skjermene til de angitte brukerne...

brukerN

* Vis en melding på skjermene til alle brukere

*.emerg /dev/console

*.err;auth.notice /dev/console

*.err;auth,mail,user.info /var/log/messages

mail.err /var/log/mail.log

mail.info @192.168.0.1

Når vi snakker om syslog-systemet, må vi nevne logger-kommandoen, som lar deg skrive oppføringer til systemloggen fra shell-skript.

Denne kommandoen er nyttig for å sjekke endringer som er gjort i filen /etc/syslog.conf.

local5.warning /var/log/local.log

og vil sjekke om det fungerer, skriv deretter inn kommandoen

# logger -p local5.advarsel "Lokal test"

Se på filen /var/log/local.log. Hvis "Local test"-linjen ikke er der, har du mest sannsynlig glemt å sende HUP-signalet til syslogd-demonen.

SERGEY SUPRUNOV

FreeBSD-tips: bruk av syslog

– Unnskyld meg, kamerater, jeg har alle trekkene skrevet ned!

"Kontoret skriver," sa Ostap.

I. Ilf, E. Petrov “12 stoler”.

Logging av driften av ethvert system, og spesielt serveren, er en av de viktigste komponentene i administrasjonen. Det er loggfilene vi ser på først når det oppstår problemer i systemet. Derfra får vi tillit til at dette eller det programmet fungerer som forventet. Ved utvikling av webapplikasjoner blir loggfilen den viktigste kilden til feilsøkingsinformasjon. Funksjonene til syslog-daemonen, som er ansvarlig for logging av systeminformasjon, vil bli diskutert.

Hva er syslog

Syslog er en sentralisert tjeneste som samler inn og registrerer logginformasjon fra ulike operativsystemkomponenter og brukerprosesser. Tredjepartsprogrammer kan som regel fungere med loggfilene deres uavhengig, selv om mange av dem kan konfigureres til å fungere med syslogd-demonen. Fordelene med å bruke syslog inkluderer muligheten til å administrere innsamlingen av nødvendig informasjon ved hjelp av en enkelt konfigurasjonsfil, som sikrer konsistens i de resulterende loggfilene og til slutt forenkler administrasjonen av dem.

Syslog-tjenesten leveres av syslogd-daemonen, som automatisk startes ved systemstart. Den ligger konstant i minnet, venter på meldinger fra andre prosesser og behandler dem i henhold til innstillingene.

Hver melding er preget av et nivå og en kilde (anlegg). Nivået spesifiserer graden av viktighet av meldingen fra et synspunkt om systemdrift. Syslog.h-filen definerer følgende nivåer (prioriteringer):

Tabell 1. Meldingsnivåer

Nivå	Beskrivelse
dukke opp, panikk	Tilstand av "panikk"
varsling	Tilstand som krever umiddelbar inngripen
crit	Kritisk tilstand
feil, feil	Andre driftsfeil
advarsel, advarsel	Advarsler
legge merke til	Meldinger som ikke er feil, men som du bør være oppmerksom på
info	Informasjonsmeldinger (normal drift)
feilsøke	Feilsøkingsinformasjon

Tabell 1 viser meldingsnivåer i synkende rekkefølge. Denne rekkefølgen vil være nødvendig senere når man diskuterer konfigurasjonsfilsyntaks.

Meldingsnivåbetegnelser skrevet på samme linje (for eksempel emerg og panic) er synonymer, og begge kan brukes. Imidlertid er panikk, feil og advarsel (oppført på andreplass i tabellen) utdatert og bør unngås når du redigerer konfigurasjonsfilen. Bruk i stedet henholdsvis emerg, err og warning.

Mulige meldingskilder er oppført i tabell 2:

Tabell 2. Meldingskilder

Kilde	Beskrivelse
kern	Kjernemeldinger
auth, authpriv
sikkerhet	Sikkerhetsmeldinger (for eksempel fra brannmur)
konsoll	Meldinger som kommer til konsollen (/dev/console)
syslog	Innebygde syslog-meldinger
cron	Cron-meldinger
	Tidstjenestemeldinger
	Meldinger FTP-servere
	Skriv ut delsystemmeldinger
post	Postmeldinger
nyheter	Nyhetstjenestemeldinger
uucp	Meldinger UUCP
demon	Meldinger fra andre demoner som kjører i systemet
bruker	Bruker behandle meldinger
lokal0 – lokal7	Kan brukes til ulike brukerbehov (noen ganger også brukt av systemet)

Når du konfigurerer en applikasjon til å bruke syslog-tjenesten, sjekk hvilken funksjon den bruker. Noen programmer lar deg spesifisere kilden selv. For eksempel bruker clamd-demonen (hovedprosessen til clamav-antiviruset) local6 som standard, men lar deg angi en annen kilde (LogFacility-parameteren i konfigurasjonsfilen). I noen tilfeller kan det være nyttig å kombinere meldingene med meldinger fra e-posttjenester, og spesifisere LOG_MAIL som kilde.

Demoniseringsalternativer

For en fullstendig liste over oppstartsalternativer, se syslogd-man-siden. Her vil vi bare vurdere noen få av dem.

Syslog er i stand til å ta opp innkommende meldinger til loggfiler (som vanligvis er plassert i /var/log-katalogen), sende dem til brukerens konsoll eller tilkoblede terminal, sende dem til en ekstern vert, eller sende dem til et eksternt verktøy for behandling via en rørledning.

For å jobbe over nettverket bruker syslog porter 514 (UDP og TCP). Når den kjøres uten ekstra parametere, vil syslogd lytte på disse portene og vente på innkommende meldinger. -s-bryteren forhindrer at innkommende meldinger blir akseptert, men sockets på port 514 opprettes fortsatt for utgående tilkoblinger slik at syslogd kan sende meldinger til eksterne verter. Dobling av bryteren (-ss) deaktiverer også utgående tilkoblinger.

Som standard startes syslogd med -s-bryteren (se /etc/defaults/rc.conf, syslogd_flags parameter), så innkommende tilkoblinger er forbudt. Hvis du vil bruke serverens syslog-tjeneste til å betjene flere maskiner, legg til følgende linje i /etc/rc.conf:

syslogd_flags= ””

Dette vil overstyre verdien satt i /etc/defaults/rc.conf og syslogd vil kunne betjene innkommende tilkoblinger. Naturligvis er det i dette tilfellet nødvendig å sikre det nødvendige sikkerhetsnivået, og eliminere muligheten for at andre verter skriver noe til loggene dine. -a-bryteren lar deg sette begrensninger på innkommende tilkoblinger (se man syslogd). En riktig konfigurert brannmur spiller også en viktig rolle.

En annen nyttig bryter -l lar deg spesifisere ekstra socket-filer som syslogd-demonen lytter til i tillegg til standard /var/run/log. For eksempel kreves denne nøkkelen slik at syslog kan betjene programmer som kjører i et chroot-miljø. Spesielt er det slik named fungerer, og starter med BIND 9. I FreeBSD 5.3 startes syslogd med følgende nøkler:

#ps-voks | grep syslog

321?? Ss 0:01.67 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s

Syntaks for konfigurasjonsfil

Logging er konfigurert i filen /etc/syslog.conf. Det sier seg selv at bare root-brukeren kan redigere den. Denne filen inneholder to typer strenger - la oss kalle dem "filtre" og "regler".

Filterlinjen spesifiserer programmet eller verten som følgende regler vil bli brukt på meldinger fra den. Et filter av formen "!prog" (eller "#!prog") indikerer at de følgende linjene refererer til logger som er generert av det spesifiserte progprogrammet. Et synonym for denne oppføringen er "!+prog". "!-prog"-linjen, derimot, indikerer at påfølgende regler vil gjelde for alle meldinger bortsett fra de som kommer fra prog-programmet. Det er tillatt å liste flere programmer atskilt med komma, mens "+" eller "-" tegnet gjelder for hele listen.

Hvis filterstrengen er spesifisert som "+vertsnavn", vil den angitte verten bli brukt som kilden til meldinger som skal behandles av påfølgende regler. Som med programmer, indikerer "-"-symbolet at reglene vil gjelde for alle meldinger bortsett fra de som kommer fra den angitte verten. Du kan angi en liste over verter atskilt med komma.

"*"-tegnet spesifisert som et program eller vert vil overstyre filteret som tidligere ble satt. Det vil si at reglene spesifisert etter en slik linje vil gjelde for alle meldinger. Filtre med verts- eller programnavn er uavhengige av hverandre og kan fungere samtidig. For eksempel:

# Reglene her gjelder for alle meldinger

Min.vert

# Reglene gjelder for alle meldinger fra my.host

Logger

# Regler brukes på meldinger fra logger fra my.host (vertsfilteret forblir i kraft)

# Regler gjelder for meldinger fra su til my.host

# Reglene gjelder for meldinger fra su fra en hvilken som helst vert (vertsfilteret er kansellert, programfilteret fortsetter å fungere)

# Reglene gjelder for alle meldinger (programfilteret er også kansellert)

Regellinjene ser slik ut:

facility.CMLevel destinasjon

Her er anlegget kilden til meldingen (“*” angir alle kilder), nivå er nivået på meldinger som vil bli behandlet i henhold til denne regelen. Tjenesteordet "ingen", spesifisert i stedet for nivået, gir instruksjoner om å utelukke meldinger fra denne kilden.

CMP – sammenligningsoperasjon (symbolene “>”, “” er tillatt<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.

Destinasjon angir hvor denne meldingen skal lagres. Dette kan være en loggfil (hele banen er angitt, starter med "/"), en ekstern serveradresse (som starter med "@"-symbolet), et brukernavn (meldinger vil bli sendt til terminalen som brukeren er til tilkoblet). Meldingen kan også overføres til et eksternt program for behandling, hvor transportørsymbolet «|» brukes.

Noen eksempler på regler

Alle kjernemeldinger vil bli sendt til kern.log-filen.

kern.* /var/log/kern.log

Alle feilmeldinger, så vel som emerg-, varslings- og kritikknivåmeldinger, vil bli plassert i all-err.log. Legg merke til bindestreken før loggfilnavnet. Som standard bufres meldinger i minnet og skrives til disk når bufferen er full. Dette reduserer belastningen på filsystemet, men kan føre til tap av noe informasjon hvis maskinen krasjer. Bindestreken før filnavnet får syslogd-demonen til å umiddelbart skrive meldinger til disken.

*.err -/var/log/all-err.log

Feilsøkingsmeldinger for brukerprosesser vil sendes ut til terminalen som brukeren vasya for øyeblikket er koblet til.

user.debug Vasya

Alle meldinger fra nyheter og e-posttjenester vil bli videresendt til port 514 på syslog.host.ru-maskinen.

mail.*,nyheter.* @syslog.host.ru

Alle utskriftstjenestemeldinger hvis nivå er lavere enn advarselen vil bli plassert i den angitte filen. Som nevnt tidligere er standardsammenligningen "større enn eller lik" og "!" inverterer den og erstatter den med "mindre". Hvis du trenger å ekskludere et spesifikt nivå, bør du bruke "!="-konstruksjonen.

lpr.!advarsel /var/log/printers.log

Meldinger om feilsøkingsnivået (og bare dette) med funksjonsnivå 0 og nivå 3 vil sendes ut til alle tilkoblede terminaler.

nivå0,nivå3.=debug *

Tidstjenestemeldinger som er høyere enn kritiske (det vil si emerg og alert) og mindre enn eller lik varsel (varsel, info og feilsøking) vil bli sendt til ntpuser- og root-brukerterminalene.

ntp.>crit,<=notice ntpuser,root

Alle meldinger på advarselsnivå, unntatt de som kommer fra e-posttjenester, vil bli registrert i warn.log-filen.

*.=advarsel,mail.none /var/log/warn.log

I dette tilfellet vil alle meldinger hvis nivå er større enn eller lik crit bli sendt på e-post til root-brukeren.

*.crit | e-postens "kritiske melding"-rot

Som du kan se, tillater konfigurasjonsfilformatet flere nivåer, kilder og destinasjoner å bli oppført på én linje, noe som gjør konfigurasjonen mer fleksibel. For at endringer etter redigering skal tre i kraft, må du sende et HUP-signal til syslogd-prosessen:

# kill –HUP `cat /var/run/syslog.pid`

Det skal bemerkes at hvis en bestemt melding er underlagt flere linjer i konfigurasjonsfilen, vil den bli behandlet i samsvar med hver av dem. Eksempel:

mail.* /var/log/maillog

*.=err /var/log/error.log

I dette tilfellet vil mail.err-meldinger havne i både maillog og error.log.

Strategi for å lage en konfigurasjonsfil

Som avslutning på vår gjennomgang av konfigurasjonsfilen, vil jeg si noen ord om strategiene for å kompilere den. I tillegg til det veldig populære "så lenge det fungerer", kan vi skille mellom to hovedtyper, som vi grovt sett vil kalle "etter kilde" og "etter formål."

• Den første strategien, som kan sees i en rekke GNU/Linux-distribusjoner, er å skrive en annen regel for hver meldingskilde (eller en gruppe regler hvis meldinger på forskjellige nivåer skal behandles forskjellig). Fordelen er at det er enkelt å finne ut hvor meldinger fra bestemte tjenester tas opp.
• Strategien "etter destinasjon" innebærer å opprette, hvis mulig, bare én linje for hver "mottaker" av meldingen, for eksempel en fil. Denne tilnærmingen følges spesielt av FreeBSD. Som et resultat kan du enkelt finne ut hvilken informasjon som skrives til en bestemt loggfil, men for eksempel må destinasjoner for kjernemeldinger samles gjennom hele konfigurasjonsfilen.

Logger-verktøy

Systemet inkluderer et loggeverktøy som lar deg sende meldinger til syslog-tjenesten direkte fra kommandolinjen. Det er praktisk å bruke når du tester konfigurasjonsregler, så vel som i utviklede skript for å logge driften deres. Eksempler:

user$ logger -p user.err “Feil i brukerprogram!”

user$ logger -h syslog.host.ru “Test det”

Det første eksemplet vil sende en melding med feil på anleggsbrukernivå, som vil bli behandlet i henhold til konfigurasjonsfilen. Den andre kommandoen vil sende en melding til den eksterne verten, standard kilde og nivå vil bli satt til bruker.varsel.

Bruke rotasjonsmekanismer

Loggmekanismen diskutert ovenfor gir ingen administrasjon av loggfiler. Meldinger plasseres ganske enkelt i dem i henhold til reglene beskrevet i konfigurasjonsfilen. Dette betyr at loggfilene vil stadig vokse, og hvis ingenting gjøres, vil de før eller siden fylle all tilgjengelig plass på den tilsvarende partisjonen. For å unngå dette brukes en rotasjonsmekanisme.

For eksempel, når størrelsen på debug.log-filen overstiger 100 MB, blir den omdøpt til debug.log.0 og pakket inn i debug.log.0.bz2. Og i stedet opprettes en ny debug.log. Deretter, når størrelsen på den nye filen når 100 MB, blir debug.log.0.bz2 omdøpt til debug.log.1.bz2, og prosedyren beskrevet ovenfor gjentas. Systemet lagrer bare et visst antall arkivfiler, og sletter de eldste. Dette er rotasjon.

newsyslog-verktøyet

På FreeBSD-systemet er newsyslog-verktøyet ansvarlig for rotasjon, som som standard lanseres i begynnelsen av hver time av cron-demonen. Du kan endre rotasjonsperioden ved å redigere /etc/crontab.

Rotasjonsparameterne som er angitt i eksemplet ovenfor (filstørrelse, emballasje), samt en rekke andre, er satt i /etc/newsyslog.conf konfigurasjonsfilen. For hver fil som må roteres, inneholder den en linje med generelt ni felt: filnavn, eier og gruppe, tilgangsrettigheter, høyeste antall i arkivfilnavnet, maksimal filstørrelse, rotasjonsperiode, tilleggsflagg og bane til PID-fil for applikasjonen som signalet skal sendes til etter rotasjon, og nummeret på signalet som skal sendes. (Det kan være nødvendig å sende et signal til prosessen, for eksempel hvis prosessen holder loggfilen åpen til enhver tid; hvis dette ikke gjøres, vil ikke filbeskrivelsen som brukes samsvare med den nyopprettede filen.) Noen felt kan utelates. . Her er to eksempler, komplette og "typiske":

/var/log/pflog rot:hjul 600 3 100 * JB /var/run/pflog.pid 1

I henhold til denne regelen skal pflog-filen overskrives så snart størrelsen overstiger 100 MB (5. felt) uavhengig av klokkeslettet («*»-tegnet i det sjette feltet). Arkiverte filer vil ha navn som pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2, etc.), og X kan ikke være mer enn tre (parameter 3 i det 4. feltet). J-flagget indikerer at arkivfilen skal pakkes med bzip2-verktøyet. Takket være B-flagget vil ikke rotasjonstjenestemeldinger legges til arkiverte og nyopprettede filer, siden filen oppfattes som binær. Den nyopprettede filen vil eies av rotbrukeren og hjulgruppen (dette feltet kan utelates siden dette er standardeieren). Tillatelsene vil bli satt til rw------- (numerisk verdi 600), noe som betyr at bare eieren vil kunne lese og skrive til denne filen. Til slutt vil et signal 1 (HUP) bli sendt til prosessen hvis PID er lagret i /var/run/pflog.pid for å gjenåpne loggfilen.

/var/log/maillog 640 7 * @T00 J

Denne regelen spesifiserer rotasjonsparametrene for maillog-filen: uavhengig av størrelsen (stjerne i det 5. feltet), vil filen bli skrevet om hver natt kl. 00:00 (i man newsyslog.conf er tidsformatet beskrevet i tilstrekkelig detalj). Arkivet må pakkes, de siste 8 arkivene (nummerert 0 til og med 7) vil bli lagret, den nyopprettede filen vil eies av root-brukeren (standardverdi, så eierfeltet hoppes over) og har rettighetene rw-r -----.

For å se pakkede loggfiler kan du bruke zcat- og bzcat-verktøyene (for henholdsvis gzip og bzip2). Midnight Commander kaller de aktuelle verktøyene automatisk.

Etter redigering av newsyslog.conf-filen, trenger ingen signaler å sendes noe sted - konfigurasjonen vil bli lest på nytt neste gang newsyslog kalles opp.

Det bør bemerkes at newsyslog-verktøyet ikke er knyttet til syslogd-demonen. Det vil si at den kan brukes til å rotere alle filer som trenger det. Hvis rotasjon er aktivert for logger som applikasjonen vedlikeholder uavhengig (for eksempel clamd- eller squid-logger), så vær spesielt forsiktig med å spesifisere eieren og tilgangsrettighetene. Hvis du spesifiserer dem feil, kan det føre til at etter rotasjon vil en applikasjon som kjører som en uprivilegert bruker ikke kunne skrive til den nyopprettede filen.

Oppsummering

Syslog-systemet er et veldig kraftig og effektivt verktøy for å logge ulike hendelser som skjer i systemet. Standardinnstillingene er ganske balanserte og fungerer bra for de fleste systemer. Men å forstå hvordan syslog fungerer vil tillate deg å forbedre kvaliteten på loggingen betydelig ved å tilpasse registreringen av logginformasjon strengt i samsvar med dine behov.