|
|
www.lissyara.su
—> документация
—> EXIM
—> 4.70
—> часть 49
49. Файлы логов
Exim пишет три различных лога, называемых - главный лог, лог отклонённых, и лог паники:
В главном логе записывается приход каждого сообщения, и каждая доставка, по одной строке на каждый случай. Формат - компактен насколько возможно, с целью попытаться уменьшить размер лог-файлов. Двухсимвольная последовательности флага облегчают выбор этих строк. Множество иных событий записывается в главный лог. Некоторые из них - опциональны, управляемые включением или выключением опции селектора логов “log_selector ”. Perl`овый скрипт, называемый “eximstats ”, производит простой анализ файлов главного лога, предоставляется в дистрибутиве exim`a (смотрите раздел 50.7).
В лог отклонённых записывается информация из сообщений, которые были отклонены как результат конфигурационных опций (т.е. по причинам политик). Первая строка каждого отклонения - копия строки, которая, также, пишется в главный лог. Затем, если заголовки сообщения были прочитаны во время записи лога, их содержимое пишется в этот лог. Доступны лишь оригинальные строки заголовоков; заголовки добавленные ACL - не логгируются. Вы можете использовать лог отклонённых для проверки, что ваши политики работают корректно; на загруженных хостах это может быть более легким чем сканирование главного лога на отклонённые сообщения. Вы можете подавить запись лога отклонённых путём установки “write_rejectlog ” в ложь.
Когда происходят определённые серьёзные ошибки, exim делает запись в лог паники. Если ошибка достаточно серьёзная, exim прекращает работу. Записи в лог паники, обычно, также пишутся в главный лог, но могут теряться среди массы других записей. В обычных обстоятельствах, лог паники должен быть пустой. Хорошая идея - проверять его регулярно (или скрипт в “cron ”, который будет это делать), с целью узнать о проблемах. Когда exim yе может открыть свой лог паники, он пытается, как последнее средство, записать в системный лог (syslog). Он открывается с LOG_PID+LOG_CONS и кодом средства LOG_MAIL. Само сообщение пишется с приоритетом LOG_CRIT.
Каждая строка лога начинается со штампа времени, в формате, показанном в следующем примере. Отметьте, что многие из примеров, показанных в этой части, с переносом строк. В файле логов, это было бы одной строкой:
2001-09-16 16:09:47 SMTP connection from [127.0.0.1] closed
by QUIT
| По умолчанию, штампы времени в локальной временной зоне. Есть два способа это изменить:
Вы можете установить опцию “timezone ” в иную временную зону; в частности, вы можете установить:
для штампов времени в UTC (который - GMT).
Вы можете установить “log_timezone ” в истину, для добавления временной зоны к штампу времени, например:
2003-04-25 11:17:07 +0100 Start queue run: pid=12762
| По умолчанию, exim не включает свой идентификатор процесса в строки логов, но вы можете запросить это путём задания лог селектора “pid ” (смотрите раздел 49.15). Когда это задано, выводиться pid процесса в квадратных скобках, сразу после времени и даты.
49.1 Где пишутся логи
Логи могут быть записаны в локальные файлы, или в syslog, или и туда и туда. Однако, нужно отметить, что многие реализации syslog используют в качестве транспорта UDP, и ненадёжны, в смысле, что не гарантируется прибытие сообщений на хост логгирования, и при этом порядок сообщений не обязательно поддерживается. Также сообщалось, что на больших файлах логов (десятки мегабайт), возможно, вам необходимо настроить syslog, для предотвращения синхронизации файла при каждой записи - на linux было замечено, что это вызывало 90% загрузку центрального процессора.
Назначение для логов exim`a конфигурируется путём установки LOG_FILE_PATH в “Local/Makefile ”, или путём установки “log_file_path ” в рабочей конфигурации. Эта, последняя, строка раскрывается, и, таким образом, она может содержать, например, ссылки на имя хоста:
log_file_path = /var/log/$primary_hostname/exim_%slog
| Вообще, желательна установка строки в “Local/Makefile ”, вместо рабочей конфигурации, поскольку в этом случае установка доступна с самого начала выполнения exim`a. Иначе, если будет нужно залоггировать что-то до чтения конфигурационного файла (например, ошибку в конфигурационном файле), он не сможет использовать путь который вы хотите, и может оказаться не в состоянии залоггировать вообще что бы то нибыло.
Значение LOG_FILE_PATH или “log_file_path ” - список разделённый двоеточиями, в настоящее время ограниченный максимум двумя элементами. Это - единственная опция, где не может использоваться средство для изменения разделителя списка. Этот список всегда должен быть разделён двоеточиями. Если элемент в списке - “syslog ”, тогда используется syslog; иначе, элемент должен быть абсолютным путём, содержащим “%s ” как точку, где должны быть вставлены “main ”, “reject ”, или “panic ”, или быть пустым, подразумевая использование дефолтового пути.
Когда exim сталкивается с пустым элементом в списке, он ищет список, заданный путём LOG_FILE_PATH, и использует первый найденный элемент, если он не пустой, или не “syslog ”. Это означает, что в “log_file_path ” может использоваться пустой элемент, для обозначения “использовать путь заданный при сборке ”. Если элемента не существует, лог файлы пишутся в субдиректорию “log ”, в директории спула. Это эквивалентно установке:
log_file_path = $spool_directory/log/%slog
| Если вы не определили что-то при компиляции или в рабочей конфигурации, логи пишутся по указанному пути.
Путь к логам может содержать “%D ”, если в имени логов используется штамп даты - смотрите секцию 49.3, ниже.
Вот - некоторые примеры возможных установок:
LOG_FILE_PATH=syslog syslog only
LOG_FILE_PATH=:syslog syslog and default path
LOG_FILE_PATH=syslog : /usr/log/exim_%s syslog and specified path
LOG_FILE_PATH=/usr/log/exim_%s specified path only
| Если в списке более двух путей, используется первый, и логгируется паническая ошибка.
49.2 Логгинг в локальные файлы, которые периодически ротируются
Некоторые операционные системы предоставляют централизованные и стандартизованные методы для ротации файлов логов. Для тех, которые этого не делают, предоставляется скрипт утилиты с именем “exicyclog ” (смотрите секцию [url=/doc/exim/4.70/exim_utilities/#50.6]50.6[/url). Он переименовывает и сжимает главный лог, и лог отклонённых при каждом его вызове. Может быть настроено максимальное число оставляемых старых логов. Предполагается, что этот скрипт запускается как ежедневное задание “cron ”.
Процесс доставки exim`a открывает главный лог когда ему первый раз необходимо в него записать, и оставляет его открытым в случае, если требуется последующая запись - например, если для одного и того же сообщения производится несколько различных доставок. Однако, удалённые SMTP-доставки могут занять много времени, и это означает, что файл может оставаться открытым после его переименования, если “exicyclog ”, или что-то подобное используется для переименования файлов логов на регулярной основе (имеется ввиду - постоянно - раз в сутки, например - прим. lissyara). Для гарантии, что переключение лог-файлов будет замечено как можно быстрее, exim вызывает “stat() ” для имени главных логов, до повторного использования открытых файлов, и если файл не существует, или изменилась его инода, старый файл закрывается, и exim пробует открыть пустой главный лог. Таким образом, старый лог может оставться открытым довольно долго, но никакие процессы exim`a в него не пишут, как только он был переименован.
49.3 Штамп даты на файлах логов
Вместо ротации файлов главного лога и лога отклонённых путём их периодического переименовывания, некоторые любят исполльзовать файлы, чьи имена содержат штамп времени, например, “mainlog-20031225 ”. Штамп времни имеет форму “yyyymmdd ”. Exim обладает поддержкой для этого способа работы. Он включается путём установки опции “log_file_path ” в путь, который содержит “%D ” в точке где требуется штамп даты. Например:
log_file_path = /var/spool/exim/log/%slog-%D
log_file_path = /var/log/exim-%s-%D.log
log_file_path = /var/spool/exim/log/%D-%slog
| Как и прежде, “%s ” заменяется на “main ” или “reject ”; вот - примеры имён генерируемых этим примером:
/var/spool/exim/log/mainlog-20021225
/var/log/exim-reject-20021225.log
/var/spool/exim/log/20021225-mainlog
| Когда задана эта форма логов, exim автоматически переключается на новые файлы по ночам. Он не предпринимает никаких попыток для сжатия старых логов; вам придётся написать свой скрипт, который будет это делать. Вы не должны запускать “exicyclog ” с этой формой логгинга.
Местоположение лога паники, также определяется путём “log_file_path ”, но на него не ставиться штамп даты, поскольку ротация лога паники не имеет смысла. При генерации имени лога паники, “%D ” удаляется из строки. Дополнительно, если он идёт немедленно после слэша, следующий не алфавитно-цифровой символ - удаляется; иначе, удаляется предшествующий не алфавитно-цифровой символ. Таким образом, предыдущие три примера, привели бы к таким логам паники:
/var/spool/exim/log/paniclog
/var/log/exim-panic.log
/var/spool/exim/log/paniclog
|
49.4 Логгинг в syslog
Использование syslog не изменяет того, как exim логгирует, или формат его сообщений, исключая одно отношение. Если “syslog_timestamp ” установлена в ложь, штамп времени в строках лога exim`a пропускается, когда строка посылается в syslog. Кроме того? те же самые строки пишутся в syslog как в файлы логов. Средство ( “facility ”) syslog установлено в LOG_MAIL, и по умолчанию, программа именуется “exim ”, но вы можете изменить это путём опций “syslog_facility ” и “syslog_processname ”, соответственно. Если exim скомпилен с SYSLOG_LOG_PID установленным в “Local/Makefile ” (это, значение по умолчанию, в “src/EDITME ”), тогда, на системах, которые разрешают это (все, исключая ULTRIX), флаг LOG_PID - установлен так, чтобы вызов “syslog() ” добавлял pid, также как и время и имя хоста, в каждую строку. Три потока логов распределяются по приоритетам syslog следующим образом:
“mainlog ” - маппится на LOG_INFO
“rejectlog ” - маппится на LOG_NOTICE
“paniclog ” - маппится на LOG_ALERT
Многие строки пишутся в оба - “mainlog ” и “rejectlog ”, а некоторые пишутся и в “mainlog ” и в “paniclog ”, таким образом, они будут дублироваться, если syslod их направит в одно место. Вы можете подавить дубликацию путём установки “syslog_duplication ” в ложь.
Иногда, строки логов exim`a бывают очень длинными, и некоторые записи “rejectlog ” содержат несколько строк, когда включаются заголовки. Для борьбы с этими обоими случаями, записываемые в syslog вхождения разделяются в отдельные вызовы “syslog() ” по внутренним новым строкам, и, также, после максимум, 870 знаков. (Это учитывает максимальную длинну строки syslog - 1024, когда добавлены дополнения, типа штампа времени.) Если вы запускаете замену syslog, которая может обработать строки длинней чем 1024 символа, разрешённые RFC3164, вы должны установить
в “Local/Makefile ” до сборки exim`a. Это предотвращает разбитие exim`ом длинных строк, но всё ещё разбирает внутренние новые строки во вхождениях лога “reject ”.
Для облегчения повторной сборки разбитых строк, каждый компонент разбитого вхождения начинается со строки формы “[<n>/<m>] ” или “[<n>\<m>] ”, где “<n> ” - компонент числа, и “<m> ” - полное число компонентов вхождения. Разделитель “/ ” используется когда строка разбита из-за того, что она слишком длинная; если же она разбита из-за внутренней новой строки, используется разделитель “\ ”. Например, предположим что ограничение длинны 50 вместо 870, следующий пример был бы результатом типичного отклонения сообщения в “mainlog ” (LOG_INFO), дополненительно, каждая строка предваряется временем, именем хоста, и pid, добавляемых syslog:
[1/5] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected from
[2/5] [127.0.0.1] (ph10): syntax error in 'From' header
[3/5] when scanning for sender: missing or malformed lo
[4/5] cal part in "<>" (envelope sender is <ph10@cam.exa
[5/5] mple>)
| Та же самая ошибка могла бы привести к следующим строкам записанным в “rejectlog ” (LOG_NOTICE):
[1/18] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected fro
[2/18] m [127.0.0.1] (ph10): syntax error in 'From' head
[3/18] er when scanning for sender: missing or malformed
[4/18] local part in "<>" (envelope sender is <ph10@cam
[5\18] .example>)
[6\18] Recipients: ph10@some.domain.cam.example
[7\18] P Received: from [127.0.0.1] (ident=ph10)
[8\18] by xxxxx.cam.example with smtp (Exim 4.00)
[9\18] id 16RdAL-0006pc-00
[10/18] for ph10@cam.example; Mon, 16 Sep 2002 16:
[11\18] 09:43 +0100
[12\18] F From: <>
[13\18] Subject: this is a test header
[18\18] X-something: this is another header
[15/18] I Message-Id: <E16RdAL-0006pc-00@xxxxx.cam.examp
[16\18] le>
[17\18] B Bcc:
[18/18] Date: Mon, 16 Sep 2002 16:09:43 +0100
| Строки логов, которые не слишком длинные, или не содержат символа новой строки, пишутся в syslog без модификации.
Если используется только syslog, монитор exim`a не может показывать логи, если syslog не направляет “mainlog ” в файл на локальном хосте, и переемнная окружения EXIMON_LOG_FILE_PATH не указывает монитору, где он находится.
49.5 Флаги строк логов
На каждое пришедшее сообщение, в логи записывается одна строка, и для каждой успешной, неуспешной, и задержанной доставки. Эти строки могут быть выбраны по отличительным двухсимвольным флагам, которые идут сразу за штампом времени. Флаги таковы:
Флаг
|
Значение
|
<=
|
прибытие сообщения
|
=>
|
нормальная доставка сообщения
|
->
|
дополнительный адрес в той же доставке
|
*>
|
доставка подавлена путём -N
|
**
|
доставка неудачна; отправляется рикошет
|
==
|
доставка задержана; временная проблема
|
|
49.6 Логирование приёма сообщений
Формат однострочного вхождения в главном логе, который пишется для каждого полученного сообщения, показан в простом примере, ниже, который разбит на несколько строк, чтобы уместиться на странице:
2002-10-31 08:57:53 16ZCW1-0005MB-00 <= kryten@dwarf.fict.example
H=mailer.fict.example [192.168.123.123] U=exim
P=smtp S=5678 id=<incoming message id>
| Адрес, немедленно сопровождаемый “<= ” - адрес отправителя конверта. Рикошет отображается с адресом отправителя “<> ”, и, если он сгенерирован локально, он сопровождается элементом в форме:
являющимся ссфлкой на сообщение, которое вызвало отсылку рикошета.
Для сообщений с других хостов, поля “H ” и “U ” идентифицируют удалённый хост и запись идентификатора RFC1413 пользователя, пославшего сообщение, если оно было принято. Число данное в кадратных скобках - IP адрес, отсылавшего хоста. Если тут единственное, не заключённое в скобки, имя хоста в поле “H ”, как выше, значит оно было проверено на соответствие IP адресу (смотрите опцию “host_lookup ”). Если имя в круглых скобках, то это имя, указанное удалённым хостом в SMTP команде HELO или EHLO, и оно не было проверено. Если проверка приводит к имени отличающемуся от данного в HELO или EHLO, проверенное имя показано первым, сопровождаемое именем HELO или EHLO в круглых скобках.
Неверно сконфигурированные хосты (и те, кто подделывает почту) иногда помещают IP адрес, с квадратными скобками, или без, в команду HELO или EHLO, приводя к записям в логах, типа этих примеров:
H=(10.21.32.43) [192.168.8.34]
H=([10.21.32.43]) [192.168.8.34]
| Это может запутывать. Можно положиться лишь на последний адрес в квадратных скобках.
Для локально сгенерённых сообщений (т.е. не переданных через TCP/IP), поле “H ” - пропущено, и поле “U ” содержит логин вызвавшего exim.
Для всех сообщений, поле “P ” определяет протокол, используемый для получения сообщения. Это значение сохраняется в “$received_protocol ”. В случае входящего SMTP сообщения, значение указывает, использовались ли расширения SMTP (ESMTP), шифрование, или аутентификация. Если сессия SMTP была шифрованная, есть дополнительное поле “X ”, в котором записан тип использовавшегося шифрования.
Протокол устанавливается в “esmtpsa ” или “esmtpa ” для сообщений переданных от хостов которые аутентифицировались, используя команду SMTP AUTH. Первое значение используется когда SMTP соединение шифрованное ( “secure ”). В этом случае, есть дополнительный пункт “A= ”, сопровождаемый именем использовавшегося аутентификатора. Если аутентифицированная идентификация была установлена аутентифкационной опцией “server_set_id ”, она также логируется, отделяемая двоеточием от имени аутентификатора.
Поле “id ” записывает существующий идентификатор сообщения, если он есть. Размер принятого сообщения даётся в поле “S ”. Когда сообщение доставляется, заголовки могут быть удалены или добавлены, таким образом, размер доставленных копий сообщений может не соответствовать этому значению (и в действительности могут отличаться друг от друга).
Опция “log_selector ” может использоваться для запроса логгинга дополнительных данных, при получении сообщения. Смотрите раздел 49.15.
49.7 Логгинг доставок
Формат однострочного вхождения в главном логе, который пишется для каждой доставки показан в одном из примеров ниже, для локальной и удалённой доставки соответсвенно. Каждый пример был разбит на две строки, чтобы вписаться в страницу:
2002-10-31 08:59:13 16ZCW1-0005MB-00 => marv
<marv@hitch.fict.example> R=localuser T=local_delivery
2002-10-31 09:00:10 16ZCW1-0005MB-00 =>
monk@holistic.fict.example R=dnslookup T=remote_smtp
H=holistic.fict.example [192.168.234.234]
| Для обычных локальных доставок, оригинальный адрес даётся в угловых скобках после финального адреса доставки, который может быть трубой или файлом. Если между оргтнальным и финальным адресом существует промежуточный, последний даётся в круглых скобках после заключительного адреса. Поля “R ” и “T ” записывают роутер и транспорт которые использовались при обработке адреса.
Если после успешной локальной доставки запускается теневой транспорт, к концу строки о успешной доставке добавляется элемент, в форме:
ST=<shadow transport name>
| Если теневой транспорт был неуспешен, сообщение о ошибке помещается в конце, в круглых скобках.
Когда в одной доставке включён более чем один адрес (например, две команды SMTP RCPT в одной транзакции), второй и последующие адреса помечаются флагами с “-> ” вместо “=> ”. Когда два и более сообщения отправляются по одному SMTP соединению, для второго и последующих сообщений в строках логов за IP адресом вставляется звёздочка.
Генерация сообщения с ответом, путём файла фильтра, логгируется как “доставка ” на адрес, которому предшествует “> ”.
Опция “log_selector ” может использоваться для запроса логгинга дополнительных данных, при получении сообщения. Смотрите раздел 49.15.
49.8 Доставки от которых отказались
Когда от сообщения отказались, как разультат команды “seen finish ” появившейся в файле фильтра, который не генерит никаких доставок, в логи записывается вхождение такой формы:
2002-12-10 00:50:49 16auJc-0001UB-00 => discarded
<low.club@bridge.example> R=userforward
| для указаний, почему не залоггированы никакие доставки. Когда от сообщения отказываются по причине что альяс привёл к “:blackhole: ” (чёрная дыра - /dev/null - прим. lissyara), строка логов будет такой:
1999-03-02 09:44:33 10HmaX-0005vi-00 => :blackhole:
<hole@nowhere.example> R=blackhole_router
|
49.9 Отсроченные доставки
Когда сообщение задержано, логгируется строка следующей формы:
2002-12-19 16:20:23 16aiQz-0002Q5-00 == marvin@endrest.example
R=dnslookup T=smtp defer (146): Connection refused
| В случае удалённых доставок, ошибка - то, что давалось для последнего пробовавшегося IP адреса. Детали индивидуальной SMTP ошибки также пишутся в лог, таким образом, вышеупомянутой строке предшествовало бы что-то вроде этого:
2002-12-19 16:20:23 16aiQz-0002Q5-00 Failed to connect to
mail1.endrest.example [192.168.239.239]: Connection refused
| Когда задержанный адрес пропускается, поскольку не наступило его времяя повтора, в лог записывается сообщение, но это может быть подавлено путём установки соответствующего значения в “log_selector ”.
49.10 Ошибки доставки
Если доставка неуспешна по причине невозможности сроутить адрес, логгируется строка такой формы:
1995-12-19 16:20:23 0tRiQz-0002Q5-00 ** jim@trek99.example
<jim@trek99.example>: unknown mail domain
| Если доставка неудачна в транспортное время, показываются роутер и транспорт, и включается ответ удалённого хоста, как в этом примере:
2002-07-11 07:14:17 17SXDU-000189-00 ** ace400@pb.example
R=dnslookup T=remote_smtp: SMTP error from remote mailer
after pipelined RCPT TO:<ace400@pb.example>: host
pbmail3.py.example [192.168.63.111]: 553 5.3.0
<ace400@pb.example>...Addressee unknown
| Слово “pipelined ” указывает, что было использовано расширение SMTP PIPELINING. Смотрите “hosts_avoid_esmtp ” в транспорте “smtp ” для способа отключения PIPELINING. Строки логов для всех форм неудачной доставки помечаются флагом “** ”.
49.11 Поддельные доставки
Если доставка, фактически, не имела места, поскольку для её подавления использовалась опция “-N ”, в лог пишется обычная строка доставки, исключая, что “=> ” заменяется на “*> ”.
49.12 Завершение
Строка в форме
2002-10-31 09:00:11 16ZCW1-0005MB-00 Completed
| пишется в главный лог когда сообщение должно быть удалено из спула, в конце его обработки.
49.13 Краткое изложение полей в строках логов
Краткое изложение идентификаторов полей, которые используются в строках логов, показано в следующей таблице:
Идентификатор
|
Значение
|
A
|
имя аутентификатора (и опциональный id)
|
С
|
подтверждение SMTP после доставки
|
-
|
список команд в “no mail in SMTP session ”
|
CV
|
статус проверки сертификата
|
D
|
длительность “no mail in SMTP session ”
|
DN
|
характерное имя от сертификата узла
|
DT
|
в строке => - время затраченное на доставку
|
F
|
адрес отправителя (в строках доставки)
|
H
|
имя хоста и IP адрес
|
I
|
используемый локальный интерфейс
|
id
|
идентификатор сообщения для входящего сообщения
|
P
|
в строке <= - используемый протокол
|
P
|
в => и ** строках - обратный путь
|
QT
|
в строках => - время нахождения в очереди на данный момент
|
QT
|
в строках “Completed ” - время нахождения в очереди
|
R
|
в строках <= - ссылка для локального рикошета
|
R
|
в ** и == строках - имя роутера
|
S
|
размер сообщения
|
ST
|
имя теневого транспорта
|
T
|
в строках <= - тема сообщения
|
T
|
в ** и == строках - имя транспорта
|
U
|
локальный пользователь или идентификатор RFC1413
|
X
|
способ шифрования TLS
|
|
49.14 Другие записи логов
Различные иные типы записей время от времени пишутся в логи. Большинство из них - очевидны. Чаще всего:
“retry time not reached ” - предварительно, адрес подвергся временной ошибке при роутинге, или локальной доставке, и время его повтора ещё не наступило. Это сообщение не пишется в индивидуальный файл лога, если это не происходит во время первой попытки доставки.
“retry time not reached for any host ” - предварительно, адрес подвергся временной ошибке в процессе удалённой доставки, и ни для одного из хостов, к которым был сроучен адрес, не наступило время повтора.
“spool file locked ” - Попытка доставки сообщения не может произойти, поскольку некоторые иной процесс exim`a уже работают над ним. Это довольно обычно, если процесс обработки очереди запускается через короткие интервалы. Сервисный скрипт “exiwhat ” может быть использован чтобы узнать, чем занимаются процессы exim`a.
“error ignored ” - есть несколько обстоятельств, которые могут привести к этому сообщению:
1. Exim не может доставить рикошет, чей возрас больше чем “ignore_bounce_errors_after ”. От рикошета отказываются.
2. Файл фильтра установил доставку используя опцию “noerror ”, и доставка неудачна. От доставки отказываются.
3. Доставка настроенная путём роутера сконфигурированного с
неудачна. От доставки отказываются.
49.15 Сокращение или увеличение того, что логгируется
Путём установки глобальной опции “log_selector ”, вы можете отключить некоторое дефолтовое логгирование exim`a, или вы можете запросить дополнительный логгинг. Значение “log_selector ” составлено из имён, с предшествующем символом плюса или минуса. Например:
log_selector = +arguments -retry_defer
| Список опциональных элементов лога, указаны в следующей таблице, с дефолтовым значением отмеченным звёздочкой:
элемент
|
значение
|
*acl_warn_skipped
|
пропущенное в ACL утверждение “warn ”
|
address_rewrite
|
перезапись адреса
|
all_parents
|
все родители в => строке
|
arguments
|
аргументы командной строки
|
*connection_reject
|
отклонения соединений
|
*delay_delivery
|
задержка немедленной доставки
|
deliver_time
|
время затраченнное на выполнение доставки
|
delivery_size
|
добавляет S=nnn в строки =>
|
*dnslist_defer
|
задержки поисков в списках DNS (RBL)
|
*etrn
|
команды ETRN
|
*host_lookup_failed
|
в названии опции всё сказано
|
ident_timeout
|
таймаут соединения ident
|
incoming_interface
|
входящий интерфейс в строке <=
|
incoming_port
|
входящий порт в строке <=
|
*lost_incoming_connection
|
что сказано в названии опции (включая таймауты)
|
outgoing_port
|
добавляет удалённый порт к строке =>
|
*queue_run
|
начало и завершение обработки очереди
|
queue_time
|
время в очереди для одного получателя
|
queue_time_overall
|
время в очереди для всего сообщения
|
pid
|
идентификатор процесса exim'a
|
received_recipients
|
получатели в cтроках <=
|
received_recipients
|
отправители в строках <=
|
*rejected_header
|
содержимое заголовка в логе отклонённых
|
*retry_defer
|
“retry time not reached ”
|
return_path_on_delivery
|
помещает путь возврата в строки => и **
|
sender_on_delivery
|
добавляет отправителя к строкам =>
|
*sender_verify_fail
|
ошибка проверки отправителя
|
*size_reject
|
отклонение по причине слишком большого размера
|
*skip_delivery
|
пропуск доставки в обработчике очереди
|
smtp_confirmation
|
подтверждение SMTP в строках =>
|
smtp_connection
|
подключения SMTP
|
smtp_incomplete_transaction
|
незавершенная транзакция SMTP
|
smtp_no_mail
|
сессия без команд MAIL
|
smtp_protocol_error
|
ошибки протокола SMTP
|
smtp_syntax_error
|
ошибки синтаксиса SMTP
|
subject
|
содержимое Subject: в строках <=
|
tls_certificate_verified
|
статус проверки сертификата
|
*tls_cipher
|
метод шифрования TLS в строках <= и =>
|
tls_peerdn
|
TLS узел DN в строках <= и =>
|
unknown_in_list
|
неудача поиска DNS при сравнении списка
|
-
|
-
|
all
|
все вышеупомянутые
|
|
Дополнительные детали для каждого из этих элементов таковы:
“acl_warn_skipped ”: Когда пропускается “warn ” утверждение ACL, поскольку одно из его условий не может быть оценено, о этом эффекте записывается строка лога, если этот селектор установлен.
“address_rewrite ”: Это применяется к обоим перезаписям, - глобальной и транспортной, но не к перезаписи в фильтрах, работающих от непривелигированного пользователя (поскольку такой пользователь не имеет доступа к логам).
“all_parents ”: Обычно, лишь оригинальный и финальный адреса логгируются в строках доставки; с этим селектором, промежуточные предки даются между ними, в круглых скобках.
“arguments ”: Это вызывает запись exim`ом аргументов, с которыми он был вызван, в главный лог, предшествуемые текущей рабочей директорией. Это - отладочная возможность, добавленная для облегчения узнавания того, как некоторые MUA вызывают вызывают “/usr/sbin/sendmail ”. Логгинг не происходит, если exim отказался от root`овых привилегий, поскольку он вызывается с опциями “-C ” или “-D ”. Аргументы которые пусты, или которые содержат пустое пространство - помещаются в кавычки. Непечатаемые символы показываются в последовательностях начинающихся с обратной косой черты. Это средство не может логгировать нераспознанные аргументы, поскольку аргументы проверяются до чтения конфигурационного файла. Единственный способ логгировать такие случаи - вставка скрипта, типа “util/logargs.sh ”, между вызывающим и exim`ом.
“connection_reject ”: Запись в лог производится каждый раз когда отклоняется входящее SMTP подключение, по любой причине.
“delay_delivery ”: Запись в лог производится каждый раз когда процесс доставки не запускается для входящего сообщения, поскольку загрузка слишком высока, или слишком много сообщений передано в одном соединении. Логгирования не происходит, если процесс доставки не начат по причине что установлена опция “queue_only ” или используется “-odq ”.
“deliver_time ”: Для каждой доставки, количество реального времени затраченного на реальную доставку логгируется как DT=<time>, например, DT=1s.
“delivery_size ”: Для каждой доставки, размер сообщения добавляется к строке “=> ”, с тегом “S= ”.
“dnslist_defer ”: Запись в логи делается если попытка поиска хоста в чёрных списках DNS возвращает временную ошибку.
“etrn ”: Каждая полученная действительная команда ETRN логгируется, до запуска ACL, фактически определяющей, принята она или нет. Неверная команда ERTN, или переданная во время обработки сообщения - не логгируется этим селектором (смотрите “smtp_syntax_error ” и “smtp_protocol_error ”).
“host_lookup_failed ”: Когда поиск IP-адресов хоста не в состоянии найти какой-либо адрес, или когда поиск по IP адресу не возвращает имени, в логи записывается строка. Этот логгинг не применяется к прямым поискам DNS при роутинге почтовых адресов, но он применяется к поискам “по имени ”.
“ident_timeout ”: Строка в лог записывается каждый раз когда попытка подключиться к клиентскому порту ident привела к таймауту.
“incoming_interface ”: Интерфейс на котором получено сообщение добавляется к строке “<= ” как IP-адрес в квадратных скобках, помеченный путём “I= ” и сопровождаемый двоеточием и номером порта. Локальный интерфейс и порт также добавляется к прочим стркам логов SMTP, например, “SMTP connection from ”, и строкам о отклонениях.
“incoming_port ”: Удалённый номер порта, с которого было получено сообщение, добавляется к записям логов и строкам заголовков “Received: ”, сопровождаемый IP-адресом в квадратных скобках, и отделённый от него двоеточием. Это осуществляется путём изменения значения помещённого в переменные “$sender_fullhost ” и “$sender_rcvhost ”. Запись удалённого номера порта стала более важной в связи с использованием NAT (смотрите RFC2505).
“lost_incoming_connection ”: Строка лога записывается когда входящее SMTP соединение неожиданно обрывается.
“outgoing_port ”: Номер удалённого порта, добавляемый к строкам доставки (которые содержат тэг “=> ”), сопровождаемый IP-адресом. Эта опция не включена в дефолтовые настройки, поскольку в большинстве обычных конфигураций удалённый порт всегда 25 (порт SMTP).
“pid ”: Текущий идентификатор процесса добавляется к каждой строке лога, в квадратных скобках, сразу после даты и времени
“queue_run ”: Логгирование запуска и завершения обработки очереди.
“queue_time ”: Количество времени, которое сообщение находилось в очереди на локальном хосте логгируется как “QT=<time> ” в строках доставки (=>), например, QT=3m45s. Часы запускаются когда exim начинает приём сообщения, таким образом оно включает время приёма как и время доставки для текущего адреса. Это означает, что оно может быть больше чем разница между временем прибытия и временем доставки в логе, поскольку строка лога о прибытии не пишется, пока сообщение не будет успешно получено.
“queue_time_overall ”: Количество времени которое сообщение было в очереди на локальном хосте логгируется как “QT=<time> ” в строках “Completed ”, например, QT=3m45s. Часы запускаются когда exim начинает приём сообщения, таким образом оно включает время приёма как и полное время доставки.
“received_recipients ”: Получатели сообщения перечислены в главном логе, как только получено сообщение. Список появляется в конце строки лога, которая записывается когда сообщение приянто, предшествуемый словом “for ”. Адреса пеерчислены после того как они были квалифицированы, но до того как имела место перезапись адресов. Получатели от которых отказались из-за ACL для MAIL или RCPT не фигурируют в этом списке.
“received_sender ”: Не перезаписанный оригинальный отправитель сообщения добавляется в конце строки лога, которая записывается по прибытии сообщения, после слова “from ” (до получателей, если, также, установлена “received_recipients ”).
“rejected_header ”: Если во время записи о отклонении, в лог отклонённых, был получен заголовок сообщения, полный заголовок добавляется в лог. Логгинг заголовков может быть индивидуально отключен для сообщений которые были отклонены функцией “local_scan() ” (смотрите раздел 42.2).
“retry_defer ”: Строка лога записывается, если доставка задержана по причине что не достигнуто время повтора. Однако, сообщение “retry time not reached ” всегда пропускается от индивидуальных логов сообщений, после первой попытки доставки.
“return_path_on_delivery ”: Путь возврата, который передаётся с сообщением, включается в строки доставки и рикошета, используя тэг “P= ”. Он пропускается, если не было фактической доставки, например, при неудаче роутинга, или при доставке в “/dev/null ”, или в “:blackhole: ”.
“sender_on_delivery ”: Адрес отправителя сообщения, добавляемый к каждой строке доствки и рикошета, помеченный “F= ” (для “from ”). Это - оригинальный отправитель, который передан с сообщением; он - не обязательно то же самое, что и исходящий путь возврата.
“sender_verify_fail ”: Если этот селектор не установлен, не пишется отдельная строка о ошибке проверки отправителя. Строка лога для отклонения SMTP команд содержит лишь “sender verify failed ”, таким образом, некоторые детали теряются.
“size_reject ”: Каждый раз, когда сообщение отклоняется потому, что слишком велико, пишется строка лога.
“skip_delivery ”: Строка лога пишется каждый раз, когда сообщение пропущено в течение работы очереди, поскольку оно заморожено, или поскольку его уже доставляет иной процесс. Сообщение которое пишется - “spool file is locked ”.
“smtp_confirmation ”: Ответ на финальную “. ” в диалоге SMTP для исходящего сообщения добавляется в строку лога доставки, в форме “C=<text> ”. Большинство MTA (включая exim), в этом ответе, возвращают идентификационную строку.
“smtp_connection ”: Строка лога пишется каждый раз, когда SMTP соединение установлено или закрыто, исключая соединения от хостов которые совпадают с “hosts_connection_nolog ”. (В противоположность, “lost_incoming_connection ” - применется лишь когда закрытие неожиданное.) Она применяется к соединениям от локальных процессов, которые используют “-bs ”, точно так же как и к подключениям по TCP/IP. Если соединение разорвано в середине сообщения, строка лога пишется всегда, вне зависимости от установки этого селектора, если же он не установлен, то в начале и в конце соединнеия ничё не пишется.
Для TCP/IP соединений к даемону exim`a, число текущих соединений включается в сообщение лога для каждого нового соединения, но записывается, что счётчик сброшен, если даемон перезапущен. Также, поскольку соединения закрываются (и закрытие логгируется) в подпроцессах, счётчик может не включать соединения, которые были закрыты, но чьё завершение ещё не заметил даемон. Таким образом, когда возможно совпадение открытия и закрытия соединений в логе, значение логгируемого счётчика может быть не совсем точным.
“smtp_incomplete_transaction ”: Когда почтовая транзакция прервана по причине RSET, QUIT, потери соединения, или как-то иначе, инцидент логгируется, и отправитель сообщения плюс любые принятые получатели включаются в строку лога. Это может предостваить очевидные доказательства атак по словарю.
“smtp_no_mail ”: Строка пишется в главный лог всякий раз когда принятое SMTP соединение завершается без отданное команды MAIL. Это включает оба случая - когда соединение уничтожено, и случай когда использовалось QUIT. Это не включает случай когда соединение отвергнуто в начале (путём ACL, или поскольку слишком много соединений, или ещё почему-то). Эти случаи уже имеют собственные записи в логах.
Записываемые строки логов содержат средства идентификации клиента в обычной форме, сопровождаемые “D= ” и временем, которое записывает длительность соединения. Если соединение аутентифицировано, этот факт логгируется точно также как для входящих сообщений, с элементом “A= ”. Если соединение зашифровано, могут появляться элементы “CV= ”, “DN= ” и “X= ”, также как для входящего сообщения, контролируемые теми же самыми опциями логгирования.
В конце, если любая SMTP команда была отдана в процессе соединения, к строке лога добаляется элемент “C= ”, листинг использовавшихся команд. Например:
показывает что клиент выдал команду QUIT сразу после EHLO. Если команд более 20, показываются последние 20, предваряемые “... ”. Однако, установка по умолчанию - 10 для “smtp_accep_max_nonmail ”, и, соединение будет в лбюом случае оборвано до обработки 20 не-MAIL команд.
“smtp_protocol_error ”: Строка лога пишется для каждой встреченной ошибки протокола SMTP. Exim не обладает прекрасным обранужением всех ошибок протокола, из-за задержек передачи и конвейерных обработок. Если клиент оповещался о PIPELINING, сервер exim предполагает что клиент будет его использовать, и поэтому не подсчитывает “ожидаемые ” ошибки (например, RCPT переданную после отклонённого MAIL) как ошибки протокола.
“smtp_syntax_error ”: Строка лога пишется для каждой встреченной ошибки синтаксиса SMTP. Нераспознанная команда рассматривается как ошибка синтаксиса. Для внешних соединений, даётся идентификатор хоста; для внутренних соединений использующих “-bs ”, даётся идентификатор отправителя (обычно - вызывающий пользователь).
“subject ”: Тема сообщения добавляется в строку лога прибытия, с предшествующим “T= ” ( “T ” - “topic ”, т.к. “S ” уже используется для “size ”). Любые “слова ” MIME в теме - декодируются. Опция “print_topbitchars ” задаёт, должны ли символы с кодом более 127 регистрироваться неизменными, или они должны быть превращены в последовательности с обратным слэшом.
“tls_certificate_verified ”: Дополнительный пункт добавляется к строке “<= ” и “=> ”, когда используется TLS. Элемент “CV=yes ” - если сертификат узла был проверен, и “CV=no ” - если нет.
“tls_cipher ”: Когда сообщение посылается или принимается через шифрованное соединение, используемый метод шифрования добавляется к строке лога, с предшествующим “X= ”.
“tls_peerdn ”: Когда сообщение посылается или принимается через шифрованное соединение, и сетификат предоставляется удалёным хостом, DN узла добавляется к строке лога, с предшествующим “DN= ”.
“unknown_in_list ”: "nf установка вызывает запись в лог когда результат сравнения списка неудачен по причине неудачи поиска в DNS.
49.16 Лог сообщения
В дополнение к главному файлу логов, exim пишет лог-файл для каждого сообщения, которое он обрабатывает. Имена этих персональных логов для сообщений - идентификаторы сообщений, и они хранятся в субдиректории “msglog ” директории спула. Каждый лог сообщения содержит копии строк логов, которые касаются сообщения. Это облегчает выяснение статуса индивидуального сообщения без необходимости поиска по главному логу. Лог сообщения удаляется после завершения обработки сообщения, если не задана “preserve_message_logs ”, но она должна использоваться с большой осторожностью, поскольку логи могут очень быстро заполнить ваш диск.
На сильно загруженных системах, может быть желательным отключить использование персональных логов сообщений, для уменьшения дискового ввода-вывода. Это может быть сделано путём установки опции “message_logs ” в ложь.
=============
translated by lissyara
verifying by Gerk
Ссылка на обсуждение: http://forum.lissyara.su/viewforum.php?f=20.
|
|
2014-07-27, lissyara
gmirror
Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9
Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту
Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis
Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS
Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT
В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat
Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp
Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration
Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster
HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS
История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire
Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной
Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server
Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-07, lissyara
Canon/gphotofs
Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec
Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash
Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT
Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3
Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN
На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm
Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
2010-04-30, gonzo111
proftpd file auth"a
Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
2010-04-22, lissyara
tw_cli
Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
2010-04-14, fox
MySQL Master+Master
MySQL (Master Master) and (Master Slave) Как настроить репликацию…
2010-03-09, terminus
DNS zones
Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
2010-03-09, aspera
Squid+AD (group access)
Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
2010-03-02, BlackCat
Шлюз: Часть 4
Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
2010-03-01, BlackCat
Шлюз: Часть 3
Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
2010-03-01, BlackCat
Шлюз: Часть 2
Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
2010-03-01, BlackCat
Шлюз: Часть 1
Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
2010-02-23, Morty
darkstat
Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
2010-01-23, gonzo111
squid+sams+sqstat
Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
2009-12-19, schizoid
mpd5 + radius + ng_car + Abills
Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
2009-11-16, lissyara
UFS->ZFS
Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
2009-11-13, gx_ua
fusefs-ntfs
Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
2009-11-12, Morty
LiveCD
Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
2009-09-27, lissyara
Samba как PDC
Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
2009-08-30, terminus
ipfw nat
Подробное руководство по ipfw nat, сложные случаи конфигурации.
2009-08-24, levantuev
HotSpot
Установка Hotspot системы в общественное заведение.
2009-08-18, lissyara
diskless
Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
2009-07-29, BAV_Lug
Видеонаблюдение
Настройка бюджетного варианта видеонаблюдения на удаленном объекте
2009-07-22, Cancer
OpenLDAP адресная книга
Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
2009-06-30, SergeySL
AimSniff
Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
2009-06-25, atrium
Управление правами доступа
Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
2009-06-16, DNK
Exim+PgSQL
Установка почтовой системы exim+pgsql на FreeBSD 7.1
2009-05-30, mvalery
HDD(mbr) -> HDD(gpt)
Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
2009-05-22, Cancer
SendXMPP
Отправка сообщений на Джаббер сервер по средствам SendXMPP
2009-05-11, Raven2000
Network UPS Tools
Network UPS Tools представляет собой набор программ, которые обеспечивают общий
интерфейс для мониторинга и администрирование UPS оборудования.
2009-04-29, m0ps
IPSEC over GRE with RIP
Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
2009-04-24, WhiteBear777
qemu network
Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
2009-04-22, vp
freebsd + huawei 162 gsm modem
В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
2009-04-12, mvalery
Мониторинг RAID
Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
2009-04-09, texnotronic
RAID1 via LAN
Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
2009-04-03, Raven2000
Оптимизация хоста для CMS
В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и ~10 сайтов/CMS.
2009-04-01, atrium
VSFTPD + AD && MySQL
Настройка самого безопасного сервера FTP - vsftpd.
2009-03-31, Dron
Peoplenet + C-motech (3G)
Описание подключения к сети Peoplenet посредством 3G модема С-motech CCu-650U на FreeBSD
2009-03-25, lissyara
mod_auth_external
mod_auth_external - авторизация пользователей в apache c помощью внешней программы - например, системных пользователей.
2009-03-24, gx_ua
Lightsquid
Частично lightsquid может заменить sams: быстрая и простая инсталляция, быстрый парсер, cgi скрипт для динамической генерации отчета, нет привязки к БД, различные графические отчеты, мультиязычный инт
2009-03-18, LHC
Установка Zabbix-1.6
Установка и первоначальная настройка системы мониторинга Zabbix (версия 1.6)
2009-03-16, Cancer
Принт-Сервер Samba+LPD & AD
Простейшая настройка Принт-Сервера на FreeBSD используя Samba+LPD & AD
2009-03-04, Mad_caterpillar
ipsec_vpnc
Настройка VPN IPSec концентратора на FreeBSD 6.2 для клиента cisco с использованием ipsec-tools и авторизацией в активной директории
2009-02-18, Andy
Free-SA
Программа анализирует log файлы Squid'а и формирует по ним отчет.
2009-02-02, Cancer
Openfire Jabber Server
Установка Jabber сервера на примере Openfire
2009-01-28, Cancer
mpd5 + сжатие и шифрование
Установка VPN сервера mpd5 + сжатие и шифрование
2009-01-26, vp
freebsd + webcamera
Подключение и настройка вебмкамеры для работы с freebsd на примере Logitech QCam STX
2009-01-10, Grishun_U_S
конфиг для офисов
В статье разбирается конфиг для офиса, пользователи которого имеют строгие ограничения по портам. Заворачиваем www трафик на транспарентный прокси, а остальное NAT'им. Эффективно делим канал интернет
2008-12-27, Storoge
sftp+chroot
Возникла необходимость дать возможность нескольким пользователям заливать на сервер контент для своих сайтов через sftp, чтобы при этом не страдала безопасность.
2008-12-13, Morty
PurefFTPd
Администрирование pureftpd-сервера с помощью вэб интерфейса Usermanager
2008-12-11, lissyara
termlog
Небольшая простая утилита, использующаяся для записи в файл всего что происходит на терминалах системы. Полезно, когда есть доступ по ssh у тех, кому не очень доверяете. Паранойя - это не плохо =)
|