En lista över vanliga UNIX/LINUX-demoner, i Windows OS kallas tjänster som kan användas i olika UNIX/LINUX-modifieringar. UNIX/LINUX-demonnamn slutar ofta med bokstaven d som en förkortning för engelska. demon Du kan kontrollera om processen/demonen körs med kommandot top eller ps aux.

Nedan är en lista över namnen på de vanligaste demonerna och deras kort beskrivning. Listan över UNIX/LINUX-demoner nedan är inte komplett/uttömmande och ditt UNIX/LINUX-system kan ha en, alla eller flera av dem närvarande eller saknas beroende på version/typ/ändring/konfiguration av ditt UNIX/LINUX-system och det installerade den har mjukvara på den.

Process/Daemon	Process-/demonbeskrivning
granskad	auditd är en revisionskomponent för Linux-system. Upprätthåller en granskningslogg på disken, som kan ses med kommandona ausearch och aureport. Kommandot auditctl låter dig konfigurera revisionsregler. Dessutom laddas reglerna i filen /etc/audit.rules vid uppstart. Vissa parametrar för själva demonen kan konfigureras i filen auditd.conf.
sur	acpid (ACPI-händelsedemon) - en demon för att svara på ACPI-händelser, till exempel att svara på att trycka på strömknappen eller stänga locket på den bärbara datorn. Strömhantering och interaktion mellan Linux och BIOS via ACPI (Advanced Configuration and Power Interface) och APM. ACPI "sleep"-lägen: S1 - allt sover, CPU i minimalt aktivitetsläge; S3 - "Stäng av till RAM" - allt går i viloläge, processorn stängs av; S4 - "Suspend to Disk" tillståndsdumpen sparas på disk, systemet stängs av, efter att ha slagits på återställs systemet från dess tidigare plats; S5 - avstängning av programvara. http://acpid.sourceforge.net/
atd	exekverar jobbkön vid (1)
autofs	Automatiskt tabellformat. Automonteringskartor kan vara filer eller NIS-tabeller som refereras till av master-automonteringstabellen (se auto.master(5)). Tabellerna beskriver platsen filsystem, som automatiskt monteras på basmonteringspunkterna (ställs in i auto.master-filen). Detta dokument beskriver soltabellsformatet, för andra format (t.ex. hesiod) är detta dokument inte tillämpligt. Tabeller kan redigeras i farten - dessa ändringar kommer att beaktas i nästa operation med denna tabell. Detta gäller dock inte huvudtabellen auto.master!
biod	Fungerar tillsammans med fjärr-nfsd för att lösa NFS-klientförfrågningar.
certmonger	Certmonger-demonen övervakar och kontrollerar att certifikaten löper ut och kan valfritt förnya certifikat med en CA. Den kan hantera hela registreringsprocessen från nyckelgenerering till registrering och förnyelse.
cgconfig	Det här skriptet kör verktyget cgconfigparser, som analyserar och konfigurerar kontrollgruppens filsystem (cgroup). För analys används konfigurationsfilen /etc/cgconfig.conf och parametrarna som definieras i den.
cgred	Daemon hanterar cgroup-regler :)
cpufreq	Skriptet laddar kärnmoduler för att styra processorfrekvensen.
cpuhastighet	Ändrar CPU-frekvensen för att spara energi. Många moderna bärbara och stationära datorer stöder denna teknik. Den kan användas av användare med processorer Pentium-M, Centrino, AMD PowerNow, Transmetta, Intel SpeedStep, Athlon-64, Athlon-X2, Intel Core 2. Användare av bärbara datorer rekommenderas att lämna denna demon aktiverad. Inaktivera denna demon om du vill att CPU:n ska använda ett fast frekvensvärde.
crond
cupsd	Skrivarserver. Som åtkomst till fjärrskrivare, åtkomst till lokala, åtkomst utifrån till lokala.
dbus	Interprocess kommunikationssystem ( Bredare analog av CORBA och DCOP)
dbus-demon	Demon för att arbeta med databussen
dhcpd	Daemon för att dynamiskt bestämma TCP/IP-konfiguration för klienter.
dnsmasq	En demon som cachar DNS-namn och tillhandahåller en DHCP-server.
earlysyslog	Att köra syslog-demonen ger loggning.
earlyxdm	Startar X-servern
esound	Ljuddemon, med stöd för fjärråtkomst till ljudkortet
esd	Ljudserver för Enlightenment-fönsterhanteraren och GNOME-miljön. ESD blandar ljudströmmarna från flera program som körs samtidigt och matar ut den resulterande strömmen till ljudkortet. Tillhör paketet esound.
fam	FAM ( Filändringsövervakare) - filändringsövervakare. FAM-demonen används av skrivbordsmiljöer som GNOME, Xfce och KDE för att spåra och visa ändringar som gjorts i filsystemet. Ingår i fampaketet. Har en beskrivning på wiki.archlinux.org.
fläktkontroll	CPU kylare rotationshastighetskontroll. En del av lm_sensors.
fbset	Skriptet som krävs för att framebuffern ska fungera. Konfigurerar dess funktion, inklusive laddning av kärnmoduler.
festival	En demon som gör att textläsningsprogram kan fungera.
fingerad	Tillhandahåller ett nätverksgränssnitt för fingerprotokollet, för användning med fingerkommandot.
firstboot	Tjänsten är endast specifik för Fedora. Det körs endast en gång efter installationen efter installationen (inställning av root-lösenordet, lägga till användare, etc.). Kan inaktiveras efter systeminstallation.
ftpd	Tjänst för överföring av filer via FTP-protokoll.
funktioner	Ett av Arch Linux-systemets initialiseringsskript. Den beskriver funktionerna som åsidosätter de värden som används vid laddning till runlevel 3. Skriptet används endast om användaren använder runlevel 5. Det är en del av initscripts.
gpm	Musserver för konsol och xterm. Ingår i förpackningen med samma namn.
gpsd	Gränssnitt för kommunikation med GPS-utrustning. De flesta användare kan stänga av den.
Haldaemon, hal	HAL står för Hardware Abstraction Layer. En kritisk tjänst för att samla in information om utrustning från olika källor. Det rekommenderas att låta det vara aktiverat.
stanna	Stäng av och starta om skriptet.
stopp.local	Ett skript vars kommandon måste köras innan en avstängning eller omstart börjar.
hälsad	Ställer in driftstemperaturintervallet för moderkortet/processorn och kylhastigheter. Det är en av lm_sensors komponenter.
heimdal-kdc	Nyckeldistributionscenter. Ingår i heimdalspaketet.
httpd	Apache Web Server Daemon.
i det	Ett Unix-program som skapar alla andra processer. Som standard har init-demonen 7 exekveringsnivåer, som var och en kör en fördefinierad uppsättning systemtjänster. Körnivåer: 0 - Systemavstängning 1 - Driftläge för en användare 2-5 - Systemets driftlägen för flera användare Mer information om körnivåer: less /etc/inittab
inetd	Övervakar nätverksförfrågningar. Om begäran är giltig, startar en bakgrundsprocess för att betjäna begäran. Vissa system använder en utökad version - xinetd
iptables	Standardbrandvägg i Linux. Rekommenderas särskilt för direktanslutning till Internet (via kabel, DSL, T1). Rekommenderas inte om du dessutom använder en hårdvarubrandvägg (Netgear, Linksys, D-Link, etc.).
ip6-tabeller	Tjänsten iptables fungerar med IPv6-protokollet. Om du har inaktiverat IPv6-stöd, bör den här tjänsten inaktiveras. Annars rekommenderas det att låta det vara aktiverat.
irda	IrDA behövs för att stödja enheter som fungerar via infraröd ( bärbara datorer, handdatorer, mobiltelefoner, miniräknare (översättarens anmärkning: miniräknare? o_O), etc. De flesta användare kan stänga av den.
irexecd	Demon för infraröd. Levereras med lirc-utils.
irqbalance, irq_balancer	I multiprocessorsystem används det för att fördela avbrott mellan processorer. Användare som inte har flerprocessordatorer/bärbara datorer kan inaktivera denna demon/tjänst. Att aktivera den här tjänsten på en dator med en enda processor kommer inte att ha någon effekt. På nya datorer med mer än en processor (Intel Core 2 Duo, AMD X2) måste denna tjänst vara aktiverad.
ivman	Demonen ansvarar för automontering av enheter i systemet (cd-skivor, USB-enheter, etc.)
jackd, jack-ljud-anslutning-kit	Ljudserver
jexec	Ger stöd för att starta och köra applikationer i java - JAR. Kommer att vara tillgänglig om du installerar Java från Sun. Detta är valfritt och kan inaktiveras.
joystick	Ett skript som laddar kärnmoduler för att joysticken ska fungera.
kadmind	Demon för att fastställa vilka konton som har åtkomst till Kerberos-databasen och deras åtkomstnivå. Det är en av komponenterna i heimdalpaketet.
kdump	kdump - visa kärnspårningsdata. Kommandot visar kärnspårningsfilerna producerade med ktrace(1) i läsbart format. Som standard visas filen ktrace.out i den aktuella katalogen.
kbd	Ställa in tangentbordet i den virtuella terminalen.
kdm	KDM ( KDE Display Manager) är ett av programmen i kdebase-paketet ( ingår i KDE), som ger möjlighet att logga in via ett grafiskt gränssnitt.
kpasswd	Daemon för att byta lösenord i Kerberos. Det är en av komponenterna i heimdalpaketet.
ksysguardd	KDE-demon för systemövervakning.
libvirtd	Daemon för att hantera QEMU gästmaskiner och nätverk.
libvirt-gäster	Ett skript som skickar gästoperativsystem till viloläge när de stängs av och väcker dem när de laddas.
lircd	LIRC-demonen dekrypterar signaler som kommer från den infraröda porten. Levereras med lirc-utils.
lircmd	LIRC-demon som översätter mussignaler. Levereras med lirc-utils.
lvm2-skärm	Daemon för övervakning av LVM (Logical Volume Management). Rekommenderas om du använder LVM, annars lämna det inaktiverat.
lpd	"Line Printer Daemon" - protokollet används för att hantera utskriftsspoolen.
mdadm	Demonen övervakar MD-enheter (programvara RAID i Linux).
mdmonitor och mdmpd	Dessa två demoner används i lagringssystem med RAID-arrayer (redundant array av billiga/oberoende diskar). Mdmonitor startar, stoppar och startar om mdadm (multipath device monitoring and management), en RAID-övervaknings- och hanteringsprogramvarutjänst. Du behöver bara köra den här tjänsten om ditt system har RAID-enheter.
meddelandebuss	Interprocess kommunikationstjänst för Linux. Kritisk komponent eftersom den är ansluten till D-BUS. Det rekommenderas starkt att låta det vara aktiverat.
microcode_ctl, microcode.ctl	En tjänst som låter dig uppdatera firmware för en Intel-processor (Pentium Pro, PII, Celeron, PIII, Xeon, Pentium 4, och så vidare). Uppdateringar registreras varje gång du laddar ner. Bör endast aktiveras om du har en Intel-processor.
mcelog, mcelogd	För att övervaka hårdvaruproblem i 64-bitars Linux-byggen är det bekvämt att använda paketet mcelog, som analyserar MCE-status (Machine Check Exception) i AMD- och Intel-processorer, vilket kan indikera problem med minne och CPU-cache, datautbytesfel mellan processorn och moderkortets chipset.
mpd	Music Player Daemon - musikspelare har en klient-server-arkitektur som spelar musik från en specificerad katalog.
flervägs	Används för att övervaka Multi-Path-enheter, det vill säga enheter som kan nås av mer än en styrenhet eller metod.
mysqld, mysql	MySQL Databas Daemon
nfsd	NFS-operatörsbegäran för klientsystem. Historiskt sett stöder varje nfsd-demon en begäran i taget, så flera kopior lanseras.
netkonsol	Låter dig exportera konsolen till en annan maskin över nätverket. Kan vara inaktiverat som standard.
netfs	Under uppstart monterar den automatiskt filsystem som är tillgängliga över nätverket ( NFS, Samba och andra). De flesta stationära och/eller bärbara användare kan stänga av den.
nätverk	Daemon ansvarig för att skapa och konfigurera lokala nätverksgränssnitt (LAN)
nätverksfjärrkontroller	Samma som den föregående, men höjer dessutom trådlösa gränssnitt
nfs, nfslock	Tjänsterna tillhandahåller ett standardnätverksfilsystem för Unix/Linux och BSD operativsystem. Om du behöver öppna åtkomst via NFS, lämna det aktiverat, annars kan du stänga av det.
nginx	nginx är en webbserver och e-postproxyserver som körs på Unix-liknande operativsystem.
nmbd	Samba används. Se Samba nedan.
nscd	Serverdemon som cachar namn och lösenord som används av tjänster som NIS, NIS+, LDAP, hesiod. Kan stängas av.
nslcd	lokal LDAP-namntjänstdemon.
ntpd	NTP-demon som hanterar tidssynkronisering över nätverket. xntpd är utrustad med version 3 av NTP-standarden.
ntpdate
oddjobd	Daemonen oddjobd tillhandahåller tjänsten com.redhat.oddjob på den systemomfattande meddelandebussen. Varje anläggning som oddjobd tillhandahåller tillhandahålls som en separat D-Bus-metod.
openntpd	Server och klient för tidssynkronisering.
openvpn	Ger en säker metod för att skapa ett VPN. För ytterligare information se OpenVPN. Kan inaktiveras om den inte används av NetworkManager.
pcmcia	Ger stöd för pcmcia standardexpansionskort. Används vanligtvis endast i bärbara datorer.
stcd	Ger stöd för kortläsare och smartkort. Om du inte har en kortläsare eller smartkort kan du stänga av den här tjänsten. Finns ofta på bärbara datorer.
portreserve	Förhindrar åtkomst till riktiga portar för olika RPC-tjänster och prioriterar reserverade applikationer. Mer detaljerad information finns på portreservemansidan. Det rekommenderas att låta det vara aktiverat.
strömavbrott	Det här skriptet körs när meddelanden från UPS upptäcks
postfix	Postfix e-posthanteringsprogram
pppd	Point-to-Point Protocol Daemon
ppp	Skript för att arbeta med pppd-demonen.
psacct	Hanterar Linux-kärnprocesser. Engagerad i övervakning.
rensa kärnor	Manus för automatisk radering gamla kärnor ( konfigurerad i /etc/zypp.conf)
quota_nld	quota netlink message daemon
rå	Skriptet laddar råenhetsmoduler.
rskiva	Demonen för upptäckt av nätverksgateway, rdisc, fungerar som en ICMP Gateway Discovery Protocol-klient. rdisc anropas vid uppstart för att erhålla nätverkets routingtabeller med standardgateways.
rdate	tjänsten behövs för att synkronisera datorn med tidsservern vid uppstart operativ system. Kan inaktiveras.
återställa	Används för att återställa kontext och övervaka SELinux-policy relaterad till filer. Tjänsten krävs inte, men rekommenderas när du använder SELinux.
rngd	rngd - Kontrollera och mata slumpmässiga data från hårdvaruenhet till slumpmässig kärnenhet. Bokstavligen kan det översättas som en demon som kontrollerar och tar emot slumpmässiga data från hårdvaruenheter för kärnan av slumpmässiga enheter - hur smart det är :), slumptalsgeneratordemon, på ryska demonen att generera slumptal.
rpcbind	Daemon för att hantera RPC:er som används av andra tjänster (som NFS eller NIS). Fungerar liknande portmap. Kan inaktiveras om det inte finns några andra tjänster som är beroende av det.
rpcgssd, rpcidmapd, rpcsvcgssd	NFS v4 (Network File System) används. Inaktivera om du inte behöver NFS v4. http://ru.wikipedia.org/wiki/Network_File_System
rsyslog	rsyslog tjänar till bekväm insamling och bearbetning av systemloggar och positionerar sig som en utökad syslogd-modul för Unix-system och Linux, som fokuserar på säkerhet och tillförlitlighet, och som även har avancerad multi-threading. Rsyslog erbjuder ett brett utbud av funktioner, som kan hittas genom att klicka på länken - RSyslog funktioner. http://www.rsyslog.com/module-Static_Docs-view-f-features.html.phtml
rsync	rsync ( Fjärrsynkronisering) är ett program för UNIX-liknande operativsystem som synkroniserar kataloger och filer på flera ställen samtidigt som trafiken minimeras, med hjälp av datakodning vid behov. rsync skapades som en ersättning för rcp och scp. Läs mer...
saslauthd	SASL-autentiseringsserverdemon. SASL ( Enkelt autentiserings- och säkerhetslager) ger möjlighet att autentisera i protokoll baserade på fjärranslutningar.
samba, smbd	Samba-serverdemon.
skicka brev	Ger stöd för lokal IMAP- eller POP3-tjänst, låt den vara aktiverad. Tjänsten kan vara användbar för att meddela om aktiviteten hos olika demoner/tjänster, som kan tillhandahållas via cron eller skicka e-post från PHP-skript.
sensord	Demonen från lm_sensors samlar in information från olika sensorer.
sensorer	Ett skript som vid behov laddar de nödvändiga kärnmodulerna för att fungera med lm_sensors.
strandvägg	Skript för att hantera shorewall-brandväggen.
smal	Inloggningshanterare för X:s.
smartd	SMART-demonen övervakar diskar. Används för att förutsäga fel och övervaka enheter eller hårddiskproblem. Vanligtvis behöver användare inte denna demon, men det rekommenderas fortfarande (särskilt för servrar) att låta den vara aktiverad.
smb	SAMBA-demonen krävs för att öppna den gemensamma nätverkstillgång till filer på Linux för Windows-användare. Måste vara aktiverat om du har Windows-maskiner i nätverket som behöver ges åtkomst till filer.
smolt	En demon som skickar information varje månad för att samla in statistik för att hjälpa utvecklare. Statistik är tillgänglig för alla. Användare som vill hjälpa utvecklare måste aktivera denna tjänst.
snmpd, snmptrapd	Ge SNMP-stöd ( Enkelt nätverkshanteringsprotokoll), som kan användas för att hantera och konfigurera enheter som nätverkshubbar, servrar, skrivare etc. och så vidare. Kan inaktiveras, men kan behövas för att köra HP Print Services ( hplip).
bläckfisk	Squid proxy-demon.
sshd	Lyssnar efter säkra skalförfrågningar från klienter. SSH tillåter andra användare att logga in över nätverket från en annan dator och köra applikationer på din dator, som vanligtvis används för fjärradministration. Detta kan vara en potentiell säkerhetsrisk. På arbetsstationer som inte kräver fjärråtkomst är det lämpligt att stänga av den.
sssd	SSSD ( System Security Services Daemon) tillåter åtkomst till fjärrautentiseringsmekanismer. Detta suddar ut gränsen mellan nätverk och lokal autentisering och tillåter användning av olika mekanismer. Information om användare överförs av en databas som kallas en domän och kan vara en datakälla för fjärrautentisering. Flera mekanismer är tillåtna, vilket gör att flera servrar kan implementera olika namnområden. Den mottagna informationen tillhandahålls externa applikationer med hjälp av standard NSS- och PAM-gränssnitt. SSSD körs som en uppsättning tjänster som är oberoende av applikationen som anropar dem, så applikationer behöver inte initiera sina egna anslutningar till fjärrdomäner, och de behöver inte heller veta vilken demon/tjänst som används. Lokal cachelagring av gruppinformation och identitetsdata tillåter oavsett datakälla ( LDAP, NIS, IPA, DB, Samba, etc.) fortsätter att arbeta offline, vilket totalt sett förbättrar produktiviteten. SSSD kan tillåta flera leverantörer av samma typ ( till exempel LDAP).
svnserve	svn serverdemon.
sysstat	Sysstat-paketet innehåller verktyg för att övervaka systemprestanda och använda resurser.
bytare	Kopierar den lokala processen till swap-utrymme för att fixa den fysiska minnessidan för kärnan. Kallas även schema.
syslogd	Systemprocess för att spela in olika systemmeddelanden.
synk	Synkroniseras med jämna mellanrum med system minne Etablerade systemfiler.
syslog-ng	Demonen håller systemloggar.
udev-post	Systemenhetshanteraren som används av udev. Som standard stöder udev ett stort antal regler, beteenden och behörigheter för enheter. Med den här tjänsten kan du säkert hantera regler. Det rekommenderas att låta det vara aktiverat.
vhand	Frigör minnessidor för användning av andra processer. Även känd som "page stealing daemon".
vsftpd	vsftpd ( Very Secure FTP Daemon - Mycket säker FTP Daemon) - FTP-server som stöder IPv6 och SSL. vsftpd används som standard på många UNIX-liknande operativsystem, tjänar även de officiella förråden ftp.openbsd.org, ftp.freebsd.org, ftp.debian.org, ftp.redhat.com och används på den officiella Linux-kärnan FTP server.
webbmin	Systemhanteringstjänst via webbläsare ( webbgränssnitt).
winbind	En tjänst som hjälper dig att skilja på nätverket datornamn under Windows kontroll. Kan användas för att styra konton Windows med Linux-konton. Vanligtvis behöver de flesta användare inte denna demon och kan lämna den inaktiverad.
wpa_supplicant	Tjänsten behövs för att arbeta med trådlösa kort, som används för att ansluta till åtkomstpunkter ( VPN eller Radius-servrar) kräver WPA-kryptering. De flesta användare kan lämna det inaktiverat.
xfsd	Serverar X11-teckensnitt för fjärrklienter.
jams	tjänst för uppdatering av RPM-paket installerade på systemet. Används främst i Fedora Core.
ypbind	Tjänsten används för NIS-autentisering över nätverket. Om NIS-autentisering inte används kan du inaktivera den.
zvbid	En tjänst som ger åtkomst från V4L- eller V4L2-enheter till flera applikationer. Till exempel kan ett kort för att fånga Hauppage använda denna tjänst, i andra fall kan den stängas av.

