HOWTO : fidonet software for unix

[ index ] [ areafix ] [ binkd ] [ filefix ] [ ifmail ] [ inn ] [ mgetty ] [ sendmail ] [ together ] [ stat ] [ utilities ] [ download ]

inn

В настоящее время InterNetNews package (INN) разрабатывается консорциумом ISC, URL : http://www.isc.org/products/INN/. Здесь я опишу процесс настройки INN v2.3.*. Он значительно отличается от v2.2.*, описание которого переехало сюда.

Компиляция

Берем последнюю версию с ftp://ftp.isc.org/isc/inn/, например inn-2.3.1.tar.gz, раскручиваем его в /usr/src/inn-2.3.1 : tar -xzvf inn-2.3.1.tar.gz, заходим в этот каталог. В дальнейшем я буду на него ссылаться как на $SRC. Условимся, что скомпилированный пакет будем устанавливать в /usr/local/news/. Перед началом компиляции обязательно прочитайте файл INSTALL, убедитесь что у вас стоит Perl версии не ниже 5.004 (чтобы узнать номер версии, запустите perl -v). Читаем ./configure --help, запускаем ./configure с понравившимися опциями. Я использовал такие : ./configure --with-syslog-facility=LOG_NEWS --enable-tagged-hash --enable-uucp-rnews --enable-setgid-inews. Если скрипт отработает нормально, то make ; make install. Все должно поставиться в /usr/local/news.

Настройка

В /etc/manpath.config добавляем
MANDATORY_MANPATH  /usr/local/news/man
Запустив vipw, проверяем наличие пользователя news. Домашним каталогом ему я поставил /usr/local/news, шеллом - /bin/sh. Это пригодится при отладке.
Так как при тоссинге iftoss вызывает /usr/local/news/bin/rnews, то он (iftoss) должен иметь соответствующие права - rnews принадлежит news:uucp, поэтому надо будет прописать в /etc/group : uucp:*:66:fido
В /etc/syslog.conf раскоментируйте строчки с news.*, подправьте пути :
news.crit /usr/local/news/log/news.crit
news.err /usr/local/news/log/news.err
news.notice /usr/local/news/log/news.notice
и сделайте :
touch /usr/local/news/log/news.crit /usr/local/news/log/news.err /usr/local/news/log/news.notice
назначьте владельцем этих файлов news:news
Перезапустите syslogd : killall -1 syslogd

Обратите внимание : в ветке 2.2.* права на каталоги inn'а были более либеральными : они были доступны на запись группе news (и, следовательно, входившему в эту группу пользователю fido). В v2.3.* группа news потеряла право записи в каталоги inn'а. Поэтому для корректного функционирования скриптов send-ifmail/send-fidogate необходимо предоставить группе news право на запись в каталоги /usr/local/news/run/ (для создания lock-файлов), /usr/local/news/spool/outgoing/ (для обработки исходящих эх), и, опционально, в /usr/local/news/log/ (если send-ifmail/send-fidogate создают свои логи в этом каталоге)
Переходим в /usr/local/news/etc.

Редактируем inn.conf :
Разделы defaults и General Settings.
organization:  My Cool Origin
ваш Origin (так же может быть задан в настройках вашего ньюсридера) :
ovmethod: tradindexed
метод хранения overview информации.
server: news.domain.my
pathhost: news.domain.my
адрес вашего сервера. Должен быть прописан в DNS. Если у вас нет подключения к интернету, то используйте localhost.
innflags: -c0 -u
если не ставить флаг -c0 (0 - это цифра, не буква), то inn не будет принимать письма, возраст которых больше 14 дней. Флаг -u отключает буферизацию логов (это необходимо для ifmail'а).
Раздел Feed Configuration
remembertrash: false
wanttrash: true
эти два параметра необходимы для того, чтобы письма, приходящие в неизвестные для inn'а конференции не грохались, а помещались в ньюсгруппу junk, откуда потом их будут доставать всякие autocreate'ы
Раздел Article Storage
storeonxref: true
т.к. в данном примере описано использование одновременно различных методов хранения статей (traditional и CNFS), то этот параметр лучше включить.
Раздел Posting
Довольно забавный параметр checkincludedtext - при установке в true, проверяет (для локально посланных статей) соотношение написанного и отквоченного текста, и если оно менее 50%, то считает что это оверквотинг и отказывается принимать статью ;).
Раздел Logging
docnfsstat: true
Будет периодически генерироваться статистика об использовании CNFS буферов, причем есть возможность прикруть эту статистику к mrtg (если он у вас установлен). См. cnfsstat -h на предмет флагов -m, -p.
status: 600
Запись текущего состояния inn'а в файл inn_status.html каждые 600 секунд.
timer: 600
Запись текущей производительности inn'а в лог news.notice каждые 600 секунд. По этим записям innreport может строить занятную статистику.
Раздел Paths
pathhttp: /usr/local/apache/htdocs/news-stat
Каталог, куда будут помещаться отчеты innreport'а в html-формате. Он должен быть доступен пользователю news на запись.

