Demon înăuntru Unix apelați programul care funcționează "pe fundal" fără a necesita controlul terminalului și oferindu-vă posibilitatea de a vă face celelalte lucrări „în prim-plan”. Daemonul poate fi pornit fie printr-un alt proces, de exemplu, de către unul dintre scripturile de pornire a sistemului fără a accesa deloc niciun terminal de control, fie de către utilizator de la un terminal, dar în acest caz demonul "nu preia controlul" terminalul pe durata funcționării acestuia. Desigur, apare întrebarea, care demoni sunt necesari pe sistemul dumneavoastră și care pot fi dezactivați.
Originea termenului
În lumea reală (adică, fără computer), termenul (sau cuvântul) „demon” denotă un spirit (cel mai adesea – unul rău) sau o „voce interioară”. Este de remarcat faptul că ambele aceste valori se aplică și programelor daemon Unix. La fel ca demonii mitologici, demonii Unix se ascund în spatele scenei, încercând să rămână invizibili. Și, la fel ca vocea interioară sau subconștientul nostru, ele sunt mereu „în alertă”, întotdeauna disponibile, se pot „manifesta”. Cuvântul „demon” însuși reprezintă unul dintre acele acronime de computer, a cărui origine este la fel de greu de aflat pe cât este de a decide dacă a existat la început un pui sau un ou. Probabil acest termen ("DAEMON") provine din cuvinte „Monitor de disc și execuție” program.
După ce am pornit să studiez problema, m-am dus la un preot care folosește un computer cu sistemul de operare Ubuntu. Pentru orice eventualitate, am luat un disc cu Windows. Nu se știe niciodată... Sunt o persoană simplă, nu m-am bătut prin tufiș, am dat imediat toate informațiile. Explicat de mult și în detaliu. Spre marea mea fericire, a luat totul cu calm, pe alocuri, în timp ce vorbeam, chiar a zâmbit, mai ales când a povestit despre motivele refuzului soțului surorii mele de la ubuntu. Părinte, om normal, are deja 50 de ani.Am mai vorbit puțin, sau mai bine zis am vorbit, pentru a înțelege că a asimilat corect ceea ce am spus. După care mi-a spus, nu îmi amintesc la propriu, dar nu m-am gândit să-l înregistrez pe un dictafon, așa că o voi descrie cu propriile mele cuvinte. În general, nu este nimic în neregulă cu faptul că acest termen este folosit în Linux, principalul lucru este credința în Dumnezeu.
Introducere în servicii
Daemonii la care face referire /etc/init.d sunt proiectați să ruleze pe Linux ca serviciu sau serviciu. Serviciile sunt programe care sunt pornite și oprite prin intermediul scripturilor init situate în directorul /etc/init.d. Multe dintre aceste servicii sunt lansate în timpul fazei de pornire a sistemului. Utilitarul / sbin / service oferă o interfață de utilizator (interacțiune) cu scripturi de inițializare. Și aceste scripturi în sine oferă o interfață pentru gestionarea serviciilor, oferind utilizatorului opțiuni pentru a porni, opri, reporni, interoga starea serviciului și pentru a efectua alte acțiuni asupra serviciului. De exemplu, scriptul de inițializare a serviciului httpd are următoarele opțiuni:
/ sbin / service httpd Utilizare: httpd (pornire | oprire | repornire | condrestart | reîncărcare | stare | stare completă | grațios | ajutor | configtest)
Puteți vizualiza starea curentă a tuturor serviciilor de sistem utilizând următoarea opțiune a utilitarului de servicii:
/ sbin / service --status-all acpid (pid 2481) rulează ... anacron (pid 2647) rulează ... atd (pid 2657) rulează ... auditd (pid 2189) rulează ...
Informațiile despre nivelul de rulare al acestor servicii, adică setarea la care dintre nivelurile de rulare a sistemului este pornit un anumit serviciu la momentul pornirii, pot fi obținute sau modificate folosind utilitarul chkconfig. Să vedem, de exemplu, setările curente pentru serviciul de înregistrare a sistemului syslog:
/ sbin / chkconfig --list syslog syslog 0: off 1: off 2: on 3: on 4: on 5: on 6: off
Vedem că serviciul syslog pornește automat când trecem la nivelurile 2, 3, 4 și 5. Pentru a-l dezactiva de la nivelurile 3 și 4 (nu este o idee bună, apropo), puteți folosi următoarea opțiune de comanda chkconfig:
/ sbin / chkconfig --levels 34 syslog off
Utilitarul / usr / bin / system-config-services oferă o interfață grafică pentru serviciile de sistem care vă permite să vizualizați și să modificați starea lor curentă, precum și să le setați să ruleze la diferite niveluri de execuție
Să vedem cum apar aceste servicii și daemoni în ieșirea comenzii ps. Iată un fragment rapid:
UID PID PPID C STIME TTY TIME CMD rădăcină 1 0 0 23:36? 00:00:00 init root 2161 1 0 23:37? 00:00:00 auditd root 2177 1 0 23:37? 00:00:00 syslogd -m 0 root 2180 1 0 23:37? 00:00:00 klogd -x rădăcină 2207 1 0 23:37? 00:00:00 mcstransd root 2254 1 0 23:37? 00:00:00 rpc.statd root 2287 1 0 23:37? 00:00:00 rpc.idmapd root 2577 1 0 23:37? 00:00:00 crond root 2631 1 0 23:37? 00:00:00 / usr / sbin / atd root 2654 1 0 23:37? 00:00:00 rhnsd --intervalul 240
Ce este interesant de observat aici (pe lângă faptul că, desigur, am stat prea târziu la computer astăzi)? Pentru fiecare dintre demoni, identificatorul procesului părinte (PPID) este 1. Aceasta indică faptul că demonii au fost porniți de init la momentul pornirii.
Acest rezultat poate fi văzut mai clar în ieșirea unei astfel de comenzi utile precum „pstree”, care afișează „arborele” proceselor cu indicarea „părinților”. Iată un mic fragment din rezultatul pstree:
Init- + | -NetworkManager --- 2 * [(NetworkManager)] | -NetworkManagerD | -acpid | -atd | -auditd - + - python | `- (auditd) | -avahi-daemon --- avahi-daemon | -bonobo-activati --- (bonobo-activati) | -crond | -cupsd --- cups-polld | -2 * | -dbus -lansare | -dhcdbd --- dhclient
Mai multe despre demonii de pe sistemul dumneavoastră
Am terminat cu informațiile introductive. Acum haideți să vorbim despre demonii de sistem izolat și să vedem cu care puteți experimenta în siguranță. Din nou, această postare este despre un sistem care rulează Red Hat Enterprise Linux Beta 2 într-o configurație de stație de lucru. În funcție de specificul sistemului dvs., este posibil să vedeți mai mulți sau mai puțini demoni, inclusiv unele care nu sunt acoperite aici.
Descrierile pentru fiecare demon includ link-uri către site-uri de unde puteți obține mai multe informații, dar cel mai bine este totuși să începeți să învățați despre demon uitându-vă la paginile de manual respective. O „Reilly are o listă alfabetică excelentă a comenzilor Linux, iar wikipedia.org are și secțiuni despre majoritatea acestor daemoni. Nu uitați să vă uitați la fișierele README.
Este serviciul Advanced Configuration and Power Interface (ACPI). ACPI este un standard industrial deschis care definește acțiunile de gestionare a sistemului, în primul rând definirea dispozitivului plug-and-play și gestionarea energiei, inclusiv acțiunile când sistemul pornește, se oprește și când intră într-un mod de consum redus.
Probabil că nu ar trebui să dezactivați acest serviciu decât dacă îl faceți în scopuri de depanare sau pentru a rezolva probleme hardware.
Mai multe informații: http://www.acpi.info
Dacă utilizați un laptop, așa cum fac mulți oameni în zilele noastre, atunci una dintre probleme este că atunci când îi cereți demonului cron să facă ceva, nu sunteți întotdeauna sigur că computerul dvs. va fi pornit în momentul în care este executată. programate.sarcini. Anacron (acest nume vine de la „cron anacronic”, care înseamnă ceva de genul „cron învechit”) rezolvă această problemă verificând dacă joburile au fost executate într-o anumită perioadă de timp. De exemplu, anacron va începe o sarcină dacă nu a fost pornită pentru un anumit număr de zile.
Când poți înceta să mai folosești anacron? Dacă sistemul dumneavoastră rulează în mod constant.
Poți să refuzi să rulezi cron dacă rulezi anacron? Nu; pentru anacron, perioada de repornire a sarcinii poate fi specificată numai în zile, nu în minute și secunde.
Informații suplimentare:
Este demonul Advanced Power Management (APM) printr-un driver din BIOS. Standardul APM și demonul apmd au fost acum înlocuite de ACPI și acpid. Dacă hardware-ul dvs. acceptă ACPI, nu trebuie să rulați apmd.
Acesta este un daemon pentru pornirea joburilor la o oră specificată. Dacă nu îl utilizați, este foarte posibil să îl dezactivați.
Acest demon montează automat discurile și sistemele de fișiere care sunt definite în fișierul de configurare. Folosirea acestui demon facilitează lucrul cu discuri amovibile.
Mai multe informații: http://freshmeat.net/projects/autofs
Sistemul de auditare Linux constă din înregistratoare de apeluri de sistem la nivel de kernel și instrumente de colectare și vizualizare a jurnalelor din spațiul utilizatorului. Daemonul auditd scrie mesajele înregistrate pe disc. Auditd este configurabil, permițându-vă să controlați și să gestionați ce informații sunt stocate pe disc.
Ar trebui să fie menținut auditd? Informațiile din jurnalele pot fi foarte utile în configurarea a tot ceea ce are legătură cu securitatea sistemului. De exemplu, auditd este utilizat în înregistrarea evenimentelor SELinux. Există, de asemenea, utilități precum aureport care vă permit să vizualizați jurnalele de audit. Iată un exemplu de raport generat de utilitarul aureport:
Raport de sinteză
======================
Interval de timp în jurnal: 28.11.2006 06: 07: 04.800 - 02.06.2007 21: 10: 09.957 Ora selectată pentru raport: 31.12.1969 19:00:00 - 02/06/2007 10: 09.957 Număr de modificări în configurație: 285 Număr de modificări la conturi, grupuri sau roluri: 32 Număr de autentificări: 145 Număr de autentificări eșuate: 11 Număr de utilizatori: 2 Număr de terminale: 22 Număr de nume de gazdă: 11 Număr de executabile: 27 Număr de fișiere: 91 Număr de refuzuri AVC: 688 Număr de evenimente MAC: 12 Număr de apeluri de sistem eșuate: 404 Număr de evenimente de anomalie: 0 Număr de răspunsuri la evenimente de anomalie: 0 Număr de evenimente cripto: 0 Număr de procese ID-uri: 14022 Număr de evenimente: 70694 Avahi-daemon și avahi-dnsconfd
Site-ul web Avahi îl definește astfel: „Avahi este un sistem care oferă posibilitatea de a descoperi servicii într-o rețea locală. Aceasta înseamnă că, odată ce computerul este conectat la o rețea locală, puteți descoperi instantaneu imprimantele disponibile, puteți vedea ce partajări sunt disponibile. în rețea, aflați cu cine din alți utilizatori ai rețelei puteți vorbi prin chat și așa mai departe." Avahi este o implementare a protocolului Zeroconf. Iar Zeroconf este o abordare care permite utilizatorilor să creeze rețele IP fără servicii speciale de configurare, cum ar fi serverele DNS.
Cel mai adesea, avahi-daemon este folosit împreună cu Rhythmbox, astfel încât să puteți vedea fișierele muzicale care sunt partajate cu alții. Dacă nu partajați muzică sau fișiere de pe computer, puteți dezactiva acest demon.
Mai multe informații: http://avahi.org, http://zeroconf.org
Bluetooth și demonii hidd și pand
Numele în sine explică totul. Porniți aceste servicii dacă doriți să utilizați dispozitive bluetooth. Numele demonului care rulează efectiv este hcid (Host Controller Interface Daemon).
Numele demonului ascuns provine de la „daemonul dispozitivului de interfață umană Bluetooth”. Oferă suport pentru tastatură, mouse și trackball Bluetooth. Și demonul pand vă menține computerul conectat la rețeaua ethernet folosind Bluetooth.
Mai multe informații: http://www.bluetooth.com,
Acest demon acceptă interfața comună de programare a aplicațiilor ISDN. Ar trebui să fie rulat dacă vă conectați la componente hardware ISDN. Acest serviciu începe capiinit.
Mai multe informații: http://www.capi.org/pages
Nu, nu are nimic de-a face cu emisiunile de investiții imobiliare peste noapte. Serviciul conman (și daemonul conmand) acceptă gestionarea consolei. Oferă suport pentru mai multe dispozitive de consolă și lucru simultan al utilizatorului, suport pentru dispozitive seriale locale și servere terminale la distanță (prin protocolul telnet). Dacă gestionați mai multe servere, este posibil să aveți nevoie de conman.
Mai multe informații: http://home.gna.org/conman/
cpusspeed
Acest demon schimbă viteza muncii unități centrale de procesare pentru a reduce consumul de energie. Dacă procesorul este inactiv, puteți reduce viteza, scăzând astfel consumul de energie, iar pentru a crește performanța trebuie să creșteți consumul de energie. Dacă lucrezi pentru laptop, are sens să rulați cpuspeed.
Mai multe informații: http://carlthompson.net/Software/CPUSpeed
crond
Acest demon este folosit pentru a porni automat sarcinile. Acest lucru este necesar pe toate sistemele Linux și Unix. Nu opriți sau dezactivați acest serviciu.
Mai multe informații: http://www.unixgeeks.org/security/newbie/unix/cron-1.html, http://www.linuxhelp.net/guides/cron/
CUPS și cups-config-daemon
Este demonul „Common UNIX Printing Solution”. După cum sugerează și numele, este un sistem de imprimare care se ocupă de o varietate de formate de fișiere și tipuri diferite imprimante. Dacă doriți să imprimați, executați acest demon pe sistemul dumneavoastră.
Mai multe informații: http://www.cups.org, http://www.easysw.com/cups/index.php
Numele acestui demon este un acronim pentru „DHcp Client D-Bus Daemon”. wiki-ul Free DeskTop îl definește după cum urmează:
D-Bus este un sistem de magistrală de mesaje, o modalitate simplă prin care aplicațiile pot comunica (sau interacționa) între ele. Pe lângă comunicarea între procese, D-Bus ajută la coordonarea ciclului de viață al procesului; oferă o implementare simplă și fiabilă în cod a capacității de a rula o „instanță separată” a unei aplicații sau demon, care vă permite să rulați aplicații și demoni la cerere, atunci când este nevoie de serviciile adecvate.
Trebuie să rulezi acest demon? Dacă sistemul dvs. funcționează într-o rețea (cum ar putea fi altfel?), mai ales dacă vă mutați între rețele (de exemplu, treceți de la o rețea cu fir la una fără fir), atunci ar trebui să porniți NetworkManager (ne vom uita mai jos la NetworkManager) .
Daemonul dhcdbd oferă o interfață D-Bus pentru dhclient, un client DHCP de la ISC. Acest lucru permite NetworkManager să acceseze și să controleze dhclient.
Mai multe informații: http://www.freedesktop.org/wiki/Software/dbus
Acest demon vă oferă posibilitatea de a utiliza mouse-ul în aplicații bazate pe text, cum ar fi manager de fișiere Comandantul de la miezul nopții. Acest lucru poate fi util dacă utilizați frecvent consola; altfel, adică dacă utilizați sistemul X Window tot timpul, este posibil să nu aveți niciodată nevoie de gpmd.
Nu, acesta nu este computerul malefic dintr-un film din 2001 Odiseea în spațiu. În acest context, HAL înseamnă Hardware Abstraction Layer. Daemonul HAL colectează (folosind nucleul și dispozitivele în sine) informații despre dispozitivele hardware și le prezintă aplicațiilor într-o manieră consecventă.
Nu dezactivați acest serviciu. Multe aplicații îl folosesc.
Mai multe informații: „Configurație desktop și hardware”, de David Zeuthen
Acest demon oferă suport pentru sistemul HP Linux Imaging and Printing (HPLIP) utilizat pentru imprimarea, scanarea și trimiterea de faxuri cu jet de cerneală și dispozitive laser de la HP. HPLIP interacționează cu CUPS, oferindu-i acestuia din urmă acces la dispozitivele de la HP.
Informații suplimentare:
Este un demon pentru bazele de date relaționale în Java. Și-a moștenit numele de la proiectul Hypersonic SQL, care nu mai este acceptat. hsqldb este utilizat pe scară largă în proiecte open source, cum ar fi OpenOffice.org, precum și în demonstrații, deoarece poate rula în întregime în RAM. Datorită a ceea ce funcționează rapid. Trebuie să rulați acest serviciu? Doar dacă rulați vreun program care îl folosește. Dar de fapt este foarte unealtă folositoareși, dacă nu sunteți familiarizat cu el, merită să îl priviți.
Mai multe informații: http://hsqldb.org, http://dba.openoffice.org
Server web Apache. Folosit de aproape 60% din toate site-urile web. Dacă doriți să întrețineți un site web, rulați Apache. Mai trebuie să spun ceva?
Mai multe informații: http://httpd.apache.org
ip6tables și iptables
Acestea sunt firewall-uri sau firewall-uri. Potrivit Wikipedia, „Un firewall sau firewall (jargon. Firewall sau firewall din engleză. Firewall) este un set de instrumente hardware și/sau software care controlează și filtrează pachetele de rețea care trec prin acesta la diferite niveluri ale modelului OSI, în conformitate cu reguli specificate. firewall este protecție retele de calculatoare sau noduri individuale de la acces neautorizat.”
Iptables funcționează prin stabilirea regulilor de filtrare a pachetelor IPv4 sub forma unui tabel kernel. Pachetele de intrare și de ieșire sunt verificate în raport cu aceste reguli, iar cele care nu se potrivesc cu regulile sunt blocate. Ip6tables face același lucru pentru pachetele IPv6.
Pe care dintre cele două servicii doriți să rulați? Ambii. Este mereu. Rețeaua este periculoasă!
Mai multe informații: http://www.netfilter.org, http://www.ipv6.org
IrDA (Infrared Data Association) este un standard industrial pentru comunicația fără fir în infraroșu între dispozitive. Majoritatea laptopurilor sunt echipate cu un transmițător în infraroșu compatibil IrDA. Trebuie să porniți acest serviciu numai dacă aveți de gând să organizați comunicarea cu alte dispozitive prin infraroșu.
Informații suplimentare:
irqbalance
Acest demon este responsabil pentru distribuirea întreruperilor hardware între procesoarele din arhitecturile cu procesor simetric (SMP) multiprocesor pentru a îmbunătăți performanța.
Nu este nevoie să rulați acest demon pe sisteme cu uniprocesor; afectează doar sistemele cu multiprocesor.
Mai multe informații: http://www.irqbalance.org
Este un demon foarte util. Acesta rulează în momentul pornirii și verifică ce dispozitive hardware au fost adăugate sau eliminate din sistem. Este logic să rulați kudzu la pornire, chiar dacă nu intenționați să adăugați sau să eliminați dispozitive frecvent. Pentru că, mai devreme sau mai târziu, vă veți găsi în egală măsură într-o situație în care adăugați un dispozitiv și vă așteptați ca sistemul să îl detecteze. În plus, deoarece kudzu rulează în momentul pornirii, nu afectează negativ performanța sistemului.
Mai multe informații: http://fedora.redhat.com/projects/additional-projects/kudzu
Acest demon își primește numele de la Lan Information Server. Lisa oferă funcționalități similare cu cele oferite de serviciul Network Neighborhood în MS-Windows, adică oferă acces la serverele din rețeaua locală, inclusiv la serverele CIFS (Common Internet File Systems). lisa rulează peste TCP / IP, trimițând solicitări ICMP către adrese IP din intervalul specificat în fișierul de configurare și așteaptă ca computerele să răspundă.
Mai multe informații: http://docs.kde.org/stable/en/kdenetwork/lisa, http://docs.kde.org/userguide/networking-with-windows.html,
lm_senzori
Acest demon monitorizează temperaturile și tensiunile de pe placa de bază. Pentru ca sistemul de monitorizare să funcționeze, este necesar să existe senzori corespunzători în echipament. Este logic să porniți acest demon doar dacă este furnizat suport hardware. Probabil nu ar trebui să-l rulați pe stații de lucru obișnuite. Mai degrabă, este necesar pe serverele de vârf care îndeplinesc funcții critice.
Mai multe informații: http://www.lm-sensors.org, http://freshmeat.net/projects/lm_sensors
mcstrans
SELinux Context Translation System Daemon. Acest demon convertește informațiile din contextul de securitate într-o formă care poate fi citită de om. Puteți opri acest demon, dar dacă da, veți vedea informațiile SELinux afișate de comanda ls -Z schimbare. De exemplu, cu demonul care rulează, veți vedea:
Ls -Z -rw-r - r-- jsmith jsmith user_u: object_r: user_home_t bookmarks.html drwxr-xr-x jsmith jsmith user_u: object_r: user_home_t Desktop -r-xr-xr-x jsmith jsmith user_home -r object_rt - r - r-- jsmith jsmith user_u: object_r: user_home_t hello.c
Și dacă demonul este oprit, veți vedea următoarele:
Ls -Z -rw-r - r-- jsmith jsmith user_u: object_r: user_home_t: s0 bookmarks.html drwxr-xr-x jsmith jsmith user_u: object_r: user_home_t: s0 Desktop -r-xr-xr-x jsmith jsmith : object_r: user_home_t: s0 salut -r - r - r-- jsmith jsmith user_u: object_r: user_home_t: s0 hello.c
Rețineți că, dacă demonul este oprit, este afișată valoarea contextului de securitate „s0”. Mctrans a eliminat contextul în acest caz. Alte valori de context de securitate sunt convertite din valori alfanumerice în numele lor.
Mai multe informații: http://fedoraproject.org/wiki/SELinux/Understanding, http://danwalsh.livejournal.com
mdmonitor și mdmpd
Acești doi demoni sunt utilizați în sistemele de stocare RAID (redundant array) de discuri ieftine / independente. Mdmonitor pornește, oprește și repornește mdadm (monitorizare și gestionare a dispozitivelor cu mai multe căi), un serviciu software de monitorizare și management RAID. Trebuie să porniți acest serviciu doar dacă sistemul dumneavoastră are dispozitive RAID.
Mai multe informații: http://www.linuxdevcenter.com/pub/a/linux/...12/05/RAID.html
magistrală de mesaje
Este demonul magistralei de mesaje de sistem D-BUS. Acesta difuzează evenimente și evenimente de sistem, cum ar fi modificările la coada de imprimare sau adăugarea sau eliminarea dispozitivelor (rețineți că acest lucru nu este același cu kudzu, deoarece astfel de evenimente pot apărea în orice moment în timpul funcționării sistemului, nu numai în faza de pornire). ).
Mai multe informații: http://www.freedesktop.org/software/dbus
netplugd și ifplugd
Acești demoni configurează dispozitivele Ethernet atunci când este conectat un cablu de rețea și dezactivează acele dispozitive când cablul este deconectat. Când ai nevoie? De exemplu, pe laptopuri, astfel încât dvs conexiuni de retea restaurat numai în timp ce cablul de rețea este conectat.
Rețineți că suportul pentru netplugd a fost întrerupt și acum este înlocuit de ifplugd.
Mai multe informații: http://0pointer.de/lennart/projects/ifplugd
NetworkManager și NetworkManagerDispatcher
Daemonul NetworkManager automatizează comutarea între conexiunile de rețea. Acest demon este util pentru utilizatorii de laptop care comută între conexiunile wireless WiFi și conexiunile Ethernet. Daemonul NetworkManagerDispatcher lansează automat scripturi pentru a efectua operațiunile necesare (de exemplu, scripturi pentru a seta direcții specifice de rutare pentru pachete) atunci când NetworkManager modifică starea rețelei.
Mai multe informații: http://www.gnome.org/projects/NetworkManager
Este un demon care acționează ca un server de nume de domeniu. Ar trebui să îl rulați numai dacă computerul este serverul DNS pentru rețea.
Mai multe informații: http://www.dns.net/dnsrd
Daemonul nfsd oferă suport pentru protocolul de comunicare în rețea nfs, care este utilizat pentru a oferi acces la resursele rețeleiîn rețelele TCP/IP. Trebuie să îl rulați dacă le oferiți altor utilizatori acces la sistemele dvs. de fișiere folosind protocolul nfs.
Informații suplimentare:
Acesta este demonul de stocare în cache pentru serviciul de nume. Menține un tabel de grupuri și parole pentru rularea programelor și apoi produce un rezultat memorat la următoarea solicitare pentru servicii care altfel sunt prea lente, cum ar fi NIS sau LDAP. Dacă aveți aceste servicii în funcțiune, ar trebui să porniți și nscd.
Este un demon care acceptă Network Time Protocol. Setează ora sistemului și o sincronizează cu ora setată de serverele de Internet care mențin ora de referință. Dacă sistemul dumneavoastră este conectat la Internet (nu-i așa?), atunci acest demon va monitoriza setarea corectă a orei sistemului pe computerul dumneavoastră.
Mai multe informații: http://www.ntp.org
Daemonul oddjobd rulează serviciul com.redhat.oddjob pe magistrala de sistem. Fiecare oportunitate oferită de oddjobd este oferită ca metoda separata D-Bus. Oddjobd oferă suport pentru efectuarea de operațiuni privilegiate pentru aplicații neprivilegiate.
Ar trebui să porniți acest demon numai dacă utilizați aplicații care îl necesită, cum ar fi Conga.
Mai multe informații: http://people.redhat.com/nalin/oddjob/oddjob.html,
Acest demon acceptă rețele private virtuale (VPN). Scriptul de pornire al acestui demon spune următoarele:
OpenVPN este o aplicație de tunelare robustă și extrem de flexibilă care utilizează capabilitățile de criptare, autentificare și certificare ale bibliotecii OpenSSL pentru a tunel în siguranță o rețea IP printr-un singur port UDP.
Dacă sistemul dvs. este o gazdă VPN, atunci probabil că ar trebui să rulați OpenVPN.
Mai multe informații: http://openvpn.net
pcscd (PC / SC Smart Card Daemon) este un daemon pentru mediul de dezvoltare pcsc-lite (software de acces smart card) și (bazat pe Java) MuscleCard. Oferă comunicarea cu cititoarele de carduri inteligente și cu cardurile inteligente în sine.
(Un card inteligent este o placă mică care are fie un modul de memorie, fie un microprocesor cu un modul de memorie încorporat. Muscle înseamnă Mișcarea pentru utilizarea cardurilor inteligente într-un mediu Linux.
Mai multe informații: http://www.smartcardalliance.org, http://pcsclite.alioth.debian.org, http://www.linuxnet.com/musclecard/index.html
Daemonul portmapper gestionează conexiunile RPC (apel de procedură la distanță). Acesta convertește numerele de program RPC în numere de porturi TCP / IP (sau UDP / IP). Portmapper-ul este cel mai frecvent utilizat de NFS și NIS.
Deci, dacă sistemul dumneavoastră depinde de NIS sau NFS, nu dezactivați demonul portmap.
Mai multe informații: http://www.linux-nis.org/nis-howto/HOWTO/portmapper.html
Este un agent de transfer de e-mail (transport). Dacă sistemul dvs. nu este un releu pentru sistemul de e-mail, nu este necesar să porniți acest serviciu.
Mai multe informații: http://www.postfix.org
Acest demon (demonul de descoperire a routerului) găsește rute pe subrețeaua locală. Este rulat la pornire pentru a adăuga rutele implicite la tabelele de rutare.
Mai multe informații: http://www.informit.com/articles/article.asp?p=23951&rl=1
restaurarecond
Acesta este un demon de la SELinux. Restorecond monitorizează crearea fișierelor (pentru fișierele listate în /etc/selinux/restorecond.conf) și se asigură că fișierele au contextul de fișier corect pentru politica specificată și, de asemenea, definește contextul implicit de fișier SELinux.
Nu dezactivați acest serviciu. Este necesar pentru SELinux.
Mai multe informații: http://fedoraproject.org/wiki/SELinux/Understanding, http://danwalsh.livejournal.com/
Acest demon verifică periodic prin ce operațiuni trebuie efectuate interfata retea Red Hat (interfața web Red Hat Network) și le rulează. Aceste operațiuni includ instalarea, eliminarea sau actualizarea software-ului, repornirea sistemului, instalarea fișierelor de configurare și așa mai departe.
Mai multe informații: https://www.redhat.com/rhn/
rpcgssd, rpcidmapd și rpcsvcgssd
Daemonii rpcgssd și rpcsvcgssd sunt pentru securitatea peste RPC. Rpcidmapd convertește numele de utilizator în numere UID și GID.
Dacă utilizați NFS sau NIS, ar trebui să rulați acești demoni.
Informații suplimentare:
readahead_devreme și readahead_later
Daemonul readhead asigură că programele de pornire sunt încărcate în memorie înainte de a fi utilizate, ceea ce reduce timpul de pornire.
saslauthd
Acesta este demonul serverului de autentificare SASL. SASL (Simple Authentication and Security Layer) adaugă capabilități de autentificare protocoalelor bazate pe conexiuni la distanță.
Mai multe informații: http://asg.web.cmu.edu/sasl
sendmail
Este un server SMTP (Simple Mail Transfer Protocol). Sendmail redirecționează corespondența de la un sistem la altul, adică este un Agent de transport de e-mail. Dacă utilizați mailere precum Thunderbird sau Evolution, nu trebuie să rulați sendmail.
Mai multe informații: http://www.sendmail.org
depanare
Acesta este demonul de rezolvare a problemelor SELinux. Setroubleshooter este una dintre marile inovații recente în SELinux. Setroubleshooter oferă utilizatorilor feedback în timp real cu privire la erorile SELInux AVC (Access Vector Cache). În plus, acest feedback este furnizat într-un format convenabil.
Mai multe informații: https://hosted.fedoraproject.org/projects/setroubleshoot
Acest demon monitorizează citirile senzorilor SMART (Self-Monitoring, Analysis and Reporting Technology) instalați în multe tipuri de unități, de exemplu, în hard disk-urile SCSI-3. Demonul monitorizează funcționarea normală a unor astfel de dispozitive și efectuează un autotest. Dacă hardware-ul dvs. acceptă tehnologia SMART, trebuie să porniți acest serviciu.
Informații suplimentare:
spamassassin
Acest demon folosește programul Apache SpamAssassin pentru a verifica e-mailurile pentru spam. De obicei rulează împreună cu un server MDA (mail deleivery agent). Dacă utilizați programe client precum Thunderbird sau Evolution pentru a vă accesa e-mailul, nu trebuie să rulați spamassassin.
Mai multe informații: http://spamassassin.apache.org
Acesta este un demon pentru protocolul ssh deschis. Ssh înlocuiește programele nesigure rsh și rlogin și oferă conexiuni criptate între gazdele din rețele nesigure. Dacă utilizați conexiuni la alte sisteme prin Internet deschis, trebuie să utilizați ssh și să rulați acest demon.
Mai multe informații: http://www.ssh.com, http://www.openssh.com
syslog este sistemul standard de înregistrare Linux. Nu o opriți.
Mai multe informații: http://www.syslog.org
Acest demon face parte din pachetul Samba. Permite utilizatorilor domeniului Windows să se conecteze ca utilizatori Unix la servere Unix. Acest demon ar trebui să fie pornit atunci când aveți de-a face cu o rețea mixtă de computere Windows și Linux / Unix.
Mai multe informații: http://www.samba.org/samba/docs/man/Samba-...on/winbind.html, http://www.samba.org
Acesta este un server de fonturi. Acest demon încarcă fonturi în memorie, astfel încât aplicațiile grafice să ruleze mai repede decât trebuie să încarce fonturi de pe hard disk. Acest serviciu ar trebui pornit pentru a îmbunătăți performanța aplicațiilor de pe sistemul dumneavoastră.
Mai multe informații: http://linuxreviews.org/howtos/xfree/xfs
Acest serviciu leagă clientul NIS la domeniul NIS. Literele „yp” din numele său provin de la „paginile galbene”, deoarece directoarele NIS sunt ca directoarele telefonice din paginile galbene. Trebuie să porniți acest serviciu doar dacă sistemul dumneavoastră utilizează NIS (Serviciul de informații de rețea) pentru a oferi acces la bugetele utilizatorilor și la numele sistemului.
Mai multe informații: http://www.linux-nis.org
yum-actualizărid
yum-updatesd monitorizează disponibilitatea actualizărilor software și trimite notificări cu privire la aceste actualizări prin e-mail, d-bus sau mesaje de sistem și poate produce, de asemenea, actualizare automata PE. Mesajele D-bus sunt primite de utilitarul „puplet” (actualizare pachet), care informează utilizatorul că este disponibilă o actualizare și, de asemenea, îi permite utilizatorului să instaleze actualizarea.
Mai multe informații: http://linux.duke.edu/projects/yum, http://www.redhat.com/magazine/024oct06/features/fc62
Mulțumită ZOOL pentru informațiile furnizate pe site-ul http://www.centrlan.ru/node/17929
Sursa nu este specificată
Fiecare dintre utilizatorii începători de Linux întâmpină, mai devreme sau mai târziu, unele probleme în configurarea și organizarea funcționării sistemului lor. Și fiecare dintre începători a auzit aproape sigur de la utilizatorii mai experimentați sfatul: „Uită-te la jurnalele”. Acest sfat este bun, dar un începător mai trebuie să știe: ce sunt jurnalele și unde să le găsească! Așa că voi încerca în acest articol să vă spun ce și unde să căutați.În argoul de programare, „jurnalele” sunt protocoalele de lucru care sunt menținute atât de sistemul de operare în sine, cât și independent de multe programe. Cuvântul „jurnal” este adesea folosit ca sinonim pentru cuvântul „protocol” în acest sens. Există două situații principale în care devine necesară analizarea protocolului: când ceva din sistem nu funcționează așa cum ne așteptam (rezolvarea problemei) și când există suspiciunea că sistemul a fost piratat de un intrus și este necesar pentru a afla ce s-a întâmplat exact cum a fost făcut și ce trebuie făcut pentru a face față consecințelor invaziei.
Unul dintre cele mai cunoscute cazuri de utilizare a fișierelor jurnal pentru a detecta intruziunea unui atacator este povestea captării de către specialistul în securitate informatică Tsuomo Shimomura a celebrului hacker Kevin Mitnick. Iată un paragraf dintr-un articol care descrie cum s-a întâmplat acest lucru.
„În ziua de Crăciun, când Shimomura a plecat la schi în Nevada în vacanță, cineva (știm deja cine) a pătruns în computerul său super-securizat din Solana Beach, California, și a început să-și copieze fișierele - sute de fișiere clasificate din San Diego. Centrul de supercomputer, unde lucra Shimomura, a observat modificări în fișierele „jurnal” (jurnal) de sistem și și-a dat seama rapid ce se întâmplă.la un computer de rezervă din San Diego. Studentul l-a sunat pe Shimomura și s-a grăbit acasă să facă un inventar al bunurilor furate. ."
Nu voi spune aici toată povestea, este important pentru noi să remarcăm doar că analiza protocoalelor de funcționare a sistemului a servit drept bază pentru succesul cercetării acțiunilor ilegale. O descriere mai detaliată a modului în care sunt efectuate astfel de investigații poate fi găsită în articol. Dar pentru a putea folosi rezultatele înregistrării, trebuie să înțelegeți cum sunt create protocoalele, unde sunt stocate și ce poate fi extras din ele. Acest articol este dedicat luării în considerare a tuturor acestor întrebări.
Cum sunt generate mesajele pentru protocol
Trebuie să începem cu faptul că atunci când creează programe în limbajul C, programatorii au posibilitatea, dacă este necesar, de a insera un apel de funcții speciale. openlog, setlogmask, syslogși closelog incluse în biblioteca standard C. Aceste funcții sunt folosite pentru a trimite mesaje despre anumite evenimente în timpul execuției programului către un demon special de sistem syslogd conducând protocolul de sistem. Funcţie openlog stabilește o legătură cu un demon syslogd, funcție syslog generează un mesaj specific pentru a fi scris în protocol și funcția closelogînchide o legătură deschisă.
Mesaje generate de funcție syslog, constau din mai multe câmpuri separate prin spații. Fiecare mesaj începe cu un câmp PRI, care codifica informații despre categoria unității și nivelul de severitate sau prioritatea mesajului.
Categoria (facilitatea) este informații despre carei clase îi aparține mesajul dat. Categoria este codificată cu un număr de la 0 la 23. Există următoarele categorii (sunt definite în fișier /usr/include/sys/syslog.h):
Tabelul 1.
| Valoare numerică | Simbol | Decriptare |
| 0 | kern | Mesaje kernel |
| 1 | utilizator | Destinat pentru mesaje diverse din programele utilizatorului (Mesaje din programele utilizatorului) |
| 2 | Poștă | Mesaje din sistemul poștal. |
| 3 | demonul | Mesaje de la acei daemoni de sistem, care, spre deosebire de FTP sau LPR, nu au categorii specifice. |
| 4 | auth | Tot ce este legat de autorizarea utilizatorului, cum ar fi login și su (securitate / drepturi de acces) |
| 5 | syslog | Sistemul de înregistrare poate înregistra mesaje de la sine. |
| 6 | lpr | Mesaje de la sistemul de imprimare. |
| 7 | știri | Mesaje de pe serverul de știri. (Netnews, USENET) |
| 8 | uucp | Mesaje de la UNIX-to-UNIX Copy Protocol. Aceasta face parte din istoria UNIX și, cel mai probabil, nu veți avea nevoie niciodată de el (deși totuși o parte din e-mail este livrată prin UUCP). |
| 9 | cron | Mesaje de la programatorul de sistem. |
| 10 | authpriv | La fel ca auth, dar mesajele din această categorie sunt scrise într-un fișier pe care doar câțiva utilizatori îl pot citi (poate că această categorie este evidențiată deoarece mesajele care îi aparțin pot conține parole deschise de utilizator care nu ar trebui să fie văzute de persoane neautorizate și, prin urmare, fișierele jurnal trebuie să aibă permisiunile corespunzătoare). |
| 11 | ftp | Prin această categorie vă puteți configura serverul FTP pentru a-și înregistra acțiunile. |
| de la 12 la 15 | - | Rezervat pentru utilizarea sistemului. |
| de la 16 la 23 | local0 - local7 | Categoriile rezervate pentru utilizare de către administratorul de sistem. Categoria local7 este de obicei folosită pentru mesajele generate în timpul fazei de pornire a sistemului. |
Categorie auth are un sinonim învechit Securitate care nu este recomandat pentru utilizare. În plus, există o categorie specială marcă(nu are echivalent digital), care este atribuit mesajelor individuale generate de demonul însuși syslogd... Această categorie este folosită pentru a plasa semne speciale în protocol la un interval de timp specificat (în mod implicit, la fiecare 20 de minute), ceea ce permite, de exemplu, să știți cu o precizie de 20 de minute când computerul este înghețat.
Rețineți că, în general, categoria nu are nimic de-a face cu numele programului care trimite mesaje către demon. syslogd... După cum se spune, orice coincidență este pură coincidență. Mai mult, unele programe pot genera mesaje de diferite categorii. De exemplu, demon telnetdîn cazul încercărilor de înregistrare nereușite, generează mesaje de categorie authpriv, iar în alte cazuri își clasifică postările demonul.
Al doilea parametru, pe baza căruia se formează valoarea câmpului PRI, este nivelul sau prioritatea mesajului (prioritatea), adică informații despre gradul de importanță a mesajului. 8 niveluri de severitate sunt setate ca standard (sunt definite și în fișier /usr/include/sys/syslog.h), care sunt codificate cu numere de la 0 la 7:
Masa 2.
| Valoare numerică | Simbol | Decriptare |
| 0 | emerg(nume vechi PANIC) | De urgență. Sistemul este inoperant. |
| 1 | alerta | Anxietate! Este necesară intervenția imediată. |
| 2 | crit | Eroare fatală (stare critică). |
| 3 | a greșit(nume vechi EROARE) | Mesaj de eroare. |
| 4 | avertizare(nume vechi WARN) | Un avertisment. |
| 5 | înștiințare | Informații despre un eveniment normal, dar important. |
| 6 | info | Anunţ. |
| 7 | depanare | Mesaje generate în timpul depanării. |
Camp PRI mesajul se formează astfel: valoarea numerică a categoriei se înmulțește cu 8 și se adaugă la valoarea numerică a priorității, numărul rezultat se încadrează între paranteze unghiulare și se scrie în câmp.
Urmărind câmpul PRI Următoarele câmpuri sunt incluse în mesaj:
- TIMESTAMP-UL- timpul de formare a mesajului,
- HOSTNAME- numele gazdei sau adresa IP în notație zecimală,
- MSG- textul arbitrar al mesajului - un șir de text (informațional) în codul US-ASCII (0x20 - 0x7e).
Ora (locală!) Este scrisă în formatul: 13 februarie 21:12:06. Dacă numărul zilei este un număr dintr-o singură cifră, atunci este plasat un spațiu suplimentar în fața acestuia (nu 0!). Atenție la absența anului și a zonei în dată, care trebuie luată în considerare la organizare depozitare pe termen lung fișiere jurnal. Pentru ca ora din mesaj să fie corectă, trebuie să fie sincronizată (de exemplu, folosind protocolul NTP).
Numele de gazdă este inclus în mesaj pentru a nu confunda mesajele de la diferite gazde, deoarece, așa cum se va arăta mai jos, înregistrarea poate fi efectuată pe unul dintre computerele dedicate din rețea. Numele de gazdă este numele de rețea simplu al computerului, fără a specifica domeniul. Dacă un computer are mai multe interfețe cu adrese IP diferite, atunci oricare dintre ele poate fi folosită ca nume sau adresă gazdă.
Mesaj text ( MSG) conține de obicei o etichetă ( ETICHETĂ), indicând către programul sau procesul care a emis acest mesaj și corpul mesajului ( CONŢINUT). Eticheta poate conține litere și cifre latine. De obicei, un nume de program simplu este folosit ca etichetă, uneori urmat de un identificator de proces, cuprins între paranteze drepte. Corpul mesajului este separat de etichetă prin caractere speciale - în Linux, acestea sunt de obicei două puncte și spațiu.
Gestionarea mesajelor Syslogd
Toate mesajele generate programe individuale folosind funcția syslog trimis prin socket / dev / log demonul de sistem syslogd care este responsabil pentru procesarea acestor mesaje. Trebuie să spun că, de fapt, pe sistem sunt lansate doi daemoni de înregistrare - syslogdși klogd... Ambii demoni sunt incluse în pachet sysklogd, cea mai recentă versiune o găsiți pe site.
Daemon klogd responsabil pentru înregistrarea evenimentelor care au loc în nucleul sistemului. Necesitatea unui demon separat klogd se explică prin faptul că nucleul nu poate folosi funcția standard syslog... Faptul este că bibliotecile standard (inclusiv biblioteca în care se află funcția syslog) sunt destinate utilizării numai de către aplicațiile obișnuite. Deoarece nucleul are nevoie și de funcții similare, acesta include propriile biblioteci care nu sunt disponibile pentru aplicații. Prin urmare, nucleul folosește propriul mecanism de generare a mesajelor. Daemon klogd este conceput pentru a organiza procesarea acestor mesaje. În principiu, el poate efectua o astfel de prelucrare complet independent și independent de syslogd, de exemplu, prin scrierea acestor mesaje într-un fișier, dar în majoritatea cazurilor se utilizează setarea implicită klogd unde toate mesajele din nucleu sunt redirecționate către același demon syslogd.
Pentru a vă asigura că demonii syslogdși klogd rulează pe sistemul dvs., executați comanda ps -ax | jurnal grep... Această comandă mi-a dat următorul rezultat:
$ ps -ax | jurnal grep 569? S 0:00 syslogd -m 0 574? S 0:00 klogd -x 1013? S 0:00 autentificare - kos 1191? S 0:00 kalarmd --login Primele două linii indică faptul că demonii de înregistrare rulează pe sistem.Daemon care gestionează mesajele syslogd constă în faptul că monitorizează constant apariția mesajelor și compară fiecare intrare primită cu regulile care se află în fișier /etc/syslog.conf... Fiecare regulă este scrisă ca o linie a fișierului /etc/syslog.conf format din două câmpuri. Câmpul din stânga ("selector") specifică unul sau mai multe șabloane prin care sunt selectate mesajele. Șabloanele sunt separate prin punct și virgulă (vezi fișierul exemplu de mai jos /etc/syslog.conf). Marja din dreapta („acțiune”) determină ordinea în care sunt procesate mesajele selectate. Câmpurile sunt separate prin unul sau mai multe spații sau file.
Fiecare șablon din câmpul „selector” are forma „category.level” (adică „facility.priority”). Valorile câmpului „categorie” pot fi:
- una dintre denumirile convenționale ale categoriilor enumerate în tabelul 1,
- mai multe astfel de nume (în acest caz sunt separate prin virgule)
- sau caracterul * (care înseamnă „toate categoriile”).
Valorile câmpului „nivel” pot fi:
- unul dintre denumirile condiționale ale nivelului enumerat în tabelul 2,
- caracter * (înregistrați toate mesajele din această categorie, indiferent de nivel),
- sau cuvânt nici unul(nu înregistrați mesaje din această categorie).
Specificarea unei anumite valori în câmpul „nivel” este interpretată ca „toate valorile de la acest nivel și mai sus”. Dacă trebuie să înregistrați mesaje de un singur nivel, atunci trebuie să puneți un semn egal ("=") în fața valorii specificate. Dacă doriți să înregistrați mesaje de toate nivelurile, cu excepția celui indicat, atunci înaintea numelui nivelului este plasat un semn de exclamare ("!"). Plasarea acestor două semne în același timp este interpretată ca „nu înregistrați mesaje de nivelul specificat sau mai mare”.
Literele mari și mici din câmpul „selector” nu diferă. De asemenea, puteți utiliza numere (consultați /usr/include/syslog.h). Pe lângă categoriile enumerate în tabelul 1, marcă(marcate temporale obișnuite) și Securitate(sinonim depreciat pentru auth). Pe lângă valorile prioritare enumerate în Tabelul 2, puteți utiliza a avertiza(sinonim pentru avertizare), eroare(sinonim pentru a greșit), panică(sinonim pentru emerg).
Când categoria și nivelul mesajului primit se potrivesc cu unul dintre șabloanele câmpului „selector” al unui șir, syslogd procesează înregistrarea în conformitate cu acțiunea specificată în câmpul „acțiune” din acest rând.
Câmpul „acțiune” poate conține
- trebuie specificate numele unui fișier obișnuit (fișier jurnal) și calea completă către fișier, începând cu rădăcina „/”, iar dacă fișierul specificat nu există, syslogdîl creează,
- numele conductei numite - FIFO; în acest caz, o bară verticală ("|") este plasată în fața numelui, iar canalul în sine trebuie creat înainte de a începe syslogd echipă mkfifo,
- indicând către un terminal sau o consolă (cum ar fi dispozitivul: / dev / tty1),
- o referință la gazda la distanță (precedată de simbolul @),
- sau o listă de utilizatori (separați prin virgule), către ale căror terminale se va trimite un mesaj conform acestei reguli. În locul listei de utilizatori, puteți pune un asterisc (*), ceea ce va însemna că mesajele sunt trimise tuturor utilizatorilor care lucrează în acest momentîn sistem.
Cel mai adesea, câmpul „acțiune” conține în continuare numele fișierului jurnal. Mai mult, puteți pune un semn minus ("-") în fața numelui fișierului, ceea ce va însemna că sistemul poate stoca fișierul în memoria cache-tampon și nu îl va goli după ce fiecare mesaj este scris pe disc. Acest lucru, desigur, accelerează munca, mai ales dacă în jurnal sunt înregistrate multe mesaje mari, dar poate duce la pierderea unor mesaje în cazul unui blocaj neașteptat al sistemului, adică exact atunci când astfel de mesaje sunt deosebit de necesare. . De asemenea, puteți specifica o imprimantă - / dev / lp0 ca dispozitiv în câmpul „acțiune”. Această opțiune de „acțiune” este indicată să se aplice în cazurile când este vorba de sisteme deosebit de importante. Protocoalele care sunt tipărite nu pot fi șterse sau modificate de hackeri, așa că aceasta este o utilizare bună pentru o veche imprimantă matriceală.
Pe lângă rândurile cu regulile din dosar /etc/syslog.conf poate conține linii goale și linii de comentarii care încep cu #. Mai multe despre structura fișierelor /etc/syslog.conf puteți citi pagina de manual syslog.conf pentru câteva exemple de intrări de reguli în acest fișier. Rețineți că atunci când specificați perechile „category.level” în fișier syslog.conf nu puteți folosi valorile numerice date în tabelele 1 și 2, sunt permise doar denumirile lor convenționale.
Dacă un mesaj se potrivește cu modelele a două sau mai multe linii, el va fi procesat conform fiecăreia dintre aceste reguli (adică procesarea mesajului nu se oprește la primul succes). Aceasta înseamnă că un număr arbitrar de acțiuni poate fi efectuat pentru un mesaj. Prin urmare, puteți atât să scrieți un mesaj într-un fișier jurnal, cât și să îl trimiteți către utilizator(i) sau către o gazdă de la distanță.
În plus, dacă în câmpul „selector” sunt listate mai multe perechi „category.level” (separate prin punct și virgulă), atunci perechile ulterioare pot anula acțiunea celor anterioare. Puteți vedea un exemplu de astfel de anulare în lista de fișiere de mai jos /etc/syslog.conf: toate mesajele cu nivel egal sau mai mare decât info sunt scrise în fișierul / var / log / mesaje, dar mesajele din categoriile mail, authpriv și cron sunt omise (nu sunt scrise).
| Listarea 1. Fișier /etc/syslog.conf dintr-un sistem construit pe baza kitului de distribuție Red Hat Linux 7.1 (tocmai am tradus în rusă comentariile conținute în acest fișier și am selectat cu aldine linii de regulă). |
| # Imprimați toate mesajele din nucleu pe consolă. # kern. * / dev / console# Înregistrați toate mesajele de nivel de informații sau mai mare, # cu excepția mesajelor de e-mail care conțin # mesaje confidențiale de autentificare și mesaje cron. * .info; mail.none; authpriv.none; cron.none / var / log / mesaje# Scrieți mesaje care conțin # informații confidențiale de autentificare într-un fișier separat, indiferent de nivelul lor. authpriv. * / var / jurnal / securizat# Toate mesajele sistemului de poștă ar trebui, de asemenea, înregistrate separat. mail. * / var / log / maillog# Înregistrați acțiunile demonului cron. cron. * / var / log / cron# Mesajele de urgență trebuie primite imediat # de către toți utilizatorii sistemului * .emerge *# Mesajele de la serviciile de știri de nivel critic și superior trebuie scrise într-un fișier separat. uucp, news.crit / var / log / spooler# Mesajele afișate în timpul fazei de pornire trebuie copiate în fișierul boot.log local7. * /var/log/boot.log |
Fișier jurnal / var / jurnal / mesaje
Desigur, nu există nicio modalitate de a spune aici despre conținutul fiecărei linii a acestui fișier. Pentru ca cititorul să-și facă o idee despre ce informații pot fi găsite în protocol, prezentăm rânduri separate de mesaje cu comentarii foarte scurte.
Fiecare linie din fișierul jurnal conține o singură înregistrare de mesaj, constând din următoarele câmpuri de mesaj, separate prin spații:
- data în format text standard (câmp TIMESTAMP-UL din posta syslog),
- numele gazdă (câmp HOSTNAME din posta syslog)
- textul mesajului (câmpuri ETICHETĂși CONŢINUT din posta syslog)
În primul rând, este de remarcat faptul că, dacă computerul nu funcționează non-stop, dar se oprește noaptea, atunci în acest fișier puteți găsi înregistrări ale mai multor „cicluri de lucru”, începând cu pornirea computerului și terminând cu oprirea acestuia. Un astfel de ciclu începe cu un mesaj despre începutul demonilor de logare (acest lucru este de înțeles, înainte de a fi început, mesajele nu au fost înregistrate):
17 septembrie 08:32:56 kos3 syslogd 1.4-0: reporniți. 17 septembrie 08:32:56 kos3 syslog: syslogd a reușit 17 septembrie 08:32:56 kernel kos3: klogd 1.4-0, sursa jurnal = / proc / kmsg a început. 17 septembrie 08:32:56 kernel kos3: Inspectarea /boot/System.map-2.4.2-2 17 septembrie 08:32:56 kos3 syslog: start klogd succeeded
Intrările din alte fișiere de protocol menționate în fișier au aproximativ aceeași structură. /etc/syslog.conf.
Comenzi logger și tailf
Din descrierea anterioară, putem concluziona că emiterea tuturor mesajelor pentru jurnalele de sistem ar trebui să fie setată de programator în etapa creării programului. Acest lucru nu este în întregime adevărat. Utilizatorul are și capacitatea de a trimite un mesaj demonului syslogd... Pentru a face acest lucru, Linux are o comandă logger, care oferă trimiterea unui mesaj din linia de comandă (sh, bash etc.). Este inclus în pachetul util-linux. Desigur, această comandă este destinată în primul rând să ofere capabilități de înregistrare în jurnal atunci când utilizatorul creează diferite tipuri de scripturi shell. Dar poate fi lansat și direct din linia de comandă, de exemplu, pentru a vă familiariza cu capacitățile sistemului de înregistrare. Format de lansare a comenzii: logger [-isd] [-f fișier] [-p PRI] [-t TAG] [-u socket] Parametrii liniei de comandă au următoarea semnificație:
- -i- includeți numărul procesului în mesaj
- -s- mesaj duplicat către stderr
- -d- utilizați modul datagramă atunci când trimiteți mesaje (în loc de streamingul obișnuit)
- -f nume de fișier- salvați mesajul în fișierul specificat (în mod implicit este utilizat / var / jurnal / mesaje)
- -p facilitate.nivel- setați categoria și prioritatea mesajului (implicit: user.notice)
- -t ETICHETĂ - setați câmpul TAG
- -u priza- trimiteți un mesaj la socket-ul specificat în loc să apelați syslogd
- MSG- Mesaj text
Trimiteți mai multe mesaje folosind programul loggerși admirați rezultatul din dosar / var / jurnal / mesaje(cu excepția cazului în care, desigur, ați schimbat valoarea implicită).
Apropo, există o modalitate foarte interesantă de a vizualiza mesajele scrise într-un fișier / var / jurnal / mesaje echipă logger... Această metodă se bazează pe utilizare program special coada... Deschideți o fereastră de terminal, obțineți drepturi de superutilizator (cu comanda su) și rulați comanda în această fereastră
tailf / var / jurnal / mesaje
După aceea, treceți la alt terminal și rulați comanda acolo logger arbitrary_text... Mesajul dvs. va apărea imediat în fereastra în care rulează programul coada... Adică, folosind acest program, administratorul de sistem poate monitoriza în timp real înregistrarea noilor mesaje în protocol. Adevărat, este puțin probabil ca administratorul de sistem să aibă timp să monitorizeze comportamentul sistemului în acest fel (cu excepția cazului în situații de urgență). Prin urmare, au fost dezvoltate programe speciale pentru analiza protocoalelor. Dar despre ei puțin mai jos, dar deocamdată să trecem la întrebarea cum să organizăm supravegherea unui computer de la distanță (vă amintiți cum l-ați prins pe atacatorul Shimomura?).
Înregistrare în rețea
După cum sa menționat, mesajele de jurnal pot fi trimise de un demon syslogd către gazda de la distanță. Dar cineva trebuie să accepte asta acolo. Se dovedește că același demon o face syslogd rulează pe această gazdă la distanță. Mai precis, syslogd pe orice computer, poate asculta nu numai pe soclul / dev / log (primind astfel mesaje din surse locale), ci și pe portul 514 / UDP, care asigură că mesajele de la alte computere din rețeaua locală sunt primite (și apoi scrise într-un fișier local). Acest lucru oferă posibilitatea de a crea un „server de jurnal”, care poate fi foarte convenabil pentru administratorul de sistem (toate evenimentele din rețea sunt monitorizate într-un singur loc) și, de asemenea, crește securitatea rețelei, deoarece mesajele despre pătrunderea unui hackerul către una dintre gazdele rețelei nu poate fi eliminat imediat din protocol de către acest hacker.
Cu toate acestea, este nevoie de un efort suplimentar pentru a configura această „înregistrare în rețea”.
În primul rând, deoarece portul 514 / UDP este folosit pentru a trimite și primi mesaje prin rețea, acesta trebuie să fie disponibil pe ambele computere (client și server). Pentru a face acest lucru, în fișier / etc / servicii linia trebuie să fie prezentă pe ambele computere
syslog 514 / udp
Dacă o astfel de linie in / etc / servicii absent, syslogd nu poate nici să primească mesaje, nici să le trimită în rețea deoarece nu poate deschide un port UDP. Dacă apare această situație, syslogdîncetează imediat scrierea oricăror mesaje, chiar și în jurnalul local. Mai mult, așa cum arată comanda ps, rămâne în memorie și chiar stochează mesaje în unele buffer-uri, deoarece dacă șirul " syslog 514 / udp " restaurați în fișier / etc / servicii pe client, atunci cel puțin unele dintre mesajele „lipsă” apar în continuare în jurnal (după repornire syslogd).
În al doilea rând, la pornirea demonului syslogd serverul trebuie să aibă opțiunea -r care oferă capacitatea de înregistrare la distanță (în mod implicit, demonul syslogd așteaptă doar mesajele de la priza locală). Cum și unde să setați această opțiune va fi descris mai jos, în secțiunea despre pornirea demonului. syslogd.
Ei bine, și în al treilea rând, setările din fișiere trebuie corectate în consecință. /etc/syslog.conf pe ambele computere. De exemplu, dacă doriți să redirecționați toate mesajele către serverul de înregistrare, trebuie să scrieți în fișierul de pe computerul client /etc/syslog.conf o linie ca aceasta:
*. * @hostname
Dacă în timpul începerii demonului syslogd serverul va fi indisponibil (de exemplu, este deconectat de la rețea în acest moment) sau nu va fi posibil să-l găsiți după nume (serviciul DNS nu a funcționat corect) syslogd face alte 10 încercări de a găsi serverul și numai dacă după aceea serverul nu poate fi găsit, oprește încercările și trimite un mesaj corespunzător.
Dacă rețeaua dvs. are mai multe domenii care sunt deservite de un server de înregistrare, atunci nu vă mirați că jurnalul de pe server va conține numele complete ale clienților (inclusiv domeniul). Adevărat, la pornire syslogd poti folosi optiuni -s lista_domenii sau -L listă de gazde, care asigură că protocolul înlocuiește numele de gazdă complet calificate cu numele lor scurte (fără a specifica un domeniu).
Nu uitați după ajustarea opțiunilor de pornire și a fișierului /etc/syslog.conf reporniți demonul, deoarece spre deosebire de cron, sysklogd nu recitește automat fișierele de configurare.
Opțiuni de pornire a demonului Syslogd
Deoarece am atins în subsecțiunea anterioară problema setării parametrilor pentru pornirea demonului syslogd, să aruncăm o privire mai atentă la această problemă. După cum sa menționat deja, ambii daemoni de înregistrare sunt porniți în etapa de inițializare a sistemului și, mai precis, printr-un script /etc/rc.d/init.d/syslog(pentru care, precum și pentru scripturile de pornire a altor servicii, se creează legături simbolice în directoarele /etc/rc.d/rc?.d/). Cu toate acestea, pentru a seta parametrii de pornire, nu este nevoie să ajustați acest script, deoarece începând cu versiunea 7.2 în distribuția Red Hat, opțiunile de pornire pentru ambii demoni sunt citite dintr-un fișier de configurare separat. / etc / sysconfig / syslog... Iată o listă scurtă de parametri posibili pentru demon syslogd.Parametri de lansare syslogd:
- -o priză- Specifică un socket suplimentar pe care demonul va asculta syslogd... Puteți specifica până la 19 socket-uri (se pot specifica mai multe, dar trebuie să recompilați pachetul). Această opțiune este folosită atunci când un alt demon (cum ar fi ftp sau http) rulează într-un mediu restricționat (făcând chroot).
- -d- Modul de depanare. În acest caz, demonul nu trece în fundal și trimite toate mesajele către terminalul curent.
- -f nume_fișier_configurație Specifică numele unui fișier de configurare alternativ care va fi utilizat în locul celui implicit /etc/syslog.conf.
- -h Implicit în sysklogd transmiterea mesajelor primite prin rețea către un alt computer este interzisă. Acest lucru se face pentru a evita transferurile nesfârșite de mesaje în jurul inelului. Opțiunea -h vă permite să schimbați comportamentul obișnuit și să vă asigurați că mesajele primite de la gazde la distanță sunt transmise de-a lungul rețelei (și aveți grijă de posibila buclă).
- -l listă de gazde- Specifică o listă de gazde, ale căror nume nu trebuie înregistrate cu indicarea numelui complet al domeniului (FQDN - Full Qwalified Domain Name); numele din listă sunt separate prin două puncte.
- -m minute A început fără această opțiune sysklogdînregistrează în mod regulat (la fiecare 20 de minute) mesajele categoriei marcă, adică doar mărci de timp. Cu optiunea -m puteți fie să modificați intervalul dintre semne, fie să anulați complet emiterea unor astfel de mesaje, pentru care trebuie să setați un interval zero: -m 0.
- -n Nu treceți în fundal; această opțiune este necesară când syslogd este pornit și controlat de un proces init.
- -p priza Specifică un socket UNIX alternativ (în loc de ascultarea implicită / dev / log). Vă rugăm să rețineți: opțiune -A specifică prize suplimentare și -p- alternativă!
- -r Permiteți primirea mesajelor de la gazde la distanță. Am vorbit despre asta în secțiunea anterioară, așa că omit detaliile.
- -s lista de domenii Specifică o listă de domenii ale căror nume nu trebuie înregistrate împreună cu numele gazdei (adică, pentru aceste domenii, numai numele gazdei vor fi înregistrate în loc de numele de domeniu complet calificat (FQDN). Numele din listă sunt separate. prin două puncte.Numele domeniului unde se află serverul syslogd) , nu este necesar să fie specificat în această listă (numele său este eliminat implicit).
- -v Afișați versiunea și ieșiți.
- -X Interziceți determinarea numelui gazdei după adresa sa, previne blocajul atunci când lucrați pe aceeași gazdă cu serverul DNS.
După ce a pornit demonul syslogd este creat un fișier de stare / var / blocare / subsys / syslog lungime zero și fișier cu ID-ul procesului /var/run/syslogd.pid.
Folosind comanda
kill -SIGNAL `cat / var / run / syslogd.pid`
poți trimite la demon syslogd unul dintre următoarele semnale:
- SIGHUP - reporniți demonul (reinițializare); toate fișierele deschise sunt închise, demonul pornește de la capăt, recitindu-și fișierul de configurare.
- SIGTERM - oprire.
- SIGINT, SIGQUIT - dacă modul de depanare este activat (opțiunea -d), semnalele sunt ignorate, în caz contrar - ieșire.
- SIGUSR1 - activați / dezactivați modul de depanare (funcționează numai dacă demonul a fost pornit cu comutatorul -d).
Daemon klogd nu are mai puține opțiuni de pornire decât syslogd, dar nu le vom enumera aici, trimitând cititorul la pagina de manual corespunzătoare (utilizatorul nu ar trebui să fie implicat în setarea klogd, este mai bine să-l lăsați în aceeași stare în care a fost produs de dezvoltatorii kitului de distribuție).
Fișierul Dmesg și comanda dmesg
După cum sa menționat, fișierele jurnal la care se face referire în fișier /etc/syslog.conf se află de obicei în director / var / logși subdirectoarele sale. Dar, dacă ne uităm în acest director, atunci vom găsi acolo câteva fișiere, care în /etc/syslog.conf nu au fost mentionate. Să aruncăm o privire asupra scopului lor. Și să începem cu fișierul dmesg.În primul rând, trebuie menționat că Linux are o comandă cu același nume. Dacă comparați rezultatul acestei comenzi (când este rulat fără parametri) cu conținutul fișierului / var / log / dmesg, veți descoperi că sunt foarte asemănătoare, deși nu identice (transmiteți ieșirea comenzii la fișier dmesg2și compara fișiere dmesgși dmesg2). Mai exact, dosarul / var / log / dmesg one to one coincide cu începutul ieșirii pe care o vom primi prin comandă dmesg... După cum urmează din nucleu, există un buffer inel în care sunt scrise mesajele de la demonul de înregistrare a nucleului. Acele mesaje care sunt scrise în acest buffer în timpul procesului de încărcare și alcătuiesc conținutul fișierului / var / log / dmesg... Aparent, acest fișier este generat la sfârșitul pornirii sistemului.
Dacă vă uitați din nou la lista de fișiere de mai sus /etc/syslog.conf atunci vei vedea că toate postările din categorie kern sunt de asemenea emise către consolă. Dar acolo trec repede pe ecran și cu greu ai timp să le citești și să le înțelegi. Dar sunt salvate în fișier / var / log / dmesgși astfel sunt disponibile pentru înțelegere pe îndelete (dacă procesul de descărcare s-a încheiat cu succes). După încheierea procesului de pornire, scrierea mesajelor din nucleu în buffer-ul circular continuă. Când comanda este executată dmesg, este afișată starea curentă a tamponului. Prin urmare, rezultatul acestei comenzi conține mai multe mesaje decât fișierul / var / log / dmesg: în rezultatul acestei comenzi, vedeți și mesajele pe care nucleul le emite după încheierea procesului de pornire.
Toate mesajele de la / var / log / dmesg veti gasi in dosar / var / jurnal / mesaje, doar acolo alternează cu mesaje din alte programe. Există o singură diferență semnificativă: în dosar dmesg ora și sursa mesajului (numele de gazdă și categoria mesajului) nu sunt specificate. Gazda este întotdeauna „locală” aici, iar începerea numărătorii inverse este determinată de ultima repornire a computerului.
Fișierele Lastlog, wtmp și utmp
Pe langa dosar dmesgîn catalog / var / jurnal / mai sunt două fișiere care nu sunt menționate în /etc/syslog.conf, dar direct legate de înregistrare - acestea sunt fișiere ultimul butucși wtmp... Dar uitându-ne la ele este la fel cum ne uitam noi la dosar / var / jurnal / mesaje nu are sens - nu vei înțelege nimic. Faptul este că informațiile din aceste fișiere sunt înregistrate într-un format special și trebuie vizualizate folosind instrumente software speciale. Dar mai întâi, trebuie spus câteva cuvinte despre scopul acestor fișiere.
Fişier ultimul butuc stochează informații despre ultimul utilizator conectat la sistem. Nu știu dacă ați observat că atunci când introduceți numele de utilizator și parola, pe ecran apare următorul mesaj:
Conectare localhost: kos Parola: Ultima conectare: miercuri 9 octombrie 19:25:53 pe tty1 Aceste trei linii sunt generate de utilitar Autentificare, care, după ce a stabilit că utilizatorul are dreptul de a se autentifica, accesează fișierul / var / log / lastlog, preia informații despre autentificarea anterioară cu succes a utilizatorului de acolo, le imprimă pe ecran și apoi actualizează intrarea din fișier ultimul butuc... Puteți suprima acest mesaj creând un fișier .hushlogin gol în directorul dvs. de acasă. Cu toate acestea, nu este recomandat să faceți acest lucru, mai degrabă, dimpotrivă, ar trebui să acordați o atenție deosebită conținutului acestui mesaj pentru a nu rata cazurile în care altcineva a intrat în sistem sub numele dvs.
Spre deosebire de fișier / var / log / lastlog care conține înregistrări ale timpului ultimul autentificarea fiecărui utilizator, în fișier / var / log / wtmp sunt amintite toate autentificarea și deconectarea utilizatorilor de când a fost creat acest fișier. Ca în dosar ultimul butuc, intrări în / var / log / wtmp sunt realizate într-un format special, deci pot fi vizualizate numai folosind comenzi speciale. Dar, înainte de a vorbi despre aceste comenzi, să spunem că există un alt fișier care conține intrări despre înregistrarea utilizatorilor - acesta este fișierul / var / run / utmp... Acest fișier conține informații despre ce utilizator este conectat în prezent în sistem.
Acum puteți vorbi despre cum să vizualizați informații despre utilizatorii care lucrează în prezent sau care lucrează anterior în sistem. Comanda principală pentru aceasta este comanda ultimul... Scoate toate înregistrările din fișier / var / log / wtmp, mai mult, sunt indicate numele de utilizator, o indicare a terminalului de la care utilizatorul a lucrat, ora la care utilizatorul a intrat in sistem si ora la care sa deconectat, precum si durata sesiunii utilizatorului in sistem. Dacă munca utilizatorului a fost întreruptă doar din cauza închiderii sistemului, se folosește cuvântul „jos” în locul timpului de ieșire al utilizatorului (aceste linii pot determina cu ușurință timpul de oprire a sistemului). Ora de repornire este afișată pe rânduri separate, începând cu cuvântul „repornire”.
Comanda ultimulb ca o echipă ultimul dar afișează informații despre încercările de conectare nereușite ale utilizatorilor. Cu toate acestea, trebuie remarcat că această comandă va funcționa numai dacă fișierul există. / var / log / btmp... Cu toate acestea, niciunul dintre programele discutate aici nu creează fișiere jurnal, așa că dacă vreunul dintre ele este șters, atunci înregistrarea se termină.
Comanda ultimul butuc formatează și scoate conținutul fișierului / var / log / lastlog... Câmpurile vor fi numele de utilizator, numele terminalului de la care utilizatorul s-a autentificat și ora ultimei autentificări la sistem. În mod implicit (când comanda este introdusă fără parametri) elemente de fișier / var / log / lastlog va fi afișat în ordinea numerelor ID utilizator. Dacă specificați parametrul -u login-name, vor fi afișate numai informații despre ora ultimei autentificări a utilizatorului specificat. Specificând parametrul -t zile, veți obține doar înregistrări din ultimele zile. Dacă utilizatorul nu s-a autentificat deloc în sistem, atunci șirul „** Niciodată autentificat **” va fi indicat în locul numelui terminalului și al orei ultimei autentificări.
La executarea comenzii ultimul butuc pe un computer lent, în unele cazuri poate părea că comanda este blocată. Acest lucru se întâmplă din cauza faptului că, chiar dacă în sistem sunt înregistrați doar doi utilizatori (rădăcină și utilizator), în fișier / var / log / lastlog mai este loc pentru cât mai mulți utilizatori care pot lucra la sistem. Prin urmare, în dosar / var / log / lastlog pot exista decalaje mari între numerele de identificare ale utilizatorilor conectați în sistem. Deoarece la vizualizarea unor astfel de intervale, programul nu afișează informații pe ecran și apare impresia de „îngheț”.
Pentru a afișa informații despre cine lucrează în prezent în sistem, utilizați comenzile w, careși utilizatorii... Comanda utilizatorii este folosit atunci când doriți doar să știți care dintre utilizatori lucrează în prezent în sistem, dar nu sunteți interesat de ce terminal s-a conectat și ce face. Dacă vrei să știi cine s-a conectat de pe ce terminal, folosește comanda care... Această comandă scoate informații dintr-un fișier / var / run / utmp... Puteți face ca acesta să scoată date dintr-un fișier / var / log / wtmp(sau orice alt fișier pentru care are sens) dacă specificați numele acelui fișier pe linia de comandă. Dar în ieșire, veți vedea în continuare doar numele de utilizator, o indicație a terminalului de la care utilizatorul s-a autentificat, ora de conectare și, dacă v-ați autentificat de la un computer la distanță, numele computerului respectiv.
Comandă afișează mult mai multe informații w... În rezultatul său, veți vedea ora curentă, cât timp a funcționat sistemul, câți utilizatori lucrează în prezent în sistem și încărcarea medie a sistemului pentru ultimul minut, 5 și 15 minute. Apoi, pentru fiecare utilizator, tipărește:
După cum am menționat deja, comanda w scoate informațiile stocate într-un fișier utmp... Apropo, ghidul om afirmă că utilizatorilor obișnuiți ar trebui să li se refuze accesul la scriere la fișier utmp din moment ce multi programe de sistem(din anumite motive inexplicabile) depind de integritatea sa. Experiți riscul de a confunda fișierele cu statistici de sistem și de a face modificări la fișierele de sistem dacă permiteți oricărui utilizator să scrie într-un fișier utmp.
Fișierele jurnal ale altor programe
Pe lângă fișierele pe care le-am descris deja, există și alte fișiere de protocol care sunt create de programe separate. Cele mai tipice exemple sunt protocoalele demonilor. samba, ftpd sau httpd care sunt păstrate în dosare separate. Unele dintre aceste programe își creează protocoalele în subdirectoare ale directorului / var / jurnal / alții păstrează protocoalele în altă parte. Și structura acestor fișiere poate diferi semnificativ de structura fișierelor create de sistem. syslog... De exemplu, voi da câteva rânduri din jurnalul serverului Apache rulează pe computerul meu: 192.168.36.21 - - "GET / ve / documente / nou / jurnal / 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 / 20002002 192.168.36.21 - -" GET /ve/papers/new/log/protok_lovim.htm HTTP / 1.1 "200 46597" http: // linux / ve / documente / 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 / lo g / 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 "" Mozillatm /5.0 (X11; U; Linux i686; ru-RU; rv: 1.0.0) Gecko / 20020530 „După cum puteți vedea, structura acestui fișier jurnal este semnificativ diferită de ceea ce am văzut în jurnalele de sistem.Serverul Samba, pe lângă protocolul de operare al serverului principal, creează în subdirector / var / log / samba un număr de fișiere jurnal pentru cazuri diferite, în special fișiere separate pentru fiecare dintre utilizatorii cărora li se permite să utilizeze resursele furnizate de acest server. Următoarele două înregistrări sunt preluate dintr-un astfel de fișier:
Smbd / service.c: make_connection (550) linux (192.168.36.10) se conectează la service public ca utilizator kos (uid = 500, gid = 500) (pid 1366) smbd / service.c: close_cnum (550) linux (192.168. 36.10) conexiune închisă la serviciul public Aceste exemple arată că, dacă poți citi puțin în engleză și înțelegi puțin structura înregistrărilor, poți extrage o mulțime de informații utile din fișierele jurnal. Numai că trebuie extras din depozite întregi de „rocă sterilă” - fișiere jurnal secvențiale uriașe, care este o sarcină nebanală. Prin urmare, au fost dezvoltate instrumente software speciale pentru analiza protocolului.
Instrumente pentru procesarea protocoalelor
Au fost dezvoltate o mulțime de programe și scripturi diferite pentru analiza protocolului. mă voi limita descriere scurta doua astfel de mijloace: ceas de jurnalși eșantion.
ceas de jurnal este un script Perl inclus cu distribuția standard Red Hat Linux. Chiar în timpul pregătirii acestui articol, versiunea 4.1 a acestui program a fost lansată pe site-ul web al dezvoltatorului (și el este Kirk Bauer).
Ideea principală din spatele acestui program este că fișierul jurnal este trecut printr-un filtru care extrage din jurnal toate liniile (adică mesajele) care îndeplinesc un anumit criteriu. Rezultatele sunt trimise prin e-mail utilizatorului specificat (implicit este root). Filtrele pot fi scrise în orice limbaj de programare, dar autorul pachetului preferă Perl. Filtrele ar trebui scrise astfel încât să citească datele din stdin și să scoată rezultatul în stdout.
Principala modalitate de utilizare ceas de jurnal constă în includerea unui link către scriptul principal ( /etc/log.d/scripts/logwatch.pl) în directorul /etc/cron.daily, care determină execuția zilnică ceas de jurnal cu parametrii impliciti. Link-ului i se dă un nume care începe cu „00” (de exemplu, 00-logwatch), astfel încât scriptul să ruleze înainte de logrotate.
Dar puteți rula scriptul și din linia de comandă. Desigur, dacă nu ați modificat parametrul de ieșire a informațiilor, atunci rezultatul muncii sale ar trebui căutat în căsuța poștală a superutilizatorului. Dacă doriți să vedeți aceste rezultate pe ecran, atunci trebuie să setați parametrul liniei de comandă --imprimare- emite un raport către stdout.
Format general de lansare a scriptului:
/etc/log.d/scripts/logwatch.pl [--detail nivel ] [--fișier jurnal jurnalele de grup ] [--serviciu numele serviciului ] [--print] [--mailto abordare ] [--Salvați Nume de fișier ] [--arhive] [--gamă data-interval ]
Parametrii impliciti sunt stocați în fișierul /etc/log.d/logwatch.conf, comentariile în care vă permit să înțelegeți semnificația parametrilor liniei de comandă:
- LogDir - directorul relativ la care sunt luate în considerare numele fișierelor;
- MailTo - cui să trimită raportul;
- Imprimare - în loc să trimiteți un raport prin poștă, emiteți-l către stdout;
- Salvați - în loc să trimiteți raportul prin poștă, salvați-l în fișierul specificat;
- Arhive - procesează nu numai versiunile curente ale jurnalelor, ci și copiile vechi create de logrotate;
- Interval - procesează intervalul de timp specificat: Toate, Azi, Ieri (ziua calendaristică de ieri);
- Detaliu - nivelul de detaliu al raportului: de la 0 la 10 sau Low, Med, High;
- Service - Toate sau numele filtrului din /etc/log.d/scripts/services/ (pot fi specificate mai multe filtre);
- LogFile - Toate sau numele grupului de jurnal (pot fi specificate mai multe grupuri).
Mai multe informații despre scenariu ceas de jurnal vei gasi in.
Acest articol descrie un alt script pentru procesarea fișierelor jurnal care este inclus cu distribuția Mandrake Linux. Acest script se numește eșantion("Simple WATCHer") și este scris și în Perl.
Managementul muncii eșantion efectuate folosind un singur fișier de configurare, implicit $ HOME / .swatchrc... Acest fișier conține text exemplu (sub formă de expresie regulată) care eșantion va căuta în fișierele jurnal. Fiecare astfel de tipar este urmat de o acţiune care eșantion ar trebui să ia dacă găsește text care se potrivește cu modelul.
De exemplu, este posibil să doriți să primiți un avertisment de fiecare dată când încercați un atac de depășire a tamponului pe serverul dvs. web pentru un nume de fișier foarte lung. Și știți că în astfel de cazuri în fișierul jurnal /var/apache/error.log apare un mesaj cu cuvintele „Nume fișier prea lung”. În acest caz, la dosarul dvs .swatchrc trebuie inserată următoarea notă:
Watchfor / Numele fișierului este prea lung / e-mail [email protected], subiect = BufferOverflow_attempt
Nu voi da aici o descriere mai detaliată a programului. eșantion... Un articol entuziast îi este dedicat, iar programul în sine poate fi găsit pe site. Aș dori doar să notez și eșantion, și ceas de jurnal implementați un algoritm destul de primitiv pentru procesarea fișierelor de protocol, care se rezumă la căutarea protocolului pentru un șir de caractere dat (semnătură). Între timp, în primul rând, prezența unei astfel de linii adesea nu indică încă un intrus și, în al doilea rând, un atacator competent poate avea grijă să ștergă urmele activităților lor. Un alt dezavantaj evident al produselor revizuite este că funcționează în „mod întârziat”, deoarece sunt lansate doar în termen. Iar lupta împotriva intrușilor trebuie să se desfășoare „în timp real”, reacționând imediat la încercările de pătrundere în sistem. Prin urmare, produsele comerciale oferă sisteme de monitorizare care funcționează constant și implementează algoritmi „inteligenți” pentru analiza protocoalelor. Acești algoritmi se bazează pe o analiză statistică a fluxului de mesaje și pe identificarea abaterilor semnificative statistic ale sistemului de la comportamentul său normal.
În încheierea acestei secțiuni, aș dori să observ că site-ul web SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) conține o listă de link-uri către site-urile diferitelor instrumente software pentru procesarea protocoalelor cu o scurtă descriere a acestor instrumente. Puteți experimenta cu diferite programe și alegeți pe cel care vi se potrivește.
Rotirea fișierelor jurnal
Desigur, veți înțelege că, dacă sistemul este utilizat intens, atunci fișierele jurnal cresc rapid. Ceea ce implică o risipă de spațiu pe disc. Și se pune problema „îmblânzirii” protocoalelor. Red Hat Linux remediază această problemă cu scripturile. logrotate care se află în director /etc/cron.daily, și, prin urmare, este pornit de demon cron zilnic. Acest script vă permite să procesați mai mult decât doar jurnalele de sistem syslog, dar și orice alte programe.Scenariul logrotate monitorizează creșterea fișierelor jurnal și asigură așa-numita rotație a acestor fișiere dacă acestea au depășit dimensiunea specificată (sau după expirarea intervalului de timp specificat). Rotirea nu este altceva decât copierea secvențială a versiunilor anterioare ale fișierelor de arhivă, ceva de genul acesta:
și crearea unui nou fișier de mesaje pentru a înregistra mesajele ulterioare.
Lista fișierelor care urmează să fie procesate de script logrotate iar parametrii acestei prelucrări sunt determinați de fișierele de configurare, dintre care pot fi mai multe. Numele fișierelor de configurare sunt setate în linia de comandă a lansării scriptului (vezi mai jos pentru parametrii de lansare). Pe Red Hat Linux, fișierele de configurare implicite pentru logrotate fisierul folosit /etc/logrotate.conf, care poate arăta cam așa:
Rotiți săptămânal 4 create compress include /etc/logrotate.d / var / log / wtmp / var / log / lastlog (creați lunar 0664 root utmp rotate 1)
Acest fișier este ca orice fișier de configurare pentru script. logrotate constă din mai multe secțiuni. Prima secțiune definește parametri globali (unul pe linie) care stabilesc parametrii impliciti pentru toate jurnalele. Următoarele secțiuni definesc parametrii locali pentru o serie de fișiere jurnal. Numele acestor fișiere sunt listate în prima linie a secțiunii, iar apoi parametrii locali sunt setați în acolade care sunt eficienți numai la procesarea fișierelor specificate (tot un parametru pe linie). Numele fișierelor jurnal pot fi citate de regulile shell dacă conțin spații sau alte caractere speciale. Puteți specifica mai multe nume de fișiere sau modele de nume de fișiere separate prin spații (modelele urmează, de asemenea, regulile shell). Procesarea fiecărei secțiuni este tratată ca o singură acțiune. Liniile care încep cu caracterul „#” sunt comentarii. Parametrii locali au prioritate față de parametrii globali.
În exemplul dat al fișierului de configurare, sunt descriși mai întâi parametrii globali, iar apoi, într-o secțiune separată, parametrii pentru procesarea fișierelor / var / log / wtmp și / var / log / lastlog. În plus, printre parametrii globali, este dat un link către director /etc/logrotate.d, în care fiecare pachet scrie parametri locali pentru jurnalele sale.
În secțiunea parametrilor globali, în primul rând, este specificat unul dintre următorii parametri, care determină criteriul de rotație a fișierelor:
și parametru include urmat de numele altui fișier de configurare (suplimentar) sau chiar de numele unui director. În acest din urmă caz, toate fișierele din directorul specificat, cu excepția subdirectoarelor, fișierelor speciale și fișierelor cu sufixe din lista de excluderi, sunt considerate fișiere de configurare pentru script. logrotate(directivă include nu poate fi utilizat în interiorul unei secțiuni care specifică parametrii de procesare pentru un grup de fișiere).
Parametru roti număr poate fi găsit atât printre parametrii globali cât și printre cei locali și determină câte versiuni vechi trebuie păstrate; dacă numărul este 0, atunci versiunile arhivate ale protocolului nu sunt create.
Dacă parametrul este setat comprima apoi versiunile vechi sunt comprimate folosind gzip, iar dacă este specificat nocompress- nu se micsoreaza. Parametru comprescmd vă permite să specificați ce program de compresie va fi utilizat (gzip în mod implicit) și uncompresscmd setează programul de decompresie (ungzip implicit). opțiuni de compresie setează parametrii programului de compresie; implicit este „-9”, adică compresie maximă pentru gzip. Folosind parametrul compresext puteți schimba sufixul pentru fișierele comprimate și parametrul extensie sufix specifică sufixul de adăugat la numele fișierelor în timpul rotației (înainte de sufixul de compresie).
Printre cuvintele cheie găsite în fișierele de configurare, cuvintele postrotateși prerotate care servesc drept paranteze deschise pentru includerea scripturilor shell în fișierele de configurare. Toate liniile fișierului de configurare din linie postrotate la linie script final sunt executate ca comenzi shell după procesul de schimbare a versiunii fișierului jurnal. În consecință, toate liniile din linie prerotate la linie script final sunt executate înainte de rotația fișierelor jurnal. Cu ajutorul acestor scripturi, puteți organiza diverse proceduri de procesare a fișierelor jurnal în timpul rotației.
Folosind alți parametri ai fișierului de configurare, puteți suprascrie drepturile de acces la fișierele jurnal (dacă acest parametru nu este specificat, se folosesc atributele vechiului fișier jurnal); indicați cui să trimiteți mesaje despre erori în funcționarea sistemului de logare; trimiteți o copie de arhivă a jurnalului utilizatorului specificat; setați directorul în care vor fi mutate protocoalele în timpul schimbării versiunii (directorul trebuie să fie localizat pe același dispozitiv fizic as / var / log) sau specificați o listă de sufixe de excludere pentru director include... O descriere detaliată a acestor caracteristici și parametri (precum și a celor care nu au fost menționate) poate fi găsită sub comanda man logrotate.
După cum am menționat deja, fișiere de configurare suplimentare logrotate poate fi specificat pe linia de comandă a lansării scriptului. Puteți specifica un număr arbitrar de nume pentru fișierele de configurare sau directoare. Numele fișierelor și directoarelor din această listă sunt pur și simplu separate prin spații. Ordinea numelor din listă este importantă deoarece parametrii specificați în următorul fișier de configurare suprascriu valorile parametrilor specificati în dosarul anterior... Ordinea fișierelor din directorul de configurare este nedefinită.
În plus, următorii parametri pot fi specificați pe linia de comandă de pornire:
- -d- modul de depanare, nu se fac modificări reale,
- -f- face modificări chiar dacă logrotate nu vede nevoia - este utilizat atunci când există modificări în lista de jurnalele procesate,
- om ceas de jurnal
- Mick Bauer, „Paranoid Penguin: swatch: Automated Log Monitoring for Vigilant but Lazy”
- RFC 3164. C. Lonvick, Protocolul BSD Syslog, august 2001.
- RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, noiembrie 2001.
- Pe. S.Lapshansky, „Demonul urmărește sistemul”
- Denis Kolisnichenko,
Protocolul syslog și software-ul de asistență asigură că informațiile despre evenimente sunt scrise în jurnalul de sistem (jurnale, consola de sistem), precum și transmise către serverul de înregistrare prin rețea, sortate și procesate în funcție de sursa și gravitatea mesajelor. Acest articol descrie protocolul syslog, implementarea lui în Solaris și Linux (syslogd), Cisco IOS și instrumente auxiliare: logrotate, logwatch.
Componentele sistemului sunt un generator de mesaje (dispozitiv sau proces), un protocol de schimb, un colector de mesaje (colector, server syslog), relee (releu, primește mesaje de la unul sau mai multe generatoare și transmite către unul sau mai mulți colectori sau releele următoare). Generatorul (sau releul în timpul transmisiei) nu știe dacă receptorul este un releu sau un colector, poate transmite un mesaj către mai mulți receptori, poate procesa mesajul în sine (de exemplu, prin scrierea într-un fișier).
Protocolul syslog nu oferă nicio protecție împotriva falsificării mesajelor. Chiar mai rau, utilizarea protocolului UDP permite atacatorilor să trimită mesaje în numele oricărei gazde. Rețeaua locală trebuie protejată de un ecran (IOS ACL, ipchains) împotriva primirii de pachete cu adrese locale false (deși acest lucru nu împiedică trimiterea de mesaje false din interiorul rețelei locale) și a primirii pachetelor din exterior pe portul 514/udp. Există cazuri cunoscute de depășire a discului cu mesaje false.
Protocolul syslog și UDP nu oferă livrare garantată (mesajele pot fi pierdute în timpul congestionării rețelei sau interceptate, mesajele corupte sunt șterse fără avertisment), secvență de livrare corectă (mesajul despre sfârșitul procesului poate veni înainte de mesajul despre începerea acestuia) , livrare prioritară.
Mesajele nu sunt păstrate confidențiale deoarece sunt transmise în text clar.
Dacă, la configurarea generatorului de mesaje, specificați adresa greșită a colectorului sau releului, atunci nu vor fi mesaje de eroare - mesajele vor fi șterse (sau scrise în jurnalul altcuiva;).
Nu sunt prevăzute mijloace de protecție împotriva transmiterii în buclă a mesajelor prin relee configurate incorect.
RFC 3195 propune un nou protocol peste TCP (syslog-conn, 601) pentru a asigura livrarea în secvența corectă. Implementarea nu este cunoscută de mine. Un amestec monstruos de XML, comenzi în stil SMTP și coduri de returnare și anteturi MIME (BEEP) împachetate în mesaje syslog standard. Sunt utilizate două moduri - RAW (analogic al protocolului UDP actual) și COOKED (mesajele sunt structurate pe câmpuri). BEEP permite autentificarea, integritatea și confidențialitatea (SASL, TLS).
Proiectul RFC syslog-sign propune să ofere autentificare, ordonare, integritatea mesajelor și detectarea mesajelor lipsă prin generarea de mesaje speciale care conțin o semnătură digitală a unui bloc de mesaje anterioare, păstrând protocolul și formatul standard syslog și folosind UDP. Folosit de SHA1, OpenPGP DSA.
Portul 514 / UDP este folosit pentru a primi mesaje. De asemenea, este recomandat să utilizați portul sursă 514 pentru mesagerie. Mesajul este un șir de text și nu poate avea o lungime mai mare de 1024 de octeți, altfel este permis să fie trunchiat sau chiar aruncat. Chiar și un mesaj malformat trimis la portul 514 ar trebui considerat un mesaj syslog. Totuși, dacă releul transmite mesajul mai departe, atunci trebuie să-i adauge antete standard (în același timp, eventual tăindu-l la 1024 de octeți) - UTILIZATOR, NOTIFICARE, ora locală și numele simplu al sursei mesajului.
Mesajul începe cu un câmp PRI care a codificat facilitatea și nivelul de severitate al mesajului. Este urmat de timp (TIMESTAMP), spațiu, numele gazdei sau adresa IP în notație zecimală (HOSTNAME), spațiu, text mesaj arbitrar (MSG) în US-ASCII (0x20 - 0x7e).
Numele de gazdă (simplu, nu FQDN!) Este scris așa cum este cunoscut generatorului de mesaje. Dacă dispozitivul are mai multe interfețe cu adrese IP diferite, atunci oricare dintre ele poate fi folosită ca nume sau adresă gazdă.
Textul mesajului (MSG) conține de obicei o etichetă (TAG) care identifică programul sau procesul care a emis mesajul și corpul mesajului (CONTINUT). Eticheta poate conține litere și cifre latine. Începutul corpului mesajului este identificat prin primul caracter special, de obicei două puncte sau paranteze pătrate de deschidere. De exemplu, Cisco IOS folosește un număr de mesaj secvențial urmat de două puncte ca etichetă, iar Unix folosește un nume simplu de program (corpul mesajului începe cu numărul procesului între paranteze drepte și două puncte).
syslogd primește mesaje de la portul 514/UDP și din surse locale (socket/dev/log), le direcționează în funcție de sursa mesajelor și de nivelul de severitate. Vă permite să trimiteți mesaje în jurnal, să trimiteți către consolă, către terminal, să trimiteți către un alt server. Se introduce o sursă suplimentară de tip MARK (marcaje regulate, informații)
Fiecare linie a jurnalului conține o singură înregistrare de mesaj, constând din câmpuri separate prin spații:
- data în format text standard (câmpul TIMESTAMP din mesajul syslog)
- nume de gazdă (fqdn sau prescurtare, câmp HOSTNAME din mesajul syslog)
- textul mesajului (câmpurile TAG și CONTENT din mesajul syslog)
Parametri de lansare:
- -A priză-de-ascultare suplimentară (util pentru demonii care fac chroot; pot fi mai mulți)
- -d(modul de depanare)
- -f config-file-name (Mod implicit, /etc/syslog.conf)
- -h(schimbați comportamentul obișnuit prin care mesajele primite de la gazde la distanță nu sunt redirecționate pentru a fi scrise către gazda la distanță pentru a evita bucla)
- -l listă-gazdă (lista de gazde ale căror nume nu trebuie scrise ca FQDN; separate prin două puncte)
- -m minute (interval pentru înregistrările temporare obișnuite; implicit - 20; dacă 0, atunci nu faceți deloc)
- -n
- -p priză de ascultare (Mod implicit: / dev / log)
- -r(permite primirea de mesaje de la gazde la distanță; firewall-ul ar trebui să fie ușor deschis; syslog pentru 514 / udp ar trebui să fie definit în / etc / services)
- -s lista de domenii (eliminați numele domeniilor specificate de numele de gazdă; separate prin două puncte; în mod implicit, domeniul care se potrivește cu domeniul serverului syslog este trunchiat)
- -v
- -X(interzice determinarea numelui de gazdă după adresa sa, previne blocajul atunci când lucrați pe aceeași gazdă cu serverul DNS)
Fișiere utilizate:
- /etc/syslog.conf- fișier de configurare (modificat la pornire prin parametru -f)
- / dev / log- socket din care sunt citite mesajele locale (schimbat la pornire de parametru -p)
- /var/run/syslogd.pid- ID proces
Reacția la semnale:
- SIGHUP - reinițializare (închide toate fișierele, citește din nou fișierul de configurare)
- SIGTERM - oprire
- SIGINT, SIGQUIT - ieșiți dacă depanarea este dezactivată
- SIGUSR1 - activați / dezactivați depanarea (numai când utilizați comutatorul -d)
Rulează ca root. Nu modifică permisiunile pentru fișiere. Dacă este forțat să creeze un fișier, o face cu permisiuni 644. Dacă este necesar să restricționeze accesul la jurnal, fișierul corespunzător trebuie creat manual (sau permisiuni modificate). Creează probleme speciale logrotate.
Este un set de reguli de rutare a mesajelor. Fiecare regulă constă dintr-un selector și o acțiune, separate prin file (Solaris 5 pe sisteme mai vechi) sau spații (Linux). După ce a primit un mesaj care urmează să fie înregistrat (de la klogd, dintr-un program local sau de la distanță), syslogd verifică pentru fiecare regulă dacă mesajul se potrivește cu modelul specificat de selector. Dacă este cazul, se realizează acțiunea specificată în regulă. Pentru un mesaj m. au fost efectuate un număr arbitrar de acțiuni (adică procesarea mesajului nu se oprește la primul succes).
Selectorul are două părți, separate printr-un punct: sursa mesajului și gravitatea. Literele mari și mici sunt aceleași. De asemenea, puteți utiliza numere (consultați /usr/include/syslog.h). Pe lângă sursele definite în syslog.3, puteți specifica marcă(marcate de timp obișnuite) Securitate(sinonim depreciat pentru auth). În plus față de nivelurile de severitate definite în syslog.h, puteți utiliza a avertiza(sinonim pentru avertizare), eroare(sinonim pentru a greșit), panică(sinonim pentru emerg). Mesajele cu un nivel egal sau mai mare decât cel specificat în selector și o sursă egală cu cea specificată în selector sunt considerate valide. Un asterisc înaintea unui punct corespunde oricărei surse, după un punct - oricărui nivel. Cuvânt nici unul după punct - niciun nivel pentru sursa dată. Puteți specifica mai multe surse într-un singur selector (separate prin virgule). Se pot specifica mai multe selectoare pe o linie. Semantica nu este clară: dacă folosești selectori pozitivi, atunci logica SAU dacă este negativ ( nici unulși un semn de exclamare), apoi logica ȘI.
În noul syslogd (linux), nivelul poate fi precedat de un semn egal - doar mesajele cu nivelul specificat (dar nu cel mai înalt) se vor potrivi cu selectorul; semnul exclamării - mesajele cu un nivel egal sau mai mare nu se vor potrivi; semnul exclamării și egal nu vor potrivi mesajele cu un nivel egal cu cel specificat.
Ca acțiune, puteți specifica:
- numele fișierului obișnuit (calea completă de la rădăcină), minus în fața numelui dezactivează sincronizarea înregistrărilor
- canale numite - fifo (o linie verticală este plasată în fața numelui), canalul în sine ar trebui să fie creat înainte de a porni syslogd cu comanda mkfifo
- terminal sau consola
- @hostname (trimite mesaje pentru înregistrarea de la distanță)
- lista utilizatorilor (separati prin virgula), catre ale caror terminale va fi trimis mesajul
- un asterisc pentru a trimite un mesaj către toate terminalele (perete)
Când analizați un fișier de configurare syslogd compară adresa loghost(definit în / etc / hosts, nu prin DNS) cu adresa computerului dvs. și, dacă se potrivește, definește variabila LOGHOST... Syslog.conf este apoi trecut prin procesorul macro m4 (1). Practic, acesta este folosit pentru ca același fișier de configurare să poată fi utilizat pe gazdele client și server (din punct de vedere syslog).
Procedura de pornire și oprire: /etc/init.d/syslog(linkuri către acesta din directoarele /etc/rc?.d). Numărul procesului este stocat în /etc/syslog.pid.
klogd citește mesajele kernelului (prin / proc / kmsg sau apeluri de sistem), determină nivelul, traduce adresele de comandă în nume de programe și trimite un mesaj către syslogd.
Parametri de lansare:
- -c nivel(mesajele de acest nivel și mai puțin grave vor fi trimise la syslog, iar cele mai serioase vor fi trimise în consolă; implicit - 7; 0 nu poate fi specificat)
- -d(modul de depanare)
- -f Nume de fișier (înregistrați-vă în fișierul specificat în loc de syslog)
- -i(simbolurile modulului de reîncărcare în klogd care rulează deja, trebuie utilizate de fiecare dată când un modul este încărcat sau descărcat; sperăm că versiunile actuale de insmod, rmmod și modprobe fac acest lucru singure)
- -Eu(reîncărcați simbolurile nucleului și modulelor în klogd care rulează deja)
- -k Nume de fișier (utilizați fișierul specificat ca tabel cu simboluri kernel în loc de /boot/System.map)
- -n(nu mergeți în fundal; este necesar să rulați de la init)
- -o(mod unic - înregistrați toate mesajele acumulate în buffer-ul kernelului și ieșiți)
- -p(doar pentru orice eventualitate, reîncărcați tabelul cu simboluri ale modulului în momentul traducerii adresei - kernel-ul ar putea să nu poată face acest lucru)
- -s(utilizați numai apeluri de sistem și nu accesați / proc / kmsg pentru a obține mesajele originale)
- -v(arata versiunea si finisajul)
- -X(nu converti adresele în nume)
- -2 (mesajele de blocare a nucleului - Hopa! - sunt emise de două ori: înainte de a converti adresele în nume - pentru ksymoops - și după)
Nivelurile mesajelor kernel (determinate de numărul dintre paranteze unghiulare și convertite la severitatea syslog, neschimbate la ieșirea fișierului):
- KERN_EMERG - 0 (sistemul este inutilizabil)
- KERN_ALERT - 1 (acțiunea trebuie luată imediat)
- KERN_CRIT - 2 (condiții critice)
- KERN_ERR - 3 (condiții de eroare)
- KERN_WARNING - 4 (condiții de avertizare)
- KERN_NOTICE - 5 (stare normală, dar semnificativă)
- KERN_INFO - 6 (informațional)
- KERN_DEBUG - 7 (mesaje la nivel de depanare)
Reacția la semnale:
- SIGINT, SIGKILL, SIGTERM și SIGHUP - oprire
- SIGTSTP - opriți înregistrarea
- SIGCONT - reluare, eventual alegând altul sursa mesajelor (/ proc / kmsg sau apeluri de sistem)
- SIGUSR1 - Reîncărcare simboluri ale modulelor
- SIGUSR2 - Reîncărcați simbolurile nucleului și modulelor
Numărul procesului este stocat în /var/run/klogd.pid.
Inițializare înregistrare: openlog- este indicat prefixul standard adăugat tuturor mesajelor ulterioare (de obicei numele programului, numărul procesului între paranteze drepte și două puncte); sursă și opțiuni. closelog- terminați înregistrarea. syslog- logging (specifică sursa, severitatea și formatul șirului ca în printf).
logrotate(versiunea 3.2-1 / 3.3.2-1 / 3.5.9) - Luptă împotriva buștenilor în creștere: rotație (versiune), compresie, ștergere și trimitere prin corespondență. Se rulează zilnic de cron ( /etc/cron.daily/logrotate) și vă permite să procesați jurnalele dacă acestea depășesc dimensiunea specificată sau la intervalul de timp specificat. Vă permite să procesați nu numai jurnalele syslog, ci și orice alte programe. Opțiuni:
- [-d](mod depanare, nu se fac modificări reale)
- [-f](efectuați modificări chiar dacă logrotate nu vede nevoia - este folosit atunci când se modifică lista de jurnalele procesate)
- [-s statefilename ] (starea curentă a jurnalelor este stocată în acest fișier între rulări, implicit - /var/lib/logrotate.status)
- configfilenames (nume separate prin spații; ordinea contează; dacă este specificat un nume de director, atunci fiecare fișier din acesta este considerat un fișier de configurare; RH folosește un fișier /etc/logrotate.confși director /etc/logrotate.d)
Fișierul de configurare definește parametri globali (unul pe linie) care stabilesc parametrii impliciti pentru toate jurnalele. Pentru fiecare lot de loguri procesate, sunt specificați parametri locali: este specificat numele fișierului de bază, urmat de parametrii locali între acolade, câte unul pe linie. Numele fișierului poate fi citat de regulile shell dacă conține spații sau alte caractere speciale. Puteți specifica mai multe nume de fișiere sau modele de nume de fișiere separate prin spații (modelele urmează, de asemenea, regulile shell). Procesarea fiecărei secțiuni este tratată ca o singură acțiune. Liniile care încep cu caracterul „#” sunt comentarii. Parametrii specificați în următorul fișier de configurare suprascriu valorile parametrilor specificati în fișierul anterior. Parametrii locali au prioritate față de parametrii globali. Ordinea fișierelor din directorul de configurare este nedefinită.
Opțiuni:
- comprima | nocompress(versiunile mai vechi sunt comprimate sau nu cu gzip)
- comprescmd(setează programul de compresie, gzip în mod implicit)
- uncompresscmd(setează programul de decompresie, implicit - ungzip)
- compresext(setează sufixul pentru fișierele comprimate)
- opțiuni de compresie(setează parametrii programului de compresie; implicit este „-9”, adică compresia maximă pentru gzip)
- copytruncate | nocopytruncate(de obicei, versiunea veche este redenumită și se creează o nouă versiune a jurnalului; atunci când acest parametru este setat logrotate copiază jurnalul într-un fișier nou și apoi îl trunchiază pe cel vechi; folosit dacă programul care creează jurnalul nu îl poate închide; înregistrările făcute între copiere și trunchiere se pierd; Dar ajută dacă programul care creează jurnalul, în loc de modul de adăugare, scrie pur și simplu într-un fișier folosind un pointer intern?)
- crea [ drepturi de acces proprietar grup] | nocreate(imediat după redenumirea vechii versiuni a jurnalului și înainte de a suna postrotate se creează un nou jurnal cu atributele specificate - permisiunile sunt setate în octal, ca în chmod.2; dacă atributele nu sunt specificate, acestea sunt preluate din vechiul jurnal)
- zilnic(schimbarea versiunii în serie are loc zilnic)
- delaycompress | nodelaycompress(unele programe nu închid imediat jurnalul, caz în care compresia ar trebui amânată până la următorul ciclu)
- erori e-mail (cui să trimită rapoarte de eroare)
- extensie sufix (setează sufixul adăugat la numele fișierelor atunci când se rotește înainte de sufixul de compresie)
- dacă gol | notificare gol(schimbați versiunile chiar dacă fișierul este gol; acesta este implicit)
- include Nume de fișier | nume-director (înlocuiți textual un fișier sau toate fișierele din directorul specificat; subdirectoarele, fișierele speciale și fișierele cu sufixe din lista de excludere nu sunt incluse; nu pot fi utilizate în interiorul unei secțiuni)
- Poștă abordare | nomail(atunci când o schimbare de versiune face necesară ștergerea vechiului jurnal, apoi trimiteți-l la adresa specificată)
- mail first(trimiteți nu versiunea ștearsă a jurnalului, ci prima)
- mailast(trimite versiunea ștearsă a jurnalului; aceasta este implicită)
- lipsingok | nomissingok(nu trimiteți mesaje de eroare dacă lipsește jurnalul)
- lunar(schimbarea versiunii are loc lunar)
- olddir director | noolddir(în timpul unei schimbări de versiune, jurnalul este mutat în directorul specificat; ar trebui să fie pe același dispozitiv fizic)
- postrotate script final sunt executate ca comenzi shell după procesul de actualizare)
- prerotate(toate liniile ulterioare până la linie script final sunt executate înainte de procesul de actualizare)
- roti număr (câte versiuni vechi să păstrați; dacă 0, atunci niciuna)
- mărimea octet (schimbarea versiunii are loc dacă dimensiunea jurnalului a depășit numărul specificat; puteți folosi sufixele „k” - kilobytes - și „M" - megabytes)
- scripturi partajate | nosharedscripts(executați comenzi prerotateși postrotate o singură dată pentru toate fișierele descrise în secțiune)
- tabooext [+ ] sufix-list (specificând o listă de excepții de sufix pentru include; dacă este specificat semnul plus, atunci adăugare, în caz contrar înlocuire; valori implicite: .rpmorig, .rpmsave, .rpmnew, ", v", .swp și "~")
- săptămânal(schimbarea versiunii are loc săptămânal)
În livrare RH /etc/logrotate.conf descrie parametrii și parametrii globali pentru / var / log / wtmp și / var / log / lastlog și se referă la directorul /etc/logrotate.d, în care fiecare pachet scrie parametri locali pentru jurnalele sale.
logwatch este un cadru de scriere a programelor (numite filtre) pentru a extrage informații utile din jurnalele numeroase, mari și variate (nu doar syslog). „Pachetul” conține mai multe filtre concepute pentru Red Hat Linux (un fel de versiune veche, deoarece inetd este menționat în loc de xinetd), dar va trebui să le adaptați la situația specifică. Ultima modificare a fost făcută de autor în septembrie 2000, așa că nu este nevoie să așteptați o dezvoltare ulterioară.
Filtrele pot fi scrise în orice limbaj de programare, dar autorul pachetului preferă perl. Filtrele ar trebui scrise astfel încât să citească datele din stdin și să scoată rezultatul în stdout. Înainte de a apela filtrul, variabilele de mediu sunt setate: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Programul principal este, de asemenea, scris în perl: /etc/log.d/scripts/logwatch.pl(/etc/log.d/logwatch, / usr / sbin / logwatch și /etc/cron.daily/00-logwatch sunt link-uri simbolice către acesta).
Director /etc/log.d/conf/logfiles/ conține fișiere de configurare ale grupurilor de jurnal, în care sunt stocate înregistrările serviciilor întreținute. Fiecare grup este descris într-un fișier separat numele Grupului.conf, în care sunt setate:
- LogFile = numele fișierului care conține jurnalul sau modelul de nume; pot fi specificate mai multe nume sau modele; nume m. relativ la LogDir
- Arhivă = numele fișierului creat de logrotate a versiunii arhivate a jurnalului sau un model de denumire; pot fi specificate mai multe nume sau modele; nume m. relativ la LogDir
- nume de filtre ( o singură dată, deși se arată celălalt!) din /etc/log.d/scripts/shared/ la fel de
*nume-filtru = Opțiuni , de exemplu, pentru a filtra jurnalul după dată, dacă este scris în formatul standard syslog, utilizați linia:
* ApplyStdDate =
Director /etc/log.d/conf/services/ conține fișierele de configurare pentru serviciile ale căror intrări de jurnal le va procesa logwatch. Fiecare serviciu este descris într-un fișier separat numele serviciului.conf, în care sunt setate:
- LogFile = numele grupului de jurnal
- filtru numele de la /etc/log.d/scripts/shared/ la fel de
*nume-filtru = Opțiuni înainte de filtrul de service - $nume-variabilă-de-mediu = sens
Director /etc/log.d/scripts/logfiles/ conține filtre pentru procesarea grupurilor de jurnal: la procesarea unui grup de jurnal, toate fișierele din director /etc/log.d/scripts/logfiles/ numele Grupului folosite ca filtre.
Director /etc/log.d/scripts/services/ conține filtre pentru procesarea înregistrărilor unor servicii specifice.
Director /etc/log.d/scripts/shared/ conține filtre generale utilizate în fișierele de configurare a grupului de jurnal:
- applystddate - filtrează jurnalul după data cerută, dacă este scris în format syslog (aici și în filtre private după dată, introduceți LANG = înainte de data apelării, altfel Mar nu coincide în niciun fel cu Mar;)
- expandrepeat - transformă liniile „ultimul mesaj repetat” în numărul corespunzător de linii de mesaj din linia anterioară
- onlycontains - lasă doar acele linii de jurnal care conțin șirul specificat (am pus ghilimele în jurul „$ *”)
- onlyservice - extrage din formatul de log in syslog liniile legate de serviciul specificat (numele serviciului este transmis ca parametru)
- remove - lasă doar acele linii de jurnal în format syslog care nu conțin linia specificată ( Am pus ghilimele în jurul „$ *” și am făcut remove1, remove2 etc. deoarece nu am înțeles cum să specific mai multe submodele pentru egrep într-o singură linie; apropo, parametrii sunt înlocuiți în shell, așa că nici caracterele speciale nu pot fi folosite)
- removeheaders - eliminați câmpurile standard (data, ora, numele gazdei, eticheta serviciului și numărul procesului)
- removeservice - extrage linii din jurnalul în format syslog care nu au legătură cu serviciul specificat (numele serviciului este transmis ca parametru)
Parametrii impliciti sunt stocați în fișierul /etc/log.d/conf/logwatch.conf (/etc/log.d/logwatch.conf are o legătură simbolică către acesta), comentariile în care vă permit să înțelegeți semnificația parametri:
- LogDir - directorul relativ la care sunt luate în considerare numele fișierelor
- MailTo - cui să trimită raportul
- Imprimare - în loc să trimiteți un raport prin poștă, trimiteți-l către stdout
- Salvare - în loc să trimită raportul prin poștă, îl va salva în fișierul specificat
- Arhive - utilizați versiuni ale jurnalelor generate de logrotate
- Interval - interval de timp considerat: Toate, Azi, Ieri (ziua calendaristică de ieri)
- Detaliu - nivelul de detaliu al raportului: de la 0 la 10 sau Low, Med, High
- Service - Toate sau numele filtrului din /etc/log.d/scripts/services/ (pot fi specificate mai multe filtre)
- LogFile - Toate sau numele grupului de jurnal (pot fi specificate mai multe grupuri)
Parametri de lansare:
- --detaliu nivel (nivelul de detaliu al raportului: ridicat, mediu sau scăzut)
- --fișier jurnal jurnalele de grup (procesează numai jurnalele acestui grup; grupul este specificat printr-un nume simbolic în fișierul de configurare; pot fi specificate mai multe grupuri)
- --serviciu numele serviciului (procesează numai acele intrări din jurnalele care se referă la acest serviciu; serviciul este specificat printr-un nume simbolic în fișierul de configurare; pot fi specificate mai multe servicii; nume Toate procesarea înregistrărilor apelurilor pentru toate serviciile)
- --imprimare(raportați la stdout)
- --mailto abordare (trimiteți un raport la adresa specificată)
- --Salvați Nume de fișier (scrieți raportul în fișierul specificat)
- --arhive(procesează nu numai versiunile curente ale jurnalelor, ci și copiile vechi create de logrotate)
- --gamă data-interval (procesează numai acele intrări din jurnalele care se referă la intervalul de timp dat: Ieri, Azi, Toate)
Utilizarea principală este includerea unui fișier 00-logwatch (începând cu „00” pentru a rula înainte de logrotate) în directorul /etc/cron.daily, ceea ce face ca logwatch să ruleze zilnic cu opțiunile implicite.
Din păcate, toate filtrele sunt proiectate astfel încât jurnalele să fie scrise pe aceeași gazdă pe care rulează serviciul.
Toate jurnalele sunt păstrate pe un singur computer (dacă aveți tendințe paranoice, puteți înregistra jurnale pe două servere simultan).
Corespondența dintre numele formal al sursei și dispozitivul sau programul real:
- local0 - Cisco
- local3 - ftp (există un nume de sursă special, dar Solaris 2.5 nu îl știe)
- local4 - rezervat contabilitatii
- local5 - POP3 / IMAP
- local6 - tac_plus>
Un ecran pentru portul 514 / udp ar trebui să fie deschis pe server (puteți restricționa adresele sursă ale pachetelor, dar acest lucru va ajuta doar în caz de accidente). Pornirea syslogd (parametrii din /etc/rc.d/init.d/syslog sau / etc / sysconfig / syslog) trebuie pornită cu tastele „-r -m 0” (și, de asemenea, „-x” dacă același computer este rulează server DNS). Porniți klogd cu comutatoarele „-2 -c 1”. Configurare Syslog.conf:
- * .crit - mesaje de nivel de severitate CRIT și mai mare pentru a fi trimise la terminale și scrise într-un fișier separat (chmod 600), mesajele tale urmând să fie trimise către serverul de rezervă; sendmail consideră că mesajele despre probleme legate de recepția e-mailului sunt critice
- kern - creați un fișier kern pentru toate nivelurile de mesaje (chmod 600)
- mail - creați un fișier de e-mail pentru mesajele de toate nivelurile (fără sincronizare)
- auth, authpriv - creați un fișier securizat pentru mesajele de toate nivelurile (chmod 600)
- știri - în directorul de știri, creați un fișier separat pentru fiecare nivel de severitate (depanare fără sincronizare)
- cron - creați un fișier cron pentru mesajele de toate nivelurile (cron în RH 6.2 și Solaris 2.5 nu poate folosi syslog)
- local0 - creați un fișier separat pentru fiecare nivel de severitate din directorul Cisco (err și mai jos fără sincronizare)
- local3 - în directorul ftp, creați un fișier separat pentru fiecare nivel de severitate (informații și depanare fără sincronizare)
- local5 - creați fișierul imap.log pentru mesajele de toate nivelurile
- local6 - creați un fișier tac_plus.log pentru mesajele de toate nivelurile
- local7 - fișier boot.log (mesaje când sistemul pornește și syslogd și klogd pornesc sau se opresc)
- toate mesajele de nivel INFO și superior care nu au intrat într-unul dintre fișierele definite mai sus, scrieți în fișierul de mesaje (chmod 600)
Pe computerele client, configurați syslog astfel încât toate mesajele să fie trimise către serverul syslog, mesajele de eroare să fie duplicate în / var / log / syslog, mesajele de stare critică să fie duplicate pe consolă, terminalele utilizatorului. Pe mașinile Linux, aruncați și mesajele de boot în fișierul local (local7, boot.log). Serverul Syslog de rezervă ar trebui să primească mesaje critice din rețea și să le scrie într-un fișier (gaură în ecran, comutator de pornire „-r”).
logrotate: păstrați pentru totdeauna, schimbați versiunile cât mai rar posibil (lunar, cu excepția squid), dump în directoare separate (cu excepția squid) și comprimați (în modul întârziat, cu excepția ftpd, linuxconf, sendfax), trimiteți-mi erori și fișiere șterse. Potriviți parametrii pentru syslog.
Plasarea unui simbol țeavă (|) în fața numelui fișierului vă va permite să utilizați fifo (primul intrat - primul ieşit, primul a venit - primul a venit) sau conductă numită ca receptor de mesaje. Înainte de a porni (sau reporni) syslogd, trebuie să creați un fifo folosind comanda mkfifo. Uneori, fifos sunt folosite în scopuri de depanare.
Terminal și Consolă
Terminal precum / dev / console.
Mașină de la distanță
Pentru a redirecționa mesajele către o altă gazdă, precedați numele gazdei cu simbolul @. Rețineți că mesajele nu sunt redirecționate de la gazda care primește. (pentru ca această misiune să funcționeze pe client și server din fișier / etc / servicii rândul trebuie scris syslog 514 / udp, iar portul UTP 514 este deschis)
o listă de utilizatori
O listă separată prin virgulă a utilizatorilor care primesc mesaje (dacă utilizatorul este autentificat). Acesta include adesea utilizatorul root.
Toți utilizatorii înregistrați
Pentru a notifica toți utilizatorii înregistrați cu comanda wall, utilizați simbolul asterisc (*).
Un exemplu de simplu syslog.conf:
# Trimiteți toate mesajele kernel-ului în consolă. # kern * / dev / console # Toate jurnalele la nivel de informații sau mai sus, cu excepția mesajelor de e-mail și # nu înregistrați mesajele de autentificare și mesajele cron daemon! * .info; mail.none; authpriv.none; cron.none / var / log / mesaje # Scrieți mesaje care conțin # informații confidențiale de autentificare într-un fișier separat, indiferent de nivelul lor. authpriv * / var / log / secure # Toate mesajele din sistemul de e-mail ar trebui să fie, de asemenea, scrise într-un fișier separat. mail. * - / var / log / maillog # Înregistrați mesajele de planificare în / var / log / cron cron * / var / log / cron # Mesajele de urgență trebuie primite imediat # toți utilizatorii sistemului * .emerg * # Salvați mesajele știri despre nivel critic și mai mare într-un fișier separat. uucp, news.crit / var / log / spooler # Salvați mesajele de pornire în boot.log local7. * /var/log/boot.log
Ca și în cazul multor fișiere de configurare, sintaxa este următoarea:
- liniile care încep cu # și liniile goale sunt ignorate.
- Simbolul * poate fi folosit pentru a indica toate categoriile sau toate prioritățile.
- Cuvântul cheie special none indică faptul că nu trebuie efectuată nicio înregistrare pentru această categorie pentru această acțiune.
- O cratimă în fața numelui fișierului (cum ar fi / var / log / maillog în acest exemplu) indică faptul că jurnalul nu trebuie sincronizat după fiecare intrare. În cazul unei erori de sistem, este posibil să pierdeți informații, dar dezactivarea sincronizării va îmbunătăți performanța.
În sintaxa fișierului de configurare, puteți pune înainte prioritate semn! pentru a indica faptul că acțiunea nu trebuie aplicată, de la acest nivel și mai sus... În mod similar, se poate acorda prioritate semn = pentru a indica faptul că regula se aplică numai la acel nivel sau != pentru a indica faptul că regula se aplică la toate nivelurile, cu excepția acestuia. Câteva exemple sunt prezentate mai jos (multe alte exemple pot fi găsite în man syslog.conf):
# Trimiteți toate mesajele nucleului către / var / log / kernel. # Trimite toate mesajele critice și mai mari către mașina Sysloger de la distanță și către consolă # Trimite toate mesajele de informații, notificare și avertizare către / var / log / kernel-info # kern * / Var / log / kernel kern.crit @sysloger kern .crit / dev / console kern.info; kern.! err / var / log / kernel-info # Trimite toate mesajele sistemului de e-mail, cu excepția nivelului de informații în / var / log / mail. mail. *; mail.! = info / var / log / mail
Am încercat să arăt activitatea lui syslogd cât mai clar posibil în diagramă:
Pornirea demonului syslogd
Daemonul de logare este pornit în etapa de inițializare a sistemului prin intermediul unui script /etc/rc.d/init.d/syslog, cu toate acestea, pentru a seta parametrii de lansare, nu este nevoie să ajustați acest script - începând cu versiunea 7.2, opțiunile de lansare sunt citite dintr-un fișier de configurare separat / etc / sysconfig / syslog (/ etc / implicit / syslogîn debian).
Iată câteva posibile Opțiuni de pornire a demonului syslogd:
- -a / folder / socket- specificarea unei prize de ascultare suplimentare (nu uitați să creați mai întâi o priză)
- -d- modul de depanare. În acest caz, demonul nu trece în fundal și trimite toate mesajele către terminalul curent;
- -f config-file-name... Specifică numele unui fișier de configurare alternativ care va fi utilizat în loc de /etc/syslog.conf implicit;
- -l listă de gazde- stabilirea unei liste de gazde ale căror nume nu trebuie înregistrate cu indicarea numelui complet al domeniului (FQDN - Full Qwalified Domain Name);
- -m minute- sysklogd lansat fără această opțiune înregistrează mesajele din categoria de marcaj (marcate temporale) la fiecare 20 de minute. Folosind opțiunea -m, puteți fie să modificați intervalul dintre semne, fie să anulați complet emiterea unor astfel de mesaje;
- -p priza- setarea unui socket UNIX alternativ (în loc de a asculta implicit / dev / log);
- -r- permisiunea de a primi mesaje de la gazde la distanță;
- -X- interzicerea determinării numelui gazdei după adresa sa pentru a preveni înghețarea atunci când se lucrează pe aceeași gazdă cu serverul DNS.
- -v- arata versiunea si termina lucrarea
După pornirea demonului syslogd, este generat un fișier de stare / var / blocare / subsys / syslog lungime zero și fișier cu ID-ul procesului /var/run/syslogd.pid.
Folosind comanda
kill -SIGNAL `cat / var / run / syslogd.pid`
poate fi trimis la demonul syslogd unul dintre următoarele semnale: SUPRAȚI- repornirea demonului; SIGTERM- finalizarea lucrărilor; SIGUSR1- activați / dezactivați modul de depanare.
Există de fapt doi daemoni de înregistrare care rulează pe sistem - syslogdși klogd... Ambii demoni sunt incluse în pachet sysklogd.
Daemonul Klogd responsabil pentru înregistrarea evenimentelor care au loc în miezul sistemului... Necesitatea unui daemon klogd separat se datorează faptului că nucleul nu poate utiliza funcția standard syslog. Ideea este că bibliotecile standard C (inclusiv biblioteca care conține funcția syslog) sunt destinate să fie utilizate numai aplicatii conventionale... Deoarece nucleul are nevoie și de funcționalitate de logare, acesta include propriile biblioteci care nu sunt disponibile pentru aplicații. Prin urmare, nucleul folosește propriul mecanism de generare a mesajelor.
Daemonul Klogd este conceput pentru a organiza procesarea acestor mesaje. În principiu, poate face această procesare complet independent și independent de syslogd, de exemplu, prin scrierea acestor mesaje într-un fișier, dar în majoritatea cazurilor este folosită setarea implicită klogd, care trimite toate mesajele din nucleu către același demon syslogd.
Rotație automată (actualizarea fișierelor complete) și arhivarea jurnalelor
În timp, fișierul jurnal tinde să crească, mai ales cu munca intensivă a oricărui serviciu. În consecință, trebuie să puteți controla dimensiunea jurnalelor. Acest lucru se face cu comenzile logrotate care se face de obicei demonul cron... Voi vorbi despre munca lui cron în articolele următoare. obiectivul principal comenzile logrotate este să faceți periodic copii de rezervă ale jurnalelor și să creați noi jurnale curate. Sunt păstrate mai multe generații de jurnale, iar când jurnalul de ultima generație ajunge la data de expirare, acesta poate fi arhivat (comprimat). Rezultatul poate fi trimis prin poștă, de exemplu, către persoana responsabilă cu întreținerea arhivelor.
Pentru a determina ordinea de rotație și arhivare a jurnalelor, utilizați fișier de configurare /etc/logrotate.conf ... Pentru diferite jurnale, puteți seta o frecvență diferită, de exemplu, zilnic, săptămânal sau lunar, în plus, puteți ajusta numărul de generații acumulate, precum și să specificați dacă copii ale arhivelor vor fi trimise persoanei responsabile cu arhivarea și, dacă da, când. Prezentat mai jos exemplu de fișier /etc/logrotate.conf:
# parametrii „implicit” sunt setați mai întâi (opțiuni globale) # actualizați fișierele jurnal săptămânal săptămânal # păstrați o arhivă de jurnalele pentru ultimele 4 săptămâni rotiți 4 # creați un fișier nou (gol) după rotație (actualizare) creați # decomentați dacă doriți ca fișierele salvate să fie comprimate #comprimați # activați setările de rotație din directorul specificat includ /etc/logrotate.d # nu stocați wtmp, sau btmp - setările de rotație a datelor din jurnal sunt după cum urmează: / var / log / wtmp (missingok creați lunar 0664 rotire utmp rădăcină 1) / var / log / btmp (missingok creați lunar 0664 rotire utmp rădăcină 1) # jurnalele de sistem specifice pot fi configurate mai jos
Opțiunile globale sunt plasate la început fișier logrotate.conf... Ele sunt utilizate în mod implicit dacă nu este specificat nimic mai specific în altă parte. În exemplu, are loc rotația jurnalelor săptămânal iar copiile de rezervă sunt păstrate pt patru săptămâni. De îndată ce jurnalul este rotit, unul nou este creat automat în locul vechiului jurnal. Fișierul Logrotate.conf poate conține specificații din alte fișiere. Deci, include toate fișierele din director /etc/logrotate.d.
Acest exemplu conține și reguli speciale pentru / var / log / wtmpși / var / log / btmp(stochează informații despre încercările reușite și nereușite de autentificare în sistem), care sunt rotate lunar. Dacă fișierele lipsesc, nu este afișat niciun mesaj de eroare. Se creează un fișier nou și se salvează o singură copie de rezervă.
În acest exemplu, când backup-ul ajunge la ultima generație, acesta este șters deoarece nu este definit ce să facă cu el.
Backup-uri în jurnal pot fi generate și atunci când jurnalele ating o anumită dimensiune, iar scripturile pot fi generate din seturi de comenzi pentru a fi executate înainte sau după o operație de backup. Exemplu:
/ var / jurnal / mesaje (rotiți 5 mail [email protected] dimensiune 100k postrotate / usr / bin / killall -HUP syslogd endscript)
În acest exemplu, rotația / var / jurnal / mesaje produs când ajunge la 100 KB. Se acumulează cinci copii de rezervă, iar când expiră cea mai veche copie de rezervă, aceasta este trimisă prin poștă [email protected] Cuvântul de comandă postrotate permite unui script să repornească demonul syslogd după ce rotația este completă prin trimiterea unui semnal HUP. Cuvântul de comandă endscript este necesar pentru a termina scriptul și, de asemenea, dacă scriptul prerotate este disponibil. Consultați paginile de manual logrotate pentru mai multe informații.
Opțiuni dat în fișierul de configurare logrotate.conf:
- comprima| nocompress(versiunile mai vechi sunt comprimate sau nu cu gzip)
- comprescmd(setează programul de compresie, gzip în mod implicit)
- uncompresscmd(setează programul de decompresie, implicit - ungzip)
- compresext(setează sufixul pentru fișierele comprimate)
- opțiuni de compresie(setează parametrii programului de compresie; implicit este „-9”, adică compresia maximă pentru gzip)
- copytruncate| nocopytruncate(de obicei, versiunea veche este redenumită și se creează o nouă versiune a jurnalului; atunci când acest parametru este setat logrotate copiază jurnalul într-un fișier nou și apoi îl trunchiază pe cel vechi; folosit dacă programul care creează jurnalul nu îl poate închide; înregistrările făcute între copiere și trunchiere se pierd; dar ajută dacă programul care creează jurnalul, în loc de modul de adăugare, scrie pur și simplu într-un fișier folosind un pointer intern?)
- crea[grup de proprietari de permisiuni] | nocreate(imediat după redenumirea vechii versiuni a jurnalului și înainte de a apela postrotate, se creează un nou jurnal cu atributele specificate - permisiunile sunt setate în octal, ca în chmod.2; dacă nu sunt specificate atribute, acestea sunt preluate din vechiul jurnal. )
- zilnic(schimbarea versiunii în serie are loc zilnic)
- delaycompress| nodelaycompress(unele programe nu închid imediat jurnalul, caz în care compresia ar trebui amânată până la următorul ciclu)
- erorie-mail(cui să trimită rapoarte de eroare)
- extensiesufix(setează sufixul adăugat la numele fișierelor atunci când se rotește înainte de sufixul de compresie)
- dacă gol| notificare gol(schimbați versiunile chiar dacă fișierul este gol; acesta este implicit)
- includeNume de fișier| nume-director (înlocuiește textual un fișier sau toate fișierele dintr-un director specificat; subdirectoarele, fișierele speciale și fișierele cu sufixe din lista de excluderi nu sunt incluse; nu pot fi utilizate în interiorul unei secțiuni)
- Poștăabordare| nomail(atunci când o schimbare de versiune face necesară ștergerea vechiului jurnal, apoi trimiteți-l la adresa specificată)
- mail first(trimiteți nu versiunea ștearsă a jurnalului, ci prima)
- mailast(trimite versiunea ștearsă a jurnalului; aceasta este implicită)
- lipsingok| nomissingok(nu trimiteți mesaje de eroare dacă lipsește jurnalul)
- lunar(schimbarea versiunii are loc lunar)
- olddirdirector| noolddir(în timpul unei schimbări de versiune, jurnalul este mutat în directorul specificat; ar trebui să fie pe același dispozitiv fizic)
- postrotate(toate liniile ulterioare până la linia endscript sunt executate ca comenzi shell după procesul de schimbare a versiunii)
- prerotate(toate liniile ulterioare până la linia finală sunt executate înainte de procesul de schimbare a versiunii)
- rotinumăr(câte versiuni vechi să păstrați; dacă 0, atunci niciuna)
- mărimeaoctet(schimbarea versiunii are loc dacă dimensiunea jurnalului a depășit numărul specificat; puteți folosi sufixele „k” - kilobytes - și „M" - megabytes)
- scripturi partajate| nosharedscripts(executați comenzile de prerotate și postrotate o singură dată pentru toate fișierele descrise în secțiunea)
- tabooext[+] sufix-list(specificarea unei liste de excluderi de sufixe pentru include; dacă este specificat semnul plus, atunci adăugare, în caz contrar înlocuire; implicit: .rpmorig, .rpmsave, .rpmnew, ", v", .swp și "~")
- săptămânal(schimbarea versiunii are loc săptămânal)
Explorarea și monitorizarea jurnalelor
Intrările de jurnal conțin, de obicei, un marcaj de timp, numele de gazdă pe care rulează procesul descris și numele procesului. Vizualizați jurnalele puteți folosi un program de paginare, de exemplu, Mai puțin, puteți căuta anumite intrări (de exemplu, mesaje kernel de la un anumit demon) folosind comanda grep:
# less / var / log / mesaje # grep "ppp" / var / log / mesaje | tail Dec 17 16:34:25 proxy pppd: Conexiune terminată. 17 dec 16:34:25 proxy pppd: Ieșire. 17 decembrie 16:35:57 proxy pppd: LCP terminat de peer (^ P] kV ^ @ Este posibil ca computerul să nu funcționeze tot timpul și să se oprească, să zicem noaptea. Prin urmare, înregistrările în / var / jurnal / mesaje sunt stocate ciclic de la pornirea computerului până la oprire, acest lucru se poate vedea din mesaje: 17 decembrie 08:32:56 syslog-server syslogd 1.4-0: reporniți. 17 decembrie 08:32:56 syslog-server syslog: syslogd a reușit 17 decembrie 08:32:56 syslog-server kernel: klogd 1.4-0, sursa jurnal = / proc / kmsg a început. 17 decembrie 08:32:56 syslog-server syslog: start klogd a reușit 17 decembrie 08:32:56 kernel-server syslog: linie de comandă kernel: auto BOOT_IMAGE = linux ro root = 303 BOOT_FILE = / boot / vmlinuz-2.4.2-2 17 decembrie 08:32:56 kernel-server syslog: Memorie: 125652k / 130560k disponibile (1365k cod kernel, 4200k rezervat, 92k date, 236k init, 0k highmem) 17 decembrie 08:32:56 Syslog-server kernel: CPU: Intel (R) Pentium (R) 4GHz step1. De asemenea, în acest fișier puteți găsi informații despre memoria discului (inclusiv informații despre geometria discului, structura partiției și întreruperile utilizate), informații despre dispozitivele periferice, despre pornirea serviciilor și serviciilor individuale, informații despre conectarea sistemelor de fișiere și mesaje despre conectarea utilizatorului. precum și mesajele de eroare. Uneori poate fi necesar jurnalele sistemului de monitorizare pentru a căuta evenimente curente. De exemplu, puteți încerca să prindeți un eveniment rar în momentul în care sa întâmplat. În acest caz, puteți utiliza comanda coadă cu optiune -f pentru a urmări conținutul syslog-ului. Exemplu: # tail -f / var / jurnal / mesaje | grep syslog-server 17 decembrie 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 17 decembrie 16:46:09 syslog-server pppd: Script / etc / ppp / ip-up terminat (pid 12552), stare = 0x0 17 decembrie 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 conexiunea de control începută 17 decembrie 16:46:49 syslog-server pptpd: CTRL: Pornirea apelului pppd deschidere GRE) 17 decembrie 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so încărcat. Pe lângă fișierele jurnal specificate în /etc/syslog.conf, există și alte fișiere, de exemplu, un fișier care stochează informații despre procesul de pornire a sistemului înainte de a porni syslogd, precum și fișiere care au un format binar și stochează informații. despre ultima conectare a utilizatorului, toate conectările de succes ale utilizatorilor și, respectiv, toate conectările nereușite ale utilizatorilor. De asemenea, directorul / var / log / poate conține fișierele jurnal ale demonilor, cum ar fi un server web sau un server proxy. Formatul acestor fișiere este similar cu jurnalele syslogd. În cele din urmă, aș dori să subliniez că acest protocol nu este foarte sigur. syslog nu conține niciun mijloc de protecție împotriva falsificării mesajelor. Mai rău, utilizarea UDP permite atacatorilor să trimită mesaje în numele oricărei gazde. Rețeaua dvs. locală ar trebui să fie verificată împotriva primirii de pachete cu adrese locale false (deși acest lucru nu vă împiedică să trimiteți mesaje false din interiorul rețelei locale) și să primiți pachete în afara portului 514 / udp. Există cazuri cunoscute de depășire a discului cu mesaje false. Protocolul syslog și UDP nu oferă livrare garantată (mesajele pot fi pierdute în timpul congestionării rețelei sau interceptate, mesajele corupte sunt șterse fără avertisment), secvență de livrare corectă (mesajul despre sfârșitul procesului poate veni înainte de mesajul despre începerea acestuia) , livrare prioritară. Mesajele nu sunt păstrate confidențiale deoarece sunt transmise în text clar. Dacă, la configurarea generatorului de mesaje, specificați adresa greșită a colectorului sau releului, atunci nu vor fi mesaje de eroare - mesajele vor fi șterse (sau vor fi scrise în jurnalul altcuiva). Au fost propuse mai multe proiecte pentru a îmbunătăți protocolul syslog. De exemplu, RFC 3195 propune un sistem de înregistrare bazat pe TCP (syslog-conn) pentru a se asigura că mesajele sunt livrate în secvența corectă. Proiectul syslog-sign își propune să asigure autentificarea, ordonarea, integritatea mesajelor și detectarea mesajelor lipsă prin generarea de mesaje speciale care conțin o semnătură digitală a blocului de mesaje anterioare, menținând în același timp protocolul și formatul standard syslog și folosind UDP. Să rezumam: Linux are un singur demon responsabil pentru înregistrarea evenimentelor pe sistemul local și sistemele de la distanță. Toate evenimentele sunt colectate de la soclul / dev / log, portul UDP - 514, precum și de la "helper" - demonul klogd, care trimite mesaje din kernel. Toate mesajele colectate sunt filtrate de demonul syslogd prin regulile din fișierul /etc/syslog.conf și distribuite conform regulilor către destinațiile corespunzătoare. Fișierele jurnal sunt periodic „trunchiate”. Frecvența este determinată de fișierul logrotate.conf și de comanda logrotate, care este rulată de programatorul de sistem - cron. Asta e tot pentru azi. Sper că am descris totul cât mai clar posibil. Cu timpul, voi completa articolul! Cu respect, Mc.Sim! SERGEY SUPRUNOV Sfaturi FreeBSD: utilizarea syslog - Scuzați-mă, tovarăși, am toate mișcările notate!
— Biroul scrie, spuse Ostap.
I. Ilf, E. Petrov „12 scaune”.
Înregistrarea lucrărilor oricărui sistem, și mai ales a serverului, este una dintre cele mai importante componente ale administrării. În fișierele jurnal ne uităm în primul rând atunci când există unele probleme în sistem. De aici obținem încredere că acest program sau acela funcționează conform așteptărilor. Când se dezvoltă aplicații web, fișierul jurnal devine cea mai importantă sursă de informații de depanare. Caracteristicile demonului syslog, care este responsabil pentru înregistrarea informațiilor despre sistem, vor fi discutate. Ce este syslog Syslog este un serviciu centralizat care colectează și înregistrează informații de jurnal de la diferite componente ale sistemului de operare și procese ale utilizatorului. Programele terță parte sunt de obicei capabile să lucreze cu fișierele lor jurnal pe cont propriu, deși multe dintre ele pot fi configurate să funcționeze cu demonul syslogd. Avantajele utilizării syslog includ capacitatea de a controla procesul de colectare a informațiilor necesare folosind un singur fișier de configurare, care asigură consistența fișierelor jurnal primite și, ca urmare, simplifică gestionarea acestora. Serviciul syslog este furnizat de demonul syslogd, care este pornit automat la pornirea sistemului. Este constant în memorie, așteaptă mesaje de la alte procese și le procesează în conformitate cu setările sale. Fiecare mesaj este caracterizat de un nivel și de o facilitate. Nivelul precizează gradul de importanță a mesajului în ceea ce privește funcționarea sistemului. Fișierul syslog.h definește următoarele niveluri (priorități): Tabelul 1. Niveluri de mesaje Nivel Descriere emerge, panică Stare de panică alerta O afecțiune care necesită atenție imediată crit Situatie critica eroare, eroare Alte erori de lucru avertizare, avertizare Avertizări înștiințare Mesaje care nu sunt erori, dar care trebuie reținute info Mesaje informative (funcționare normală) depanare Informații de depanare Tabelul 1 listează nivelurile de mesaje în ordine descrescătoare. Această ordine va fi necesară mai târziu în discuția despre sintaxa fișierului de configurare. Indicatorii de nivel al mesajelor scrise pe aceeași linie (de ex. emerg și panic) sunt sinonime și oricare dintre ei poate fi folosit. Cu toate acestea, panica, eroarea și avertismentul (enumerate al doilea în tabel) sunt depreciate și ar trebui evitate la editarea fișierului de configurare. Folosiți în schimb emerg, err și warning. Sursele posibile ale mesajului sunt enumerate în Tabelul 2: Tabelul 2. Sursele mesajelor O sursă Descriere kern Mesaje kernel auth, authpriv Securitate Mesaje de securitate (de exemplu, de la un firewall) consolă Mesaje către consolă (/dev/console) syslog Mesaje native Syslog cron Mesaje ale subsistemului Cron Mesaje de serviciu de timp Postări Servere FTP Imprimați mesajele subsistemului Poștă Mesaje de la serviciile poștale știri Mesaje ale serviciului de știri uucp Postări UUCP demonul Mesaje de la alți daemoni care rulează pe sistem utilizator Utilizatorul procesează mesajele local0 - local7 Poate fi folosit pentru diverse nevoi ale utilizatorului (uneori folosit și de sistem) Când configurați o aplicație pentru a funcționa cu serviciul syslog, verificați ce facilitate folosește. Unele programe vă permit să specificați singur sursa. De exemplu, demonul clamd (procesul principal al antivirusului clamav) folosește local6 în mod implicit, dar vă permite să specificați o sursă diferită (parametrul LogFacility din fișierul de configurare). În unele cazuri, poate fi util să combinați mesajele sale cu mesajele de la serviciile de e-mail, specificând LOG_MAIL ca sursă. Opțiuni de pornire Daemon O listă completă a opțiunilor de pornire poate fi găsită în pagina de manual syslogd. Aici vom lua în considerare doar câteva dintre ele. Syslog este capabil să scrie mesaje primite în fișierele jurnal (care sunt de obicei situate în directorul / var / log), să le trimită către consolă sau către un terminal de utilizator conectat, să le trimită la o gazdă la distanță sau să le trimită către un utilitar extern pentru prelucrare. Pentru rețea, syslog utilizează porturile 514 (UDP și TCP). Syslogd, pornit fără parametri suplimentari, va asculta pe aceste porturi mesajele primite. Comutatorul -s dezactivează mesajele de intrare, dar socket-urile pe porturile 514 sunt încă create pentru conexiunile de ieșire, astfel încât syslogd să poată trimite mesaje către gazdele de la distanță. Dublarea tastei (-ss) neagă și conexiunile de ieșire. În mod implicit, syslogd este pornit cu comutatorul -s (vezi /etc/defaults/rc.conf, parametrul syslogd_flags), astfel încât conexiunile de intrare sunt refuzate. Dacă doriți să utilizați serviciul syslog al serverului dvs. pentru a servi mai multe mașini, adăugați următoarea linie la /etc/rc.conf: syslogd_flags = ””
Aceasta va suprascrie valoarea setată în /etc/defaults/rc.conf, astfel încât syslogd să poată gestiona conexiunile de intrare. Desigur, în acest caz este necesar să se asigure nivelul necesar de securitate, excluzând posibilitatea ca gazdele străine să scrie ceva în jurnalele dvs. Comutatorul -a vă permite să setați restricții pentru conexiunile de intrare (vezi man syslogd). Un firewall configurat corespunzător joacă, de asemenea, un rol important. Un alt comutator util, -l, vă permite să specificați fișiere socket suplimentare pe care syslogd le ascultă în plus față de implicit / var / run / log. De exemplu, acest comutator este necesar pentru ca syslog să poată gestiona programe care rulează într-un mediu chroot. În special, așa funcționează named începând cu BIND 9. Pe FreeBSD 5.3, syslogd este pornit cu următoarele chei: # ps -ceara | grep syslog Sintaxa fișierului de configurare Înregistrarea este configurată în fișierul /etc/syslog.conf. Este de la sine înțeles că numai utilizatorul root îl poate edita. Acest fișier conține două tipuri de șiruri - să le numim „filtre” și „reguli”. Șirul de filtru specifică programul sau gazda din care să aplice următoarele reguli mesajelor de la. Un filtru precum „! Prog” (sau „#! Prog”) indică faptul că următoarele rânduri se referă la jurnalele generate de programul de prog specificat. Sinonimul pentru această intrare este „! + Prog”. În schimb, linia „! -Prog” înseamnă că următoarele reguli se vor aplica tuturor mesajelor, cu excepția celor care provin din programul prog. Este permisă listarea mai multor programe separate prin virgule, în timp ce semnul „+” sau „-” este aplicat întregii liste. Dacă șirul de filtru este specificat ca „+ nume de gazdă”, atunci gazda specificată va fi folosită ca sursă de mesaje care urmează să fie procesate de regulile ulterioare. Ca și în cazul programelor, simbolul „-” indică faptul că regulile se vor aplica tuturor mesajelor, cu excepția celor care provin de la gazda specificată. Puteți specifica o listă de gazde separate prin virgule. Caracterul „*” specificat ca program sau gazdă va înlocui filtrul setat anterior. Adică regulile specificate după o astfel de linie se vor aplica tuturor mesajelor. Filtrele cu nume de gazdă sau program sunt independente unele de altele și pot funcționa în același timp. De exemplu: # Regulile aflate aici se aplică tuturor mesajelor gazda mea # Regulile se aplică tuturor mesajelor de la my.host Logger # Regulile se aplică mesajelor de la logger cu my.host (filtrul gazdă continuă) # Regulile se aplică mesajelor de la su cu my.host # Regulile se aplică mesajelor de la su de la orice gazdă (filtrul gazdei este anulat, filtrul programului continuă) # Regulile sunt aplicate tuturor mesajelor (filtrul programului este de asemenea anulat) Liniile regulilor sunt după cum urmează: facilitate.CMLevel destinație Aici facilitate este sursa mesajului ("*" reprezintă orice sursă), nivelul este nivelul mesajelor care vor fi procesate în conformitate cu această regulă. Cuvântul de serviciu „niciun”, specificat în locul nivelului, indică excluderea completă a mesajelor din această sursă. CMP - operație de comparare (simboluri „>”, „<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.
Destinația specifică unde trebuie salvat acest mesaj. Acesta poate fi un fișier jurnal (este indicată calea completă, începând cu „/”), adresa serverului la distanță (începând cu simbolul „@”), un nume de utilizator (mesajele vor fi trimise către terminalul către care acest utilizator) este conectat). De asemenea, mesajul poate fi transmis unui program extern pentru procesare, pentru care se folosește simbolul „|”. Câteva exemple de reguli Toate mesajele kernelului vor fi trimise în fișierul kern.log. kern. * /var/log/kern.log Toate mesajele de eroare, precum și mesajele emerg, alertă și nivel critic vor fi plasate în all-err.log. Observați cratima din fața numelui fișierului jurnal. În mod implicit, mesajele sunt stocate în memorie și sunt scrise pe disc pe măsură ce tamponul se umple. Acest lucru reduce încărcarea sistemului de fișiere, dar poate duce la pierderea unor informații atunci când aparatul se blochează. Cratima din fața numelui fișierului face ca demonul syslogd să scrie imediat mesaje pe disc. * .err - / var / log / all-err.log Mesajele de depanare de la procesele utilizatorului vor fi transmise la terminalul la care utilizatorul vasya este conectat în prezent. user.debug vasya Toate mesajele de la serviciile de știri și e-mail vor fi redirecționate către portul 514 al mașinii syslog.host.ru. mail. *, știri. * @ syslog.host.ru Toate mesajele de service de imprimare de mai jos de avertizare vor fi plasate în fișierul specificat. După cum sa menționat mai devreme, valoarea implicită este mai mare sau egală cu comparația, iar! se inversează, înlocuindu-l cu „mai puțin”. Dacă trebuie să excludeți un anumit nivel, ar trebui să utilizați construcția „! =". lpr.! avertisment /var/log/printers.log Mesajele de nivel de depanare (și numai mesajele de depanare) cu nivel de facilitate 0 și nivel 3 vor fi transmise la toate terminalele conectate. level0, level3. = depanare * Mesajele Time Service care sunt mai mari decât critice (adică emerg și alertă) și mai mici sau egale cu notificarea (notificare, informații și depanare) vor fi trimise către terminalele ntpuser și root. ntp.> crit,<=notice ntpuser,root
Toate mesajele de avertizare, cu excepția celor de la serviciile de e-mail, vor fi scrise în fișierul warn.log. *. = avertisment, mail.none /var/log/warn.log În acest caz, toate mesajele cu un nivel mai mare sau egal cu crit vor fi trimise prin e-mail utilizatorului root. * .crit | mail -s rădăcină „mesaj critic”. După cum puteți vedea, formatul fișierului de configurare permite ca mai multe niveluri, surse și destinații să fie listate pe o singură linie, ceea ce face configurația mai flexibilă. Pentru ca modificările să intre în vigoare după editare, trebuie să trimiteți un semnal HUP către procesul syslogd: # kill –HUP `cat / var / run / syslog.pid` Trebuie remarcat faptul că, dacă acest sau acel mesaj intră sub acțiunea mai multor linii din fișierul de configurare, atunci acesta va fi procesat în conformitate cu fiecare dintre ele. Exemplu: mail. * / var / log / maillog *. = err /var/log/error.log În acest caz, mesajele mail.err vor merge atât la maillog, cât și la error.log. Strategia fișierului de configurare Încheind examinarea fișierului de configurare, voi spune câteva cuvinte despre strategiile de compilare a acestuia. Pe lângă popularul „dacă funcționează”, se pot distinge două principale, pe care le vom numi condiționat „după sursă” și „după scop”. Utilitar logger Sistemul include un utilitar de înregistrare care vă permite să trimiteți mesaje către serviciul syslog direct din linia de comandă. Este convenabil să îl utilizați atunci când testați regulile de configurare, precum și în dezvoltarea scripturilor pentru înregistrarea lucrărilor lor. Exemple: user $ logger -p user.err „Eroare în programul utilizatorului!” utilizator $ logger -h syslog.host.ru „Testează-l” Primul exemplu va trimite un mesaj utilizator de facilitate la nivel de eroare, care va fi procesat conform fișierului de configurare. A doua comandă va trimite un mesaj gazdei la distanță, sursa și nivelul implicit vor fi setate la user.notice. Utilizarea mecanismelor de rotație Mecanismul de înregistrare discutat mai sus nu oferă niciun fel de gestionare a fișierelor jurnal. Mesajele sunt pur și simplu plasate în ele conform regulilor descrise în fișierul de configurare. Aceasta înseamnă că fișierele jurnal vor crește constant și, dacă nu se face nimic, mai devreme sau mai târziu vor umple tot spațiul disponibil pe partiția corespunzătoare. Pentru a evita acest lucru, se folosește un mecanism de rotație. De exemplu, de îndată ce fișierul debug.log depășește 100 MB, este redenumit în debug.log.0 și împachetat în debug.log.0.bz2. În schimb, este creat un nou debug.log. Apoi, când dimensiunea noului fișier atinge 100 MB, debug.log.0.bz2 este redenumit debug.log.1.bz2 și procedura de mai sus se repetă. Sistemul stochează doar un anumit număr de fișiere de arhivă, ștergându-le pe cele mai vechi. Aceasta este rotația. Utilitar Newsyslog Pe FreeBSD, rotația este gestionată de utilitarul newsyslog, care în mod implicit este rulat la începutul fiecărei ore de către demonul cron. Puteți modifica perioada de rotație prin editarea fișierului / etc / crontab. Parametrii de rotație specificați în exemplul de mai sus (dimensiunea fișierului, ambalarea), precum și o serie de alții, sunt setați în fișierul de configurare /etc/newsyslog.conf. Pentru fiecare fișier care necesită rotație, acesta conține, în general, o linie de nouă câmpuri: numele fișierului, proprietarul și grupul, drepturile de acces, cel mai mare număr din numele fișierului arhivă, dimensiunea maximă a fișierului, perioada de rotație, steaguri suplimentare și calea către PID fișierul aplicației pentru a trimite semnalul după rotație și numărul semnalului care urmează să fie trimis. (Poate fi necesar să trimiteți un semnal unui proces, de exemplu, dacă procesul menține fișierul jurnal deschis tot timpul; în caz contrar, descriptorul de fișier utilizat nu se va potrivi cu fișierul nou creat.) Unele câmpuri pot fi omise. Iată două exemple, complete și tipice: / var / log / pflog rădăcină: roată 600 3 100 * JB /var/run/pflog.pid 1 Conform acestei reguli, fișierul pflog trebuie suprascris de îndată ce dimensiunea lui depășește 100 MB (al 5-lea câmp), indiferent de oră ("*" în al 6-lea câmp). Fișierele de arhivă vor avea nume precum pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2 etc.), iar X nu poate fi mai mare de trei (parametrul 3 în al 4-lea câmp). Indicatorul J indică faptul că fișierul arhivă ar trebui să fie comprimat folosind utilitarul bzip2. Datorită steagului B, mesajele de serviciu despre rotație nu vor fi adăugate fișierelor arhivate și nou create, deoarece fișierul este perceput ca binar. Fișierul nou creat va fi deținut de utilizatorul root și de grupul de roți (acest câmp ar fi putut fi omis deoarece acesta este proprietarul implicit). Permisiunile vor fi setate la rw ------- (valoare numerică 600), ceea ce înseamnă că numai proprietarul poate citi și scrie în acest fișier. În cele din urmă, un semnal 1 (HUP) va fi trimis procesului al cărui PID este stocat în /var/run/pflog.pid pentru a redeschide fișierul jurnal. / var / log / maillog 640 7 * @ T00 J Această regulă specifică parametrii de rotație pentru fișierul maillog: indiferent de dimensiune (un asterisc în al 5-lea câmp), fișierul va fi rescris în fiecare noapte la ora 00:00 (vezi man newsyslog.conf pentru o descriere detaliată a formatului de timp). Arhiva trebuie împachetată, vor fi salvate ultimele 8 arhive (cu numere de la 0 la 7 inclusiv), fișierul nou creat va fi deținut de utilizatorul root (valoare implicită, deci câmpul proprietar este omis) și va avea rw-r ----- permisiuni. Puteți utiliza utilitarele zcat și bzcat (pentru gzip și, respectiv, bzip2) pentru a vizualiza fișierele jurnal împachetate. Midnight Commander invocă automat utilitățile corespunzătoare. După editarea fișierului newsyslog.conf, nu trebuie trimis niciun semnal nicăieri - configurația va fi recitită data viitoare când este apelat newsyslog. Rețineți că utilitarul newsyslog nu este legat de demonul syslogd. Adică, poate fi folosit pentru a roti orice fișiere care au nevoie de el. Dacă rotația este activată pentru jurnalele pe care aplicația le menține singură (de exemplu, pentru jurnalele clamd sau squid), atunci acordați o atenție deosebită specificarii proprietarului și drepturilor de acces. Specificarea incorectă a acestora poate duce la faptul că, după rotație, o aplicație lansată ca utilizator neprivilegiat nu va putea scrie în fișierul nou creat. Rezumând Sistemul syslog este un instrument foarte puternic și eficient pentru înregistrarea diferitelor evenimente care apar în sistem. Setările implicite sunt destul de echilibrate și funcționează bine pentru majoritatea sistemelor. Cu toate acestea, înțelegerea modului în care funcționează syslog vă va permite să îmbunătățiți semnificativ calitatea înregistrării prin personalizarea înregistrării pentru a răspunde nevoilor dumneavoastră specifice.
321 ?? Ss 0: 01.67 / usr / sbin / syslogd -l / var / run / log -l / var / named / var / run / log -s