Om ovanstående lista över UNIX/Linux-demoner/tjänster inte fungerar på ditt system, då för att få hjälp om en sådan tjänst använd man name_daemon, och om det inte finns någon information om den körande tjänsten där, då skriv i kommentarerna och tillsammans kommer vi att samla in information om en sådan tjänst och lägga till listan över UNIX/Linux-demoner/tjänster som ges här.

Om det inte finns någon beskrivning av tjänsten i hjälpen man name_daemon, då demonen/tjänsten kan vara ett virus, i det här fallet, sök efter den körbara filen där namn_daemon är och skicka den för analys till ett viruslaboratorium - detta kan göras utan att installera ett antivirus via webbgränssnittet, till exempel http://vms.drweb.com/online/, http://www.esetnod32.ru/.support/scanner/ eller https://www.virustotal.com/.

Laddar UNIX/LINUX-demoner/tjänster automatiskt

Nedan finns detaljerade instruktioner för hantering av start av demoner/tjänster i de vanligaste modifieringarna/versionerna av UNIX-liknande OS som t.ex CentOS Linux, Debian Linux och BSD-typ OS. I andra modifieringar/versioner av UNIX-liknande operativsystem har hanteringen av autoloading av demoner/tjänster en liknande procedur, även om det kan ha några mindre eller till och med radikala skillnader!

Laddar Daemons/tjänster automatiskt på CentOS Linux

CentOS har definierade belastningsnivåer enligt System V-principen och är målade i filen /etc/inittab, läs mindre /etc/inittab .

Katalogerna för varje laddningsnivå namnges och finns i katalogen /etc/rc.d.

I var och en av katalogerna som motsvarar en viss belastningsnivå finns skript, eller snarare länkar till dem, med instruktioner för att starta demonen/programmet/tjänsten, och själva skripten med instruktioner för att starta demonen/programmet/tjänsten finns i katalogen /etc /rc.d/init.d

Ett exempel på skript som styr lanseringen av en demon/program/tjänst kan ses genom att köra mindre /etc/rc.d/init.d/mysqld eller mindre /etc/rc.d/init.d/sshd . Vanligtvis visas skript som styr lanseringen av en demon/program/tjänst i /etc/rc.d/init.d/ och är länkade till runlevel-kataloger efter mjukvaruinstallation, och deras status är av/på för varje löpnivå styrs av verktyget chkconfig.

Du kan se vilka demoner som kommer att köras på olika körnivåer med kommandot chkconfig --list. Du kan aktivera demonen att köras automatiskt i vilken som helst av körningsnivåerna med kommandot chkconfig --level 345 mysqld on och stänga av chkconfig --level 345 mysqld respektive, chkconfig –del service_ name för att ta bort en tjänst, chkconfig service_name på |av för att aktivera eller inaktivera en tjänst på alla nivåer.

När det gäller att lägga till skript vid start, alltså För automatisk nedladdning skript betjänas av /etc/rc.local, i /etc/rc.local räcker det att lägga till hela sökvägen till skriptet, till exempel: /root/scripts/script.sh eller /bin/sh /root/scripts/script.sh . Om efter installation av programvaran det inte finns något startkontrollskript i /etc/rc.d/init.d/ önskat program, då är det lättare att lägga till dess initialiserings-/startrad till /etc/rc.local.

Det finns ett verktyg som heter ntsysv för att hantera körnivåer, man ntsysv.

Laddar Daemons/tjänster automatiskt på Debian Linux

Katalogerna för varje startnivå i Debian Linux är också namngivna rc0.d, rcl.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d Men, belägen inte längre i katalogen /etc/rc.d, men i roten av katalogen /etc

Det fanns skript med instruktioner för att starta demonen/programmet/tjänsten, eller snarare symboliska länkar till dem finns i /etc/rc?.d-katalogerna var är tecknet? motsvarar belastningsnivån, och Själva skripten med instruktioner för att starta demonen/programmet/tjänsten finns i katalogen /etc/init.d. Ett exempel på en sådan skipt, baserat på vilket du kan skriva din egen, finns i filen less /etc/init.d/skeleton.

Nedan kommer vi att ge en förklaring av tjänsteinformationen som används i skriptmallen /etc/init.d/skeleton:

• Ger: Beskriver objekten som tillhandahålls av det här skriptet (arg1, agr2, ...) på ett sådant sätt att när skriptet körs med argumentet start, anses dessa objekt existera, och därför andra skript i init som kräver existensen av dessa objekt kommer att kunna starta i ett senare skede. Vanligtvis kan du använda namnet på skriptet som objekt, men du kan också använda namnet på tjänsten som det ersätter. Virtuella objekt anges inte här. De definieras utanför init.d-skripten
• Obligatorisk-start: Anger objekt som måste finnas för att köra skriptet. Om det behövs kan du använda virtuella objekt enligt beskrivningen nedan. Om objekt inte är specificerade kan skriptet startas omedelbart efter start, utan att behöva ansluta lokala filsystem, starta systemloggen etc.
• Obligatoriskt stopp: Anger objekten som används av tjänsten, som tillhandahålls av skriptet. Objektet som tillhandahålls av det här skriptet måste slutföras innan objekten som listas här slutförs för att undvika konflikter. Vanligtvis anges samma objekt här som i Required-Start
• Bör-Starta: Anger de objekt som, om de finns, ska startas före tjänsten som tillhandahålls av detta skript. Detta tillåter svaga beroenden som inte gör att tjänsten misslyckas om objekt inte är tillgängliga. Du kan använda virtuella objekt efter behov, enligt beskrivningen nedan.
• Bör-Stoppa: Anger objekt som, om de finns, ska stoppas efter av denna tjänst. Vanligtvis anges samma objekt här som i Bör-Start
• Standard-Start: Ställer in de körnivåer vid vilka skriptet ska startas (stoppas) som standard. Till exempel, om tjänsten endast ska startas på nivåerna 3, 4 och 5, ange "Default-Start: 3 4 5" och "Default-Stop: 0 1 2 6".
• Kort beskrivning: Anger en kort beskrivning av skriptåtgärden. Begränsad till en rad.
• Beskrivning: Anger en mer detaljerad beskrivning av skriptåtgärden. Kan vara på flera rader, i vilket fall varje beskrivningsrad måste börja med ett #-tecken följt av ett tabbtecken eller minst 2 blanksteg. Beskrivningen slutar före en rad som inte matchar detta villkor.
• X-Start-Before, X-Stop-After: Anger omvända beroenden som har samma innebörd som om de var specificerade i bör-start och bör-stopp i paketen som anges här.

Nyckelorden tillhandahåller, krävs- och bör- är viktiga för att spåra beroenden. Resten används inte. Runlevels används av programmet som standard för att organisera skript ( till exempel insserv) för att hålla reda på vilken katalog rc?.d uppdatera när en tjänst först läggs till och bör återspegla syftet med tjänsten. Här är några "virtuella" objekt:

• $local_fs- Alla lokala filsystem är anslutna. Alla skript som skriver till /var/ bör bero på detta om de inte redan är beroende av $remote_fs
• $nätverk- lågnivånät, dvs. nätverkskort, kan innebära att PCMCIA körs
• $namn- Demoner som kan ge upplösning av domännamn antas vara igång. Till exempel DNS, NIS+ eller LDAP
• $portmap- Demoner som tillhandahåller SunRPC/ONCRPC-portmappningstjänsten enligt beskrivningen i 1833 (om några)
• $remote_fs- Alla filsystem är anslutna. Skript som måste köras under en systemavstängning innan en dödningssignal skickas till alla processer måste bero på $remote_fs.
• $syslog- Systemloggen fungerar
• $tid- rätt systemtid är inställd, till exempel ntp eller rdate, eller RTC
• $all- Kör skriptet så sist som möjligt

Daemon autoloading i Debian Linux styrs med hjälp av verktyget update-rc.d, som beskrivs i man update-rc.d . Verktyget update-rc.d skapar eller tar inte bort något annat än symboliska länkar i /etc/rc?.d till de så kallade init-skripten som styr start och stopp av daemon/program/tjänst, som finns i katalogen /etc/init.d.