Редактируем expire.ctl (необязательно):
/remember/:10
Это число регулирует, сколько дней Message-ID каждого письма будет храниться в файле /usr/local/news/db/history (history - это аналог дупобазы в фидошных эхопроцессорах).
# Значение по умолчанию для всех эх
*:A:1:10:never
# Моя локалка - хранить вечно ;)
f99.local:A:never:never:never
# Местные эхи
orn.*:A:14:90:180
orn.test:A:1:1:1
orn.sysop.pvt:A:never:never:never
Смысл всех букв и цифр объясняется в самом начале expire.ctl. Настраивайте в зависимости от объема свободного места на вашем диске. Имейте в виду, что оно обычно кончается гораздо быстрее чем предполагалось ;)
Прочитайте man expire.ctl

Если планируется читать почту ньюсридером по локальной сетке, то надо будет отредактировать readers.conf (Бывший nnrp.access).
В этом файле параметры сгруппированы в разделы двух типов : auth и access. В разделах auth описывается идентификация пользователей, которые могут подключиться к inn'у. Идентификация возможна разными способами - по имени хоста, IP адреса, логина/пароля, и т.д. В разделах access описываются ньюсгруппы, доступные пользователям, прошедшим идентификацию.
Имеющиеся по умолчанию секции auth "localhost" и access "localhost" не трогайте, составляйте свои, например :
Раздел auth :
auth "all network users" {
   auth: "ckpasswd -f /usr/local/news/db/users.passwd"
   hosts: "10.1.0.0/16"
   default: "<LOCAL-USERS>"
}
Раздел access :
access "all users" {
   users: "<LOCAL-USERS>"
   read: "local.*"
}

access "tech users" {
   users: "tech1,tech2,tech3"
   newsgroups: "su.hardw.*"
}

access "finance users" {
   users: "fin1,fin2,fin3"
   read: "ru.bank"
   post: "ru.1csoft"
}
В данном примере доступ к ньюссерверу имеют только те пользователи, IP адреса которых попадают под маску 10.1.*.*. Если они не предъявили логин/пароль, то попадают в секцию "all users" и могут лишь читать local.*. Но если они дополнительно предъявят корректные логин/пароль, то в зависимости от логина (tech1, fin1, fin2, etc.) получают доступ каждый к своим ньюсгруппам.
Обратите внимание : строчки типа default: "<LOCAL-USERS>" не должны содержать пробелов внутри кавычек.
Файл с паролями (users.passwd) создайте с помощью утилиты htpasswd (она обычно входит в дистрибутив сервера apache), например : htpasswd -c /usr/local/news/db/users.passwd tech1. Добавление новых пользователей : htpasswd /usr/local/news/db/users.passwd tech2, и т.д. Вообщем, man htpasswd. Не забывайте сделать user.passwd доступным пользователю news на чтение
Прочитайте man 5 readers.conf.
Небольшое отступление : Позже, когда вы запустите INN, то для проверки корректности настройки очень удобно использовать телнет на 119 (nntp) порт сервера. Так, описанную выше конфигурацию можно проверить следующим образом (допустим вы уже создали пользователя с паролем, например tech1/pass1) :
$ telnet news.domain.my nntp
201 news.domain.my InterNetNews NNRP server INN 2.3.1 ready (no posting).
все правильно, пока мы не предъявили логин/пароль, мы в группе "all users" с r/o доступом. Проверим, какие группы нам доступны :
list active
215 Newsgroups in form "group high low flags".
local.talks 0000000000 0000000001 y
local.pvt 0000000000 0000000001 y
Проверим, можем ли мы туда писать :
group local.talks
211 0 0 0 local.talks
post
440 Posting not allowed
Хорошо, теперь идентифицируем себя как tech1 :
authinfo user tech1
381 PASS required
authinfo pass pass1
281 Ok
list active
215 Newsgroups in form "group high low flags".
su.hardw.monitor 0000000000 0000000001 y
su.hardw.video 0000000000 0000000001 y
[...]
group su.hardw.video
211 0 0 0 su.hardw.video
post
340 Ok, recommended ID <8sa7a4$i0c$1@news.domain.my>
[...]
Аналогично можно протестировать настройки всех access разделов.

