Корпоративный сервер новостей.
20.09.2016Сегодня вы познкомитесь с процесом развертывания сервера новостей на базе Linux.
Это будет NNTP сервер. Пользователи ОС MS Windows будет подключаться к нему используя Outlook Express, Windows Mail или подобными программами, коих много существует.
Будем считать что у Вас уже установлен сервер на платформе Linux. Здесь не говорится о сервере с графическим интерфейсом. Сервер, в хорошем понимании, — это консоль.. ну да .. мелкософт — совсем другая история..
Продолжая статью, расчитываю, что вы имеете представление о пакетах. Первым делом устанавливаем пакет inn-2.5.2. У вас он может быть другой версии, а в данном примере описан именно этот вариант.
Выполняем сборку сервера командами make и configure.. Этот процесс пропускаю, так же считая что Вы умеете это делать.
Приступаем к настройке нашего сервера..
Файл inn.conf — Главный файл настройки INN. Размещен в каталоге etc установленного пакета.
У меня он получился таким (не буду описывать все параметры, покажу лишь основные):
organization: "ESRR" // отображаемое имя организации pathhost: news.esrr.mps // dns-имя сервера pathnews: /usr/local/news mailcmd: /usr/local/news/bin/innmail server: news.esrr.mps # Feed Configuration bindaddress: all maxartsize: 1000000 // максимально допустимый размер вложения вместе с телом сообщения (1 мб) maxconnections: 50 //максимальное кол-во одновременных коннектов для фида (тут линк между слинкованными серверами) port: 119 sourceaddress: any # Reading allownewnews: true clienttimeout: 600 msgidcachesize: 11000 # Posting addnntppostingdate: true addnntppostinghost: true localmaxartsize: 1000000 nnrpdpostport: 119 # Paths // пути размещения хранилищ и служебных скриптов patharchive: /usr/local/news/spool/archive patharticles: /usr/local/news/spool/articles pathbin: /usr/local/news/bin pathcontrol: /usr/local/news/bin/control pathdb: /usr/local/news/db pathetc: /usr/local/news/etc pathfilter: /usr/local/news/bin/filter pathhttp: /usr/local/news/http pathincoming: /usr/local/news/spool/incoming pathlog: /usr/local/news/log pathoutgoing: /usr/local/news/spool/outgoing pathoverview: /usr/local/news/spool/overview pathrun: /usr/local/news/run pathspool: /usr/local/news/spool pathtmp: /usr/local/news/tmp
Подробно описывать каждый параметр не вижу необходимости.
Файл incoming.conf — файл отвечаюший за взаимодействие (синхронизацию) между слинкованными ньюс-серверами (обмен статьями и комментами).
Это живой, рабочий конфиг. В нем описаны ip серверов которые могут отдавать новости мне и для каждого адреса я создал удобные мне имена, которые потом использую в файле innfeed.conf для отдачи им новостей размещаемых на моем сервере.
streaming: true # streaming allowed by default max-connections: 8 # per feed peer ME { hostname: "10.240.73.1,10.123.160.50,10.115.1.202,10.43.229.238,10.64.8.250,10.132.226.200,10.51.41.21,127.0.0.1,localhost" } peer zdr-main { hostname: "10.240.73.1" patterns: * } peer pluton { hostname: "10.123.160.50" patterns: * } peer pvrr { hostname: "10.115.1.202" patterns: * } peer nrr { hostname: "10.43.229.238" patterns: * } peer kbsh { hostname: "10.64.8.250" patterns: * } peer alt { hostname: "10.132.226.200" patterns: * } peer xzname { hostname: "10.51.41.21" patterns: * } // patterns oпределяет группы, которые принимаются от соответствующего сервера.
Файл hosts.conf — В нем IP-адреса доверенных к взаимному обмену новостями серверов.
Тут может быть указан IP сервера, либо его dns-имя. У меня он таков:
localhost: 10.240.73.1: pluton.zrw.oao.rzd: news.zrw.oao.rzd: news.pvrr.mps: news.nrr.rzd: 10.43.229.238: news.kbsh.mps: sphinx.alt.wsr.mps: 10.132.226.200: 10.51.41.21: 10.115.1.202:
Файл expire.ctl — отвечает за старение статей.
В нем отражается набор групп в которых размещены статьи. Символ «А» — означает, что правило применяется ко всем сообщениям в группе.
Следующие за этим символом числа означают время через которое статью считаем устаревшей и удаляем. Первое число — для статей имеющих поле Expires в заголовке, второе — для остальных.
*:A:1:20:25 // применимо ко всем статьям вообще. Должно быть первым правилом, если есть исключения. mps.*:A:1:20:25 // применимо к записям в ветке новостей начинающихся с mps newsmasters:A:1:20:25 irkutsk.*:A:1:20:25 esrr:A:never:never:never // эта ветка новостей мной принята для объявлений и не устаревает никогда (информация не удаляется) rzd.*:A:1:20:25
Файл innfeed.conf
Как я ранее уже писал, его стуктура похожа на incoming.conf. Вот он:
peer zdr-main { ip-name: 10.240.73.1 streaming: true } peer pvrr { ip-name: 10.115.1.202 streaming: true } peer nrr { ip-name: 10.43.229.238 streaming: true } peer kbsh { ip-name: 10.64.8.250 streaming: true } peer pluton { ip-name: 10.123.160.50 streaming: true } peer alt { ip-name: 10.132.226.200 streaming: true } peer xzname { ip-name: 10.51.41.21 streaming: true } peer skzd { ip-name: 10.51.5.167 streaming: true }
Файл newsfeeds. Не имеет расширения. Так же размещен в каталоге etc.
Очень интересный файл. Создает правила регламентирующие подачу новостных веток другим серверам и пользователям-клиентам сервера.
Не буду приводить весь его код, поскольку и двух строк хватит чтобы понять:
ME:*,!junk,!control.*,!local.*:: zdr-main:*,!junk,!control.*,!local.*,!kooler.art:Tm:innfeed!
Секция ME — отдаем для отображения на своем сервере все ветки кроме помеченных знаком «!» вначале названия.
Секция zdr-main — этому серверу так же отдаем все кроме помеченного используя технологию innfeed.
Флаг Tm определяет формирование буфера для отправки новостей, в данном случае тип потока содержит идентификатор потока новостей в виде Message-ID (символ «m»).
Файл nnrp.access.
Определяет права доступа к новостям
localhost:Read Post:::* *:Read Post:::*
Файл readers.conf
Это тот самый файл, в котором определяются детальные права доступа серверов и пользователей к чтению статей.
В нем можно не только назначить права, но и забанить пользователя (комп) на нашем сервере, ограничив его права только чтением, либо совсем закрыв ему доступ.
Основными обозначениями прав доступа применяются символы R и P.
R- разрешает чтение. (read)
P- разрешает запись. (post)
Объявляем права для самого сервера (ему можно все)
auth "localhost" { hosts: "localhost, 127.0.0.1, stdin" default: "<localhost>" } access "localhost" { users: "<localhost>" newsgroups: "*" access: RPA }
Объявляем группы и входящие в них хосты:
auth "ban-users" { hosts: "*" default: "<ban-users>" } auth "local" { hosts: "localhost, 10.51.5.167, 10.240.73.1, 10.115.1.202, 10.43.229.238, 10.64.8.250, 10.123.160.50, 10.104.0.0/16, 10.105.0.0/16, 10.106.0.0/16, 10.107.0.0/16, 10.108.0.0/16, 10.109.0.0/16, 10.110.0.0/16, 10.111.0.0/16" default: "<local>" } auth "local2" { hosts: "10.110.41.0/24" default: "<local2>" } auth "temp-ban-users" { hosts: "" default: "<ban-users>" }
Теперь для каждой группы назначим права.
Для начала все возможные хосты баним на нашем сервере,- обычная практика для рапределения ролей, после чего для каждой группы выставляем необходимые права.
access "ban-users" { users: "<ban-users>" newsgroups: "esrr" access: R }
Группе выставили разрешение только на чтение одной единственной ветки esrr.
Выше, в группе local мы описали IP серверов, с которыми обмениваемся потоками и конкретные подсети, которым даем доступ к серверу.
Выделяем им права:
access "local" { users: "<local>" newsgroups: "mps.*,irkutsk.*,krr.*,newsmasters,!esrr" access: RP }
Кодом размещенным ниже, назначаем права для компов из подсети 10.110.41.0/24 ( Как видите, у них чуть больше прав) и вообще блокируем доступ машинам прописаным в группе temp-ban-users (сюда обычно вношу IP машин для временного прекращения доступа ко всему серверу…)
access "local2" { users: "<local2>" newsgroups: "*,!control.*,!junk,!control,!esrr" access: RP } access "temp-ban-users" { users: "<ban-users>" newsgroups: "" access: }
Вот собственно и все что хотел рассказать о файлах конфигурации INND сервера.
Настало время описать некоторые полезные для админа ньюс-сервера команды.
Выполнение любой команды отправляемой для изменения параметров новостного сервера начинаем с «./ctlinnd «.
Создание группы новостей:
ctlinnd newgroup group
Удаление группы новостей:
ctlinnd rmgroup group
Отмена статьи. Редко используемая команда, но так необходимая в случае, если юзер отправил на сервер в публичный доступ информацию, которую не следовало туда подавать. Правда, если произошла синхронизация серверов или кто-то уже прочел информацию — удаление записи будет произведено только на стороне сервера, а те кто прочел ее — не перестанут видеть лишнее сообщение в своем клиенте.
ctlinnd cancel Message-Id
Удачной Вам конфигурации и использования, хоть технология и устарела, тем не менее часто применяется в корпоративных сетях.