Om skriptet för att autostarta demonen/tjänsten skapas manuellt med mallen /etc/init.d/skeleton, då måste du först placera den i katalogen /etc/init.d och sedan skapa en symbolisk länk till detta skript i katalogen /etc/rc?.d, var? - runlevel nummer ( systemets belastningsnivå). Den symboliska länken ska se ut så här: S№№script_name, där No. är startordernumret, om du vill lämna en symbolisk länk men inte köra skriptet tillfälligt, bör den symboliska länken ändras till detta tillstånd KNo. script_name.

Innan någon exekveringsnivå kan bearbetas, exekveras först alla skript som börjar med bokstaven ". K" (dessa skript stoppar tjänster), och sedan exekveras alla skript som börjar med bokstaven " S" (dessa skript startar tjänster). Det tvåsiffriga numret efter bokstaven "S" eller "K" anger i vilken ordning skripten kommer att köras. Skript med ett lägre nummer exekveras först, till exempel: S01script_name startar först och S09script_name kommer att startas som nionde.

För att skapa en symbolisk länk, använd programmet ln -s file1 file2 , Var nyckel -s talar om att skapa en symbolisk länk, fil1 pekar på en befintlig fil, och fil 2 namnet på den nya länken, men istället för att skapa symboliska länkar manuellt kan du använda verktyget update-rc.d, som är designat specifikt för att skapa symboliska länkar i /etc/rc?.d till skript från /etc/init. d.

Update-rc.d-syntaxen är så här: lägga till med standardparametrar update-rc.d defaults , ta bort och stoppa daemon/service update-rc.d -f ta bort && update-rc.d stopp 20 2 3 4 5 . Start och stopp av demoner/tjänster kan styras genom tjänstens namn start|stop|restart script.

Uppriktigt sagt är update-rc.d ett relativt ogenomskinligt verktyg, Verktyget chkconfig är bekvämare, som inte är tillgängligt som standard på Debian Linux. För att installera det måste vi lägga till ytterligare förråd, det är tillrådligt att endast använda officiella Debian Linux-paketförråd, till slutet av listan vi /etc/apt/sources.list, exempel sources.list i Debian GNU/Linux 6.0.5 _Squeeze_ - Officiell 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 , tidigare känd som "volatile" # En nätverksspegel valdes inte under installationen. Följande poster # tillhandahålls som exempel, men du bör ändra dem efter behov # för din valfri spegel. # # 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 contribution #deb http://mirror.yandex.ru/debian-multimedia/ squeeze main contrib

Uppdatera sedan listan över paket med apt-get update och installera chkconfig apt-get install chkconfig , och som ett alternativ kan du dessutom installera sysv-rc-conf apt-get install sysv-rc-conf . Hur man använder verktyget chkconfig nämndes ovan, se dessutom man sysv-rc-conf och man chkconfig.

När du lägger till Debian Linux-förråd, var medveten om programvarupolicyerna som gäller för vart och ett av områdena som huvud, bidrag och icke-gratis:

• huvud: - Paketen i detta område är en del av den fullständiga Debian Linux-distributionen och inget av paketen i huvudområdet kräver programvara från utanför detta område för att fungera fullt ut. Vem som helst kan fritt använda, dela, modifiera och distribuera paket från huvudområdet.
• bidrag: - Paket från detta område kan distribueras fritt, men vissa av deras beroenden kanske inte är gratis.
• icke-fria: - innehåller paket som inte kan distribueras gratis enligt DSFG, och paket från området kan innehålla fel som inte beaktas vid utveckling och uppdatering av Debian Linux.

För att autoköra andra skript och program i Debian Linux kan du använda den gamla goda /etc/rc.local.

Systemadministratörer och vanliga Linux-användare behöver ofta titta på loggfiler för att felsöka problem. Detta är faktiskt det första en systemadministratör bör göra när något fel uppstår i systemet.

Själva operativsystemet Linux och de program som körs genererar olika typer av meddelanden som loggas i olika loggfiler. Linux använder speciell programvara, filer och kataloger för att lagra loggfiler. Att veta vilka filer som innehåller loggarna för vilka program hjälper dig att spara tid och lösa problemet snabbare.

I den här artikeln kommer vi att titta på huvuddelarna av Linux-loggningssystemet, loggfiler och verktyg som du kan använda för att se Linux-loggar.

De flesta filer Linux-loggar finns i mappen /var/log/. Du kan lista loggfilerna för ditt system med kommandot ls:

Rw-r--r-- 1 rotrot 52198 10 maj 11:03 alternatives.log
drwxr-x--- 2 rot rot 4096 14 nov 15:07 apache2
drwxr-xr-x 2 root root 4096 25 apr 12:31 apparmor
drwx------ 2 root root 4096 5 maj 10:15 revision
-rw-r--r-- 1 rotrot 33100 10 maj 10:33 boot.log

Nedan kommer vi att titta på 20 olika Linux-loggfiler som finns i katalogen /var/log/. Vissa av dessa loggar finns bara på vissa distributioner, till exempel finns dpkg.log bara på Debianbaserade system.

/var/log/meddelanden- innehåller globala Linux-systemloggar, inklusive de som registreras vid systemstart. Flera typer av meddelanden registreras i denna logg: mail, cron, olika tjänster, kärna, autentisering och andra.

/var/log/dmesg- innehåller meddelanden som tagits emot från kärnan. Loggar många meddelanden under uppstartsfasen, de visar information om hårdvaruenheter som initieras under uppstartsprocessen. Du kan säga att detta är en annan logg över Linux-systemet. Antalet meddelanden i loggen är begränsat, och när filen är full kommer de gamla att skrivas över med varje nytt meddelande. Du kan också visa meddelanden från den här loggen med kommandot dmseg.

/var/log/auth.log- innehåller information om användarbehörighet i systemet, inklusive användarinloggningar och autentiseringsmekanismer som användes.

/var/log/boot.log- Innehåller information som loggas när systemet startar.

/var/log/daemon.log- Innehåller meddelanden från olika bakgrundsdemoner

/var/log/kern.log- Innehåller även meddelanden från kärnan, användbara vid felsökning av fel i anpassade moduler inbyggda i kärnan.

/var/log/lastlog- Visar information om den senaste sessionen för alla användare. Det här är en icke-textfil och du måste använda kommandot lastlog för att visa den.

/var/log/maillog /var/log/mail.log- loggar för e-postservern som körs på systemet.

/var/log/user.log- Information från alla loggar på användarnivå.

/var/log/Xorg.x.log- X-servermeddelandelogg.

/var/log/alternatives.log- Information om hur programmet update-alternatives fungerar. Dessa är symboliska länkar till standardkommandon eller bibliotek.

/var/log/btmp- logga Linux-fil innehåller information om misslyckade inloggningsförsök. För att se filen är det bekvämt att använda kommandot last -f /var/log/btmp

/var/log/cups- Alla meddelanden relaterade till utskrift och skrivare.

/var/log/anaconda.log- alla meddelanden som spelas in under installationen sparas i den här filen

/var/log/yum.log- Loggar all information om paketinstallationer med Yum.

/var/log/cron- Närhelst Cron-demonen börjar köra ett program, skriver den en rapport och meddelanden från själva programmet i den här filen.

/var/log/secure- innehåller information relaterad till autentisering och auktorisering. Till exempel loggar SSHd allt här, inklusive misslyckade inloggningsförsök.

/var/log/wtmp eller /var/log/utmp - Linux-systemloggar , innehålla en logg över användarinloggningar. Med hjälp av kommandot wtmp kan du ta reda på vem som är inloggad och när.

/var/log/faillog- logga linux-system, innehåller misslyckade inloggningsförsök. Använd kommandot faillog för att visa innehållet i den här filen.

/var/log/mysqld.log- Linux-loggfiler från MySQL-databasservern.

/var/log/httpd/ eller /var/log/apache2- loggfiler för linux11 Apache webbserver. Åtkomstloggar finns i access_log-filen och felloggar finns i error_log

/var/log/lighttpd/ - linux loggar lighttpd webbserver

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

/var/log/mail/- den här katalogen innehåller ytterligare e-postserverloggar

/var/log/prelink/- Prelink-programmet länkar bibliotek och körbara filer för att påskynda nedladdningsprocessen. /var/log/prelink/prelink.log innehåller information om .so-filer som har modifierats av programmet.

/var/log/audit/- Innehåller information genererad av den granskade demonen.

/var/log/setroubleshoot/ - SE Linux använder setroubleshootd-demonen (SE Trouble Shoot Daemon) för att rapportera säkerhetsproblem. Den här loggen innehåller meddelanden från detta program.

/var/log/samba/- innehåller information och loggar från Samba-filservern som används för att ansluta till delade mappar Windows.

/var/log/sa/- Innehåller .cap-filer som samlats in av Sysstat-paketet.

/var/log/sssd/- Används av systemsäkerhetsdemonen som hanterar Fjärranslutning till kataloger och autentiseringsmekanismer.

Visa loggar i Linux

För att se loggar på Linux är det bekvämt att använda flera kommandoradsverktyg Linux-strängar. Det kan vara vem som helst textredigerare, eller särskild nytta. Troligtvis kommer du att behöva superanvändarrättigheter för att se loggar i Linux. Här är de kommandon som oftast används för dessa ändamål:

• zgrep
• zmore

Jag kommer inte att gå in i detalj på vart och ett av dessa kommandon, eftersom de flesta av dem redan har diskuterats i detalj på vår webbplats. Men jag ska ge några exempel. Att visa Linux-loggar är väldigt enkelt:

Vi tittar på loggen /var/log/messages, med möjligheten att rulla:

mindre /var/log/meddelanden

Visa Linux-loggar i realtid:

tail -f /var/log/meddelanden

Öppna dmesg-loggfilen:

cat /var/log/dmesg

Första raderna i dmesg:

huvud /var/log/dmesg

Vi matar bara ut fel från /var/log/messages:

grep -i fel /var/log/meddelanden

Dessutom kan du visa loggar på Linux med hjälp av grafiska verktyg. Systemprogram Log Viewer kan användas för att bekväm visning och övervakningssystem loggar på en bärbar dator eller personlig dator med Linux.

Du kan installera programmet på alla system med en X-server installerad. Dessutom kan vilken grafisk testredigerare som helst användas för att visa loggar.

Slutsatser

I katalogen /var/log kan du hitta all nödvändig information om driften av Linux. Från dagens artikel har du lärt dig tillräckligt för att veta var du ska leta och vad du ska leta efter. Nu kommer du inte att få problem att se loggar i Linux. Om du har några frågor, fråga i kommentarerna!

Var och en av nybörjarna Linux-användare stöter förr eller senare på några problem med att ställa in och organisera hur deras system fungerar. Och var och en av nykomlingarna har nästan säkert hört råd från mer erfarna användare: "Titta på loggarna." Råden är bra, men en nybörjare behöver fortfarande veta: vad loggar är och var man ska leta efter dem! Så i den här artikeln ska jag försöka berätta för dig vad du ska titta på och var.

I programmeringsslang är "loggar" arbetsprotokoll som underhålls både av själva operativsystemet och oberoende av många program. Ordet "journal" används ofta som en synonym för ordet "protokoll" i denna mening. Det finns två huvudsakliga situationer där behovet av att analysera ett protokoll uppstår: när något i systemet inte fungerar som vi förväntat oss (problemlösning), och när det finns en misstanke om att systemet har hackats av någon angripare och vi måste ta reda på exakt vad som hände, hur det gjordes och vad som behöver göras för att eliminera konsekvenserna av invasionen.

Ett av de mest kända fallen av att använda loggfiler för att upptäcka en angripares intrång är historien om tillfångatagandet av den berömda hackaren Kevin Mitnick av datasäkerhetsspecialisten Tsuomo Shimomura. Här är ett stycke från en artikel som beskriver hur detta hände.

"På juldagen, när Shimomura åkte skidor i Nevada för semestern, bröt någon (vi vet redan vem) sig in i hans supersäkra hemdator i Solana Beach, Kalifornien, och började kopiera sina filer - hundratals hemligstämplade filer. En doktorand vid Supercomputing Center i San Diego, där Shimomura arbetade, märkte förändringar i systemets "loggfiler" och insåg snabbt vad som hände. Allt detta var möjligt tack vare det faktum att Shimomura installerade ett program på sin dator som automatiskt kopierar "journal"-poster till en backupdator i San Diego. Eleven ringde Shimomura, som rusade hem för att inventera de stulna föremålen."

Jag kommer inte att berätta hela historien här, det är viktigt för oss att bara notera att analysen av systemets driftprotokoll låg till grund för framgången för utredningen om tjänstefel. Du hittar en mer detaljerad beskrivning av hur sådana undersökningar går till i artikeln. Men för att kunna dra nytta av loggningens resultat behöver du förstå hur protokoll skapas, var de lagras och vad som kan extraheras från dem. Den här artikeln ägnas åt övervägandet av alla dessa frågor.

Hur meddelanden för protokollet genereras

Vi måste börja med det faktum att när man skapar program på C-språket har programmerare möjlighet att vid behov infoga anrop till specialfunktioner openlog, setlogmask, syslog Och closelog, inkluderat i standardbiblioteket för språket C. Dessa funktioner används för att skicka meddelanden om vissa händelser under programkörning till en speciell systemdemon syslogd, utför systemprotokollet. Fungera öppen log upprättar en förbindelse med en demon syslogd, funktion syslog genererar ett specifikt meddelande som ska registreras i protokollet och funktionen closelog stänger en öppen anslutning.

Meddelanden som genereras av funktionen syslog, består av flera fält åtskilda av mellanslag. Varje meddelande börjar med ett fält PRI, som i kodad form innehåller information om meddelandets (anläggningens) kategori och meddelandets allvarlighetsgrad (allvarlighetsgrad) eller prioritet (prioritet).

Kategori (anläggning) är information om vilken klass detta meddelande tillhör. Kategorin är kodad med ett nummer från 0 till 23. Följande kategorier finns (de definieras i filen /usr/include/sys/syslog.h):

Bord 1.

Numeriskt värde	Symbol	Avkodning
0	kern	Kärnmeddelanden
1	användare	Designad för olika meddelanden från användarprogram. (meddelanden från användarprogram)
2	post	Meddelanden från Postsystem.
3	demon	Meddelanden från dessa systemdemoner som, till skillnad från FTP eller LPR, inte har kategorier dedikerade specifikt till dem.
4	auth	Allt relaterat till användarbehörighet, som inloggning och su (säkerhet/åtkomsträttigheter)
5	syslog	Loggningssystemet kan logga meddelanden från sig självt.
6	lpr	Meddelanden från utskriftssystemet.
7	Nyheter	Meddelanden från nyhetsservern. (Netnews, USENET)
8	uucp	UNIX-till-UNIX Copy Protocol-meddelanden. Det är en del av UNIX-historiken och du kommer förmodligen aldrig att behöva det (även om en del post fortfarande levereras via UUCP).
9	cron	Meddelanden från systemschemaläggaren.
10	authpriv	Samma som auth, men meddelanden i denna kategori skrivs till en fil som bara vissa användare kan läsa (kanske är den här kategorin vald eftersom meddelanden som hör till den kan innehålla tydliga användarlösenord som inte ska ses av främlingar, och därför måste loggfiler ha lämpliga åtkomsträttigheter).
11	ftp	Med den här kategorin kan du konfigurera din FTP-server så att den registrerar dess aktiviteter.
från 12 till 15	-	Reserverad för systemanvändning.
från 16 till 23	lokal0 - lokal7	Reserverade kategorier för användning av systemadministratören. Kategorien local7 används vanligtvis för meddelanden som genereras under systemets startfas.