Теперь редактируем файл newsfeeds. В нем расписано от кого вы получаете эхи и кому их отдаете. Сначала прочитайте комментарии в этом файле, затем можете подкорректировать секцию ME, типа :
ME:*,!junk,!control*::
В каком-то FAQ рекомендовалось прописать "фиктивный" feed. Пропишите, хуже от этого не будет :
dummy-feed:!*::
Далее описываем линков. Обратите внимание на то, что адреса необходимо писать с указанием зоны (z2).
В простейшем случае у вас будут только фидошные эхи и локалка :

Аплинк :
f500.n5058.z2:!*,\
  orn.*,\
  uplink.local,\
  su.os2, \
  su.os2.apps,\
  f99.local,\
  [...]
  :Tf,Wfb,B4096/1024:

На домашнего пойнта:
p1.f99.n5058.z2:!*,\
  f99.local, \
  f99.notify, \
  ru.unix.ftn, \
  :Tf,Wfb,B4096/1024:

А здесь другой пойнт
p2.f99.n5058.z2:!*,\
  ru.sex, \
  wwb_sysop, \
  tyt.bce.hacpem, \
  regcon.eur, \
  mo.echo, \
  zcc-public, \
  :Tf,Wfb,B4096/1024:

А этот технический пойнт автоматом подписан на всё. (убран '!' перед '*')
p100.f99.n5058.z2:\
  *,\
  :Tf,Wfb,B4096/1024:

А этот feed подписан на все эхи - он просматривает все сообщения, ищет адресованные мне и откладывает их в carboncopy (настройка описана в разделе carboncopy)
cc:\
  !my.cc,\
  !uplink.local,\
  !junk,\
  !f99.*,\
  *,\
  :Tm:ccmailer

ccmailer:\
  !*\
  :W*,Tp:/usr/local/news/bin/carboncopies *

Небольшое пояснение о флагах (Tf,Wfb,B4096/1024) :
Флаг T - тип feed'а (f - file, p - program, и т.д.)
Флаг B - размеры буферов, в байтах
Флаг W - определяет, какая информация об уходящей на данный feed статье будет записываться в файл в каталоге /usr/local/news/spool/outgoing. Т.е. при комбинации "Wfb", будет записываться token статьи и ее размер в байтах (так, для traditional спула, token выглядит как "/usr/local/news/spool/articles/ru/unix/ftn/590367", для cnfs спула - как "@030146494C45303100000000002000000001@"). Более подробные описания флагов - см. man 5 newsfeeds

