Logging системы INN
28.Дек.24
Загрузоки:
Комментарии ()
Прросмотры:
58
Файл newsfeeds содержит информацию о том, какие статьи и каким образом необходимо пересылать на соседние NNTP узлы. Информация из этого файла считывается в память демоном innd при запуске, либо при получении определенного указания демону innd от программы ctlinnd. Для каждого узла, с которым Вы обмениваетесь новостями должно быть соответствующее описание в этом файле (feed entries). В дальнейшем feed entry для NNTP-узла упоминается как поток новостей для этого узла.
Описание потока новостей имеет следующий формат:
sitename:[/exclude, exclude, ...]\В квадратных скобках - необязательные параметры, обратный слэш ("\") - склеивание этой строки с последующей. Ниже описывается значение параметров.
:pattern, pattern...[/distrib, distrib, ...]\
:flag, flag, ...\
:param
- sitename - имя удаленного узла, которому передаются статьи. Во-первых, это имя используется при записи информации в файлы регистрации (log файлы). Во-вторых, это имя используется при определении нужно ли статью передавать на данный узел: если sitename фигурирует в заголовке Path данной статьи, то она не будет поставлена в очередь на отправку на этот узел (она уже там есть или была). Значение этого параметра обычно совпадает со значением параметра pathhost в файле inn.conf на удаленном узле (Для того, чтобы узнать параметр pathhost дайте telnet на nntp-порт удаленного узла: Вы увидите сообщение 200 sitename...). В-третьих, это имя используется в качестве метки в файле nntpsend.ctl, если Вы его используете.
- exclude - если это имя фигурирует в заголовке Path данной статьи, то она не будет поставлена в очередь на отправку на этот узел.
- pattern - образцы в формате wildmat для имен групп новостей,
которые необходимо пересылать на данный узел. Эти образцы сверяются со
списком групп новостей, которые получает локальная машина (в файле active).
"Список подписки" по умолчанию - все группы новостей. Если первый символ
образца - восклицательный знак, то все группы, соответствующие образцу
будут удалены из "списка подписки", иначе они будут добавлены к группам
на отправку. Вы можете также запретить отправку статей, написанных в определенную
группу новостей, даже если эти статьи были распространены в другие группы,
на которые данный узел "подписан". Для этого используйте первым символом
в образце знак "@". Например, статья посылается ее составителем в группы
alt.sex.pictures и misc.test. Вы не хотите передавать конкретному узлу
любые статьи из группы alt.sex.pictures, но в то же время этот узел получает
от Вас статьи из группы misc.test. Для решения этой проблемы в описании
потока новостей для данного узла укажите образцы:
@alt.sex.pictures, misc.test, ...:
- distrib - изменяет "список подписки". По умолчанию, все статьи,
написанные в группу, на которую подписан узел, отправляются к нему. Однако,
если статья содержит заголовок Distribution: (он формируется на основании
файла distrib.pats), и определен параметр distrib,
то она проверяется на возможность отправки (если, конечно она удовлетворяет
"списку подписки" данного узла) в соответствии со следующими правилами:
- Если заголовок Distribution: соответствует любому значению distrib, то статья ставится на отправку;
- Если distrib начинается со знака "!" и заголовок Distribution: соответствует этому значению distrib, то статья не ставится на отправку;
- Если заголовок Distribution: не соответствует ни одному из значений distrib, и есть по-крайней мере один distrib не начинающийся со знака "!", то статья не ставится на отправку;
- Если заголовок Distribution: не соответствует ни одному из значений distrib, причем все distrib начинаются со знака "!", то статья ставится на отправку.
- flag - определяет различные параметры, влияющие на формирование
буфера статей на отправку. После флага (заглавная буква) сразу, без пробела
следует значение (или значения) этого флага. С помощью флагов Вы можете
управлять отправкой статей, основываясь на их размере, содержимом заголовков
статей и др. Подробное описание флагов смотри в руководстве по newsfeeds(5).
Ниже поясняются наиболее важные из них:
- Fимя - имя файла, используемого в качестве спула для отправки статей к sitename. По умолчанию, если флаг не определен, информация о статьях на отправку к данной sitename записывается в файл /var/news/spool/out.going/sitename.
- Tтип - определяет тип потока новостей (feed) для данного узла. По умолчнию Tf - файл.
- Witems - определяет информацию, которая записывается
в файл-спул. Items указывают набор значений, записываемых в файл-спул.
Ниже некоторые из items:
.b - размер статьи в байтах (используется при UUCP-отправке);
.f - полный путь к статье;
.m -идентификатор сообщения статьи (Message-ID);
.n - путь к статье относительно спул-каталога статей (/var/news/spool/articles).Например, описание потока новостей provider:...:Tf, Wnm:..., говорит о том, что тип потока новостей для узла provider файловый; а файл /var/news/spool/out.going/provider содержит строки вида:relcom/test/1 <01bd219$1115ac@asdu.domain.ru>
relcom/humor/33 <23cd33$fh2223@netlab.domain.ru>
При описании потока новостей
provider:...:Tf, Wnb:... файл /var/news/spool/out.going/provider содержит строки вида:relcom/test/1 536
relcom/humor/33 1378- param - дополнительные параметры, зависящие от типа потока (Т). Этот параметр может быть опущен.
Некоторые значения этого поля демонстрируются на конкретных примерах:
Если Вы пользуетесь программой транспортировки nntpsend, то поле param может содержать полное доменное имя удаленного NNTP-узла; например, следующая строка говорит, что для удаленного узла newsserver.our.provider группы новостей, соответствующие образцу (все, кроме junk, control и локальных групп новостей) отправлять по адресу newsserver.our.provider:newsserver.our.provider:*, !junk, !control*, !local*:Tf, \
Wnm:newsserver.our.provider
Заметим, что если поле sitename не совпадает с полным доменным именем (например, provider), то для использования nntpsend нужно отредактировать файл nntpsend.ctl, добавив следующую строку (при этом последнее поле в файле newsfeeds нужно опустить):provider:newsserver.our.provider
Если Вы пользуетесь программой транспортировки nntplink, то тип потока - channel (Tc), а поле param содержит запуск этой программы с определенными параметрами, например:provider/newsserver.our.provider:*, !junk, !control*, !local*\
Особое значение имеет описание потока с именем ME. Это описание обязательно и должно быть первым в файле. Если ME имеет список подписки, то он является списком по умолчанию для всех последующих описаний. Если же в последующих описаниях потоков встречается образец, обратный указанному в образцах ME, то он заменяет его. Например, строки
:Tc, Wnm, S1024\
:/usr/news/bin/nntplink -i stdin newsserver.our.providerME:*, !junk, !control*, !local*::
говорят о том, что начальный список рассылки для всех соседей предполагает все группы, кроме "junk", "control*" и локальных групп новостей "local*". Узел netlab использует в точности начальный список расылки. Однако образец local* для узла ace позволяет ему получать локальные группы новостей, изменяя тем самым образец !local* в описании потока с именем ME.
netlab:!junk::
ace:local*::Если ME имеет подполе /distrib, то только статьи у которых заголовок Distribution: соответствует образцам в этом подполе будут приняты, все остальные отвергнуты. Например, чтобы отвергать все локальные статьи от ненастроенных узлов, можно указать следующую строку:
ME:*, !junk, !control*, !local*/!local::
Если Вы желаете слепо принимать все distribution, то просто не указывайте подполе /distrib.После изменений в файле newsfeeds не забудьте дать команду демону innd перечитать этот файл (вместо причины syslog можно указать любой текст, который определяет причину перезагрузки файла):
ctlinnd reload newsfeeds syslog
Файл nnrp.access
Файл nnrp.access определяет права доступа к данному NNTP узлу для клиентов-машин, обработка соединений которых передана демоном innd демону nnrpd (например, клиенты, обращающиеся к узлу при помощи программы чтения новостей). Этот файл считывается каждый раз при вызове демона nnrpd демоном innd. Все строки состоят из пяти полей, разделенных двоеточием и имеют следующий формат:
hosts:perms:username:password:patterns
Ниже описывается значение параметров:
hosts - образец в формате wildmat, определяющий группу IP-адресов или DNS имен, к которым будет применяться оставшаяся часть строки. Применяется последнее соответствие адреса клиента образцу hosts в файле;perms определяет права, предоставляемые клиентам. Возможны два значения этого параметра:
- R (или Read) - клиент может запрашивать статьи с сервера;
- P (или Post) - клиент может публиковать статьи на сервере;
password - пароль, который пользователь на машине-клиенте должен использовать при аутентификации себя, чтобы получить доступ к статьям новостей на сервере. Если это поле пустое (но не пробел), то аутентификация не нужна. Если Вы поставите пробел в этом поле, то это запретит доступ вообще, поскольку пользователь не сможет аутентифицировать себя.
patterns - образцы в формате wildmat, определяющие группы новостей, к которым у клиента есть доступ. По умолчанию запрещены все группы новостей. Чтобы наоборот, разрешить все группы новостей, поместите в этом поле "*".
Например, мы хотим ограничить пространство пользования ресурсами нашего сервера новостей нашей Интранет-сетью (192.168.111.0/255.255.255.0) и нашей внешней сетью (домен our.domain), причем пользователям этих сетей мы разрешаем и читать новости, и публиковать их на наш сервер. Ах да, мы чуть не забыли о наших хороших партнерах из домена partner.domain (правда, им нечего делать в наших локальных конференциях). Есть еще один знакомый user, работающий на хосте host.familiar.domain, которому мы разрешим пользоваться нашими ресурсами новостей, но только после аутентификации: он будет запрошен для ввода имени (user) и пароля (serge). Ну, а для остальных поместим первым правило, запрещающее все и вся. Файл будет выглядеть так:
*:: -no- : -no- :!*
192.168.111.*:Read Post:::*
*.our.domain:Read Post:::*
*.partner.domain:Read Post:::*, !local*
host.familiar.domain:Read Post:user:serge:*, !local*
Если Вы сделали изменения в файле nnrp.access, то те вступят
в силу автоматически при обработке демоном nnrpd новых соединений.
Итак, конфигурационные файлы отредактированы, система INN не обнаружила в них синтаксических ошибок, из cron'а вызываются периодические процессы системы INN, демон innd запущен. Естественное желание - убедиться, что все работает корректно. К счастью, система INN достаточно дружественная и извещает нас о своей работе (либо об ошибках, в результате которых она работать не может), используя стандартную в Unix-систему регистрации syslog. Кроме того, система INN поставляется с рядом сценариев, обобщающих информацию в log-файлах (и не только в них) и выводящих их в приятном для чтения виде. Наконец, обобщенная статистика может ежедневно отправляться по e-mail администратору сервера новостей. Об этом здесь и пойдет речь
Посмотрев конфигурациооный файл /etc/syslog.confдемона syslogd, мы увидим куда идут данные регистрации ситемы INN. Напомню, что во время инсталляции INN мы раскомментировали в этом файле строки:
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice /var/log/news/news.notice
Затем создали соответствующие файлы (их владелец - news, группа - news) и перезапустили демон syslogd.
Наиболее разрастающийся из них - news.notice. Cюда пишет innd о соединении с ним удаленных NNTP-хостов, демон nnrpd записывает сюда информацию об активности клиентов, в этом же файле информируют о своей работе программы ctlinnd, innxmit, rnews и др.
Файл news.crit содержит сообщения о критических ошибках, требующих внимания от администратора сервера новостей. (Например, сервер INN не может открыть файл из-за неверных прав доступа; или здесь появится сообщение о гашении сервера с помощью ctlinnd и т.д.).
Файл news.err содержит сообщения о фатальных
ошибках сервера. Вообще говоря трудно провести
четкую границу между информацией об ошибках,
записываемых в news.crit и news.err. (Syslogd зачастую
записывает одинаковую информацию в оба файла).
Система INN имеет помимо log-файлов, поддерживаемых системой syslog, встроенные log-файлы - errlog и news (по-умолчанию они расположены в каталоге /var/log/news).
Файл errlog содержит стандартный вывод и
стандартные ошибки любых программ, порождаемых
демоном innd. В частности, при перезагрузке
операционной системы в этом файле появится
следующая строка:
INND exiting because of signal
Файл newsрегистрирует все статьи,
поступающие к innd для обработки. Строки в этом
файле имеют следующий формат:
mon dd hh:mm:ss.mmm flag feed Message-ID [reason] size site ...
Первые три поля определяют дату поступления (с точностью до миллисекунд) статьи к демону innd. Следующее поле - флаг, определяющий действие, выполненное innd с данной статьей. Возможны 4 флага:
- "+" - статья успешно принята.
- "-" - статья отвергнута по причине [reason] (поле reason фигурирует только если статья отклонена).
- "j" - статья успешно принята, но поскольку она из групп новостей, имеющих в файле active флаг "j", она будет помещена в группу junk.
- "c" - в этом случае прежде чем поступит сама статья будет принято cancel-сообщение.
Поле feed определяет от кого статья была получена демоном innd для дальнейшей обработки. Если это поле представляет IP-адресс 0.0.0.0, то статья получена локально (nnrpd принял ее от клиента).
Поле Message-ID определяет идентификатор данной статьи.
Если статья была отвергнута, то поле [reason] определяет причину, по которой это было сделано. Причем, это поле будет последним в данной строке (поля size site ... отсутствуют).
Поле size определяет размер статьи в байтах.
Последнее поле site ... определяет список сторон, которым данная статья будет распространена (основываясь на файле newsfeeds).
Рассмотрим для примера фрагмент файла news:
Mar 28 06:06:20.340 + ace.domain.ru <6fgqr8$qun$1@simtel.ru>
27127 netlab
Mar 28 06:06:21.278 - ace.domain.ru 437 Unwanted newsgroup
"relcom.rec.puzzles"
......
Mar 31 11:31:43.818 + 0.0.0.0 <35209BDE.D94E6A66@kari.ru>
2140 ace netlab
Mar 31 14:07:57.876 + 0.0.0.0 <01bd5c8c$e11b9520$8832e9c1@bsd.kari.ru>
479 ace
первая строка говорит, что от ace.domain.ru была принята статья (опубликованная на машине домена simtel.ru) размером 27127 байт и копия статьи поставлена в очередь на отправку стороне netlab. Вторая строка говорит, что машина ace.domain.ru послала нам статью из группы новостей relcom.rec.puzzles, на которую мы не подписывались, поэтому innd отверг ее с указанием причины: 437 Unwanted newsgroup "relcom.rec.puzzles". В последних двух строках статьи размером 2140 и 479 байт были опубликованы клиентами нашего сервера с локальной машины и с хоста bsd.kari.ru, используя nnrpd, и распространены на стороны ace, netlab и ace соответственно.
Помимо перечисленных выше файлов регистрации, ряд программ системы INN ведут собственные файлы регистрации (expire.log, send-uucp.log, nntpsend.log и др.).
Програама expire оповещает о проделанной ею работе через файл expire.log. Ниже приведен пример этого файла:
expire begin Sat Mar 28 04:06:34 MSK 1998: (-v1) Article lines processed 14581 Articles retained 12437 Entries expired 2144 Files unlinked 2854 Old entries dropped 408 Old entries retained 2967 expire end Sat Mar 28 04:09:21 MSK 1998Первая и последняя строки обозначает временные границы работы программы expire -v1. Следующие строки означают, что программа expire прочитала в history-файле 14581 строк, из них оставлено 12437 строк (читай статей), т.е. удалено 2144 строки (на самом деле строка не удаляется, а "сокращается" до трех полей - message-id, дата прибытия статьи и значение заголовка Expire (либо ~, если заголовок отсутствует), поэтому в действительности - 2144 есть число удаленных тел статей). Значение Files unlinked (2854) определяет число удаленных файлов на диске; дело в том, что одна статья (одно тело) может быть опубликована в несколько групп (при этом для каждой группы создается свой файл), поэтому это значение может быть больше, нежели Entries expired. Последние два цифровых значения относятся к неполным строкам (из 3 полей), т.е. к message-id статей, тела которых уже удалены из системы. Old enties dropped (408) - число удаленных строк для статей, тела которых уже были удалены. Old entries retained (2967) - число оставленных строк для статей, тела которых уже удалены (неполных строк).
Если Вы пользуетесь программой nntpsend для
отправки статей к NNTP-соседям, то Вы обнаружите
файл nntpsend.log, в который эта программа
записывает информацию о своей работе. Например
при сеансе отправки потока новостей к NNTP-соседу
netlab при помощи nntpsend , файл nntpsend.log
пополнится примерно следующим:
nntpsend: [3560] start
nntpsend: [3560] stop
nntpsend: [3560:3611] begin netlab Wed Apr 1 11:43:37 MSD 1998
nntpsend: [3560:3611] innxmit -a netlab ...
nntpsend: [3560:3611] end netlab Wed Apr 1 11:43:39 MSD 1998
Безусловно, регулярно просматривать кипу регистрационных файлов, да еще и в не совсем удобочитаемом формате - дело не из приятных и отнимает много времени. К счастью, необходимости в этом нет. Пакет INN включает ряд сценариев, обрабатывающих log-файлы и выдающих суммарную информацию в удобном виде.
Сценарий innstat выдает "фотоснимок" системы INN. Он показывает режим работы сервера, использование дискового пространства, статус всех log- и lock- файлов.
Perl-сценарий innlog.pl выдает статистику активности демонов innd и nnrpd , обобщая информацию в регистрационных файлах системы syslog. Обычно этот сценарий вызывается другим сценарием - scanlogs.
Сценарий scanlogs обобщает информацию, записываемую в log-файлы INN. По умолчанию, он также производит ротацию и очистку ряда регистрационных файлов. В каталоге /var/log/news/OLD содержатся компрессованные файлы, полученные в результате ротации (цикл ротации - 3). Обычно scanlogs вызывается сценарием news.daily(который запускают обычно раз в сутки), поэтому в результате ротации файлов, у Вас на системе будет хранится регистрационная информация за последние трое суток плюс текущая информация.
По большому счету, Вам нет необходимости запускать перечисленные выше сценарии по отдельности. Запуская из cron'а ежедневно сценарий news.daily, администратор сервера новостей news (псевдоним usenet) будет ежедневно по почте получать полную статистику работы INN сервера, как суммарный итог работы этих сценариев.
Прежде чем разбираться, что же нам послал в письме news.daily, разберемся по шагам, что в действительности делает этот сценарий:
- Сначала он формирует Subject для будущего письма по адресу usenet@this.news.server в следующем виде: this.news.server daily usenet report for [current data]
- Вызывает сценарий innstat, который показывает статус innd (вывод команды ctlinnd mode), использование дискового пространства, размеры batch-, log- и lock-файлов в блоках по 512 байт (округление идет до следующего целого значения), а текущие соединения с сервером.
- news.daily вызывает программу expire, которая сканирует файл history и основываясь на сроках хранения статей (прописанных в файле expire.ctl) удаляет старые статьи.
- news.daily передает работу сценарию scanlogs,
который выполняет следующее:
- показывает критические ошибки от syslog (содержимое файла news.crit).
- показывает фатальные ошибки от syslog (содержимое файла news.err).
- показывает содержимое файла expire.log (о проделанной командой expire работе).
- сканирует регистрационные файлы на наличие
различных проблем относительно статей, которые
были приняты или отправлены системой, а затем
выводит для каждой категории по 20 верхних
(по-умолчанию) элементов. В частности, будут
выведены (если, конечно, есть)
- 20 сторон, отправлявших нам чаще всего (количество в первом столбце) статьи с ошибками;
- 20 сторон, посылавших нам чаще всего статьи из групп, на которые мы не подписывались;
- 20 наиболее частых из нежелательных распространений;
- 20 наиболее часто приходящих групп новостей, на которые мы не подписаны;
- 20 сторон из тех, которые наиболее часто пытались установить соединение по NNTP с нами, но не имели на то прав;
- 20 наиболее часто встречающихся основных проблем;
- 20 сторон посылавших нам чаще всего статьи с ошибочными заголовками.
- scanlogs вызывает perl-сценарий innlog.pl, который
обобщает syslog-информацию о работе innd и nnrpd
и выводит следующую статистику:
- неизвестные для сценария вхождения в файле news;
- команды, полученные демоном innd от ctlinnd;
- группы новостей, созданные через ctlinnd;
- группы новостей, удаленные через ctlinnd;
- статистика о получении демоном innd статей (по системам и итоговая информация);
- далее выводится различная innd статистика (об ошибочных ID статей, об ошибочных ihave- и sendme- сообщениях, об ошибочных командах, об отвергнутых из-за размера статей, и др.);
- статистика об отправлении статей командой innfeed (если используется);
- nntpd-статистика;
- статистика об отправлении статей командой innxmit (по системам и итого);
- попытки ( в том числе ошибочные) установления соединений для передачи статей другим системам (по системам и итого);
- nntplink-статистика (если для отправки используется эта программа);
- batcher-статистика;
- rnews-статистика;
- nnrp-статистика (статистика работы nnrp-клиентов по хостам и доменам, запросы на аутентификацию по пользователям, счетчики запросов статей по категориям и группам, ошибки при работе gethostbyaddr и др.);
- mthreads-статистика (если используется).
- после завершения работы сценария innlog.pl, scanlogsкомпрессует нужные файлы и производит их ротацию с циклом 3 (если у команды нет опции norotate), после чего возвращает управление работой сценарию news.daily;
- news.daily снова вызывает сценарий innstat, который показывает статус innd после очистки. произведенной программой expire;
- перенумерует файл active;
- из временных файлов формирует окончательное почтовое сообщение для usenet;
- и, наконец, завершает свою работу, формируя в каталоге /var/news/etc файл news.daily, в котором сообщает время завершения своей работы.