Kategori auth har ett föråldrat synonymnamn säkerhet, vilket inte rekommenderas. Dessutom finns det en speciell kategori märke(som inte har någon digital motsvarighet), som tilldelas individuella meddelanden som genereras av demonen själv syslogd. Den här kategorin används för att placera speciella märken i protokollet vid ett angivet tidsintervall (var 20:e minut som standard), vilket gör att du till exempel kan ta reda på med 20 minuters noggrannhet när din dator frös.

Observera att kategorin i allmänhet inte har något att göra med namnet på programmet som skickar meddelanden till demonen syslogd. Som de säger, varje slump är en ren slump. Dessutom kan vissa program generera meddelanden i olika kategorier. Till exempel en demon telnetd i händelse av misslyckade loggningsförsök, genererar kategorimeddelanden authpriv, och i andra fall kategoriserar deras meddelanden demon.

Den andra parametern på grundval av vilken fältvärdet bildas PRI, är meddelandets nivå eller prioritet (prioritet), det vill säga information om graden av betydelse för meddelandet. Som standard är 8 nivåer av betydelse specificerade (de definieras också i filen /usr/include/sys/syslog.h), som är kodade med siffror från 0 till 7:

Tabell 2.

Numeriskt värde	Symbol	Avkodning
0	uppstå(gammalt namn PANIC)	Nödsituation. Systemet fungerar inte.
1	varna	Ångest! Omedelbart ingripande krävs.
2	crit	Kritiskt fel(kritiskt tillstånd).
3	fela(gammalt namn FEL)	Felmeddelande.
4	varning(gammalt namn VARNA)	Varning.
5	lägga märke till	Information om någon normal men viktig händelse.
6	info	Meddelande.
7	felsöka	Meddelanden som genereras under felsökning.

Fält PRI Meddelandet bildas på följande sätt: kategorins numeriska värde multipliceras med 8 och läggs till det numeriska värdet för prioriteten, det resulterande talet omges av vinkelparenteser och skrivs i fältet.

Följer fältet PRI Meddelandet innehåller följande fält:

• TIDSSTÄMPEL- meddelandegenereringstid,
• VÄRDNAMN- värdnamn eller IP-adress i decimalnotation,
• MSG- godtycklig meddelandetext - någon textsträng (informations) i US-ASCII-kod (0x20 - 0x7e).

Tid (lokal!) skrivs i formatet: 13 feb 21:12:06. Om dagnumret är en ensiffrig, placeras ett extra mellanslag (inte 0!) framför det. Observera att det inte finns något årtal och zon i datumet, vilket måste beaktas när man organiserar långtidslagring av loggfiler. För att tiden i meddelandet ska vara korrekt måste det synkroniseras (till exempel med hjälp av NTP-protokollet).

Värdnamnet ingår i meddelandet för att undvika förvirring mellan meddelanden från olika värdar, eftersom, som kommer att visas nedan, loggning kan göras på en av de dedikerade datorerna i nätverket. Värdnamnet är det enkla nätverksnamnet på datorn, utan att ange domänen. Om en dator har flera gränssnitt med olika IP-adresser kan vilken som helst av dem användas som värdnamn eller adress.

Meddelandetext ( MSG) innehåller vanligtvis en etikett ( MÄRKA), som anger programmet eller processen som utfärdade meddelandet och meddelandets brödtext ( INNEHÅLL). Etiketten kan innehålla latinska bokstäver och siffror. Typiskt är etiketten helt enkelt programnamnet, ibland kompletterat med en processidentifierare omgiven av hakparenteser. Meddelandets brödtext skiljs från etiketten med specialtecken - i Linux är dessa vanligtvis ett kolon och ett mellanslag.

Bearbetar meddelanden av syslogd-demonen

Alla meddelanden som genereras av enskilda program som använder funktionen syslog, skickas via uttag /dev/log systemdemon syslogd, som ansvarar för behandlingen av dessa meddelanden. Det måste sägas att faktiskt två loggningsdemoner lanseras i systemet - syslogd Och klogd. Båda demonerna ingår i paketet sysklogd, den senaste versionen som du kan hitta på webbplatsen.

Demon klogdär ansvarig för att logga händelser som inträffar i systemkärnan. Behovet av en separat demon klogd på grund av att kärnan inte kan använda standardfunktionen syslog. Faktum är att standardbibliotek(inklusive biblioteket där funktionen finns syslog) är endast avsedda att användas av vanliga applikationer. Eftersom kärnan också behöver liknande funktioner inkluderar den sina egna bibliotek som inte är tillgängliga för applikationer. Därför använder kärnan sin egen meddelandegenereringsmekanism. Demon klogdär utformad för att organisera behandlingen av dessa meddelanden. Han kan i princip utföra sådan behandling helt oberoende och oberoende av syslogd, till exempel genom att logga dessa meddelanden till en fil, men i de flesta fall används standardinställningen klogd, där alla meddelanden från kärnan vidarebefordras till samma demon syslogd.

För att se till demonerna syslogd Och klogd körs på ditt system, kör kommandot ps -ax | grep loggen. Detta kommando gav mig följande resultat:

$ ps -ax | grep loggen 569? S 0:00 syslogd -m 0 574 ? S 0:00 klogd -x 1013 ? S 0:00 inloggning -- kos 1191 ? S 0:00 kalarmd --login De två första raderna indikerar att loggningsdemoner körs i systemet.

Bearbetar meddelanden av demonen syslogdär att den ständigt övervakar utseendet på meddelanden och jämför varje inkommande post med reglerna som finns i filen /etc/syslog.conf. Varje regel skrivs som en filrad /etc/syslog.conf, bestående av två fält. Det vänstra fältet ("väljaren") anger en eller flera mallar med vilka meddelanden väljs. Mönster separeras med semikolon (se exempelfil nedan /etc/syslog.conf). Det högra fältet ("åtgärd") bestämmer i vilken ordning valda meddelanden behandlas. Fält separeras med ett eller flera mellanslag eller tabbtecken.

Varje mönster i "väljaren"-fältet har formen "category.level" (det vill säga "facility.priority"). Värdena i fältet "kategori" kan vara:

• ett av de konventionella namnen på kategorierna i tabell 1,
• flera sådana namn (i det här fallet är de åtskilda med kommatecken)
• eller symbolen * (som betyder "alla kategorier").

Värdena i fältet "nivå" kan vara:

• ett av nivånamnen i tabell 2,
• symbol * (spela in alla meddelanden i denna kategori, oavsett nivå),
• eller ord ingen(spela inte in meddelanden i denna kategori).

Att ange ett specifikt värde i fältet "nivå" tolkas som "alla värden denna nivå och högre". Om du behöver spela in meddelanden på endast en nivå, måste du sätta ett likhetstecken ("=") framför det angivna värdet. Om du vill spela in meddelanden på alla nivåer utom den angivna, sätta före namnet på nivån Utropstecken("!"). Att placera dessa två skyltar samtidigt tolkas som "spela inte in meddelanden på den specificerade nivån eller högre."

Det är ingen skillnad mellan stora och små bokstäver i "väljaren"-fältet. Du kan också använda siffror (se /usr/include/syslog.h). Utöver de kategorier som anges i Tabell 1 kan du ange märke(vanliga tidsstämplar) och säkerhet(föråldrad synonym till auth). Utöver prioritetsvärdena som anges i Tabell 2 kan du använda varna(synonym till varning), fel(synonym till fela), panik(synonym till uppstå).

När en matchning hittas mellan kategorin och nivån för ett mottaget meddelande och ett av mönstren i "väljaren"-fältet för någon sträng, syslogd behandlar posten i enlighet med den åtgärd som anges i fältet "åtgärd" på denna rad.

Fältet "åtgärd" kan innehålla

• namnet på en vanlig fil (loggfil) och den fullständiga sökvägen till filen måste anges, med början från roten "/", och om den angivna filen inte finns, syslogd skapar det,
• namnet på det namngivna röret - FIFO; i det här fallet placeras en vertikal stapel ("|") före namnet, och själva kanalen måste skapas innan start syslogd team mkfifo,
• pekar på en terminal eller konsol (som i enhet: /dev/tty1),
• en indikation på fjärrvärden (föregås av symbolen @),
• eller en lista över användare (avgränsade med kommatecken) till vars terminaler ett meddelande kommer att skickas enligt denna regel. Istället för en lista med användare kan du sätta en asterisk (*), vilket innebär att meddelanden skickas till alla användare som arbetar i det här ögonblicket i systemet.

Oftast innehåller fältet "åtgärd" fortfarande namnet på loggfilen. Dessutom kan du sätta ett minustecken ("-") framför filnamnet, vilket kommer att innebära att systemet kan lagra filen i cachebufferten, snarare än att spola den efter att ha skrivit varje meddelande till disken. Detta påskyndar naturligtvis arbetet, speciellt om många stora meddelanden skrivs till protokollet, men det kan leda till att vissa meddelanden går förlorade vid en oväntad systemkrasch, det vill säga exakt när sådana meddelanden är särskilt nödvändiga . Du kan också ange en skrivare - /dev/lp0 - som en enhet i fältet "åtgärd". Detta alternativ för "åtgärd" är tillrådligt att använda i fall där särskilt viktiga system är inblandade. Protokoll som skrivs ut kan inte raderas eller ändras av hackare, så detta är en bra användning för en gammal matrisskrivare.

Förutom raderna med reglerna i filen /etc/syslog.conf kan innehålla tomma rader och kommentarsrader som börjar med #-symbolen. Mer om filstruktur /etc/syslog.conf Du kan läsa mansidan för syslog.conf för en hel del exempel på regelposter i den här filen. Observera att när du anger "category.level"-par i filen syslog.conf kan inte använda numeriska värden, angivna i tabellerna 1 och 2, är endast deras konventionella namn tillåtna.

Om ett meddelande matchar mönstren för två eller flera strängar kommer det att bearbetas enligt var och en av dessa regler (det vill säga, meddelandebehandlingen slutar inte vid första framgången). Detta innebär att ett godtyckligt antal åtgärder kan utföras för ett meddelande. Därför kan du skriva meddelandet till en loggfil och skicka det till användaren/användarna eller till en fjärrvärd.

Dessutom, om "väljaren"-fältet listar (separerade med semikolon) flera "category.level"-par, kan efterföljande par åsidosätta de föregående. Du kan se ett exempel på sådan annullering i fillistan nedan /etc/syslog.conf: Alla meddelanden vars nivå är lika med eller högre än info skrivs till filen /var/log/messages, men meddelanden från kategorierna mail, authpriv och cron hoppas över (skrivs inte).

Lista 1. Fil /etc/syslog.conf från ett system byggt på Red Hat Linux 7.1-distributionen (jag översatte bara kommentarerna i den här filen till ryska och markerade reglerna i fetstil).

# Skriv ut alla meddelanden från kärnan till konsolen. #kern.* /dev/console# Logga alla meddelanden på infonivå eller högre, # förutom e-postsystemmeddelanden som innehåller känslig # information från autentiseringsmeddelanden och cron-demonmeddelanden. *.info;mail.none;authpriv.none;cron.none /var/log/messages# Skriv meddelanden som innehåller känslig # autentiseringsinformation till en separat fil, oavsett nivå. authpriv.* /var/log/secure# Alla meddelanden från e-postsystemet bör också spelas in separat. mail.* /var/log/maillog# Logga cron-demonens åtgärder. cron.* /var/log/cron# Nödmeddelanden ska tas emot omedelbart # av alla användare av systemet *.eerg*# Skriv meddelanden från nyhetstjänster på crit-nivå och högre till en separat fil. uucp,news.crit /var/log/spooler# Meddelanden som utfärdas under uppstartsfasen kopieras till filen boot.log local7.* /var/log/boot.log

Som du kan se skrivs de flesta meddelanden helt enkelt till olika loggfiler som finns i katalogen /var/log eller dess underkataloger, där huvudsystemets loggfil i Red Hat Linux är filen /var/log/meddelanden. Det inkluderar inte bara meddelanden från kategorierna mail, authpriv och cron (för vilka separata filer är tilldelade). Låt oss ta en titt på den här filen och använda dess exempel för att se vad som är registrerat i loggfiler.

Loggfil /var/log/messages

Naturligtvis är det inte möjligt att här tala om innehållet i varje rad i denna fil. För att läsaren ska få en uppfattning om vilken information som finns i protokollet presenterar vi individuella meddelanderader med mycket korta kommentarer.

Varje rad i loggfilen innehåller en enda meddelandepost, bestående av följande meddelandefält, separerade med mellanslag:

• datum i standardtextformat (fält TIDSSTÄMPEL från meddelandet syslog),
• värdnamn (fält VÄRDNAMN från meddelandet syslog)
• meddelandetext (fält MÄRKA Och INNEHÅLL från meddelandet syslog)

För det första är det värt att notera att om din dator inte är igång 24/7, utan är avstängd på natten, så kan du i den här filen hitta register över flera "arbetscykler" som börjar med att datorn startar och slutar med att den stängs av. En sådan cykel börjar med ett meddelande om lanseringen av loggningsdemoner (detta är förståeligt, meddelanden spelades inte in innan de lanserades):

17 sep 08:32:56 kos3 syslogd 1.4-0: omstart. 17 sep 08:32:56 kos3 syslog: start av syslogd lyckades 17 sep 08:32:56 kos3 kärna: klogd 1.4-0, loggkälla = /proc/kmsg startade. 17 sep 08:32:56 kos3 kärna: Inspekterar /boot/System.map-2.4.2-2 17 sep 08:32:56 kos3 syslog: startar klogd lyckades

- Vilken kärnversion används: 17 september 08:32:56 kos3 kärna: Linux version 2.4.2-2 ( [e-postskyddad]) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sön 8 Apr 20:41:30 EDT 2001

- Vilka parametrar körde kärnan med: Sep 17 08:32:56 kos3 kärna: Kernel kommandorad: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2

- Information om processortyp och kapacitet random access minne: 17 sep 08:32:56 kos3 kärna: Detekterad 1594,849 MHz processor. 17 sep 08:32:56 kos3-kärna: Minne: 125652k/130560k tillgängligt (1365k kärnkod, 4200k reserverad, 92k data, 236k init, 0k highmem) 17 sep 08:32:56: kos32:56: kos3-kärna: CPU , L1 D cache: 8K Sep 17 08:32:56 kos3 kärna: CPU: L2 cache: 256K Sep 17 08:32:56 kos3 kärna: CPU: Intel(R) Pentium(R) 4 CPU 1,60GHz stepping 02