Небольшое отступление : работая с версией 2.2.*, описанной здесь я использовал метод хранения статей "по умолчанию" - traditional, когда каждая статья хранилась в отдельном файле. В данном примере, в 2.3.*, я буду использовать два метода - traditional и CNFS. При использовании CNFS, для хранения статей используется один большой файл (или даже целый raw-раздел жесткого диска) и когда он заполняется до конца, то начинает использоваться с начала, циклически. (Это можно условно сравнить с двумя прокси - squid и oops ;). У первого метод хранения кешированных файлов - "traditional", а у второго - "cnfs" ;). Более подробно об этих и других методах можете подробно прочитать в man storage.conf, секция "STORAGE METHODS".
Итак, редактируем файл cycbuff.conf :
В первую очередь закоментарьте все строчки с примерами cycbuff и metacycbuff, иначе inn воспримет их всеръез и будет пытаться инициализировать эти буферы.
Теперь надо определиться - какие эхи будем хранить в traditional спуле, а какие в CNFS. Ньюсгруппу junk - однозначно в traditional, так как почти все (все ?) autocreat'ы рассчитаны на это.
Замечание : Если планируется использовать в качестве гейта не ifmail, а fidogate (с -snp патчами by Serge N. Pokhodyaev, snp@ru.ru, 2:5020/1838@fidonet, URL : http://f1838.euro.ru/fidogate/), настройка которого описана в разделе fidogate, то особой необходимости держать junk в traditional спуле нет. Можете использовать любой.
Остальные эхи - на ваше усмотрение. У себя я сделал так : junk, всякие control.* и локалку - в traditional, остальные - в два CNFS спула. В первом (маленьком, 10 Mb) - местные эхи, для которых expire установлен побольше (см. пример в expire.ctl). Во втором (200 Mb) - все остальные.
cycbuff:FILE01:/usr/local/news/spool/articles/local_echoes:10240
cycbuff:FILE02:/bhome/part2/01/fido/other_part_1:51200
cycbuff:FILE03:/usr/local/news/spool/articles/other_part_2:153600
Первый файл - 10 Mb, второй и третий находятся на разных жестких дисках и занимают (точнее будут занимать, когда мы их создадим) 50 и 150 Mb соответственно.
metacycbuff:ORN:FILE01
metacycbuff:RU:FILE02,FILE03
Вот, наконец, мы задали два CNFS спула : ORN (10Mb) и RU (200 Mb).

Редактируем storage.conf :
method cnfs {
        newsgroups: orn.*
        class: 0
        options: ORN
}
method tradspool {
        newsgroups: junk,control*,f99.local
        class: 1
}
method cnfs {
        newsgroups: *
        class: 2
        options: RU
}
Для получения дополнительной информации - man storage.conf.

Т.к. в inn.conf мы прописали метод хранения overview информации как data/index (ovmethod: buffindexed), то редактируем buffindexed.conf, предварительно прочитав man buffindexed.conf :
0:/usr/local/news/spool/overview/OV1:30720
Размер overview базы определяется эмпирически, но примерно 1/5...1/7 от объема news-базы (для описываемой конфигурации). Т.е. в данном примере, при размере news-базы 210 Мб., размер overview-базы возьмем 30 Мб. Пока этот файл не существует, его мы создадим позже, вместе с файлами для CNFS. Оценить объем, занимаемый overview можно с помощью утилиты "inndf -o".

Переходим в /usr/local/news/db. В отличие от версии 2.2, 2.3 уже идет с установленными файлами active и newsgroups, необходимыми для запуска inn'а. Поэтому можно сразу перейти к созданию файла history :
touch history
../bin/makedbz -i
переименовываем полученные файлы :
mv history.n.dir history.dir
mv history.n.pag history.pag
Устанавливаем права на файлы в /usr/local/news/db :
chown news:news *
chmod 0664 *
Базы history готовы.
Теперь создаем CNFS спулы и overview database:
dd if=/dev/zero of=/usr/local/news/spool/articles/local_echoes bs=1k count=10240
dd if=/dev/zero of=/bhome/part2/01/fido/other_part_1 bs=1k count=51200
dd if=/dev/zero of=/usr/local/news/spool/articles/other_part_2 bs=1k count=153600
dd if=/dev/zero of=/usr/local/news/spool/overview/OV1 bs=1k count=30720
Вот. Теперь у этих файлов установите владельцем news:news и права 0664.

Для проверки синтаксиса файлов конфигурации, владельцев файлов и каталогов запустим скрипт /usr/local/news/bin/inncheck, после чего исправьте найденные им ошибки.
Произведем пробный запуск inn'а (от имени пользователя news) :
su news -c "/usr/local/news/bin/rc.news start"
При этом на экране появится нечто вроде :
Starting innd.
Scheduled start of /usr/local/news/bin/innwatch.
Scheduled start of cnfsstat.
А в файле /usr/local/news/log/news.notice появятся строчки типа :
Nov 1 24:08:24 domain.my innd: buffindexed: No magic cookie found for buffindexed 0, initializing
Nov 1 24:08:24 domain.my innd: SERVER descriptors 1064
Nov 1 24:08:24 domain.my innd: SERVER outgoing 1051
Nov 1 24:08:24 domain.my innd: SERVER ccsetup control:12
Nov 1 24:08:24 domain.my innd: SERVER lcsetup localconn:14
Nov 1 24:08:24 domain.my innd: SERVER rcsetup remconn:4
Nov 1 24:08:24 domain.my innd: dummy-feed opened dummy-feed:16:file
Nov 1 24:08:24 domain.my innd: f500.n5058.z2 opened f500.n5058.z2:17:file
Nov 1 24:08:24 domain.my innd: p1.f99.n5058.z2 opened p1.f99.n5058.z2:18:file
Nov 1 24:08:24 domain.my innd: p2.f99.n5058.z2 opened p2.f99.n5058.z2:19:file
Nov 1 24:08:24 domain.my innd: p100.f99.n5058.z2 opened p100.f99.n5058.z2:20:file
Nov 1 24:08:24 domain.my innd: tradspool: /usr/local/news/spool/tradspool.map not found
Nov 1 24:08:24 domain.my innd: CNFS-sm: No magic cookie found for cycbuff FILE01, initializing
Nov 1 24:08:24 domain.my innd: CNFS-sm: No magic cookie found for cycbuff FILE02, initializing
Nov 1 24:08:24 domain.my innd: CNFS-sm: No magic cookie found for cycbuff FILE03, initializing
Nov 1 24:08:24 domain.my innd: SERVER starting
В живости innd можно убедиться, запустив ps :
$ ps -ax -Unews
  PID  TT  STAT     TIME COMMAND
  188  ??  Is     0:28.84 /usr/local/news/bin/innd -p4 -u -c0
  190 con- I      0:00.00 /bin/sh /usr/local/news/bin/rc.news start
  191 con- I      0:00.00 /bin/sh /usr/local/news/bin/rc.news start
  194 con- I      0:00.00 /usr/bin/perl /usr/local/news/bin/cnfsstat -s -l -P
  198 con- I      0:01.60 /bin/sh /usr/local/news/bin/innwatch
  320 con- I      0:00.00 sleep 600
Обычно inn запускают при загрузке системы из /usr/local/etc/innd.sh. У меня он таков :
#!/bin/sh
case "$1" in
start)
   [ -x /usr/local/news/bin/rc.news ] && su news -c "/usr/local/news/bin/rc.news start" > /dev/null && echo -n ' innd'
   ;;
