Сервер новостей InterNetNews (INN)

1. Введение
2. Общая схема настройки сервера новостей
3. Инсталляция пакета INN
4. Краткое описание работы системы INN
5. Настройка системы INN
   • Файл active
   • Файл expire.ctl
   • Файл inn.conf
   • Файл hosts.nntp
   • Файл newsfeeds
   • Файл nnrp.access

---

Введение

Пакет 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

Процесс инсталляции пакета 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.

---

Краткое описание работы системы INN

Во время загрузки системы в качестве пользователя 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

Итак, мы инсталлировали систему 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 -v). Мы можем ограничить работу 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 поможет нам в этом) и насладиться его работой!

---

Файл active

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

        name    himark  lomark  flags

Ниже описывается значение параметров:

• name - имя группы новостей;
• himark - номер самой новой статьи в данной группе новостей на локальном сервере. Это число увеличивается при получении новых статей;
• lomark - номер самой старой статьи в данной группе новостей на локальном сервере. Это число изменяется в результате удаления старых статей на диске;
• flags - это поле определяет один из шести возможных флагов:
  • y - для данной группы новостей разрешена локальная публикация;
  • n - для данной группы новостей не разрешена локальная публикация;
  • m - данная группа с ведущим (модератором) и все публикации должны быть одобрены ведущим;
  • j - статьи из данной группы новостей не храняться на локальном сервере (на самом деле они помещаются в группу junk, которая обязательно должна быть указана в файле active), а только передаются через него;
  • x - статьи не могут посылаться в данную группу новостей;
  • =news.group - статьи для данной группы новостей помещаются локально в группу news.group.

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

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

           ctlinnd newgroup relcom.humor y
   

   добавляет группу новостей "relcom.humor" с флагом "y" (см. выше), помещая соответствующие строки в файлах active и active.times. Файл active.times содержит информацию о времени создания новой группы новостей (и о том, кто ее создал), которая используется некоторыми программами чтения новостей (Trumpet одна из них) для оповещения своих пользователей о наличии новых групп новостей.
2. Второй подход - непосредственное редактирование файла 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.ctl

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

        /remember/:время

где время - срок хранения в днях (можно указывать и дробную часть дня, наприме, /remember/:7.5 - семь с половиной дней), по истечении которого из системы удаляются идентификаторы старых статей. Последующие командные строки определяют когда нужно удалять из системы тела статей. Они имеют следующий формат:

        pattern:modflag:keep:default:purge

Ниже описывается значение параметров:

• pattern - образец для групп новостей в wildmat-формате, для которых применяется остаток данной строки;
• modflag - флаг, используемый для дальнейшего ограничения списка групп новостей, для которых использовать данную строку. Если это поле:
  • М - то применять остаток данной строки только для групп с ведущим (moderated groups) из тех, которые соответствуют образцу pattern первого поля;
  • U - то применять остаток данной строки только для групп без ведущего (unmoderated groups) из тех, которые соответствуют образцу pattern первого поля;
  • A - то применять остаток данной строки для всех групп новостей, соответствущих образцу pattern первого поля.
  Следующие 3 поля определяют какое количество дней хранить тела статей на локальном сервере новостей:
• keep - определяет минимальное число дней хранения тел статей на системе для определяемых групп новостей. Любая статья из этих групп не может хранится меньше указанного этим полем срока (если Expires-заголовок статьи имеет меньший срок, то будет использовано значение keep).
• default - определяет число дней хранения для тех статей из определяемых групп, у которых отсутствует заголовок Expires.
• purge - определяет максимальное число дней хранения тел статей на системе для определяемых групп новостей. Любая статья из этих групп не может хранится больше указанного этим полем срока (если Expires-заголовок статьи имеет больший срок, то будет использовано значение purge).

Помимо строки /remember/ Вы должны указать строку с pattern '*' и modflag 'A'. Эта строка является строкой по умолчанию для срока хранения всех статей на системе. При этом она обязательно должна стоять раньше, чем строки с образцами для конкретных групп, поскольку этот файл проверяется программой expire до конца и последняя соответствующая группе новостей строка будет использована.

Например, мы хотим после удаления тела статьи хранить ее идентификатор в базе данных в течение 5-ти дней. Тела статей будут храниться на системе от 3-ех до 5-ти дней, за исключением локальных конференций, которые мы хотим хранить подольше (в течение 10-ти дней). Тогда наш файл будет выглядеть так:

        /remember/:5
        *:A:3:4:5
        local*:A:10:10:10

---

Файл inn.conf

Файл inn.conf содержит различные глобальные параметры сервера новостей (имя сервера, имя домена) и параметры, используемые при формировании заголовков статей (начавших свой путешествие по Usenet с этого сервера). Все изменения, сделанные в этом файле считываются демоном innd только после перезагрузки сервера новостей. Строки в этом файле имеют следующий формат:

        имя: [возможны пробелы] значение

Здесь имя - имя параметра, значение - его значение. Некоторые параметры могут быть изменены определением переменных окружения системы. Ниже описываются имена параметров и их значения:

• fromhost - этот параметр используется при формировании заголовка From:, если того нет. Переменная окружения FROMHOST затирает это значение. По умолчанию, это полное доменное имя локальной машины.
• moderatormailer - имя машины, содержащей псевдонимы для всех управляемых (moderated) групп. Этот параметр используется только если нужную информацию нельзя почерпнуть из файла moderators.
• organization - определяет содержимое заголовка Organization:, если он пуст. Если определена переменная окружения ORGANIZATION, то она изменяет это значение.
• pathhost - определяет, какое имя локального узла помещается в заголовок Path:. По умолчанию, это полное доменное имя локальной машины. Это очень важный параметр, поскольку заголовок Path: просматривается сервером при приеме статьи и в зависимости от файла newsfeeds принимает решение, что делать со статьей.
• server - определяет имя NNTP сервера, на котором должны публиковаться созданные статьи. Если определена переменная окружения NNTPSERVER, то она изменяет это значение.
• domain - определяет имя домена, к которому принадлежит локальная машина. Этот параметр используется, если подпрограмма GetFQDN из библиотеки libinn не может получить полного доменного имени при вызове функций gethostname или gethostbyname.

Следующие три параметра используются только демоном nnrpd при приеме публикаций от клиентов:

• mime-version - этот параметр определяет версию MIME (Многоцелевые расширения электронной почты для Internet). Если nnrpd принимая статью от клиента не обнаруживает в ней заголовка Mime-Version, то он добавляет этот заголовок, используя данный параметр.
• mime-contenttype - если был добавлен заголовок Mime-Version, то этот параметр формирует заголовок Content-Type. Значение по умолчанию: "text/plain; charset=US-ASCII".
• mime-encoding - если был добавлен заголовок Mime-Version, то этот параметр формирует заголовок Content-Transfer-Encoding. Значение по умолчанию: "7bit".

Ниже приведен пример этого файла на машине news.our.domain:

        fromhost :              news.our.domain
        organization :          Kari Ltd.
        pathhost :              news.our.domain
        server :                news.our.domain
        domain :                our.domain
        mime-version :          1.0
        mime-contenttype :      text/plain; charset=KOI8-R
        mime-encoding :         8bit

---

Файл hosts.nntp

Файл hosts.nntp содержит информацию о том, какие хосты могут снабжать локальный сервер новостями, используя NNTP протокол. Информация из этого файла считывается в память демоном innd при запуске, либо при получении определенного указания демону innd от программы ctlinnd. Когда удаленная машина соединяется с NNTP портом системы INN, демон innd сверяет ее IP-адрес с адресами машин, перечисленных в файле hosts.nntp. Если демон не находит соответствующей записи для данной машины в этом файле, то он "порождает" процесс nnrpd, который обслуживает данное соединение. Запомните: Вы НЕ сможете передавать потоки новостей по NNTP на удаленный сервер новостей INN, пока тот не пропишет Вас (вашу машину) корректно в своем файле hosts.nntp. Строки этого файла имеют следующий формат:

        address:password:pattern

Ниже описываются значения полей:

• address - IP адрес или полное доменное имя удаленного NNTP-хоста, которому разрешено передавать потоки новостей на локальный сервер. Заметим, что если NNTP хост имеет несколько адресов, то все они должны быть перечислены в этом файле;
• password - определяет пароль для удаленной машины, требуемый от нее при первом соединении с локальным сервером новостей (чаще всего это поле пустое);
• pattern - образцы в формате wildmat для имен групп новостей, статьи из которых принимаются на локальный сервер от машины с данным address. Это позволяет ограничить прием групп новостей от NNTP соседей, которые посылают Вам все без разбора.

После изменений в файле hosts.nntp не забудьте дать команду демону innd перечитать этот файл (вместо причины edit можно указать любой текст, который определяет причину перезагрузки файла):

        ctlinnd reload hosts.nntp edit

Файл newsfeeds

Файл 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, то она проверяется на возможность отправки (если, конечно она удовлетворяет "списку подписки" данного узла) в соответствии со следующими правилами:
  1. Если заголовок Distribution: соответствует любому значению distrib, то статья ставится на отправку;
  2. Если distrib начинается со знака "!" и заголовок Distribution: соответствует этому значению distrib, то статья не ставится на отправку;
  3. Если заголовок Distribution: не соответствует ни одному из значений distrib, и есть по-крайней мере один distrib не начинающийся со знака "!", то статья не ставится на отправку;
  4. Если заголовок 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*\
            :Tc, Wnm, S1024\
            :/usr/news/bin/nntplink -i stdin newsserver.our.provider
    

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

          ME:*, !junk, !control*, !local*::
          netlab:!junk::
          ace:local*::
  

  говорят о том, что начальный список рассылки для всех соседей предполагает все группы, кроме "junk", "control*" и локальных групп новостей "local*". Узел netlab использует в точности начальный список расылки. Однако образец local* для узла ace позволяет ему получать локальные группы новостей, изменяя тем самым образец !local* в описании потока с именем ME.

  Если 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 определяет права, предоставляемые клиентам. Возможны два значения этого параметра:
    1. R (или Read) - клиент может запрашивать статьи с сервера;
    2. P (или Post) - клиент может публиковать статьи на сервере;
  • username - имя, которое пользователь на машине-клиенте должен использовать при аутентификации себя, чтобы получить доступ к статьям новостей на сервере. Если это поле пустое, то аутентификация не нужна;
  • 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 новых соединений.

  ---

  Copyright (C) by Yuri V. Savin, 1998. E-Mail: msav@kari.ru