Корпоративный сервер новостей.
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
Удачной Вам конфигурации и использования, хоть технология и устарела, тем не менее часто применяется в корпоративных сетях.