- Information om diskminne(inklusive information om diskgeometri, diskpartitionsstruktur och använda avbrott): 17 sep 08:32:56 kos3 kärna: hda: MAXTOR 6L020J1, ATA DISK-enhet 17 sep 08:32:56 kos3 kärna: hdc: SAMSUNG CD-ROM SC -148C, ATAPI CD/DVD-ROM-enhet 17 sep 08:32:56 kos3 kärna: ide0 vid 0x1f0-0x1f7,0x3f6 på irq 14 sep 17 08:32:56 kos3 kärna: ide1 vid 0x170-0x37 7 på 0x170-0x37 17 sep 08:32:56 kos3 kärna: hda: 40132503 sektorer (20548 MB) w/1819KiB Cache, CHS=2498/255/63, UDMA(100) 17 sep 08:32:17 check: Sep: Partition 08:32:56 kos3 kärna: hda: hda1 hda2 hda3 hda4< hda5 hda6 hda7 >17 sep 08:32:56 kos3 kärna: Diskettenhet(ar): fd0 är 1,44M

- Information om kringutrustning: 17 sep 08:32:56 kos3 kärna: usb-uhci.c: USB UHCI vid I/O 0x1820, IRQ 11 sep 17 08:32:56 kos3 kärna: usb-uhci.c: Upptäckte 2 portar 17 sep 08: 32:56 kos3 kärna: ttyS00 vid 0x03f8 (irq = 4) är en 16550A 17 sep 08:32:56 kos3 kärna: ttyS01 vid 0x02f8 (irq = 3) är en 16550A 8 sep 32:06:06 kos3 kärna: 32:0 Intel(R) 8255x-baserad Ethernet-adapter Sep 17 08:32:56 kos3 kärna: Intel(R) PRO/100 Fast Ethernet Adapter - Laddarbar drivrutin, ver 1.5.6 Sep 17 08:32:56 kos3 kärna: PCI: Hittade IRQ 11 för enhet 02:08.0

- Information om lanseringen av enskilda tjänster: 17 september 08:32:56 kos3 kärna: NET4: Linux TCP/IP 1.0 för NET4.0 sep 17 08:32:56 kos3 kärna: IP-protokoll: ICMP, UDP, TCP, IGMP 17 sep 08:32:56 kos3 kärna: NET4: Unix-domänsockets 1.0/SMP för Linux NET4.0. 17 sep 08:32:56 kos3 kärna: parport0: PC-stil vid 0x378 (0x778) 17 sep 08:32:56 kos3 kärna: parport0: irq 7 upptäckt 17 sep 08:32:42 kos3 rc.sysinit: Slår på användaren och gruppkvoter för lokala filsystem: lyckades 17 sep 08:32:43 kos3 rc.sysinit: Aktiverar swap-utrymme: lyckades 17 sep 08:32:44 kos3 init: Går in i runlevel: 3 sep 17 08:32:45 kosing kudzu /etc/fstab lyckades Sep 17 08:32:55 kos3 kudzu: lyckades Sep 17 08:32:55 kos3 nätverk: Ställa in nätverksparametrar: lyckades Sep 17 08:32:55 kos3 nätverk: Höjning av gränssnitt lo: 17 lyckad Se8p 32:56 kos3 nätverk: Aktiverar gränssnitt eth0: lyckades 17 sep 08:32:56 kos3 tangentbord: Laddar tangentbordslayout: 17 sep 08:32:56 kos3 tangentbord: Laddar systemtypsnitt: 17 sep 08:32:56 kosalizing3 slumpmässigt: I slumptalsgenerator: lyckades 17 sep 08:32:41 kos3 rc.sysinit: Konfigurera kärnparametrar: lyckades 17 sep 08:32:41 kos3 rc.sysinit: Inställning av standardteckensnitt (cyr-sun16): lyckades 08:32 sep. 41 kos3 rc.sysinit: Aktiverar swap-partitioner: lyckades 17 sep 08:32:41 kos3 rc.sysinit: Inställning av värdnamn kos3: lyckades 17 sep 08:33:03 kos3 xinetd: startar xinetd lyckades 05 sep:3317 kos3:33 pm kos3 rc.sysinit: : start gpm lyckades 17 sep 08:33:05 kos3 crond: start crond lyckades 17 sep 08:33:06 kos3 xfs: lyssnar på port 7100 sep 17 08:33:06 kos3 xfs: start xfs lyckades

- Information om att montera filsystem: Sep 17 08:32:56 kos3 kärna: VFS: Mounted root (ext2 filsystem) skrivskyddad. 17 sep 08:32:56 kos3 kärna: Lägger till Swap: 265032k swap-space (prioritet -1) 17 sep 08:32:56 kos3 kärna: MSDOS FS: Använder kodtabell 866 17 sep 08:32:56 kosOS FS kärna: MSD : IO charset koi8-r 17 sep 08:32:41 kos3 rc.sysinit: Montering av USB-filsystem: lyckades 17 sep 08:32:41 kos3 rc.sysinit: Kontrollerar rotfilsystemet lyckades 17 sep 08:32:413 kossinit. : Återmontering av rotfilsystem i läs-skrivläge: lyckades 17 sep 08:32:41 kos3 rc.sysinit: Montering av proc filsystem: lyckades 17 sep 08:32:41 kos3 fsck: /: clean, 30407/16005270/39005270/39005270 filer, blockerar 17 sep 08:32:42 kos3 fsck: /HEMMA: ren, 6573/432864 filer, 689090/863722 blockerar sep 17 08:32:42 kos3 fsck: /usr: ren, 55105/3299508 filer, 28528 sep 17 08:32:42 kos3 rc.sysinit: Kontroll av filsystem lyckades

- Några felmeddelanden: Sep 17 08:32:42 kos3-montering: SMB-anslutning misslyckades 17. sep 08:32:42 kos3-montering: Paketsändning misslyckades till 10.104.129.245(137) ERRNO=Nätverket går inte att nå 17 sep 08:32: kos3 mount: mount: /dev/sda4: okänd enhet 17 sep 08:32:59 kos3 mount: fel vid anslutning till 192.168.36.20:139 (Ingen väg till värd) 17 sep 08:32:59 kos3 mount: mount: / dev /sda4: okänd enhet

- Meddelanden om användarloggning: 17 sep 08:33:14 kos3 login(pam_unix): session öppnad för användaren kos av LOGIN(uid=0) 17 sep 08:33:14 kos3 -- kos: LOGGA IN PÅ tty1 BY kos 17 sep 08:41:39 kos3 su(pam_unix): autentiseringsfel; logname=kos uid=500 euid=0 tty= ruser= rhost= användare=root

- Och slutligen, meddelanden som spelas in när datorn är avstängd, till exempel: 17 september 10:30:07 kos3 rc: Stoppar tangentbord: lyckades 17 sep 10:30:07 kos3 Font Server: avslutas 17 september 10:30:08 kos3 xfs: stopp xfs lyckades 17 sep 10:30:08 kos3 gpm: stopp gpm lyckades 17 sep 10:30:08 kos3 xinetd: Avslutar... 17 sep 10:30:10 kos3 rpc.statd: oupptäckt signal 15, registrera och avsluta. 17 sep 10:30:11 kos3 kärna: Kärnloggning (proc) stoppades. 17 sep 10:30:11 kos3 kärna: Kernel log daemon avslutas. 17 sep 10:30:12 kos3 syslog: att stoppa klogd lyckades 17 sep 10:30:12 kos3 avslutas på signal 15

Posterna i andra protokollfiler som nämns i filen har ungefär samma struktur /etc/syslog.conf.

logger och tailf kommandon

Från den tidigare beskrivningen kan vi dra slutsatsen att utfärdandet av alla meddelanden för systemloggar bör specificeras av programmeraren vid skapandet av programmet. Detta är inte helt sant. Användaren har också möjlighet att skicka ett meddelande till demonen syslogd. Det finns ett kommando för detta i Linux logger, som tillåter att skicka ett meddelande från kommandoraden (sh, bash, etc.). Det är en del av util-linux-paketet. Naturligtvis är detta kommando främst avsett att tillhandahålla loggningsmöjligheter när användaren skapar olika typer av skalskript. Men det kan också startas direkt från kommandoraden, till exempel för att bekanta dig med loggningssystemets funktioner. Kommandostartsformat: logger [-isd] [-f fil] [-p PRI] [-t TAG] [-u socket] Kommandoradsalternativen har följande betydelse:

• -jag- inkludera processnumret i meddelandet
• -s- duplicera meddelande till stderr
• -d- använd datagramläge när du skickar meddelanden (istället för vanlig streaming)
• -f filnamn- spara meddelande till specificerad fil(standard är /var/log/meddelanden)
• -p anläggning.nivå- ställ in kategori och prioritet för meddelandet (standard: user.notice)
• -t MÄRKA - ställ in TAG-fältet
• -u uttag- skicka ett meddelande till den angivna socket istället för att anropa syslogd
• MSG- Meddelandetext

Skicka flera meddelanden med programmet logger och beundra resultatet i filen /var/log/meddelanden(såvida du inte har ändrat standardvärdet förstås).

Förresten, det finns ett mycket intressant sätt att se meddelanden som skrivits till en fil /var/log/meddelanden team logger. Denna metod är baserad på användningen specialprogram svans. Öppna ett terminalfönster, få superanvändarrättigheter (med kommandot su) och kör kommandot i det här fönstret
tailf /var/log/meddelanden
Efter det byter du till en annan terminal och kör kommandot där logger free_text. Ditt meddelande visas omedelbart i fönstret där programmet körs svans. Det vill säga, med hjälp av detta program kan systemadministratören övervaka inspelningen av nya meddelanden i protokollet i realtid. Sann, systemadministratör det finns knappt tid att övervaka systemets beteende på detta sätt (förutom kanske nödsituationer). Därför har speciella program utvecklats för att analysera protokoll. Men mer om dem nedan, men låt oss nu gå vidare till frågan om hur man organiserar övervakning av en fjärrdator (minns du hur du fångade angriparen Shimomura?).

Nätverksloggning

Som sagt kan loggningssystemmeddelanden skickas av demonen syslogd till fjärrvärden. Men någon måste acceptera honom där. Det visar sig att samma demon gör detta syslogd, körs på den här fjärrvärden. Mer exakt, syslogd på vilken dator som helst kan lyssna inte bara på /dev/log-uttaget (därmed acceptera meddelanden från lokala källor), utan också på port 514/UDP, som säkerställer att meddelanden tas emot från andra datorer i det lokala nätverket (och deras efterföljande inspelning i lokal fil). Detta gör det möjligt att skapa en "loggningsserver", vilket kan vara mycket bekvämt för en systemadministratör (alla händelser i nätverket övervakas på ett ställe), och ökar också nätverkssäkerheten, eftersom meddelanden om en hackers penetration av en av nätverksvärdar kan inte omedelbart rapporteras borttagna från protokollet av denna hacker.

För att organisera sådan "nätverksloggning" måste dock ytterligare ansträngningar göras.

För det första, eftersom port 514/UDP används för att skicka och ta emot meddelanden över nätverket, måste den vara tillgänglig på båda datorerna (klient och server). För att göra detta i filen /etc/tjänster linjen måste finnas på båda datorerna
syslog 514/udp
Om en sådan linje in /etc/tjänster frånvarande, syslogd kan varken ta emot meddelanden eller skicka dem till nätverket eftersom det inte kan öppna UDP-porten. Om en sådan situation uppstår, syslogd slutar omedelbart att skriva alla meddelanden, även till den lokala loggen. Samtidigt, som laget visar ps, det finns kvar i minnet och till och med lagrar meddelanden i vissa buffertar, eftersom om raden " syslog 514/udp"återställ till fil /etc/tjänster på klienten, sedan av minst Vissa av de "saknade" meddelandena visas fortfarande i loggen (efter omstart syslogd).

För det andra, när du startar demonen syslogd alternativet måste anges på servern -r, som tillhandahåller fjärrloggningsfunktioner (standarddemon syslogd väntar endast på meddelanden från den lokala uttaget). Hur och var man ställer in det här alternativet kommer att diskuteras nedan, i avsnittet om att starta demonen syslogd.

Jo, och för det tredje måste inställningarna i filerna korrigeras i enlighet med detta /etc/syslog.conf på båda datorerna. Om du till exempel vill omdirigera alla meddelanden till loggservern måste du skriva in en fil på klientdatorn /etc/syslog.conf en rad så här:
*.* @värdnamn
Om under början av demonen syslogd servern kommer att vara otillgänglig (till exempel är den för närvarande frånkopplad från nätverket) eller så kommer den inte att vara möjligt att hitta den med namn (DNS-tjänsten fungerade inte korrekt) syslogd gör ytterligare 10 försök att hitta servern och bara om servern inte kan hittas efter det slutar den att försöka och skickar ett motsvarande meddelande.

Om du har flera domäner på ditt nätverk som betjänas av en enda loggningsserver, bli inte förvånad över att loggen på servern kommer att innehålla de fullständiga namnen på klienterna (inklusive domänen). Sant, vid start syslogd alternativ kan användas -s domänlista eller -l host_list, som ger ersättning av fullständiga värdnamn i protokollet med deras korta namn (utan att ange domänen).

Glöm inte efter att ha justerat start- och filalternativen /etc/syslog.conf starta om demonen eftersom, till skillnad från cron, sysklogd läser inte om konfigurationsfiler automatiskt.

syslogd-demonens startalternativ

Sedan vi berörde frågan om att ställa in parametrar för demonstart i föregående underavsnitt syslogd, låt oss titta på den här frågan mer i detalj. Som redan nämnts, startas båda loggningsdemonerna vid systeminitieringsstadiet, och mer specifikt, genom ett skript /etc/rc.d/init.d/syslog(för vilka, liksom för startskript för andra tjänster, symboliska länkar skapas i /etc/rc.d/rc?.d/-katalogerna). Men för att ställa in startparametrarna finns det inget behov av att justera detta skript, eftersom från och med version 7.2 i Red Hat-distributionen läses startalternativen för båda demonerna från en separat konfigurationsfil /etc/sysconfig/syslog. Här är en kort lista över möjliga parametrar för demonen syslogd.

Startparametrar syslogd:

• -ett uttag- Specificerar en extra socket som demonen kommer att lyssna på syslogd. Du kan ange upp till 19 sockets (fler är möjligt, men för detta måste du kompilera om paketet). Det här alternativet används i fall där någon annan demon (till exempel ftp eller http) körs i en begränsad miljö (chrooting).
• -d- Felsökningsläge. I det här fallet går demonen inte in bakgrundsläge och matar ut alla meddelanden till den aktuella terminalen.
• -f config-filnamn Anger namnet på en alternativ konfigurationsfil som kommer att användas istället för standardfilen /etc/syslog.conf.
• -h Standard i sysklogd Det är förbjudet att överföra meddelanden som tas emot via nätverket till en annan dator. Detta görs för att förhindra oändliga överföringar av meddelanden runt ringen. Alternativet -h låter dig ändra det vanliga beteendet och se till att meddelanden som tas emot från fjärrvärdar sänds vidare över nätverket (och ta hand om eventuell looping själv).
• -l värdlista- Anger en lista över värdar vars namn inte ska skrivas med ett fullständigt domännamn (FQDN - Fullständigt kvalificerat domännamn); namnen i listan avgränsas med ett kolon.
• -m minuter Lanserades utan detta alternativ sysklogd regelbundet (var 20:e minut) registrerar kategorimeddelanden i protokollet märke, det vill säga helt enkelt tidsstämplar. Använder alternativet -m du kan antingen ändra intervallet mellan markeringar eller helt avbryta utfärdandet av sådana meddelanden, för vilka du måste ställa in intervallet till noll: -m 0.
• -n Tona inte in i bakgrunden; detta alternativ krävs i fall där syslogd startas och kontrolleras av en process i det.
• -p uttag Anger ett alternativt UNIX-uttag (istället för standarduttaget som lyssnar /dev/log). Observera: option -a specificerar ytterligare uttag, och -s– alternativ!
• -r Tillåt att ta emot meddelanden från fjärrvärdar. Vi pratade om detta i föregående avsnitt, så jag utelämnar detaljerna.
• -s domänlista Anger en lista över domäner vars namn inte behöver loggas tillsammans med värdnamnet (det vill säga för dessa domäner kommer endast värdnamnet att loggas istället för det fullständiga domännamnet (FQDN). Namnen i listan är separerade med ett kolon Namnet på domänen där syslogd-servern finns behöver inte inkluderas i denna lista (dess namn tas bort som standard).
• -v Visa version och avsluta arbetet.
• -x Förbjud att bestämma ett värdnamn efter dess adress, förhindrar dödläge när du arbetar på samma värd med en DNS-server.

Efter att ha startat demonen syslogd en statusfil skapas /var/lock/subsys/syslog noll längd och en fil med ett processidentifikationsnummer /var/run/syslogd.pid.

Använder kommandot
kill -SIGNAL `cat /var/run/syslogd.pid`
du kan skicka till demonen syslogd en av följande signaler:

• SIGHUP - starta om demonen (återinitiering); alla öppna filer stängs, demonen startar igen och läser om sin konfigurationsfil.
• SIGTERM - avstängning.
• SIGINT, SIGQUIT - om felsökningsläge är aktiverat (alternativ -d), ignoreras signaler, annars stängs av.
• SIGUSR1 - aktivera/avaktivera felsökningsläge (fungerar endast om demonen startades med -d-växeln).

Demon klogd har inte färre startalternativ än syslogd, men vi kommer inte att presentera dem här, utan hänvisar läsaren till motsvarande man-sida (användaren ska inte bry sig om att konfigurera klogd, det är bättre att lämna det i det tillstånd där det producerades av distributionsutvecklarna).

dmesg-filen och dmesg-kommandot

Som redan nämnts, loggfilerna som nämns i filen /etc/syslog.conf vanligtvis i en katalog /var/log och dess underkataloger. Men om vi tittar in i den här katalogen kommer vi att hitta flera filer där /etc/syslog.conf nämndes inte. Låt oss titta på deras syfte. Låt oss börja med filen dmesg.

Först måste vi nämna att Linux har ett kommando med samma namn. Om du jämför resultatet av detta kommando (när det körs utan parametrar) med innehållet i filen /var/log/dmesg, kommer du att upptäcka att de är väldigt lika, även om de inte är identiska (direkta utmatningen av kommandot till en fil dmesg2 och jämför filerna dmesg Och dmesg2). Mer exakt, filen /var/log/dmesg en till en sammanfaller med början av utdata som vi får från kommandot dmesg. Som följer av har kärnan en ringbuffert i vilken meddelanden från kärnans loggningsdemon skrivs in. De meddelanden som skrivs till denna buffert under nedladdningsprocessen utgör innehållet i filen /var/log/dmesg. Tydligen genereras den här filen efter att systemet startar.

Om du tittar på fillistan som tillhandahålls igen /etc/syslog.conf, kommer du att se att alla meddelanden i kategorin kern skickas också till konsolen. Men där springer de snabbt över skärmen och man hinner knappt läsa och förstå dem. Men de sparas i en fil /var/log/dmesg och är därmed tillgängliga för lugn reflektion (om nedladdningsprocessen slutförs framgångsrikt). Efter att uppstartsprocessen är klar fortsätter att skriva meddelanden från kärnan till ringbufferten. När kommandot utförs dmesg, visas buffertens nuvarande tillstånd. Därför innehåller utmatningen av detta kommando fler meddelanden än filen /var/log/dmesg: i utgången av det här kommandot ser du också meddelanden som kärnan utfärdar efter att uppstartsprocessen är klar.

Alla meddelanden från /var/log/dmesg hittar du i filen /var/log/meddelanden, bara där växlar de med meddelanden från andra program. Det finns bara en betydande skillnad: i filen dmesg tid och källa för meddelandet (värdnamn och meddelandekategori) anges inte. Värden här är alltid "lokal", och början av tidsräkningen bestäms av den senaste omstarten av datorn.

lastlog, wtmp och utmp-filer

Förutom filen dmesg i katalogen /var/log/ det finns ytterligare två filer som inte nämns i /etc/syslog.conf, men direkt relaterade till loggning - det här är filer sista loggen Och wtmp. Men titta på dem på samma sätt som vi tittade på filen /var/log/meddelanden inte vettigt - du kommer inte att förstå någonting. Faktum är att informationen i dessa filer är inspelad i ett speciellt format, och det måste ses med speciella programvara. Men först måste vi säga några ord om syftet med dessa filer.

Fil sista loggen lagrar information om användarens senaste inloggning. Jag vet inte om du märkte att när du anger ditt användarnamn och lösenord visas något i stil med följande meddelande på skärmen:

Localhost login: kos Lösenord: Senaste inloggning: Ons 9 okt 19:25:53 på tty1 Dessa tre rader genereras av verktyget logga in, som, efter att ha fastställt att användaren har inloggningsrättigheter, kommer åt filen /var/log/lastlog, hämtar information om användarens tidigare lyckade inloggning därifrån, visar den på skärmen och uppdaterar sedan posten i filen sista loggen. Du kan undertrycka detta meddelande genom att skapa en tom .hushlogin-fil i din hemkatalog. Det rekommenderas dock inte att göra detta, tvärtom bör du vara särskilt uppmärksam på innehållet i detta meddelande för att inte missa fall då någon annan loggat in under ditt namn.

Till skillnad från filen /var/log/lastlog, som innehåller tidsrekord sista logga in för varje användare, i filen /var/log/wtmp kommer ihåg Allt inloggningar och utloggningar av användare sedan skapandet av denna fil. Samma som i filen sista loggen, poster i /var/log/wtmpär gjorda i ett speciellt format, så de kan endast visas med hjälp av speciella kommandon. Men innan vi pratar om dessa kommandon, låt oss säga att det finns en annan fil som innehåller användarloggningsposter - det här är filen /var/run/utmp. Den här filen innehåller information om vilka användare som för närvarande arbetar i systemet.

Nu kan du prata om hur du ser information om användare som arbetar eller tidigare arbetat i systemet. Huvudkommandot för detta är kommandot sista. Den visar alla poster från en fil /var/log/wtmp, varvid användarnamnet anges, en indikation på terminalen från vilken användaren arbetade, tiden då användaren loggade in i systemet och tiden han loggade ut ur systemet, samt varaktigheten av användarens session i systemet. Om användarens arbete bara avbröts för att själva systemet var avstängt, finns ordet "ner" istället för användarens utgångstid (från dessa rader är det lätt att avgöra när systemet stannade). Omstartstiden visas på separata rader som börjar med ordet "omstart".

Team lastb som ett team sista, men visar information om misslyckade inloggningsförsök. Det bör dock noteras att detta kommando bara fungerar om filen finns /var/log/btmp. Inget av programmen som diskuteras här skapar dock loggfiler, så om någon av dem raderas avslutas inspelningen.

Team sista loggen formaterar och visar innehållet i filen /var/log/lastlog. Användarnamnet, terminalnamnet från vilket användaren loggade in och senaste inloggningstiden kommer att visas. Som standard (när kommandot anges utan parametrar) filelementen /var/log/lastlog kommer att visas i användar-ID-nummerordning. Om du anger alternativet -u login-name, kommer endast den senaste inloggningstiden för den angivna användaren att visas. Genom att ange parametern -t days får du endast poster för de sista dagarna i dagarna. Om användaren inte har loggat in i systemet alls, kommer istället för terminalens namn och senaste inloggningstid, strängen "**Aldrig inloggad**" att indikeras.

När du kör kommandot sista loggen På en långsam dator kan det i vissa fall verka som att kommandot har fastnat. Detta beror på att även om endast två användare är registrerade i systemet (root och användare), i filen /var/log/lastlog Det finns fortfarande utrymme för så många användare som möjligt att arbeta med systemet. Därför i filen /var/log/lastlog Det kan finnas stora klyftor mellan ID-numren för användare som arbetar i systemet. För när man tittar på sådana intervall visar programmet inte information på skärmen, och intrycket av att "frysa" uppstår.

För att visa information om vem som för närvarande arbetar på systemet, använd kommandona w, WHO Och användare. Team användare används när du bara vill veta vilken användare som för närvarande arbetar i systemet, men inte är intresserad av vilken terminal de anslutit från och vad de gör. Om du vill veta vem som loggat in från vilken terminal, använd kommandot WHO. Detta kommando skriver ut information från en fil /var/run/utmp. Du kan tvinga den att mata ut data från en fil /var/log/wtmp(eller någon annan fil som det är vettigt för) om du anger namnet på denna fil i kommandorad. Men i utgången ser du fortfarande bara användarnamnet, en indikation på terminalen från vilken användaren loggat in, inloggningstiden och, vid inloggning med fjärrdator, namnet på den här datorn.

Kommandot matar ut betydligt mer information w. I dess utdata kommer du att se aktuell tid, hur länge systemet har körts, hur många användare som för närvarande arbetar i systemet och den genomsnittliga systembelastningen för den sista minuten, 5 och 15 minuter. Sedan skriver den ut för varje användare:

Användarnamn,

terminalnamn,

fjärrvärdens namn

tid som har gått sedan inloggning,

den tid under vilken denna terminal inte används (ledig tid),

total tid för alla processer som startade från av denna terminal(JCPU kolumn),

den tid under vilken den senast startade processen av användaren körs (PCPU-graf),

information om vilket program som för närvarande exekveras av användaren (i form av en kommandorad för att starta ett kommando med alla parametrar).

Som redan nämnts, laget w visar information lagrad i en fil utmp. Förresten, manualen man stater som vanliga användare måste nekas skrivåtkomst till filen utmp, eftersom många systemprogram (av några oförklarliga skäl) är beroende av dess integritet. Du riskerar att förväxla systemstatistikfiler och göra ändringar i systemfiler om du tillåter vilken användare som helst att skriva till utmp-filen.

Loggfiler för andra program

Utöver de filer som vi redan har pratat om finns det andra protokollfiler som skapas av separata program. De mest typiska exemplen är protokollen för demoner samba, ftpd eller httpd, som utförs i separata filer. Vissa av dessa program skapar sina protokoll i underkataloger till katalogen /var/log/, andra lagrar protokoll på andra ställen. Och strukturen för dessa filer kan skilja sig betydligt från strukturen för filer som skapas av systemet syslog. Som ett exempel kommer jag att ge några rader från serverprotokollet Apache körs på min dator: 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; ru-RU; 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 är strukturen för denna protokollfil väsentligt annorlunda än vad vi såg i systemprotokollen.

Samba-servern, förutom huvudserverns operationsprotokoll, skapas i en underkatalog /var/log/samba en hel serie loggfiler för olika fall, särskilt separata filer för var och en av de användare som får använda resurserna som tillhandahålls av denna server. Följande två poster är hämtade från en sådan fil:

Smbd/service.c:make_connection(550) linux (192.168.36.10) anslut till tjänsten offentlig som användare kos (uid=500, gid=500) (pid 1366) smbd/service.c:close_cnum(550) linux (192.168. 36.10) stängd anslutning till offentliga tjänster. Exemplen ovan visar att om du kan läsa lite engelska och har en viss förståelse för strukturen av poster kan du extrahera mycket från loggfiler användbar information. Bara det måste extraheras från hela avlagringar av "avfallssten" - enorma sekventiella protokollfiler, vilket är en icke-trivial uppgift. Därför har speciella mjukvaruverktyg utvecklats för protokollanalys.

Verktyg för bearbetning av protokoll

En hel del olika program och skript har utvecklats för att analysera protokoll. Jag ska begränsa mig kort beskrivning två sådana medel: logwatch Och swatch.

logwatchär ett Perl-skript som ingår i den vanliga Red Hat Linux-distributionen. Precis under förberedelserna av denna artikel publicerades version 4.1 av detta program på utvecklarens webbplats (och han är Kirk Bauer).

Huvudtanken bakom detta program är att loggfilen passeras genom ett filter, som från loggen väljer ut alla rader (det vill säga meddelanden) som uppfyller ett givet kriterium. Resultat skickas av e-post till den angivna användaren (som standard - root). Filter kan skrivas på vilket programmeringsspråk som helst, men paketets författare föredrar Perl. Filter måste skrivas för att läsa data från stdin och mata ut resultatet till stdout.

Grundläggande användning logwatch består av att inkludera en länk till huvudskriptet ( /etc/log.d/scripts/logwatch.pl) till katalogen /etc/cron.daily, vilket orsakar daglig exekvering logwatch med standardinställningar. Länken får ett namn som börjar med "00" (t.ex. 00-logwatch) så att skriptet körs före logrotate.

Men du kan också köra skriptet från kommandoraden. Naturligtvis, om du inte har ändrat informationsutdataparametern, bör resultatet av dess operation letas efter i superanvändarens brevlåda. Om du vill se dessa resultat på skärmen måste du ställa in parametern på kommandoraden --skriva ut- utfärda en rapport till stdout.

Allmänt skriptstartsformat:

/etc/log.d/scripts/logwatch.pl [--detalj nivå ] [--loggfil tidningsgrupp ] [--tjänst Service namn ] [--print] [--mailto adress ] [--spara filnamn ] [--arkiv] [--intervall datum-intervall ]

Standardparametrarna lagras i filen /etc/log.d/logwatch.conf, kommentarerna i vilka hjälper dig förstå innebörden av kommandoradsparametrarna:

• LogDir - katalog i förhållande till vilken filnamn som beaktas;
• MailTo - vem ska rapporten skickas till;
• Skriv ut - istället för att skicka rapporten per post, mata ut den till stdout;
• Spara - istället för att skicka rapporten per post, spara den i den angivna filen;
• Arkiv - process inte bara nuvarande versioner loggar, men även gamla kopior skapade av logrotate;
• Intervall - bearbeta det angivna tidsintervallet: Alla, Idag, Igår (gårdagens kalenderdag);
• Detalj - rapportdetaljnivå: från 0 till 10 eller Låg, Medel, Hög;
• Service - Alla eller filternamn från /etc/log.d/scripts/services/ (flera filter kan anges);
• LogFile - Alla eller namnet på en logggrupp (flera grupper kan anges).

Mer information om manuset logwatch hittar du i .

Artikeln beskriver ett annat skript för bearbetning av loggfiler, som ingår i Mandrake Linux-distributionen. Detta skript kallas swatch("Simple WATCHer") och är också skriven i Perl.

Arbetsledning swatch utförs med en enda konfigurationsfil, som standard $HOME/.swatchrc. Den här filen innehåller exempeltext (i formuläret vanliga uttryck), som swatch kommer att söka i loggfiler. Efter varje sådant exempel indikeras en åtgärd som swatch måste vidta åtgärder om den stöter på text som matchar mönstret.

Du vill till exempel bli varnad när en buffertspillsattack görs på din webbserver när ett mycket långt filnamn efterfrågas. Och det vet du i sådana fall i loggfilen /var/apache/error.log Ett meddelande visas med orden "Filnamn för långt". I det här fallet till din fil .swatchrc Följande instruktion måste infogas:

Se upp för /Filnamn för långt/ mail [e-postskyddad], subject=BufferOverflow_attempt

Jag kommer inte att ge en mer detaljerad beskrivning av programmet här. swatch. En entusiastisk artikel tillägnas det, och själva programmet finns på hemsidan. Jag vill bara påpeka, och swatch, Och logwatch implementera en ganska primitiv algoritm för att bearbeta protokollfiler, vilket går ut på att söka i protokollet efter en given teckensträng (signatur). Under tiden, för det första, indikerar närvaron av en sådan linje ofta inte ett intrång av en angripare, och för det andra kan en kompetent angripare ta hand om att radera spår av hans aktiviteter. En annan uppenbar nackdel med de granskade produkterna är att de fungerar i "uppskjutet läge", eftersom de bara körs enligt ett schema. Och kampen mot inkräktare måste utföras "i realtid", och omedelbart reagera på försök att penetrera systemet. Därför erbjuder kommersiella produkter övervakningssystem som fungerar kontinuerligt och implementerar "intelligenta" protokollanalysalgoritmer. Dessa algoritmer är baserade på statistisk analys av meddelandeflödet och identifiering av statistiskt signifikanta avvikelser hos systemet från dess normala beteende.

Som avslutning på det här avsnittet noterar jag att webbplatsen SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) ger en lista med länkar till webbplatserna för olika programvaruverktyg för bearbetning av protokoll med en kortfattad beskrivning av dessa verktyg. Du kan experimentera med olika program och välja det som passar dig.

