Настройка системы INN

Итак, мы инсталлировали систему INN и запустили демон innd. Более того, мы не получили сообщений об ошибках и процесс innd выполняется на системе. Настала пора возложить на innd

реальные функции. Для этого нужно внести в конфигурационные файлы изменения, отражающие наши потребности. Для начала погасим демон innd

с помощью команды:

ctlinnd shutdown configure

Теперь мы смело можем править конфигурационные файлы пакета INN (главное, не пугаться их количества :-)). По умолчанию они находятся в каталоге /var/news/etc. Естественно, прежде чем редактировать файлы надо иметь представление о том, как функционирует пакет INN (Вы ведь прочитали ).

Попробуем выяснить, что нам может предложить провайдер (или любые хосты, которые согласны снабжать нас новостями). Для этого получим список новостей, на которые он подписан. Один из способов получения списка следующий. Воспользуемся командой пакета INN:

getlist -h newsserver.our.pro > active.provider

Созданный вышестоящей командой файл active.provider

содержит список групп новостей, на которые подписан наш провайдер. Выберем из этого списка те группы, на которые мы действительно хотим подписаться и пропишем их в нашем файле . Например, если Вы хотите подписаться на конференцию 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:

Теперь назначим различные глобальные параметры сервера новостей (имя сервера, имя домена) и параметры, используемые при формировании заголовков статей, публикуемых у нас. Эта информация хранится в файле

Определимся теперь с клиентами нашего сервера новостей (хосты, которые через программу чтения новостей общаются с нашим сервером). Например, мы хотим ограничить пространство пользования ресурсами нашего сервера новостей нашей Интранет-сетью (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, а от нас требуется только дать ей соответствующие указания в файле (ну, и, конечно, запускать механизм очистки - об этом ). Мы должны указать в этом файле, во-первых - срок хранения идентификаторов статей в файле 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.
Для проверки файла на наличие неверных строк, можно дать следующую команду:

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

поможет нам в этом) и насладиться его работой!

Содержание раздела