stop)
   [ -r /usr/local/news/run/innd.pid ] && su news -c "/usr/local/news/bin/rc.news stop" > /dev/null && echo -n ' innd'
   ;;
*)
   echo "Usage: `basename $0` {start|stop}" >&2
   ;;
esac
exit 0

Создайте файлик news.cron с содержимым :
0   3 * * * /usr/local/news/bin/news.daily expireover lowmark delayrm
1   * * * * /usr/local/news/bin/nntpsend
*/2 * * * * /usr/local/news/bin/rnews -U
После каждого редактирования этого файла не забывайте запускать crontab -u news news.cron. Если вы выключаете компьютер на ночь, то проставьте в первой строчке подходящее время для запуска news.daily. Прочитайте man news.daily.

В идеале, все ваше взаимодействие с inn ограничится добавлением/убавлением линков и корректировкой их подписки в файле newsfeeds. Я бы не советовал делать это руками, лучше довериться areafix'у - по крайней мере, при правильной настройке вы сможете избежать грубых технических ошибок. Но несколько команд для "ручной" работы я здесь упомяну.

Практически все управление осуществляется программой /usr/local/news/bin/ctlinnd (при работающем innd). Прочитайте man ctlinnd. Перед тем, как менять какой-либо конфиг (типа newsfeeds, active) необходимо приостановить innd командой "ctlinnd pause причина". В данном случае "причина" - это слово(слова), которые попадут в news.notice, и которые понадобятся для "разморозки" innd. После изменения конфигурационных файлов необходимо их перечитать командой "ctlinnd reload имя_конфига причина". Если вы редактируете newsfeeds, то по окончании редактирования, перед запуском ctlinnd reload сначала запустите ctlinnd checkfile - он проверит синтаксис newsfeeds.
Для автосоздания новых эхоконференций, падающих обычно в junk (во всяком случае при вышеописанной настройке они должны падать именно туда ;) используйте программы-autocreate'ы, описанные в разделе autocreate

