Linux - Алексей Стахнов

• флаги – это поле определяет один из шести возможных флагов:

– y – для данной группы новостей разрешена локальная публикация;

– n – для данной группы новостей не разрешена локальная публикация;

– m – данная группа модерируемая, и все публикации должны быть одобрены модератором;

– j – статьи из данной группы новостей не хранятся на локальном сервере, а только передаются через него;

– x – статьи не могут посылаться в данную группу новостей;

– =news. group – статьи для данной группы новостей помещаются локально в группу news.group.

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

Существуют два основных подхода к выполнению указанных выше операций с группами новостей.

• Первый подход – использование соответствующих подкоманд команды ctlinnd – newgroup, rmgroup и changegroup.

• Второй подход – непосредственное редактирование файла active. Такой подход удобен для операций с большим количеством групп.

Файлы базы данных и журналы

Список файлов базы данных и их стандартное размещение приведено ниже.

• /var/lib/news/.news.daily

• /var/lib/news/history

• /var/lib/news/active

• /var/lib/news/newsgroups

• /var/lib/news/active.times

• /var/lib/news/subscriptions

• /var/lib/news/distributions

Список файлов журналов и их стандартное размещение приведено ниже.

• /var/log/news

• /var/log/news/news.err

• /var/log/news/OLD

• /var/log/news/news.notice

• /var/log/news/news.crit

Сами статьи находятся в следующих файлах:

• /var/spool/news/archive

• /var/spool/news/innfeed

• /var/spool/news/articles

• /var/spool/news/outgoing

• /var/spool/news/incoming

• /var/spool/news/overview

• /var/spool/news/incoming/bad

• /var/spool/news/uniover

Настройка списка получаемых групп новостей

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

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

Созданный этой командой файл active.provider содержит список групп новостей, на которые подписан наш провайдер. Выберем из списка те группы, на которые мы действительно хотим подписаться, и пропишем их в нашем файле active. Например, если вы хотите подписаться на конференцию relcom.humor, добавьте в этот файл примерно следующее:

relcom.humor 0000000000 0000000001 у

Если вы хотите принимать все (или почти все) группы новостей, на которые подписан ваш провайдер, то файл 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:

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

*: А:3:4:5

local*:А:5:6:7

Заметим, что значение по умолчанию (образец *) должно фигурировать раньше, чем строки для отдельных групп, поскольку применяется последнее соответствие образцу в первом поле.

Важным шагом после редактирования конфигурационных файлов является проверка корректности сделанных нами изменений. Система INN имеет ряд средств, помогающих нам в решении этой задачи. Вот некоторые из них.

• Для поиска ошибок в файле newsfeeds можно дать следующую команду:

innd -s

Например, если вы получили в ответ следующее:

Found 1 errors –see syslog

то это значит, что командой обнаружена одна ошибка, о которой сообщается через syslog в файлах news.err и news.notice. • Для проверки файла active на наличие неверных строк можно дать следующую команду:

expire -n -х -t

Например, если в ответ получено следующее:

/var/news/etc/active: line 5 wrong number of fields

то это значит, что вы ошиблись с количеством полей в 5-й строке этого файла (их должно быть 4). Однако это не лучший способ проверки файла active. В частности, expire не замечает отсутствие флага для группы новостей (в отличие от inncheck). Итак, обратим внимание на inncheck – Рег1-сценарий, предназначенный для проверки всех рассматриваемых нами конфигурационных файлов. Помимо проверки файлов на наличие синтаксических ошибок, он может осуществлять проверку прав доступа к файлам их владельцев. Возвращаясь к примеру выше (отсутствие флага в конце строки файла active), inncheck сообщит вам об этой ошибке:

/var/news/etc/active:5: ends with whitespace

Запущенный без параметров, inncheck проверит синтаксис всех файлов (которые может проверить), с выводом на экран сообщений об ошибках. Если мы укажем опцию v (режим verbose), то inncheck расскажет нам о том, что он просматривает. Мы можем ограничить работу inncheck проверкой синтаксиса конкретного файла, дав команду inncheck имя_файла. Для того чтобы проверить корректность прав доступа к файлам и корректность владельцев и групп файлов, можно дать команду inncheck -perm. Ту же информацию, да еще и с указанием того, какие команды надо выполнить, чтобы устранить ошибки, дает команда inncheck -f -perm. Последний шаг настройки – периодически запускать программу отправки статей с нашей машины, программу чистки каталога статей и обобщения log-файлов. Для этого отредактируем таблицу заданий пользователя news для демона сгоп:

crontab -u news -е

Ваш редактор (определенный переменной окружения 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 минут каждого часа из сгоп будем вызывать программу sendbatch:

37 * * * * /usr/news/bin/sendbatch -с provider > /dev/null 2>&1 &

Ну что ж, теперь можно запустить демон innd (rc.news поможет нам в этом) и насладиться его работой!

Журналирование пакета INN