Roterande loggfiler

Du förstår naturligtvis att om systemet används intensivt så växer loggfilerna snabbt. Vilket resulterar i ett slöseri med diskutrymme. Och problemet med att "tämja" protokollen uppstår. I Red Hat Linux löses detta problem med skript logrotera, som finns i katalogen /etc/cron.daily, och därför lanseras av demonen cron dagligen. Detta skript låter dig bearbeta inte bara systemloggar syslog, men även andra program.

Manus logroteraövervakar tillväxten av loggfiler och ger så kallad rotation av dessa filer om de överskrider den angivna storleken (eller efter ett angivet tidsintervall). Rotation är inget annat än sekventiell kopiering av tidigare versioner av arkivfiler ungefär som följer:

meddelanden.2 -> meddelanden.3

meddelanden.1 -> meddelanden.2

meddelanden.0 -> meddelanden.1

meddelanden -> meddelanden.0
och skapa en ny meddelandefil för att spela in efterföljande meddelanden.

Lista över filer som ska bearbetas av skriptet logrotera och parametrarna för denna bearbetning bestäms av konfigurationsfiler, av vilka det kan finnas flera. Namnen på konfigurationsfilerna anges på kommandoraden för start av script (för startparametrar, se nedan). På Red Hat Linux, som standard, är konfigurationsfilerna för logrotera fil används /etc/logrotate.conf, som kan se ut ungefär så här:

Veckorotering 4 skapa komprimering inkluderar /etc/logrotate.d /var/log/wtmp /var/log/lastlog (skapa månadsvis 0664 root utmp rotera 1 )

Den här filen är som vilken konfigurationsfil som helst för ett skript logrotera består av flera sektioner. Det första avsnittet definierar globala parametrar (en per rad) som anger standardparametrar för alla loggar. Följande avsnitt definierar lokala parametrar för en serie loggfiler. Namnen på dessa filer listas på den första raden i avsnittet, och sedan anges lokala parametrar med klammerparenteser, som endast är giltiga vid bearbetning av de angivna filerna (även en parameter per rad). Loggfilnamn kan citeras enligt skalregler om de innehåller mellanslag eller andra specialtecken. Du kan ange flera filnamn eller filnamnsmönster separerade med mellanslag (mönster följer även skalregler). Att bearbeta varje avsnitt behandlas som en enda åtgärd. Rader som börjar med "#"-symbolen är kommentarer. Lokala parametrar har företräde framför globala.

Exemplet på konfigurationsfilen beskriver först globala parametrar och sedan, i ett separat avsnitt, parametrar för bearbetning av filerna /var/log/wtmp och /var/log/lastlog. Bland de globala parametrarna ges dessutom en länk till katalogen /etc/logrotate.d, där varje paket skriver lokala parametrar för sina loggar.

I avsnittet globala parametrar ställer du först in en av följande parametrar som bestämmer filrotationskriteriet:

dagligen- ändringar i versioner i serien sker dagligen,

varje vecka- versioner ändras varje vecka,

en gång i månaden- versioner ändras varje månad,

storlek byte - en versionsändring inträffar om loggstorleken överstiger det angivna antalet byte; du kan använda suffixen "k" - kilobyte - och "M" - megabyte)

och parameter omfatta, följt av namnet på en annan (ytterligare) konfigurationsfil eller till och med namnet på en katalog. I det senare fallet anses alla filer i den angivna katalogen, förutom underkataloger, specialfiler och filer med suffix från listan över undantag, som konfigurationsfiler för skriptet logrotera(direktiv omfatta kan inte användas i en sektion som anger bearbetningsparametrar för en grupp filer).

Parameter rotera siffra kan hittas bland både globala och lokala parametrar och bestämmer hur många gamla versioner som ska lagras; om siffran är 0 skapas inte arkiverade versioner av protokollet.

Om parametern är specificerad komprimera, då komprimeras äldre versioner med gzip, och om det anges nocompress– de krymper inte. Parameter compresscmd låter dig ange vilket komprimeringsprogram som ska användas (gzip som standard), och uncompresscmd anger dekompressionsprogrammet (standard - ungzip). kompressioner ställer in komprimeringsprogrammets parametrar; standard är "-9", dvs. maximal komprimering för gzip. Använder parametern compressext du kan ändra suffixet för komprimerade filer och förlängning ändelse anger suffixet som läggs till filnamn under rotation (före komprimeringssuffixet).

Bland nyckelord, som finns i konfigurationsfiler, bör vi särskilt notera orden efterrotera Och förrotera, som fungerar som öppningsparenteser för inkludering i skalskriptkonfigurationsfiler. Alla rader i konfigurationsfilen från raden efterrotera att rada slutskrift exekveras som skalkommandon efter processen att ändra loggfilens version. Följaktligen alla linjer från linjen förrotera att rada slutskrift körs innan loggfilerna roteras. Med hjälp av dessa skript kan du organisera olika procedurer för att bearbeta loggfiler under rotation.

Med hjälp av andra parametrar i konfigurationsfilen kan du omdefiniera åtkomsträttigheter till loggfiler (om denna parameter inte anges används attributen för den gamla loggfilen); ange till vem du ska skicka meddelanden om fel i loggningssystemets funktion; skicka en arkiverad kopia av loggen till den angivna användaren; ställ in katalogen som loggar ska flyttas till under versionsändringar (katalogen måste vara på samma fysiska enhet som /var/log) eller ställ in en lista med undantagssuffix för katalogen omfatta. Detaljerad beskrivning Du hittar dessa funktioner och parametrar (liksom de som inte nämndes) med kommandot man logrotera.

Som redan nämnts, ytterligare konfigurationsfiler logrotera kan anges på kommandoraden för scriptstart. Du kan ange ett godtyckligt antal konfigurationsfil- eller katalognamn. Namnen på filer och kataloger i den här listan separeras helt enkelt med mellanslag. Ordningen som namnen listas i spelar roll eftersom alternativen som anges nedan konfigurationsfil, överlappar värdena för parametrarna som anges i föregående fil. Ordningen på filerna i konfigurationskatalogen är inte definierad.

Dessutom kan du ange följande parametrar på startkommandoraden:

• -d- felsökningsläge, inga verkliga ändringar görs,
• -f- göra ändringar, även om logrotera ser inte behovet - används när det finns ändringar i listan över bearbetade loggar,
• man logwatch
• Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
• RFC 3164. C. Lonvick, The BSD Syslog Protocol, augusti 2001.
• RFC 3195. D. New, M. Rose, pålitlig leverans för syslog, november 2001.
• Per. S. Lapshansky, "Demonen tittar på systemet"
• Denis Kolisnichenko,

Åtgärderna för syslogd-demonen kontrolleras av konfigurationsfilen /etc/syslog.conf. Detta är en enkel textfil där tomma rader och rader med ett # i första position ignoreras. Filformatet är som följer:

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

Till exempel,

mail.err /var/log/mail.errors

Den här raden kommer att säkerställa att alla e-postleveransfel registreras i filen /var/log/mail.errors.

Viktigt: Använd endast knappen som avgränsare mellan väljaren och åtgärden . Att använda mellanslag skulle vara ett fel som inte är lätt att upptäcka.

Som du redan har märkt är väljaren skriven i en sammansatt form. I allmän syn det ser ut som en medelnivå

Dessutom på fältet<селектор>kan innehålla en eller flera väljare, separerade med semikolon. En väljare kan innehålla en grupp faciliteter separerade med kommatecken. Väljaren kan innehålla tecknen * och ingen, vilket betyder "alla" respektive "ingenting".

Exempel på väljare:

medel, handlingsnivå

betyder 1, betyder 2. handlingsnivå

betyder 1. nivå 1, betyder 2. nivå 2-åtgärd

*.åtgärdsnivå

*.nivå;betyder.ingen åtgärd

Följande tabeller listar de viktigaste syslogfunktionernas namn och svårighetsgradsnivåer.

Verktygsprogram som använder det

kärn Systemkärna

användare Användarprocesser

e-postsystem

daemon Systemdemoner

auth säkerhets- och auktoritetssystem

lpr Utskriftssystem

nyheter Telekonferenssystem

cron Cron-demonen

lokal0-7 Åtta nivåer av lokalt budskap

syslog Interna syslog-systemmeddelanden

ftp ftpd-demon

*Allt ovanstående betyder

Nivå Nivåvärde

nödsituationer

varna Brådskande situationer

crit Kritiska tillstånd

fel Felförhållanden

varning Varningar

notera Ovanliga förhållanden

Info Informationsmeddelanden

debug Felsökningsinformation

Nivåerna listas i fallande ordning. Det betyder att nivåerna anger den minsta betydelse som ett meddelande måste ha för att loggas i syslog-systemet.

Fält<действие>indikerar vad som ska göras med det mottagna meddelandet.

Åtgärdsbeskrivning

filnamn Skriv meddelandet till en fil på den lokala datorn

@maskinnamn Vidarebefordra ett meddelande till syslogd-demonen på den angivna maskinen

@IP_address Samma, endast maskinens IP-adress anges

användare1, Visa ett meddelande på skärmarna för de angivna användarna...

användareN

* Visa ett meddelande på alla användares skärmar

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

På tal om syslog-systemet måste vi nämna logger-kommandot, som låter dig skriva poster till systemloggen från skalskript.

Det här kommandot är användbart för att kontrollera ändringar som gjorts i filen /etc/syslog.conf.

local5.warning /var/log/local.log

och vill kontrollera om det fungerar, skriv sedan in kommandot

# logger -p local5.warning "Lokalt test"

Titta på filen /var/log/local.log. Om raden "Lokalt test" inte finns där, har du troligen glömt att skicka HUP-signalen till syslogd-demonen.

SERGEY SUPRUNOV

FreeBSD-tips: använder syslog

– Ursäkta mig, kamrater, jag har alla drag nedskrivna!

"Kontoret skriver", sa Ostap.

I. Ilf, E. Petrov "12 stolar".

Att logga driften av alla system, och särskilt servern, är en av de viktigaste komponenterna i administrationen. Det är loggfilerna vi tittar på först när problem uppstår i systemet. Därifrån får vi förtroende för att det eller det programmet fungerar som förväntat. Vid utveckling av webbapplikationer blir loggfilen den viktigaste källan för felsökningsinformation. Funktionerna i syslog-demonen, som är ansvarig för att logga systeminformation, kommer att diskuteras.

Vad är syslog

Syslog är en centraliserad tjänst som samlar in och registrerar logginformation från olika operativsystemkomponenter och användarprocesser. Tredjepartsprogram kan som regel arbeta med sina loggfiler oberoende, även om många av dem kan konfigureras för att fungera med syslogd-demonen. Fördelarna med att använda syslog inkluderar möjligheten att hantera insamlingen av nödvändig information med en enda konfigurationsfil, vilket säkerställer konsekvens i de resulterande loggfilerna och i slutändan förenklar hanteringen av dem.

Syslog-tjänsten tillhandahålls av syslogd-demonen, som automatiskt startas vid systemstart. Den finns ständigt i minnet och väntar på meddelanden från andra processer och bearbetar dem enligt dess inställningar.

Varje meddelande kännetecknas av en nivå och en källa (anläggning). Nivån anger graden av betydelse för meddelandet ur systemdriftsynpunkt. Filen syslog.h definierar följande nivåer (prioriteringar):

Tabell 1. Meddelandenivåer

Nivå	Beskrivning
uppstå, panik	Tillstånd av "panik"
varna	Tillstånd som kräver omedelbart ingripande
crit	Kritiskt tillstånd
fel, fel	Andra driftsfel
varning, varning	Varningar
lägga märke till	Meddelanden som inte är fel men som du bör vara uppmärksam på
info	Informationsmeddelanden (normal drift)
felsöka	Felsökningsinformation

Tabell 1 listar meddelandenivåer i fallande ordning. Denna ordning kommer att behövas senare när man diskuterar konfigurationsfilens syntax.

Meddelandenivåbeteckningar skrivna på samma rad (till exempel emerg och panik) är synonymer, och båda kan användas. Panik, fel och varning (som anges på andra plats i tabellen) är dock föråldrade och bör undvikas när du redigerar konfigurationsfilen. Använd istället emerg, err respektive warning.

