Sysklogd предоставя два помощни програми, които осигуряват поддръжка за регистриране на системата и задържане на съобщения в ядрото. Поддръжката както на интернет, така и на домейни на UNIX домейни дава възможност на този полезен пакет да поддържа локално и отдалечено регистриране.
Системното регистриране се осигурява от версия на syslogd (8), получена от BSD източниците на запаси. Подкрепата за регистрирането на ядрото се осигурява от помощната програма klogd (8), която позволява записването на ядрото да се извършва самостоятелно или като клиент на syslogd.
Syslogd осигурява видовете регистриране, които използват много съвременни програми. Всяко записано съобщение съдържа поне поле за време и име на хост, обикновено и поле за име на програмата, но това зависи от това доколко надеждна е програмата за регистриране.
Докато syslogd източници са силно модифицирани няколко бележки са в ред. На първо място има систематичен опит да се гарантира, че syslogd следва своето стандартно BSD поведение по подразбиране. Втората важна концепция е, че тази версия на syslogd взаимодейства прозрачно с версията на syslog, намерена в стандартните библиотеки. Ако бинарна, свързана със стандартните споделени библиотеки, не успее да функционира правилно, бихме искали пример за аномалното поведение.
Основният конфигурационен файл /etc/syslog.conf или алтернативен файл, даден с опцията -f , се чете при стартиране. Всички линии, започващи с маркера ("#") и празни линии, се игнорират. Ако възникне грешка по време на анализа, целият ред се игнорира.
резюме
[ -n ] [ -p socket ] [ -r ] [ -s домейн ] [ -d ] [ -f конфиг файл ] [ -h ] [ -l хост списък ] [ -m интервал ] v ] [ -x ]
Настроики
- гнездо
Като използвате този аргумент, можете да зададете допълнителни sockets, от които трябва да се изслуша syslogd . Това е необходимо, ако ще позволите даден демон да се движи в среда на chroot (). Можете да използвате до 19 допълнителни гнезда. Ако вашата среда се нуждае от още повече, трябва да увеличите символа MAXFUNIX в изходния файл syslogd.c. Пример за демон за chroot () е описан от хората от OpenBSD на адрес http://www.psionic.com/papers/dns.html.
-д
Включва режима на отстраняване на грешки. Използвайки това, демонът няма да премине вилица (2), за да се позиционира във фонов режим, но се противопоставя на този престой на преден план и ще напише много информация за отстраняване на грешки на текущия tty. Вижте раздела DEBUGGING за повече информация.
-f конфигурационния файл
Посочете алтернативен конфигурационен файл вместо /etc/syslog.conf , който е по подразбиране.
-h
По подразбиране syslogd няма да препраща съобщенията, които получава от отдалечени хостове. Определянето на този превключвател в командния ред ще доведе до това, че демонтът на дневника ще препраща всички отдалечени съобщения, които получава, за пренасочване на хостове, които са били дефинирани.
-l списък за хостинг
Посочете име на хост, което трябва да бъде записано само със своето просто име на хост, а не с fqdn. Няколко хоста може да се задават като се използва двойката (``: '').
-м интервал
Syslogd регистрира редовно маркера за време. Интервалът по подразбиране между два MARK линии е 20 минути. Това може да се промени с тази опция. Задаването на интервала до нула го изключва напълно.
-н
Избягвайте автоматичното фокусиране. Това е необходимо, особено ако syslogd се стартира и управлява от init (8).
-p гнездо
Можете да зададете алтернативен сокет на домейн unix вместо / dev / log .
-r
Тази опция ще позволи на съоръжението да получава съобщение от мрежата чрез гнездо за интернет домейн с услугата syslog (вж. (5)). По подразбиране е да не се получават съобщения от мрежата.
Тази опция е въведена във версия 1.3 на пакета sysklogd. Моля, обърнете внимание, че поведението по подразбиране е обратното на поведението на по-старите версии, така че може да се наложи да го включите.
-domainlist
Посочете име на домейн, което трябва да бъде премахнато, преди да се регистрирате. Могат да бъдат посочени няколко домейна, като се използва сепараторът на двоеточие (``: ''). Моля, имайте предвид, че не могат да бъдат посочени други поддомейни, а само цели домейни. Например, ако -s north.de е зададен и хостът за регистриране се решава на satu.infodrom.north.de никой домейн няма да бъде отрязан, ще трябва да определите два домейна като: -s north.de:infodrom.north.de .
-V
Печатайте версията и излезте.
-х
Забранете търсенето на имена, когато получавате отдалечени съобщения. Това предотвратява затварянето, когато сървърът за имена работи на същата машина, която изпълнява демона на syslog.
Сигнали
Syslogd реагира на набор от сигнали. Можете лесно да изпратите сигнал до syslogd, като използвате следното:
kill -SIGNAL "котка / var / run / syslogd.pid"SIGHUP
Това позволява на syslogd да извърши повторно инициализация. Всички отворени файлове са затворени, конфигурационният файл (по подразбиране е /etc/syslog.conf ) ще бъде прегледан отново и съоръжението syslog (3) ще бъде стартирано отново.
SIGTERM
Syslogd ще умре.
SIGINT , SIGQUIT
Ако отстраняването на грешки е разрешено, те се игнорират, в противен случай syslogd ще умре.
SIGUSR1
Превключете отстраняването на грешки в / изключете. Тази опция може да се използва само ако syslogd стартира с опцията -d debug.
SIGCHLD
Изчакайте децата, ако някой се е родил поради съобщенията на стената.
Разлики в синтактичния файл на конфигурационните файлове
Syslogd използва малко по-различен синтаксис за конфигурационния си файл, отколкото оригиналните източници на BSD. Първоначално всички съобщения с конкретен приоритет и по-горе бяха препратени в регистрационния файл.
Например, следният ред е причинил ВСИЧКИ изходи от демони, използващи демонските устройства (debug е най-ниският приоритет, така че всяко по-високо ниво също ще съответства), за да отидете в / usr / adm / daemons :
# Пример за syslog.conf daemon.debug / usr / adm / daemonsСпоред новата схема това поведение остава същото. Разликата е добавянето на четири нови спецификатора, заместващата звездичка ( * ), уравнението ( = ), удивителен знак ( ! ) И знакът минус ( - ).
* Посочва, че всички съобщения за конкретното съоръжение трябва да бъдат насочени към местоназначението. Обърнете внимание, че това поведение е дегенерирано с определяне на приоритетно ниво на отстраняване на грешки. Потребителите са посочили, че означението със звездичка е по-интуитивно.
The = wildcard се използва за ограничаване на регистрацията в зададения приоритетен клас. Това позволява, например, маршрутизиране само на отстраняване на грешки в даден източник за регистриране.
Например, следващият ред в syslog.conf ще насочва съобщенията за отстраняване на грешки от всички източници към файла / usr / adm / debug .
# Пример за syslog.conf *. = Debug / usr / adm / debugВърнете се в началото се използва, за да изключи регистрирането на зададените приоритети. Това засяга всички (!) Възможности за определяне на приоритетите.
Например, следните редове ще регистрират всички съобщения от пощенската кутия на съоръжението, с изключение на тези с приоритетна информация в / usr / adm / mail файла. И всички съобщения от news.info (включително) до news.crit (с изключение на) ще бъдат записани в / usr / adm / news file.
# Пример за syslog.conf поща. *; Mail.! = Info / usr / adm / mail news.info; новини.! Crit / usr / adm / newsМожете да я използвате интуитивно като спецификатор на изключения. Горепосоченото тълкуване е просто обърнато. Правете това, което можете да използвате
mail.noneили
поща.! *или
поща.! отстраняване на грешкида прескочите всяко съобщение, което се доставя с пощенска база. Има много място за игра с него. :-)
The - може да се използва само за префикс на име на файл, ако искате да пропуснете синхронизирането на файла след всяко записване в него.
Това може да отнеме известно аклиматизиране за тези хора, използвани за чисто поведение на BSD, но тестери са посочили, че този синтаксис е малко по-гъвкав от BSD поведението. Обърнете внимание, че тези промени не трябва да засягат стандартните файлове syslog.conf (5). Трябва да промените конкретно конфигурационните файлове, за да получите подобрено поведение.
Поддръжка за отдалечено регистриране
Тези модификации осигуряват мрежова поддръжка на съоръжението syslogd. Мрежовата поддръжка означава, че съобщенията могат да бъдат препращани от един възел, изпълняващ syslogd, до друг възел, изпълняващ syslogd, където те действително ще бъдат записани в дисков файл.
За да го активирате, трябва да посочите опцията -r на командния ред. По подразбиране поведение е, че syslogd няма да слуша мрежата.
Стратегията е да имате syslogd да слушате в socket за домейн unix за локално генерирани съобщения в дневника. Това поведение ще позволи на syslogd да взаимодейства със syslog, намиращ се в стандартната библиотека C. В същото време syslogd слуша на стандартния порт syslog за съобщения, препратени от други хостове. За да работим правилно, файловете за услуги (5) (обикновено намиращи се в / etc ) трябва да имат следния запис:
syslog 514 / udpАко този запис липсва, syslogd нито може да получава отдалечени съобщения, нито да ги изпраща, защото пристанището на UDP не може да бъде отворено. Вместо това syslogd ще умре веднага, издухвайки съобщение за грешка.
За да пренасочите съобщенията на друг хост, заместете нормалния ред на файла в файла syslog.conf с името на хоста, на който трябва да бъдат изпратени съобщенията, пренасочени с @.
Например, за да изпратите ВСИЧКИ съобщения до отдалечен хост, като използвате следния запис syslog.conf :
# Извадете конфигурационния файл syslogd до # съобщения до отдалечен хост напред. *. * @ име на хостаЗа да препраща всички съобщения на ядрото до отдалечен хост, конфигурационният файл ще бъде както следва:
# Примерна конфигурационна файл, за да препращате всички съобщения на ядрото до отдалечен хост. kern. * @hostnameАко името на отдалечения хост не може да бъде разрешено при стартиране, тъй като име сървърът може да не е достъпен (може да се стартира след syslogd), не е нужно да се притеснявате. Syslogd ще опита отново да разреши името десет пъти и след това ще се оплаче. Друга възможност да избегнете това е да поставите името на хоста в / etc / hosts .
При нормални syslogd бихте получили syslog-loops, ако изпращате съобщения, получени от отдалечен хост към един и същ хост (или по-сложно за трети хост, който го изпраща обратно към първия и т.н.). В моя домейн (Infodrom Oldenburg) случайно получихме едно и нашите дискове бяха изпълнени със същото съобщение. :-(
За да се избегне това по-нататък, съобщенията, получени от отдалечен хост, вече не се изпращат на друг (или същия) отдалечен хост. Ако има сценарии, когато това няма смисъл, моля, пуснете ме (Джоуи).
Ако отдалеченият хост се намира в същия домейн като хоста, syslogd се изпълнява, само просто име на хост ще бъде регистрирано вместо цялото fqdn.
В локална мрежа можете да предоставите централен лог сървър, за да имате цялата важна информация, съхранявана на една машина. Ако мрежата се състои от различни домейни, не е нужно да се оплаквате от регистрирането на напълно квалифицирани имена вместо от прости имена на хостове. Може да искате да използвате функцията "домейн-домейн" на този сървър. Можете да кажете на syslogd да премахне няколко домейна, различни от този, в който се намира сървърът и да регистрира само прости имена на хостове.
Използвайки опцията -l има и възможност за дефиниране на единични хостове като локални машини. Това също води до регистриране само на техните прости имена на хостове, а не на файловете.
Гнездото UDP, използвано за препращане на съобщения до отдалечени хостове или за получаване на съобщения от тях, се отваря само когато е необходимо. В изданията преди 1.3-23 тя е отворена всеки път, но не е отворена за четене или препращане съответно.
Изход към назовани тръби (FIFOs)
Тази версия на syslogd има поддръжка за извеждането на изходни данни до имената на тръбите (fifos). Една FIFO или наречена тръба може да бъде използвана като дестинация за лог-съобщения, като предварително се добави символът pipy (`` | ') към името на файла. Това е удобно за отстраняване на грешки. Имайте предвид, че FIFO трябва да се създаде с командата mkfifo преди да започне syslogd.
Следващият конфигурационен файл маршрутизира съобщенията от ядрото до FIFO:
# Примерна конфигурация за маршрутизиране на ядрото # съобщения САМО за / usr / adm / debug, което е # име на тръба. kern = debug | / usr / adm / debugИнсталационни проблеми
Вероятно има важно значение при инсталирането на тази версия на syslogd. Тази версия на syslogd зависи от правилното форматиране на съобщенията чрез функцията syslog. Функционирането на функцията syslog в споделените библиотеки се промени някъде в областта на libc.so.4 [2-4] .n. Специфичната промяна беше да се прекрати нулево съобщение, преди да се пренесе в / dev / log socket. Правилното функциониране на тази версия на syslogd зависи от нулевото прекратяване на съобщението.
Този проблем обикновено се проявява, ако в системата се използват стари статично свързани двоични файлове. Файловете, използващи стари версии на функцията syslog, ще доведат до записа на празни линии, последвани от съобщението с първия знак в премахнатото съобщение. Пренасочването на тези двоични файлове към по-новите версии на споделените библиотеки ще отстрани този проблем.
Както syslogd (8), така и klogd (8) могат да бъдат изпълнени от init (8) или стартирани като част от последователността rc. *. Ако се стартира от init, опцията -n трябва да бъде зададена, в противен случай ще получите тонове от syslog демони. Това е така, защото init (8) зависи от идентификатора на процеса.
Защитни заплахи
Съществува потенциал за използване на демона syslogd като проводник за атака на отказ от услуга. Благодаря на Джон Морисън (jmorriso@rflab.ee.ubc.ca), че ме предупредихте за този потенциал. Една нелоялна програма (mer) може много лесно да наводни демона syslogd със syslog съобщения, в резултат на които файловете в дневника консумират цялото оставащо пространство в файловата система . Активирането на регистрацията по иглените домейни на домейни, разбира се, ще изложи системата на рискове извън програми или физически лица на локалната машина.
Има няколко метода за защита на машината:
- Изпълнете защитна стена на ядрото, за да ограничите кои хостове или мрежи имат достъп до гнездото 514 / UDP.
- Записването може да бъде насочено към изолирана или не-root файлова система, която, ако е попълнена, няма да навреди на устройството.
- Може да се използва ext2 файлова система, която може да бъде конфигурирана да ограничава определен процент от файлова система до използване само от root. Имайте предвид, че това ще изисква syslogd да се изпълнява като процес, който не е root. ЗАБЕЛЕЖКА, че това ще предотврати използването на отдалечено регистриране, тъй като syslogd няма да може да се свърже към гнездото 514 / UDP.
- Деактивирането на домейни за домейни inet ще ограничи риска за локалната машина.
- Използвайте стъпка 4, а ако проблемът продължава и не е вторичен за недобросъвестна програма / демон, вземете дължина на смукателния прът от 3,5 фута (около 1 метър) и говорете с въпросния потребител. Дебелина на пръта def. --- 3/4, 7/8 или 1in. закалена стоманена пръчка, с резба на всеки край. Първична употреба в петролната индустрия в Западна Северна Дакота и други места за изпомпване на "смученото" масло от нефтените кладенци. Вторичните употреби са за изграждане на партиди фуражи за едър рогат добитък и за справяне с случайно непочтителен или войнствен индивид.
Отстраняване на грешки
Когато debugging е включен, използвайки опцията -d , тогава syslogd ще бъде много подробен, като напише голяма част от това, което прави на stdout. Всеки път, когато конфигурационният файл се препрочита и преработи отново, ще видите табличен, съответстващ на вътрешната структура на данните. Тази таблица се състои от четири полета:
номер
Това поле съдържа сериен номер, започващ от нула. Това число представлява позицията във вътрешната структура на данните (т.е. масива). Ако един номер е оставен, тогава може да има грешка в съответния ред в /etc/syslog.conf .
модел
Това поле е трудно и точно представлява вътрешната структура. Всяка колона означава съоръжение (вижте syslog (3)). Както можете да видите, все още има някои съоръжения, оставени свободни за предишна употреба, само лявата най-много се използват. Всяко поле в колона представлява приоритетите (вижте syslog (3)).
действие
Това поле описва конкретното действие, което се случва всеки път, когато се получи съобщение, което съответства на модела. Обърнете се към страницата syslog.conf (5) за всички възможни действия.
аргументи
Това поле показва допълнителни аргументи за действията в последното поле. За записване на файлове това е името на файла за лог файла; за регистриране на потребители това е списък с потребители; за отдалечено записване това е името на хоста на устройството, за което се регистрира; за конзолно регистриране това е използваната конзола; за tty-logging това е посоченото tty; стената няма допълнителни аргументи.
Вижте също
Сътрудници
Syslogd е взет от BSD източници, Грег Уетщайн (greg@wind.enjellic.com) извърши пристанището към Linux , Martin Schulze (joey@linux.de) поправи някои грешки и добави няколко нови функции. Първоначално Klogd е написан от Стив Лорд (lord@cray.com), Грег Уетщайн направи големи подобрения.
Д-р Грег Уетщайн
Разработка на системи за електронни системи
Онкологичен изследователски отдел
Център за ракови заболявания на Роджър Марис
Fargo, ND
greg@wind.enjellic.com
Стивън Туиди
Катедра "Информатика"
Университет Единбург, Шотландия
sct@dcs.ed.ac.uk
Юха Виртанан
jiivee@hut.fi
Шейн Алдертън
shane@ion.apana.org.au
Мартин Шулце
Инфод Олденбург
joey@linux.de
Важно: Използвайте командата човек ( % man ), за да видите как се използва команда на вашия компютър.
Свързани статии