Сервер новостей InterNetNews (INN)
Юрий Савин
- Введение
- Общая схема настройки сервера
новостей
- Инсталляция пакета INN
- Краткое описание работы системы INN
- Настройка системы INN
- Logging системы INN
Пакет INN, автором которого является Рич Солц (Rich
Salz), представляет полнофункциональный пакет
программ для построения сервера новостей. Для
взаимодействия с другими машинами используется
стандартный протокол NNTP. Как и любой сервер
новостей, система INN предполагает наличие по
крайней мере одного поставщика новостей, а также
наличие хостов, которым новости отсылаются (NNTP
соседей называют newsfeeders). Кроме того, у сервера
имеются клиенты, которые через "читалку
новостей" обращаются к серверу для чтения
и/или публикации новостей.
Статьи (articles) в Usenet классифицируются по
телеконференциям, которые подобно каталогам
файловой системы имеют иерархическую структуру.
Новости хранятся на сервере в дереве каталогов,
имена которых формируются путем замены точек
слэшами ("/"). Например, статьи из группы
relcom.fido.ru.unix хранятся в каталоге /var/news/spool/articles/relcom/fido/ru/unix.
- Выделить место на диске для хранения дерева
статей Usenet (в INN /var/news/spool).
- Инсталлировать один из пакетов программ
телеконференций (например, INN).
- Найти поставщика новостей и выяснить имя
сервера поставщика.
- Сообщить поставщику имя своего сервера
новостей и список телеконференций, которые Вы
хотели бы получать.
- Внести всю необходимую информацию в
конфигурационные файлы.
- Запустить демон новостей и ждать, когда
структура новостей начнет заполняться статьями.
- Это еще не все. Структуру надо иногда очищать.
Для этого из демона cron необходимо запускать
сценарии сопровождения и очистки новостей.
Процесс инсталляции пакета INN идентичен для
Unix-основанных систем, но каждая платформа имеет
свои особенности инсталляции. Описанная ниже
последовательность действий ориентирована на
FreeBSD (пакет inn-1.7.2 ставился на FreeBSD-2.2.5).
Во-первых, Вам необходимо заполучить
свеженький дистрибутив INN. Обратитесь на сервер ftp.isc.org и перейдите в каталог isc/inn. Выберите необходимый
архив (например, inn-1.7.2.tar.gz),
перекачайте, декомпрессируйте и разархивируйте
его, поместив результат в выбранный Вами каталог
(в дальнейшем он упоминается как $inn).
Сменив текущий каталог на $inn, Вы обнаружите
два файла формата nroff, использующие макрос -ms: Install.ms.1
и Install.ms.2. Это две части оффициального
руководства по инсталляции InterNetNews.
Дайте команду
make Install.ms
При этом два файла объединяются в один - Install.ms
с правами доступа 444. Приведите этот файл в более
читабельный вид (в частности, для просмотра с
помощью more) командой:
nroff -ms Install.ms > Install
При возникновении проблем в инсталляции пакета
необходимо обращаться за помощью к этому файлу.
Следующий этап процедуры инсталляции -
редактирование главного файла конфигурации сonfig.data.
В каталоге $inn/sample-configs содержатся шаблоны
файла config.data для различных платформ. Вам
необходимо выбрать наиболее подходящий для Вас
файл и скопировать его в $inn/config/config.data,
например, для FreeBSD выполните следующие команды:
cd $inn
cp sample-configs/config.data-FreeBSD-2.0 config/config.data
Теперь настала пора отредактировать сам файл config.data.
INN получает из этого файла информацию о своей
среде (т.е. где лежат компоненты, используемые INN).;
Для пользователей FreeBSD надо подкорректировать
опции для LIBS:
LIBS -lutil -lcrypt
Пакет поставляется с некоторыми perl-сценариями,
требующими пакет языка perl версии не ниже, чем 5.001,
так что Вам, возможно, придется установить новый
пакет языка perl и прописать корректный путь к
команде perl:
_PATH_PERL /usr/local/bin/perl
Подробное описание содержимого файла config.data
смотрите в файле Install.
Скомпилируйте все исходники:
cd $inn
make all
Перед инсталляцией компонентов пакета
необходимо создать каталоги, куда они будут
помещены:
mkdir /usr/news /var/news /var/news/spool
Теперь можно инсталлировать компоненты пакета
INN. Если Вы ставите пакет в первый раз на эту
систему, то просто дайте команду:
make install
Если же Вы заменяете уже существующую систему
INN, то рекомендуется инсталлировать отдельно
программы и отдельно конфигурационные файлы и
сценарии. Это позволит не затирать
конфигурационные файлы текущей INN системы. Итак,
сначала запустите сценарий:
makedirs.sh
Он создаст все остальные каталоги (ниже
созданных командой mkdir на предыдущем этапе).
Заметим, что команда make install вызывает этот
сценарий сама. Теперь инсталлируйте программы и
руководства (man'ы):
make update
При этом сценарии и конфигурационные файлы
будут скопированы из каталога $inn/samples в
каталог $inn/site. Если Вы хотите сохранить
настройки предыдущей версии INN, затрите файлы из
каталога $inn/site такими же файлами из старого
программного обеспечения, после чего:
cd $inn/site
make install
Запуск сценария:
$inn/BUILD
позволит создать файлы active и history.
После запуска сценария, он спросит, использовать
ли с-версию subst (если она существует):
-- do you want to use it [y or n]? y
Далее он спросит построили ли Вы бинарники:
Have you already built the executables [y or n]? y
Затем он спросит существуют ли каталоги spool, etc
и т.д.:
Do the spool, etc., directories exist [y or n]? y
Следующим вопросом будет: желаете ли Вы
продолжить инсталляцию:
Do you want to continue with the installation [y or n]? y
И, наконец, последний ворос: запускать ли subshell
для редактирования конфигурационных файлов:
Start a subshell to edit the config files [y or n]? n
После завершения работы сценария проверьте,
что владельцем файла active является
пользователь news, группа news, права доступа на него
644, а если это не так (а практика показывает что в
сценарии действительно что-то не так :-)), то
исправьте это, дав команды
chmod 644 active
chown news:news active
Сделайте почтовый псевдоним для пользователя news
в файле /etc/mail/aliases:
usenet: news
Дайте знать об этом sendmail, перестроив после
редактирования файла базу псевдонимов:
/usr/bin/newaliases
INN оповещает о своей работе, используя систему syslog.
Проверьте конфигурационный файл демона syslogd /etc/syslog.conf.
Раскомментируйте в этом файле строки, содержащие
news.crit, news.err, news.notice. После этого не забудьте
создать соответствующие файлы в каталоге /var/log/news
(владелец - news, группа -news, права доступа -
664).
Заметим, что, если Ваш файл newsfeeds
не содержит строк с указанием "питающихся" у
Вас сторон, кроме строки ME, то демон innd при
запуске выдаст ошибку: "SERVER bad_newsfeeds no feeding sites".
Для того, чтобы успокоить сервер, на начальной
стадии Вы можете прописать холостой поток:
dummy-feed:!*::
Добавьте в .profileпользователя root пути
поиска в новых каталогах:
PATH=$PATH:/usr/news/bin:/var/news
Для чтения руководств с помощью команды man,
добавьте строку в файле /etc/manpath.config:
MANDATORY_MANPATH /usr/news/man
Поместите запуск демона innd в сценарий rc.local:
/usr/news/bin/rc.news > /dev/console
Проверьте наличие строки
DOINNWATCH=true
в файле rc.news. Это позволит использовать
утилиту innwatch.ctl, которая "гасит" сервер
новостей, когда Ваш диск переполнился и
предотвращает крушение системы.
Перезагрузите машину и проверьте, работает ли
демон innd. Во-первых, должен быть
соответствующий процесс, запущенный
пользователем news:
ps -U news | grep inn
Во-вторых, дав команду
telnet localhost nntp
Вы должны увидеть примерно следующее:
Trying 127.0.0.1
Connected to localhost.your.domain.
Escape character is '^]'.
200 news.your.domain InterNetNews server INN 1.7.2 ready
Чтобы увидеть, какие команды понимает этот
news-сервер, дайте команду help. Для возврата из
сеанса telnet обратно в shell, дайте команду quit.
Во время загрузки системы в качестве
пользователя root запускается сценарий rc.news
(хорошее место для запуска - файл /etc/rc.local). В
результате чего выполняется демон innd
(посмотрите процесс командой ps -U news | grep inn).
Эта программа прослушивает порт NNTP (TCP-port 119) на
наличие входящих соединений. Если соединяются
локальные клиенты для чтения новостей, то innd
передает дальнейшее управление демону nnrpd,
вызывая его. Этот демон просматривает файл nnrp.access для определения прав доступа
к локальной базе статей. Если соединяются
поставщики новостей (они должны быть прописаны в
файле hosts.nntp), то innd принимает
статьи (просматривая файлы hosts.nntp и active)
и размещает их на Вашем диске (по умолчанию в
каталоге /var/news/spool/articles).
В функции innd не входит отсылка новостей с
локальной машины, для этого предназначены другие
программы. Как только статья получена от
поставщиков, она распространяется на все
NNTP-машины, которые подписаны на конкретную
телеконференцию у данной машины. Конкретно, куда
и каким образом статьи будут отправляться с
локального сервера определяется в файле newsfeeds. Программа, отвечающая за
отправку статей (например, nntpsend, nntplink, send-nntp
- программы транспортировки по NNTP, или sendbatch -
программа транспортировки по UUCP) читает файл newsfeeds
и передает статьи в заданном направлении.
Если Вы используете nntpsend, то Вы должны
отредактировать файл nntpsend.ctl (хотя все можно
прописать в файле newsfeeds). Список статей на
отправку записывается в файл, который обычно
хранится в каталоге /var/news/spool/out.going. Имя этого
файла, как правило, совпадает с именем NNTP-соседа,
указанного в файле newsfeeds. Для того, чтобы в
один "прекрасный" момент диск не
переполнился, старые статьи надо удалять. Это
делается с помощью сценария news.daily. Он
вызывает программу expire, которая
просматривает файл expire.ctl (в нем
указывается срок хранения статей) для
обнаружения и удаления статей с устекшим сроком
хранения. Этот же сценарий предназначен для
каждодневного отчета о работе INN.
Итак, мы инсталлировали систему INN и запустили
демон innd. Более того, мы не получили сообщений
об ошибках и процесс innd выполняется на
системе. Настала пора возложить на innd
реальные функции. Для этого нужно внести в
конфигурационные файлы изменения, отражающие
наши потребности. Для начала погасим демон innd
с помощью команды:
ctlinnd shutdown configure
Теперь мы смело можем править конфигурационные
файлы пакета INN (главное, не пугаться их
количества :-)). По умолчанию они находятся в
каталоге /var/news/etc. Естественно, прежде чем
редактировать файлы надо иметь представление о
том, как функционирует пакет INN (Вы ведь прочитали
главу 4).
Попробуем выяснить, что нам может предложить
провайдер (или любые хосты, которые согласны
снабжать нас новостями). Для этого получим список
новостей, на которые он подписан. Один из
способов получения списка следующий.
Воспользуемся командой пакета INN:
getlist -h newsserver.our.pro > active.provider
Созданный вышестоящей командой файл active.provider
содержит список групп новостей, на которые
подписан наш провайдер. Выберем из этого списка
те группы, на которые мы действительно хотим
подписаться и пропишем их в нашем файле active.
Например, если Вы хотите подписаться на
конференцию relcom.humor, добавьте в этот файл
примерно следующее:
relcom.humor 0000000000 0000000001 y
Если Вы хотите принимать все (или почти все)
группы новостей, на которые подписан Ваш
провайдер, то файл active можно получить из active.provider,
"прогнав" того через следующий сценарий (он
обнуляет два средних поля каждой строки):
#!/bin/sh
sed < active.provider > active \
-e 's/^\([^ ]*\) [0-9]* [0-9]* \([^ ]*\)$/\1 0000000000
0000000000 \2/'
Наш файл active готов (он содержит строки для
всех групп, которые поддерживает наш сервер), но
надо сообщить и провайдеру о нашем выборе (чтобы
он знал какие группы новостей ему нужно
пересылать на наш хост).
Даже если провайдер пропишет нас в своей
конфигурации сервера новостей, он не сможет
скидывать нам новости по NNTP. Мы должны дать ему
разрешение на это. Для этого добавим строчку в
файл hosts.nntp:
newsserver.our.provider:
Здесь надо заметить, что мы полагаемся на
провайдера: мы знаем, что он будет снабжать нас
только теми конференциями, о которых мы его
попросили. Если же Вы не доверяете своим
NNTP-соседям, то можно указать конкретно шаблон
конференций, которые Вы принимаете на локальный
диск от конкретного NNTP-соседа. Например, мы хотим
принимать от newsserver.our.badprovider только relcom'овские
группы новостей:
newsserver.our.badprovider::relcom.*
Отредактируем файл newsfeeds, указав
всех NNTP-соседей, которых мы хотим снабжать
статьями. Не забудем указать в этом файле своего
провайдера. Ниже приведены два примера этого
файла. В первом случае мы планируем снабжать
статьями хост newsserver.our.provider по NNTP (используя
программу nntpsend, о том как ее вызывать будет
сказано позднее):
ME:*, !junk, !control*, !local*/!local::
newsserver.our.provider:*, !junk, !control*,
!local*:Tf, Wnm:newsserver.our.provider
Во втором случае мы хотим снабжать этот же хост
по UUCP (имя этой uucp-системы provider), используя
программу sendbatch (опять же о том, как ее
вызывать, будет сказано позднее):
ME:*, !junk, !control*, !local*/!local::
provider/newsserver.our.provider:*, !junk, !control*, !local*:Tf, Wnb:
Теперь назначим различные глобальные
параметры сервера новостей (имя сервера, имя
домена) и параметры, используемые при
формировании заголовков статей, публикуемых у
нас. Эта информация хранится в файле inn.conf.
Определимся теперь с клиентами нашего сервера
новостей (хосты, которые через программу чтения
новостей общаются с нашим сервером). Например, мы
хотим ограничить пространство пользования
ресурсами нашего сервера новостей нашей
Интранет-сетью (192.168.111.0/255.255.255.0) и нашей внешней
сетью (домен our.domain), причем пользователям этих
сетей мы разрешаем и читать новости, и
публиковать их на наш сервер. Ах, да, мы чуть не
забыли о наших хороших партнерах из домена
partner.domain (правда, им нечего делать в наших
локальных конференциях). Ну, а для остальных
поместим первым правило, запрещающее все и вся.
Для этого добавим строки в файл nnrp.access:
*:: -no- : -no- :!*
192.168.111.*:Read Post:::*
*.our.domain:Read Post:::*
*.partner.domain:Read Post:::*, !local*
Как только мы начнем получать статьи на
локальный диск, надо будет следить за сроком их
хранения на диске и удалять старые (диск же не
резиновый :-)). К счастью, за нас это будет делать
программа expire, а от нас требуется только дать
ей соответствующие указания в файле expire.ctl
(ну, и, конечно, запускать механизм очистки - об
этом ниже). Мы должны указать в этом
файле, во-первых - срок хранения идентификаторов
статей в файле history (это делается для того,
чтобы не принимать заново удаленные статьи),
во-вторых - срок хранения самих тел статей. Пример
ниже говорит о том, что запись об идентификаторе
статей хранится в файле history 14 дней после
удаления тела этих статей, тела статей из
локальных телеконференций хранятся на системе
от 5 до 7 дней (по умолчанию 6), а для всех остальных
телеконференций тела хранятся от 3 до 5 дней (по
умолчанию - 4 дня):
/remember/:14
*:A:3:4:5
local*:A:5:6:7
Заметим, что значение по умолчанию (образец '*')
должно фигурировать раньше, чем строки для
отдельных групп, поскольку применяется
последнее соответствие образцу в первом поле.
Важным шагом после редактирования
конфигурационных файлов является проверка
корректности сделанных нами изменений. Система
INN имеет ряд средств, помогающих нам в решении
этой задачи. Вот некоторые из них:
- Для поиска ошибок в файле newsfeeds
можно дать следующую команду
innd -s
Например, если Вы получили в ответ следующее:
Found 1 errors --see syslog
то это значит, что командой обнаружена одна
ошибка, о которой сообщается через syslog в файлах
news.err и news.notice.
- Для проверки файла active на
наличие неверных строк, можно дать следующую
команду:
expire -n -x -t
Например, если Вы получили в ответ следующее:
/var/news/etc/active: line 5 wrong number of fields
то это значит, что Вы ошиблись с количеством
полей в 5-той строке этого файла (их должно быть 4).
Однако, это не лучший способ проверки этого
файла. В частности, expire не замечает
отсутствие флага для группы новостей (в отличие
от inncheck).
- Итак, inncheck - perl-сценарий, предназначенный для
проверки всех рассматриваемых нами
конфигурационных файлов. Помимо проверки файлов
на наличие синтаксических ошибок, он может
осуществлять проверку прав доступа к файлам и их
владельцев. Возвращаясь к примеру выше
(отсутствие флага в конце строки файла active), inncheck
сообщит Вам об этой ошибке:
/var/news/etc/active:5: ends with whitespace
Запущенный без параметров, inncheck проверит
синтаксис всех файлов (которые может проверить),
с выводом на экран сообщений об ошибках. Если мы
укажем опцию -v (verbose режим), то inncheck расскажет
нам о том, что он просматривает. Мы можем
ограничить работу inncheck проверкой синтаксиса
конкретного файла, дав команду inncheck {файл}.
Для того, чтобы проверить корректность прав
доступа к файлам и корректность владельцев и
групп файлов можно дать команду inncheck -perm. Ту
же информацию, да еще и с указанием того, какие
команды надо выполнить, чтобы устранить ошибки,
дает команда
inncheck -f -perm
Последний шаг настройки -
периодически запускать программу отправки
статей с нашей машины, программу чистки каталога
статей и обобщения log-файлов. Для этого
отредактируем таблицу заданий пользователя news
для демона cron:
crontab -u news -e
Ваш любимый редактор (определенный переменной
окружения EDITOR) откроет файл /var/cron/tabs/news.
Ежедневно в 4 часа утра мы будем запускать
сценарий news.daily, в функции которого входит
обобщение и ротация файлов регистрации, прогон
программы expire и др. Далее, в 1 минуту и 28 минут
каждого часа мы будем запускать программу nntpsend
для отправки потоков статей по NNTP нашим соседям.
0 4 * * * /usr/news/bin/news.daily > /dev/null 2>&1 &
1, 28 * * * * /usr/news/bin/nntpsend > /dev/null 2>&1 &
Наконец, если мы планируем отправлять потоки
новостей по UUCP на UUCP-систему provider, то в 37 минут
каждого часа из cron'a будем вызывать программу sendbatch:
37 * * * * /usr/news/bin/sendbatch -c provider > /dev/null 2>&1 &
Ну что ж, теперь можно запустить демон innd (rc.news
поможет нам в этом) и насладиться его работой!
Этот файл содержит список групп новостей,
которые принимает локальный сервер. Содержимое
файла считывается демоном innd при запуске,
либо при получении этим демоном
соответствующего указания от программы ctlinnd.
Все статьи, опубликованные в группы новостей,
которые не указаны в файле active отвергаются
локальным сервером новостей. Строки в этом файле
имеют следующий формат:
name himark lomark flags
Ниже описывается значение параметров:
- name - имя группы новостей;
- himark - номер самой новой статьи в данной
группе новостей на локальном сервере. Это число
увеличивается при получении новых статей;
- lomark - номер самой старой статьи в данной
группе новостей на локальном сервере. Это число
изменяется в результате удаления старых статей
на диске;
- flags - это поле определяет один из шести
возможных флагов:
- y - для данной группы новостей разрешена
локальная публикация;
- n - для данной группы новостей не разрешена
локальная публикация;
- m - данная группа с ведущим (модератором) и
все публикации должны быть одобрены ведущим;
- j - статьи из данной группы новостей не
храняться на локальном сервере (на самом деле они
помещаются в группу junk, которая обязательно
должна быть указана в файле active), а только
передаются через него;
- x - статьи не могут посылаться в данную
группу новостей;
- =news.group - статьи для данной группы новостей
помещаются локально в группу news.group.
Основные операции, которые должен время от
времени выполнять администратор включают в себя
добавление новых групп, удаление ненужных групп,
изменение флагов текущих групп новостей. Все эти
операции должны отображать свои действия в файле
active. Существует два основных подхода к
выполнению указанных выше операций с группами
новостей:
- Первый подход - использование соответствующих
подкоманд команды ctlinnd: "newgroup",
"rmgroup" и "changegroup". Например, команда
ctlinnd newgroup relcom.humor y
добавляет группу новостей "relcom.humor" с
флагом "y" (см. выше), помещая соответствующие
строки в файлах active и active.times. Файл active.times
содержит информацию о времени создания новой
группы новостей (и о том, кто ее создал), которая
используется некоторыми программами чтения
новостей (Trumpet одна из них) для оповещения своих
пользователей о наличии новых групп новостей.
- Второй подход - непосредственное
редактирование файла active, удобен для
операций с большим количеством групп новостей
(попробуйте удалить несколько десятков групп с
помощью первого способа :-)), но имеет один
недостаток: он не вносит автоматических
изменений в файл active.times. Общая
последовательность действий такова:
- Приостановить работу демона innd (входящие
соединения при этом не принимаются):
ctlinnd pause "edit active"
- Отредактировать файл active. Например, при
добавлении группы "relcom.humor", Вы должны
добавить следующую строку в этот файл (флаг может
быть и другим):
relcom.humor 0000000000 0000000001 y
- Проверить корректность изменений в файле active,
дав команду:
inncheck active
- Считать в память новую копию файла active:
ctlinnd reload active "edit active"
- Восстановить работу сервера innd:
ctlinnd go "edit active"
Этот файл считывается программой expire при
запуске и определяет правила очистки дерева
статей на локальном сервере (сроки хранения тел
статей и их идентификаторов). В начале этого
файла обязательно должна находится строка
(причем, только одна), определяющая как долго
хранить записи об идентификаторах статей в файле
history, после того, как тело статьи удалено. Это
позволяет отклонить эту статью, если поставщик
новостей вновь предложит ее в определенный
промежуток времени. Эта строка имеет следующий
формат:
/remember/:время
где время - срок хранения в днях (можно
указывать и дробную часть дня, наприме, /remember/:7.5
- семь с половиной дней), по истечении которого из
системы удаляются идентификаторы старых статей.
Последующие командные строки определяют когда
нужно удалять из системы тела статей. Они имеют
следующий формат:
pattern:modflag:keep:default:purge
Ниже описывается значение параметров:
Помимо строки /remember/ Вы должны указать строку с pattern
'*' и modflag 'A'. Эта строка является строкой по
умолчанию для срока хранения всех статей на
системе. При этом она обязательно должна
стоять раньше, чем строки с образцами для
конкретных групп, поскольку этот файл
проверяется программой expire до конца и
последняя соответствующая группе новостей
строка будет использована.
Например, мы хотим после удаления тела статьи
хранить ее идентификатор в базе данных в течение
5-ти дней. Тела статей будут храниться на системе
от 3-ех до 5-ти дней, за исключением локальных
конференций, которые мы хотим хранить подольше (в
течение 10-ти дней). Тогда наш файл будет выглядеть
так:
/remember/:5
*:A:3:4:5
local*:A:10:10:10
Файл inn.conf содержит различные глобальные
параметры сервера новостей (имя сервера, имя
домена) и параметры, используемые при
формировании заголовков статей (начавших свой
путешествие по Usenet с этого сервера). Все
изменения, сделанные в этом файле считываются
демоном innd только после перезагрузки сервера
новостей. Строки в этом файле имеют следующий
формат:
имя: [возможны пробелы] значение
Здесь имя - имя параметра, значение
- его значение. Некоторые параметры могут быть
изменены определением переменных окружения
системы. Ниже описываются имена параметров и их
значения:
- fromhost - этот параметр используется при
формировании заголовка From:, если того нет.
Переменная окружения FROMHOST затирает это значение.
По умолчанию, это полное доменное имя локальной
машины.
- moderatormailer - имя машины, содержащей псевдонимы
для всех управляемых (moderated) групп. Этот параметр
используется только если нужную информацию
нельзя почерпнуть из файла moderators.
- organization - определяет содержимое заголовка
Organization:, если он пуст. Если определена переменная
окружения ORGANIZATION, то она изменяет это значение.
- pathhost - определяет, какое имя
локального узла помещается в заголовок Path:. По
умолчанию, это полное доменное имя
Logging системы INN.
Итак, конфигурационные файлы отредактированы,
система 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, в котором
сообщает время завершения своей работы.
Copyright (C) by Yuri V. Savin, 1998.
Copyright ©