Möjliga meddelandekällor listas i Tabell 2:

Tabell 2. Meddelandekällor

Källa	Beskrivning
kern	Kärnmeddelanden
auth, authpriv
säkerhet	Säkerhetsmeddelanden (till exempel från brandvägg)
trösta	Meddelanden som kommer till konsolen (/dev/console)
syslog	Inbyggda syslog-meddelanden
cron	Cron meddelanden
	Tidstjänstmeddelanden
	Meddelanden FTP-servrar
	Skriv ut delsystemmeddelanden
post	Postmeddelanden
Nyheter	Nyhetstjänstmeddelanden
uucp	Meddelanden UUCP
demon	Meddelanden från andra demoner som körs i systemet
användare	Användaren bearbetar meddelanden
lokal0 – lokal7	Kan användas för olika användarbehov (används ibland av systemet)

När du konfigurerar en applikation för att använda syslog-tjänsten, kontrollera vilken funktion den använder. Vissa program låter dig ange källan själv. Till exempel använder clamd-demonen (huvudprocessen för clamav-antiviruset) local6 som standard, men låter dig ange en annan källa (LogFacility-parametern i konfigurationsfilen). I vissa fall kan det vara användbart att kombinera dess meddelanden med meddelanden från e-posttjänster, och ange LOG_MAIL som källa.

Startalternativ för Daemon

För en komplett lista över startalternativ, se man-sidan för syslogd. Här kommer vi bara att överväga ett fåtal av dem.

Syslog kan spela in inkommande meddelanden till loggfiler (som vanligtvis finns i /var/log-katalogen), skicka dem till användarens konsol eller anslutna terminal, skicka dem till en fjärrvärd eller skicka dem till ett externt verktyg för bearbetning via en pipeline.

För att arbeta över nätverket använder syslog portar 514 (UDP och TCP). När den körs utan ytterligare parametrar kommer syslogd att lyssna på dessa portar och vänta på inkommande meddelanden. Switchen -s förhindrar att inkommande meddelanden accepteras, men sockets på port 514 skapas fortfarande för utgående anslutningar så att syslogd kan skicka meddelanden till fjärrvärdar. Fördubbling av switchen (-ss) inaktiverar också utgående anslutningar.

Som standard startas syslogd med -s-växeln (se /etc/defaults/rc.conf, syslogd_flags-parametern), så inkommande anslutningar är förbjudna. Om du vill använda din servers syslog-tjänst för att betjäna flera maskiner, lägg till följande rad till /etc/rc.conf:

syslogd_flags= ””

Detta kommer att åsidosätta värdet inställt i /etc/defaults/rc.conf och syslogd kommer att kunna betjäna inkommande anslutningar. Naturligtvis är det i det här fallet nödvändigt att säkerställa den nödvändiga säkerhetsnivån, vilket eliminerar möjligheten för andra värdar att skriva något till dina loggar. Omkopplaren -a låter dig ställa in begränsningar för inkommande anslutningar (se man syslogd). En korrekt konfigurerad brandvägg spelar också en viktig roll.

En annan användbar switch -l låter dig specificera ytterligare socketfiler som syslogd-demonen lyssnar på förutom standarden /var/run/log. Till exempel krävs denna nyckel för att syslog ska kunna tjäna program som körs i en chrootad miljö. I synnerhet är det så här named fungerar, som börjar med BIND 9. I FreeBSD 5.3 startas syslogd med följande nycklar:

#ps-vax | grep syslog

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

Syntax för konfigurationsfil

Loggning konfigureras i filen /etc/syslog.conf. Det säger sig självt att endast root-användaren kan redigera den. Den här filen innehåller två typer av strängar - låt oss kalla dem "filter" och "regler".

Filterraden anger från vilket program eller värd följande regler kommer att tillämpas på meddelanden från den. Ett filter av formen "!prog" (eller "#!prog") indikerar att följande rader refererar till loggar som genereras av det angivna progprogrammet. En synonym för denna post är "!+prog". Raden "!-prog", å andra sidan, indikerar att efterföljande regler kommer att gälla för alla meddelanden förutom de som kommer från progprogrammet. Det är tillåtet att lista flera program separerade med kommatecken, medan "+" eller "-" tecknet gäller för hela listan.

Om filtersträngen anges som "+värdnamn", kommer den angivna värden att användas som källa för meddelanden som bör behandlas av efterföljande regler. Som med program indikerar "-"-symbolen att reglerna kommer att gälla för alla meddelanden utom de som kommer från den angivna värden. Du kan ange en lista över värdar separerade med kommatecken.

Tecknet "*" som anges som ett program eller värd kommer att åsidosätta filtret som tidigare ställts in. Det vill säga, reglerna som anges efter en sådan rad kommer att gälla för alla meddelanden. Filter med värd- eller programnamn är oberoende av varandra och kan fungera samtidigt. Till exempel:

# Reglerna som finns här gäller för alla meddelanden

Min.värd

# Reglerna gäller för alla meddelanden från my.host

Logger

# Regler tillämpas på meddelanden från logger från my.host (värdfiltret förblir i kraft)

# Regler gäller för meddelanden från su till my.host

# Reglerna gäller meddelanden från su från vilken värd som helst (värdfiltret avbryts, programfiltret fortsätter att fungera)

# Reglerna gäller för alla meddelanden (programfiltret avbryts också)

Regellinjerna ser ut så här:

facility.CMLevel destination

Här är anläggning källan till meddelandet (“*” anger alla källor), nivå är nivån på meddelanden som kommer att behandlas i enlighet med denna regel. Serviceordet "ingen", som anges istället för nivån, ger instruktioner för att helt utesluta meddelanden från denna källa.

CMP – jämförelseoperation (symbolerna “>”, “” är tillåtna<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.

Destination anger var detta meddelande ska sparas. Detta kan vara en loggfil (den fullständiga sökvägen anges, som börjar med "/"), en fjärrserveradress (som börjar med "@"-symbolen), ett användarnamn (meddelanden kommer att skickas till terminalen som användaren är till ansluten). Meddelandet kan också överföras till ett externt program för bearbetning, för vilket transportörsymbolen "|" används.

Några exempel på regler

Alla kärnmeddelanden kommer att skickas till filen kern.log.

kern.* /var/log/kern.log

Alla felmeddelanden, såväl som emerg-, varnings- och kritiknivåmeddelanden, kommer att placeras i all-err.log. Notera bindestrecket före loggfilens namn. Som standard buffras meddelanden i minnet och skrivs till disk när bufferten är full. Detta minskar belastningen på filsystemet, men kan orsaka förlust av viss information om maskinen kraschar. Bindestrecket före filnamnet gör att syslogd-demonen omedelbart skriver meddelanden till disken.

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

Felsökningsmeddelanden för användarprocesser kommer att matas ut till terminalen som användaren Vasya för närvarande är ansluten till.

user.debug Vasya

Alla meddelanden från nyheter och e-posttjänster kommer att vidarebefordras till port 514 på syslog.host.ru-maskinen.

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

Alla utskriftstjänstmeddelanden vars nivå är lägre än varningen kommer att placeras i den angivna filen. Som nämnts tidigare är standardjämförelsen "större än eller lika med" och "!" inverterar den och ersätter den med "mindre". Om du behöver utesluta en specifik nivå bör du använda konstruktionen "!=".

lpr.!varning /var/log/printers.log

felsökningsnivå (och endast detta) meddelanden med anläggningsnivå0 och nivå3 kommer att matas ut till alla anslutna terminaler.

nivå0,nivå3.=felsöka *

Tidstjänstmeddelanden som är högre än kritiska (det vill säga emerg och alert) och mindre än eller lika med notis (notice, info och debug) kommer att skickas till ntpuser- och root-användarterminalerna.

ntp.>crit,<=notice ntpuser,root

Alla meddelanden på varningsnivå, utom de som kommer från e-posttjänster, kommer att registreras i filen warn.log.

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

I det här fallet kommer alla meddelanden vars nivå är högre än eller lika med crit att skickas via e-post till root-användaren.

*.crit | e-post -s rot för "kritiskt meddelande".

Som du kan se tillåter konfigurationsfilformatet att flera nivåer, källor och destinationer listas på en rad, vilket gör konfigurationen mer flexibel. För att ändringar efter redigering ska träda i kraft måste du skicka en HUP-signal till syslogd-processen:

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

Det bör noteras att om ett meddelande faller under flera rader i konfigurationsfilen, kommer det att behandlas i enlighet med var och en av dem. Exempel:

mail.* /var/log/maillog

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

I det här fallet kommer mail.err-meddelanden att hamna i både maillog och error.log.

Strategi för att skapa en konfigurationsfil

Som avslutning på vår granskning av konfigurationsfilen kommer jag att säga några ord om strategierna för att kompilera den. Förutom det mycket populära "så länge det fungerar", kan vi urskilja två huvudsakliga, som vi ungefär kommer att kalla "efter källa" och "efter syfte."

• Den första strategin, som kan ses i ett antal GNU/Linux-distributioner, är att skriva en annan regel för varje meddelandekälla (eller en grupp regler om meddelanden på olika nivåer ska behandlas olika). Dess fördel är att det är lätt att avgöra var meddelanden från specifika tjänster spelas in.
• Strategin "efter destination" innefattar att skapa, om möjligt, endast en rad för varje "mottagare" av ett meddelande, såsom en fil. Detta tillvägagångssätt följs i synnerhet av FreeBSD. Som ett resultat kan du enkelt bestämma vilken information som skrivs till en viss loggfil, men till exempel måste destinationer för kärnmeddelanden samlas in genom hela konfigurationsfilen.

Logger verktyg

Systemet inkluderar ett loggerverktyg som låter dig skicka meddelanden till syslog-tjänsten direkt från kommandoraden. Det är bekvämt att använda när du testar konfigurationsregler, såväl som i utvecklade skript för att logga deras funktion. Exempel:

user$ logger -p user.err “Fel i användarprogrammet!”

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

Det första exemplet kommer att skicka ett meddelande med fel på anläggningens användarnivå, som kommer att behandlas enligt konfigurationsfilen. Det andra kommandot skickar ett meddelande till fjärrvärden, standardkällan och nivån kommer att ställas in på user.notice.

Använda rotationsmekanismer

Loggningsmekanismen som diskuteras ovan tillhandahåller ingen hantering av loggfiler. Meddelanden placeras helt enkelt i dem enligt reglerna som beskrivs i konfigurationsfilen. Detta innebär att loggfilerna ständigt kommer att växa, och om inget görs kommer de förr eller senare att fylla allt tillgängligt utrymme på motsvarande partition. För att undvika detta används en rotationsmekanism.

Till exempel, när storleken på filen debug.log överstiger 100 MB, döps den om till debug.log.0 och paketeras i debug.log.0.bz2. Och istället skapas en ny debug.log. Därefter, när storleken på den nya filen når 100 MB, byts debug.log.0.bz2 om till debug.log.1.bz2, och proceduren som beskrivs ovan upprepas. Systemet lagrar endast ett visst antal arkivfiler och tar bort de äldsta. Detta är rotation.

newsyslog verktyg

På FreeBSD-systemet är newsyslog-verktyget ansvarigt för rotation, som som standard startas i början av varje timme av cron-demonen. Du kan ändra rotationsperioden genom att redigera /etc/crontab.

Rotationsparametrarna som anges i exemplet ovan (filstorlek, förpackning), såväl som ett antal andra, ställs in i konfigurationsfilen /etc/newsyslog.conf. För varje fil som behöver roteras innehåller den en rad med generellt nio fält: filnamn, ägare och grupp, åtkomsträttigheter, högsta nummer i arkivfilens namn, maximal filstorlek, rotationsperiod, ytterligare flaggor och sökväg till PID-fil för applikationen som signalen behöver skickas till efter rotation, och numret på signalen som ska skickas. (Att skicka en signal till processen kan vara nödvändigt, till exempel om processen håller loggfilen öppen hela tiden; om detta inte görs kommer den använda filbeskrivningen inte att matcha den nyskapade filen.) Vissa fält kan utelämnas . Här är två exempel, kompletta och "typiska":

/var/log/pflog root:wheel 600 3 100 * JB /var/run/pflog.pid 1

Enligt denna regel ska pflog-filen skrivas över så snart dess storlek överstiger 100 MB (5:e fältet) oavsett tidpunkt (tecknet "*" i det sjätte fältet). Arkiverade filer kommer att ha namn som pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2, etc.), och X får inte vara fler än tre (parameter 3 i det fjärde fältet). J-flaggan indikerar att arkivfilen ska paketeras med hjälp av verktyget bzip2. Tack vare B-flaggan kommer rotationstjänstmeddelanden inte att läggas till i arkiverade och nyskapade filer, eftersom filen uppfattas som binär. Den nyskapade filen kommer att ägas av rotanvändaren och hjulgruppen (det här fältet kan utelämnas eftersom detta är standardägaren). Behörigheterna kommer att ställas in på rw------- (numeriskt värde 600), vilket betyder att endast ägaren kommer att kunna läsa och skriva till den här filen. Slutligen kommer en signal 1 (HUP) att skickas till processen vars PID lagras i /var/run/pflog.pid för att återöppna dess loggfil.

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

Denna regel specificerar rotationsparametrarna för maillogfilen: oavsett storlek (asterisk i det 5:e fältet) kommer filen att skrivas om varje natt kl. 00:00 (i man newsyslog.conf beskrivs tidsformatet tillräckligt detaljerat). Arkivet måste packas, de senaste 8 arkiven (numrerade 0 till och med 7) kommer att sparas, den nyskapade filen kommer att ägas av rotanvändaren (standardvärde, så ägarfältet hoppas över) och har behörigheterna rw-r -----.

För att se packade loggfiler kan du använda verktygen zcat och bzcat (för gzip respektive bzip2). Midnight Commander anropar lämpliga verktyg automatiskt.

Efter redigering av newsyslog.conf-filen behöver inga signaler skickas någonstans - konfigurationen kommer att läsas om nästa gång newsyslog anropas.

Det bör noteras att newsyslog-verktyget inte är kopplat till syslogd-demonen. Det vill säga, det kan användas för att rotera alla filer som behöver det. Om rotation är aktiverat för loggar som programmet underhåller oberoende av (till exempel clamd- eller bläckfiskloggar), var särskilt försiktig med att ange ägare och åtkomsträttigheter. Om du anger dem felaktigt kan det resultera i att en applikation som körs som en oprivilegierad användare efter rotation inte kommer att kunna skriva till den nyskapade filen.

Summering

Syslog-systemet är ett mycket kraftfullt och effektivt verktyg för att logga olika händelser som inträffar i systemet. Standardinställningarna är ganska balanserade och fungerar bra för de flesta system. Men genom att förstå hur syslog fungerar kan du avsevärt förbättra kvaliteten på loggningen genom att anpassa registreringen av logginformation strikt i enlighet med dina behov.