Более подробно об автоматизации прозвонки, тоссинга, обработки файлэх, и прочего рассказано в разделе совместная работа.
Hints :
  • кодировки koi8-r, windows-1251.
    Один из вариантов конфигурации, который может оказаться полезным в довольно типичном случае (юниксовый сервер и куча клиентских машин под Windows) : в ifmail'е вместо перекодировочных таблиц outaltkoi8 и outkoi8alt можно использовать таблицы alt-win.tab и win-alt.tab, взятые из Русского Апача (http://apache.lexa.ru) и подправленные на предмет русской "Н". В такой конфигурации ifmail будет "скармливать" статьи inn'у не в koi8-r а в windows-1251. Ни для кого из фидошных линков это не будет заметно, но для локальных пользователей очень удобно, т.к. не надо заморачиваться с приручением ньюсридера к koi8-r путем подстановки шрифтов/хаканья бинарников/подкручивании виндов и т.п., а можно взять любой ньюсридер, который даже и не знает ничего о кодировках (но который, тем не менее, не работает в 7-bit only ;). При реализации такого подхода есть несколько особенностей :
    - если вы хотите читать ньюсы с консоли сервера (а зачем ? ;), то ваша читалка должна будет понимать windows-1251. Или используйте cyrproxy (см. ниже)
    - вашим локальным пользователям придется получать/отправлять фидошный нетмейл тоже в 1251 кодировке. Впрочем, TheBat! позволяет выставлять любую русскую кодировку.
    - некоторые вспомогательные программы (в основном генераторы отчетов и т.п.) могут быть немножко заточены под koi8-r.
    Другим решением проблемы с кодировками может быть использование cyrproxy (http://www.lexa.ru/lexa/) для перекодировки между koi8-r на сервере и windows-1251 у клиентов. Опять-таки для локальных пользователей это почти не заметно, и для inn 2.3.* я использую именно этот вариант. О настройке cyrproxy рассказано в разделе cyrproxy
  • ньюсридеры
    Вообще, если посмотреть хотя бы на www.winfiles.com, то выбор ньюсридеров велик. Но более-менее известных не очень много : Outlook, Forte Agent, NewsXPress, XNews, ... О "русификации" ньюсридеров можно почитать на http://koi8.pp.ru/
  • транзитные (passthru) эхи.
    Организовать passthru-эхи можно несколькими способами, хотя именно классический passthru может быть реализован только в первом варианте. Итак :
    - можно использовать патч для iftoss, by Stanislav V. Voronyi, stas@use.kharkov.ua, URL : ). И в настройках inn'а для passthru эх установить режим хранения "trash" (man storage.conf);not tested
    - можно для passthru эх установить режим хранения CNFS с небольшим размером. Но не слишком маленьким - иначе при приходе большого количества почты, iftoss может растоссить столько почты, что в CNFS буфере новая почта может затереть еще ту, что еще не успела скормиться ifpack'у;
    - можно хранить passthru эхи в traditional спуле, но установить для них в expire.ctl срок expire одни сутки (можно меньше);
    - any other ways ?
  • ньюсы от провайдера
    Если у вас есть доступ к ньюс-серверу по nnrp, то можно совместить доставку и обработку фидошных конференций и usenet-ньюсов, используя специальные программы, например suck. Настройка ее описана в разделе suck. Впрочем, если достаточно только читать usenet-ньюсы, то можно использовать программку pullnews, идущую в комплекте с inn.
  • что еще почитать
    Если хотите поподробнее почитать про inn на русском, то рекомендую http://www.citforum.ru/internet/common/inn.shtml - только учтите, что там описывается процесс компиляция старой версии inn'а - 1.7.2, в 2.3.* он несколько изменился, но что касается общей информации - рекомендую почитать.
    • This is a part of "HOWTO : fidonet software for unix", http://howto.id.ru
    Original of this document is located at http://howto.id.ru/inn.html
    Copyright (c) Vitaly Kuharev, 2:5058/49@fidonet, 1999-2001
    Last updated : March, 09, 2001