Шрифт:
шаблон_хостов:права_доступа:имя_пользователя:пароль:шаблон_имен_групп
– шаблон_хостов – задает шаблон для сравнения с хостом клиента и может использовать как имена, так и адреса с сетевой маской;
– права_доступа – перечень букв, которые определяют права клиента, зашедшего с соответствующего адреса:
· R – клиент имеет право на чтение;
· P – клиент имеет право на посылку;
· N – клиент может использовать команду newnews, несмотря на глобальный запрет;
· L – клиент может посылать статьи в группы с запретом на локальную посылку;
· полное_имя_файла – формат файла такой же, как и основного, права доступа уточняются, исходя из него;
– имя_пользователя – пустое, если аутентификация клиента не нужна;
– пароль – пустой, если аутентификация клиента не нужна;
– шаблон_имен_групп – список шаблонов имен групп через запятую, к которым клиент должен иметь доступ;
• /etc/news/nnrpd.track – файл позволяет nmpd записывать в журнал доступа определенную строку текста вместо имени или адреса хоста клиента. Состоит из строк вида:шаблон_имен_или_адресов_хостов:строка_идентифицирующая_пользователя
• /etc/news/nntpsend.ctl – файл определяет список хостов, на которые nntpsend будет рассылать статьи, если имя хоста не указано явно при запуске. Каждая строка определяет отдельный хост и имеет вид:
сайт:fqdn:size:параметры
– сайт – имя, указанное в newsfeeds;
– fqdn – полное доменное имя хоста, на который должны быть посланы статьи;
– size – размер для обрезания пакета заданий, если он станет слишком большим;
– параметры – параметры для innxmit;
• /etc/news/overview.ctl – файл используется для создания файла истории сообщений overview при использовании новых способов хранения статей;
• /etc/news/overview.fmt – файл определяет, какие заголовки будут храниться в файле истории сообщений overview;
• /etc/news/passwd.nntp – в этом файле хранятся пароли для доступа к NNTP-серверам;
• /etc/news/storage.conf – файл определяет параметры для нестандартных методов хранения статей. Для каждого класса определяется своя структура хранения.Файл active
Этот файл содержит список групп новостей, которые принимает локальный сервер. Все статьи, опубликованные в группы новостей, которые не указаны в файле active, отвергаются локальным сервером новостей. Строки в этом файле имеют следующий формат:
Имя старшая_метка младшая_метка флаги
где:
• имя – имя группы новостей;
• старшая_метка – номер самой новой статьи в данной группе новостей на локальном сервере. Это число увеличивается при получении новых статей;
• младшая_метка – номер самой старой статьи в данной группе новостей на локальном сервере. Это число изменяется в результате удаления старых статей на диске;
• флаги – это поле определяет один из шести возможных флагов:
– 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 дня):