Памятка начинающему сисопу на примере 201 ноды
 

Этот документ порождён необходимостью воспитать достойную смену в лице
косисопов /201 ноды. Он не претендует на полноту, а просто даёт некоторую
необходимую для работы информацию. Думаю, почитать его будет любопытно любому
новичку, желающему больше узнать о принципах работы Fido и/или фидошной ноды.

Этот файл не заменит чтения документации или практического опыта, но он даст
некоторые начальные представления о том, в каком направлении необходимо
творчески расти дальше :) Реальные навыки приходят только с опытом и после
прочтения кучи документации (на /201 документация лежит в соответствующих
каталогах с программами).  Ошибки неизбежны, но, к счастью, в Fido к ним
относятся снисходительно, если они вовремя исправляются и никого серьёзно не
задевают.
 

                       План (а как же без него)

 1. Что такое Fido

Fido (а полностью - FidoNet) - это любительская некоммерческая электронная
сеть. Основной режим работы Fido - off-line, основные каналы связи - обычные
коммутируемые телефонные линии (хотя практикуется и использование выделенных
каналов связи, и локальных сетей, и перенос почты вручную на магнитных
носителях, и - в последнее время - доставка почты по IP-каналам).

Fido ещё называют "сеть друзей". Действительно, за доступ к ресурсам Fido не
взимается (и не может взиматься, согласно FidoNet Policy) никакая плата,
кроме счетов за телефон. Fido существует только за счёт энтузиазма
участников, добровольно взваливающих на себя обязанности по поддержанию сети
в рабочем состоянии. Единственный способ подключиться к Fido - это найти
какого-нибудь фидошника и попросить его предоставить доступ к сети.

В мои цели не входит рекламирование Fido или подробное изложение всех
аспектов многогранной жизни сети - это тема для отдельной книги. В этом же
тексте я расскажу о технической стороне работы своей ноды.

 1.1. Нормативные документы

Fido, в целом - очень неформальная и демократическая сеть, где почти всё
держится на здравом смысле и добровольном участии. Однако, как показывает
опыт, полное отсутствие правил приводит к анархии даже в самой
добропорядочной среде, поэтому некоторые формальные правила есть и в Fido.

Основной документ, регулирующий работу всех узлов FidoNet - это FidoNet
Policy. Каждый сисоп ноды обязан ознакомиться с полиси, а также иметь у себя
экземпляр для выдачи любому желающему.

Существуют также локальные (региональные, сетевые etc.) дополнения и поправки
Policy, а также документы, регламентирующие другие стороны жизни сети
(например, EchoMail Policy, правила гейтования в другие сети etc.). Одни из
них обязательны для исполнения, другие носят рекомендательный характер; знать
их желательно всякому сознательному члену Fido.

Помимо организационных, существуют и технические документы и стандарты (FSC,
FTS etc.), регламентирующие форматы данных, протоколы обмена etc. Как
правило, доскональное их знание требуется только разработчикам фидошного
софта, но общее знакомство всегда приветствуется.

На 201 ноде нормативные документы содержатся в области "Технические стандарты
FIDO, Policy etc.", каталог j:\isiit\fido2\fts

 1.1.1. Нодлисты

Особый документ Fido - мировой нодлист (nodelist). Это полный список всех
узлов сети FidoNet, содержащий информацию об именах сисопов, телефонах,
времени работы и некоторых других особенностях узлов. Нодлист обновляется раз
в неделю.  Поскольку полный мировой нодлист - файл приличных размеров, по
сети рассылаются только отличия текущего нодлиста от предыдущего (nodediffs),
которые необходимо компилировать специальными программами - компиляторами
нодлиста.

Нодедиффы распространяются по файловой эхе NODEDIFF

Составлением и обновлением сегментов нодлиста занимаются координаторы (см.
ниже). Как правило, большинство нод и пойнтов Fido ограничиваются звонками
только в пределах своей сети, поэтому вместо полного мирового нодлиста они
довольствуются локальным сегментом; так поступаю и я.

Киевский сегмент нодлиста распространяется по файловой эхе NET_463, сегмент
50 региона - R50-LIST

Помимо нодлиста, существуют и пойнтлисты (pointlists) - списки пойнтов сети,
региона etc. в том же формате, что и нодлисты, за тем исключением, что в
пойнтлисте не обязательно указание телефона и времени работы станции.
Пойнтлисты не являются обязательными регламентированными документами (почему
- см.  ниже), но на практике все ими пользуются.

Пойнтлисты распространяются по многим файлэхам, из них на 201 ноде имеются
N463-PNT, R46_PNT, R50PNT, PNTLIST.

Поскольку большинство узлов при прозвонке руководствуются данными из нод- и
пойнтлистов, совершенно необходимо использовать самые свежие их версии из
доступных, чтобы своевременно реагировать на такие события как смена номера
телефона, времени работы etc. По этой же причине необходимо своевременно
информировать своего сетевого координатора и пойнт-координатора (подробнее об
этом см. ниже) об изменениях в режиме работы своей станции и станций своих
пойнтов.

 1.2. Структура Fido

Принцип построения Fido - территориальный (с точки зрения телефонных сетей -
какие звонки считаются местными, областными, междугородными, международными
etc.).

FidoNet делится на 6 зон (zones; 1 зона - Америка, 2 - Евразия etc.), зоны -
на регионы (regions; например, 46 регион - Украина и Молдова, 50 - Россия и
некоторые республики ex-USSR), регионы - на сети (nets; 463 сеть - Киев, 461
- Харьков, 5020 - Москва, 5030 - Петербург etc.); первые две цифры в номере
сети являются номером региона.  Сеть состоит из узлов (нод, nodes), у узлов
есть пойнты (points). Полный фидошный адрес выглядит следующим образом:
2:463/201.4 и читается как "четвёртый пойнт 201 ноды 463 сети (46 региона) 2
зоны". Это так называемая 4D-адресация; зачастую в разговоре и настройках
софта допускаются сокращённые формы адресов (типа 463/201, /201, 201.4 и
даже просто .4), когда остальные части адреса понятны из контекста.

Ноды обозначаются 3D-адресацией (2:463/201) или 4D (2:463/201.0)

В последнее время возникло множество сетей, основанных на технологии Fido
(Fido Technology Networks, FTN), но не являющихся составными частями Fido. Во
избежание путаницы такие сети используют другие номера зон, а также словесное
обозначение сети. Например: 2:463/201.4@fidonet (или
2:463/[email protected]), 505:1/100.0@nasnet etc. Часть адреса после символа
'@' по аналогии с Internet называется доменом, а сама адресация - 5D.

Фидошная система может иметь несколько адресов (тогда они называются aka -
Also Known As). Наличие нескольких пойнтовых (4D) адресов означает, что
система получает почту у нескольких нод (это имеет смысл с точки зрения
надёжности - одна нода упала, остальные работают - и выбора доступных эх и
файлэх). Несколько нодовых (3D) aka встречаются редко и особого смысла не
имеют - разве что во время переходных процессов при делении или объединении
нод. Несколько 5D-aka из разных сетей означают членство во всех этих сетях.

Наличие нескольких aka потенциально может привести к неприятностям из-за
ошибок в пересылке почты (пересылка не на те адреса, предъявление не тех
адресов во время сеансов связи etc.), поэтому настройка станции с несколькими
aka требует внимательности и некоторых познаний в фидошной технологии.

Как правило, для большинства фидошных узлов (кроме самых крупных хабов)
характерна анизотропность потока почты - в одну сторону валит поток почты
от всего внешнего мира, в другую - хилый ручеёк писем от пойнтов и ближайших
узлов. Соответственно, узел, предоставляющий другому доступ к своим эхам и
файлэхам, называется аплинком (uplink), а узел, на эти эхи подписывающийся -
даунлинком (downlink). Как правило, даунлинк прозванивается аплинку, но
бывает и наоборот - зависит от финансовых условий и качества связи.

Бывает и так, что каждый из двух узлов имеет доступ к своему набору эх, и они
тянут эти эхи друг у друга. Тогда по одним эхам аплинком является один узел,
а по другим - другой.

 1.3. Что в Fido бывает и в каком виде

Скажу сразу, что это не совсем всё, что может быть в Fido - в Fido может быть
много чего. Но нижеследующий список отражает информационные ресурсы сети на
98%, так что для начального знакомства этого вполне достаточно.

 1.3.1. Личная почта (netmail)

Доставка личной почты - основная и наиболее священная функция сети (хотя по
загрузке каналов связи она занимает самое скромное место). Письмо, отосланное
нетмейлом, получит и прочтёт только адресат (в идеале).

Строго говоря, в Fido личная почта не является абсолютно личной - согласно
полиси, сисоп любой ноды, через которую проходит письмо, имеет право
ознакомиться с его содержанием, и в том случае, если сочтёт его
противоречащим действующим правилам и законодательству, чрезмерно
оскорбительным etc., не пересылать его дальше, сопроводить комментарием etc.

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

С правом сисопов на перлюстрацию транзитной почты тесно связано ограничение
на формат нетмейла - вы не имеете право шифровать (encrypt) текст, а также
кодировать его каким-либо образом, лишающим сисопов транзитных узлов
возможности ознакомиться с текстом. Отправка таких писем без предварительной
договорённости со всеми транзитными узлами является чрезмерно раздражающим
поведением.

К сожалению, многие сисопы слишком вольно трактуют этот пункт полиси и
запрещают транзит через свои узлы почты, закодированной любым способом - даже
тем, который они могут легко раскодировать. Наиболее характерным примером
такого отношения является формат uue для передачи бинарных файлов в текстовых
письмах.

Кроме того, необходимо разумно подходить к размеру своих писем, учитывая
возможности почтовых программ и пропускную способность каналов связи.
Общепринятым ограничением является 20-30K на одно письмо, 200-500K за 1-3
суток.

Для хранения нетмейла используются два основных формата файлов:

*.msg (также известный как Opus). Каждое письмо содержится в отдельном файле,
снабжённом заголовком с указанием адресов, имён и прочей служебной
информации. Этот формат наиболее удобен для обработки разными утилитами,
для этого он и используется. Имя файла - это его порядковый номер в каталоге.

*.pkt. В одном файле (пакете) может содержаться сколько угодно писем. В этом
формате почта передаётся между узлами. Имя файла является 16-ричным кодом,
зависящим от адреса системы, где был создан пакет, и времени его создания,
что исключает возможность перекрытия имён пакетов, пришедших от разных узлов
в один приёмный каталог. Пакет не является чем-то целостным, в неповреждённом
виде доходящим от отправителя к адресату - на каждом транзитном узле пакеты
разбираются, письма дополняются соответствующей служебной информацией, и
снова упаковываются для дальнейшей отправки.

Существует множество программ для просмотра этих форматов; полезно иметь под
рукой какую-нибудь из них.

 1.3.2. Эхоконференции (echomail)

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

Существует множество эх на самые различные темы; в большинстве из них
действуют определённые правила поведения, за соблюдением которых следит
специальный человек - модератор, иногда со своими помощниками. Он регулярно
(хотя бы раз в месяц) публикует правила конференции и наказывает нарушителей.
Стандартная система наказаний выглядит следующим образом: мелкое нарушение
отмечается знаком [*]; серьёзное нарушение или большое число мелких - [+]; за
определённое число плюсов (обычно 3) следует отключение от конференции или
перевод в режим read-only на некоторый срок.

Поэтому, в отличие от нетмейла, в эхах необходимо считаться с тем, что каждое
ваше слово становится достоянием общественности. Писать нужно вежливо,
грамотно, содержательно и по теме (за исключением тех случаев, когда правила
эхи разрешают или требуют обратного).

Технически эхи передаются в файлах того же формата *.pkt, что и нетмейл.
Поскольку количество почты в конференциях значительно, обычно она передаётся
в архивированном виде (arcmail). Для этой цели может использоваться любой
распространённый архиватор, формат архивов которого понимают почтовые
программы (например, arj, zip, lha, rar). Архив с почтой имеет имя,
являющееся 16-ричным кодом, зависящим от адресов передающей и принимающей
систем, первые две буквы расширения - день недели, когда архив был создан
(mo, tu, we, th, fr, sa, su) и последний символ - порядковый номер архива в
этот день (0-9, a-z). Таким образом исключается возможность перекрытия имён
архивов, пришедших от разных систем или предназначенных для отправки на
разные системы.

Зачастую узлы, через которые проходит большой объём нетмейла, архивируют и
передают его наравне с эхами в виде аркмейла.

 1.3.3. Файловые эхи

Fido является транспортным средством не только для текстовых сообщений, но и
для произвольных файлов. Для этой цели используется механизм файловых эх
(fileecho).

По принципу распространения файлэхи совершенно аналогичны эхоконференциям -
за тем лишь исключением, что по файлэхам ходят не письма, упакованные в
пакеты, а произвольные файлы, в том виде, как они были отправлены. Каждый
файл сопровождается служебным файликом с расширением .tic; это обычный
текстовый файл, содержащий такие данные как имя файла, пояснение к нему,
контрольную сумму и прочую служебную информацию, необходимую для успешной
доставки файла.

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

 1.3.4. Фреки

Многие узлы Fido держат у себя коллекции полезных файлов (текстов, утилит,
картинок etc.) и отдают их по запросу. Такой запрос называется фреком (freq,
File REQuest) и может быть выполнен при помощи практически любой почтовой
системы Fido. В отличие от почты и файлэх, которые передаются через
транзитные узлы от отправителя к адресату, для получения файла по запросу
необходимо прямое соединение (direct) между узлом, запрашивающим файл, и
узлом, этот запрос обрабатывающим и отдающим файл. Как правило, это условие
не позволяет большинству узлов запрашивать файлы из других городов (по
причинам качества линии связи или стоимости межгорода).

Многие узлы, отдающие фреки, стремятся оградиться от любителей запросить
большую кучу файлов и занять линию на длительный промежуток времени. Для
этого вводятся ограничения на суммарный объём файлов, который можно запросить
за определённый период (день, неделю, месяц), их количество, время на линии,
и/или ограничивается перечень систем, которые могут запрашивать файлы (только
системы, упомянутые в нод- и пойнтлистах, только системы, имеющие парольный
доступ etc.)

Простейший способ узнать, отдаёт ли узел фреки, какие приняты ограничения, а
также получить список имеющихся в наличии файлов - это запросить файл с
именем FILES. Это специальное кодовое имя, используемое для этой цели всеми
узлами, отдающими фреки.

 1.4. Должности в Fido, права и обязанности

Fido имеет определённую организационную структуру, отражающую распределение
прав и обязанностей между членами сети, а также технологию доставки почты.

 1.4.1. Пойнты

Самая многочисленная и самая бесправная часть Fido. Согласно полиси, пойнты
вообще не являются членами Fido, то есть на них не распространяется действие
регламентирующих документов, они не имеют права голоса при решении
организационных вопросов в сети etc. Права и обязанности пойнтов определяет
их босс - сисоп узла (ноды), через который они получают и передают почту, и
эти права и обязанности не распространяются дальше этого узла.

За действия пойнтов, наносящие ущерб сети, отвечает их босс (ну а что за это
он сделает с провинившимся пойнтом - это уже их личное дело ;)

Единственная обязанность ноды перед пойнтами - это доставка личной почты;
единственное гарантированное право пойнтов - это бесплатный доступ к ресурсам
Fido (взимание платы за доступ к Fido запрещено полиси). Искючением является
случай костшаринга (costsharing), когда телефонные счета ноды в складчину
оплачиваются пойнтами, но этот вариант всегда оговаривается заранее и
производится на добровольной основе.

К счастью, ноды, ограничивающиеся только исполнением своих формальных
обязанностей, в Fido не уживаются, так что пойнты обычно пользуются всеми
ресурсами, доступными на ноде, а основной объём писем в конференциях исходит
именно от пойнтов.

 1.4.2. Ноды

Минимальная официальная структурная единица Fido. Именно ноды обеспечивают
доставку почты по назначению, обеспечивают бесперебойную работу своих
станций, снабжают своих пойнтов и друг друга эхами и файлэхами.

Ноды подчиняются правилам и ограничениям Fido policy, среди которых самое
священное - это Zone Mail Hour (ZMH), время, когда нода обязана отвечать на
звонки и принимать входящую почту. В Киеве ZMH (совмещённый с Net Mail Hour,
LMH) - это интервал 4:30-6:30. Абсолютное большинство нод отвечает на звонки
в гораздо более широком интервале времени (вплоть до круглосуточной работы),
так что ZMH - явление морально устаревшее, но - "закон есть закон".

 1.4.3. Хабы

Хабы (hubs) - это ноды, добровольно принявшие на себя основной груз
обязанностей по распространению почты. Как правило, это станции, имеющие
возможность на шару звонить по межгороду (примазавшись к большому объёму
междугородных переговоров какой-нибудь богатой фирмы), многолинейные станции,
способные раздавать почту большому количеству нод, либо просто надёжно
работающие ноды с опытными и сознательными сисопами.

Совокупность нод, получающих почту от определённого хаба, называется
подхабником. Совокупность хабов, взаимодействующих друг с другом с целью
доставки почты, называется бэкбоном (backbone).

Хабы бывают разные. Есть нетмейловые хабы (их легко узнать по слову Hub в
нодлисте). Они обеспечивают доставку личной почты. В Киеве каждая нода
обязана быть в подхабнике у какого-нибудь нетмейлового хаба (согласно
правилам, в нодлисте после каждого хаба перечисляются ноды его подхабника).
Через хаба отправляется и получается весь нетмейл, который не идёт директом.

Нетмейловым хабом 2:463/201 является 2:463/666. Исключением является доставка
uue - такие письма переправляются на /58 хаба.

Есть эхо- и файлэхохабы (в нодлисте для них нет стандартных флажков).  Как
понятно из названия, они занимаются доставкой эх и файлэх. Нагрузка на них
существенно солиднее, чем на нетмейловых хабов, но ответственность слегка
поменьше (потеря писем из эх и файлов из файлэх хоть и неприятна, но не
настолько, как потеря личной почты).

Как правило, эхо- и файлэхохабы по отдельности не встречаются - и то, и
другое идёт одним потоком. Зачастую они же являются и нетмейловыми хабами, но
не обязательно. Тем более не обязательно обратное.

Помимо просто эхо- и файлэхохабов (их ещё называют первичниками) существуют и
вторичники, которые получают почту у первичников и раздают её другим нодам,
таким образом формируя древесную структуру хождения конференций.

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

Нода 2:463/201 де-факто является вторичным эхо- и файлэхохабом, получая
основной объём почты у первичного хаба 2:463/166 и раздавая её десятку (или
уже двум?) нод.

 1.4.4. Хосты

Каждая сеть имеет хоста (host). Эта нода является "воротами" в сеть и имеет
номер 0. Если вы не знаете, через какой адрес отправить письмо в другую сеть
- отправляйте через хоста этой сети, он обязан обеспечить доставку почты в
пределах сети.

Мелкие сети не имеют хабов, ограничиваясь одним хостом. В Киеве хост в
одиночку не справился бы с нагрузкой.

 1.4.5. Координаторы

Вся активность в Fido регулируется координаторами. Координаторы, как и хабы,
бывают разные.

Сетевой координатор (Net Coordinator, NC) занимается выдачей новых нодовых
адресов в сети, оформлением и отправкой сетевого сегмента нодлиста
соответствующему региональному координатору, выступает в роли судьи при
возникновении конфликтов в сети. Он же обеспечивает нормальную доставку
нетмейла в сети.

Региональный координатор (RC) и зональный координатор (ZC) - вышестоящие
инстанции. Они занимаются аналогичными вопросами в пределах региона и зоны
соответственно, и имеют дело, как правило, только с координаторами более
низкого уровня.

Сетевой пойнт-координатор (NPC) занимается ведением сетевого сегмента
пойнтлиста. Это его единственная обязанность. Аналогично, существуют RPC и
(вот в этом я не уверен ;) ZPC.

Сетевой эхокоординатор (NEC) и файлэхокоординатор (NFEC, NFC) занимаются
вопросами доставки эх и файлэх соответственно. Существуют аналогичные
координаторы регионального и (возможно) зонального уровней.

 1.4.6. Модераторы

Модераторы - это люди, следящие за соблюдением правил и поддержанием порядка
в эхах и файлэхах. Модератором может быть как пойнт, так и нода (если это не
оговорено отдельно в правилах эхи), решения модератора в своей эхе имеют силу
закона (опять же, если правила не говорят иначе). Модератор может назначать
помощников - комодераторов. Смена модератора в эхе происходит путём
голосования или приказом самого модератора (зависит от правил эхи).

Поскольку основным наказанием в Fido является отключение или перевод в
read-only, соответствующие приказы модератора в отношении своих пойнтов и
линков необходимо выполнять - иначе он может потребовать отключить саму
непослушную ноду.

 1.4.7. Совмещение должностей

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

 2. Как устроена 201 нода

 2.1. Мейлер (T-Mail)

Мейлер - это та часть фидошной системы, вокруг которой крутится всё
остальное. Он занимается отправкой и приёмом файлов, запуском процессов
обработки почты и, в принципе, любых других процессов.

Существует множество разных мейлеров (FrontDoor, T-Mail, Bink, SF-Mail etc.).
Некоторые из них уже морально устарели, некоторые - ещё слишком новые и
глюкавые, остальные различаются между собой интерфейсом и набором
возможностей. В любом случае, все они придерживаются одних и тех же
стандартных протоколов связи, так что выбор конкретного мейлера - в большой
степени вопрос личного вкуса и того, с какого мейлера фидошник начинал свою
сознательную жизнь :) На 2:463/201 используется T-Mail.

Полное описание настроек и возможностей мейлера содержится в его
документации; здесь же я остановлюсь только на некоторых ключевых вопросах.

 2.1.1. В каком виде хранится почта перед отправкой

T-Mail поддерживает 3 формата хранения файлов, предназначенных для отправки:

1) Arcmail-attach

В этом случае для каждого файла создаётся служебное письмо (.msg), в котором
указан полный путь к файлу и адрес получателя. Это письмо отправляется вместе
с файлом и сопровождает его, пока файл не достигнет получателя. Эти письма
хранятся в основном нетмейловом каталоге (j:\isiit\t-mail\mail) вместе с
остальным нетмейлом.

Достоинство: это единственный способ отправить файл не напрямую, а транзитом
через несколько узлов.

Недостаток: загромождается нетмейловый каталог, много времени уходит на его
пересканирование.

2) Почтовые ящики (fileboxes)

Для каждой системы создаётся отдельный каталог, в который и складываются
файлы, предназначенные для отправки. Во время сессии с соответствующей
системой отправляются все файлы, лежащие в этом каталоге.

Достоинства: файлы, предназначенные для одной системы, локализованы в одном
каталоге; для отправки файла достаточно скопировать его в этот каталог; не
загромождается нетмейловый каталог.

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

На 2:463/201 этот формат не используется.

3) Bink-style outbound

Этот способ изначально использовался в мейлере Bink, откуда и пошло его
название. В этом случае в специальном каталоге (j:\isiit\t-mail\bink)
для каждой системы создаются текстовые файлы, содержащие список файлов,
предназначенных для отправки (bink attaches). Во время сессии с другой
системой отправляются все файлы, перечисленные в этом списке; отправленные
файлы из списка удаляются.

Существует основной bink-style каталог, соответствующий зоне и домену
системы, а также дополнительные каталоги для других зон и доменов. Так,
например, поскольку полный адрес 201 ноды - 2:463/201.0@fidonet, в основной
каталог t-mail\bink помещаются аттачи для систем зоны 2 домена fidonet. Для
аттачей на адреса 1:*/*.*@fidonet будет создан каталог t-mail\bink.001
(гм... точно ли так? Надо бы проверить), для адресов 123:*/*.*@somenet -
каталог t-mail\somenet.123

Адрес ноды-получателя (сеть и узел) в 16-ричном виде содержится в имени
файла. Если получатель - пойнт, то в бинковом каталоге создаётся подкаталог
сеть_узел.pnt, а в нём - аттачи, в имени которых указан 16-ричный номер
пойнта. М-да. Объяснил несколько сумбурно, но если взглянуть на содержимое
бинкового каталога 201 ноды, станет понятнее.

Расширения файлов зависят от их содержимого:

.?lo - списки файлов:
        .dlo - директ
        .hlo - холд
        .flo - приоритетные файлы (отправляются прежде других)
.?ut - почта (на самом деле это обычные .pkt-файлы)
        .out - обычная почта
        .dut - директ
        .hut - холд
Существует ещё несколько типов расширений, но на 201 ноде они не
используются.

Достоинства: не загромождается нетмейловый каталог; файлы, предназначенные
для одной системы, перечислены в одном текстовом файле, куда их можно
добавлять любым текстовым редактором; сами файлы могут лежать в произвольных
каталогах; большинство фидошного софта поддерживает этот формат; сканирование
файлов в bink-style outbound происходит максимально быстро, поскольку мейлеру
не требуется самостоятельно создавать список файлов для отправки.

Недостаток: как и в случае файлбоксов, файлы отправляются только директом.
 

Кроме того, существует несколько вариантов вышеперечисленных форматов в
зависимости от способа отправки почты и файлов.

1) Напрямую (direct) - файлы и почта будут отданы только во время сесии с
системой-получателем.

В .msg-файле ставится атрибут Dir. В файлбоксах это основной способ отправки.
В bink-style используются файлы .dlo, .dut и .out

2) Стандартный роутинг (осуществляется мейлером).

В .msg - никаких особых атрибутов. В файлбоксах и bink-style этот вариант не
поддерживается.

3) Холд (hold) - файлы и почта будут отданы только в том случае, если
получатель сам позвонит на узел и заберёт свою почту.

В .msg ставится атрибут Hld. В файлбоксах к расширению каталога добавляется
буква h. В bink-style - файлы .hlo и .hut
 

И последняя деталь - как поступать с файлами после их отправки. Есть три
возможности:

1) файл остаётся;

Никаких особых атрибутов .msg, никаких префиксов в bink-style аттачах. В
файлбоксах это невозможно.

2) файл удаляется;

В .msg - атрибут K/s (kill sent, erase sent). В bink-style аттачах перед
именем файла ставится символ '^'. В файлбоксах возможен только этот способ
передачи.

3) файл усекается до нулевой длины (чтобы показать, что файл с таким именем
уже был отправлен).

В .msg - атрибут T/s (truncate sent).  В bink-style аттачах перед
именем файла ставится символ '#'. В файлбоксах это невозможно.

 2.1.2. Роутинг

Роутинг (routing) - это маршрутизация доставки информации по сети. Конечно,
прямая связь между отправителем и получателем - наиболее быстрый и надёжный
способ доставки почты, но это не всегда возможно, особенно если получатель
находится в другом городе, а то и другой стране. Основной режим работы сети -
это транзитная передача данных (отправитель передаёт ближайшему узлу, тот -
следующему, и так далее, пока информация не дойдёт до получателя).

Качественная наладка роутинга (то есть минимальое время и максимальная
надёжность доставки почты) - дело сложное. В настоящее время делаются попытки
автоматизации роутинга подобно тому, как это делается в Internet, но
большинство сисопов по-прежнему делают всё вручную.

В Киеве принята следующая структура доставки почты: каждая нода передаёт
почту своему хабу, а у хабов расписаны карты роутинга - на какие узлы
передавать почту для каких сетей. Помимо этого, большинство сисопов
используют директ, если качество связи с конкретным адресатом достаточно
хорошее, а стоимость услуг АТС - не чрезмерная ;)

Все правила роутинга расписаны в файле t-mail\events.ctl

 2.1.3. Многолинейность и многозадачность

/201 нода имеет (на текущий момент) 3 телефонных линии. Поддержка
многолинейности осуществлется в T-Mailе по схеме "Master/Slave". При этом
запускается несколько копий мейлера; один процесс - Master - занимается
сканированием и перепаковкой почты, а остальные - Slave - занимаются
приёмом/передачей файлов. Для обслуживания одной телефонной линии требуется
один процесс. Часто используется схема с выделенным мастером, когда
Master-процесс вообще не обслуживает телефонную линию, а занимается
исключительно обработкой почты и запуском всяческих задач, а Slave-процессы
не тратят на это ни секунды драгоценного времени. Такая схема используется и
на /201 ноде.

Все линии используют одни и те же конфигурационные файлы мейлера, но некотрые
параметры настройки для разных линий различны. Это обеспечивается за счёт
явного указания, для какой линии какой параметр предназначен - в начале
строки в квадратных скобках может указываться перечень линий, для которых
действителен данный параметр (номера линий либо буквы M и S - Master/Slave).
Номер линии задаётся в командной строке при запуске T-Mailа.

Процессы взаимодействуют между собой путём создания флагов - файлов с
определённым именем. Флаги бывают трёх типов:

1) Флаги занятости, FrontDoor-style. Создаются в специальном каталоге
(t-mail\flags) и содержат зашифрованный в имени адрес системы, файлы для
которой заняты каким-то процессом (например, упаковки новой почты или
приёма/передачи). Все фидошные программы, занимающиеся обработкой почты,
обязаны поддерживать флаги занятости во избежание конфликтов и возможных
потерь/повреждения почтовых пакетов.

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

2) Флаги занятости, Bink-style. Имеют расширение .bsy, правила образования
имени и пути к файлу - такие же, как и для всех остальных бинковых аттачей и
пакетов. Предназначены для той же цели, что и FD-style флаги, но некоторые
программы поддерживают только Bink-style флаги, а некоторые - только
FD-style. Поэтому на /201 ноде включена поддержка T-Mailом и тех, и других
флагов.

3) Пользовательские флаги (user-defined). Используются для самых
разнообразных целей - синхронизации каких-либо операций, дистанционного
запуска задач и всего, что в голову придёт. Располагаются в том же каталоге,
что и FD-style флаги.

Даже если станция работает в однолинейном режиме, но под многозадачной
операционкой, флаги необходимы для корректного взаимодействия процессов.

 2.1.4. Поддержка нодлиста

Как и всякий уважающий себя мейлер, T-Mail поддерживает нодлисты, откуда
берёт информацию о телефоне и времени работы других станций. /201 нода, не
звонящая за пределы Киева, не использует полный мировой нодлист,
ограничиваясь киевским сегментом. Однако, поскольку нодлисты используются и
редакторами почты (например, GoldED) для автоматической подстановки
имени/фамилии по адресу либо поиска адреса по фамилии, ведётся поддержка всех
доступных ex-USSR нод- и пойнтлистов.

Нодлисты содержатся в каталоге t-mail\nodelist. Туда необходимо помещать
свежие сегменты нод- и пойнтлистов по мере их прихода, удаляя старые версии.
Исключение составляют сетевые пойнтлисты 50 региона - их слишком много, а
GoldED имеет ограничение на количество поддерживаемых файлов. Поэтому свежие
сетевые пойнтлисты 50 региона складываются в каталог t-mail\nodelist\source,
а затем склеиваются в один большой файл.

Для того, чтобы программы могли работать с нодлистами, необходимо создать
индексные файлы для быстрого поиска системы в нодлистах. Этот процесс
традиционно и неточно называется компиляцией нодлистов, и выполняется
специальной программой-компилятором, причём, как правило, каждая программа
использует свой собственный формат индексов и свой компилятор (T-Mail -
TNC.EXE, GoldED - GOLDNODE.EXE). Все необходимые действия по компиляции
нодлистов собраны в t-mail\nodelist\nodelist.bat - достаточно его просто
запустить.

В случае каких-либо изменений в наборе нодлистов неободимо скорректировать
конфигурационные файлы компиляторов. TNC использует tnc.ctl, goldnode - ряд
параметров в golded.cfg.

Помимо нодлистов, T-Mail позволяет явно задавать телефоны, время работы и
прочую информацию о других системах. Всё это содержится в файле subst.lst.
Этот файл - единственная возможность описать многолинейные узлы (в нодлисте
публикуется только одна линия), оперативно скорректировать изменившиеся
параметры узла (потому что в нодлисте они отражаются с 1-2-недельной
задержкой), составить хитроумный график прозвонки etc. Однако нужно быть
внимательным, поскольку записи в subst.lst имеют безусловный приоритет перед
содержимым нодлиста, так что содержимое этого файла всегда должно
соответствовать текущему положению вещей.

Поскольку некоммерческая версия T-Mail поддерживает только 3 линии, а у меня
их (вместе с выделенным мастером) четыре, пришлось подправить его при помощи
утилитки t-crack.exe

 2.1.5. Фоссил (Llclcom)

Традиционно фидошные мейлеры не занимаются низкоуровневой работой с
коммуникационными портами, используя вместо этого вызовы специального
драйвера - фоссила (fossil). Исключение составляет, насколько мне известно,
только T-Mail для Win95/NT, использующий системный коммуникационный драйвер.

Существует множество различных фоссилов для разных операционных систем.
Наиболее популярны: для DOS - bnu, x00, llclcom; для Win95 - winfossil,
vfossil; для OS/2 - sio. Лично я предпочитаю: под DOS - llclcom, для
DOS-версии мейлера под Win95 - vfossil.

 2.2. Тоссер (FastEcho)

Тоссер (tosser) занимается разбором приходящей в эхоконференции почты и
упаковкой её для всех, кто подписан на соответствующие конференции.
Существует множество различных тоссеров; на /201 ноде используется FastEcho.
Все файлы тоссера расположены в каталоге t-mail\fastecho.

Конфигурирование тоссера осуществляется из интерактивной утилиты fesetup.exe.

Большинство эх (за исключением нескольких, в которые пишут письма всякие
программы-роботы /201 ноды) находится в режиме Passthrough, то есть вся
приходящая почта немедленно раскладывается на подписчиков и не накапливается
на ноде.

Существуют две служебные области:

1) BadMail. Сюда помещаются письма, которые по тем или иным причинам
невозможно отправить дальше (повреждённые, слишком большого размера,
отправленные не в ту эху etc.) В специальной служебной строке (kludge)
"Reason:" указана причина, почему письмо попало сюда.

При нормальной работе Badmail пуст. Если он не пуст, нужно выяснять и
устранять причину.

2) DupeBoard. Сюда помещаются дупы - письма, уже проходившие через эту
систему, но по каким-то причинам снова пришедшие на неё. Основная причина
возникновения дупов - возникнование петель в пути распространения конференций
(в нормальных условиях - строгому дереву). Дупы обнаруживаются по служебным
строкам MSGID (уникальному номеру сообщения), PATH (пути, по которому шло
письмо), SEEN-BY (списку узлов, куда это письмо отправлялось с перечисленных
в PATH узлов), а также по контрольной сумме тела сообщения.

При нормальной работе DupeBoard пуст. Если он не пуст, нужно выяснять и
устранять причину.

Во время работы fastecho и её сопутствующие утилиты создают в каталоге
t-mail\flags флажок febusy.*, препятствующий параллельному запуску нескольких
утилит. В случае падения работающей утилиты этот флаг блокирует повторные
запуски тоссера и других утилит; к счастью, через заданное время (у меня
установлен минимум - 3 часа) устаревший флаг удаляется, и работа
возобновляется, но можно сделать это и вручную.

В остальном fastecho - достаточно надёжный тоссер; даже будучи прерван во
время тоссинга, после повторного запуска он восстанавливает конфигурацию и
продолжает работу, так что почта не теряется.

Для работы тоссера необходимо, чтобы используемые архиваторы (rar32, arj,
unarjz, pkzip/pkunzip, lha) были в пути на машине, где запущен T-Mail master.

Для нормальной работы fastecho необходимо зарегистрировать. Для используемой
сейчас версии 1.46.1 подходит ключ, создаваемый утилитой fe145key.

 2.2.1. Автоматическая подписка

В fastecho встроена утилита-робот для автоматичнской подписки на конференции
- AreaFix. Для того, чтобы подписаться/отписаться/изменить настройки тоссера,
необходимо написать нетмейлом служебное письмо

To: AreaFix
Subj: пароль

и в теле письма перечислить необходимые команды (если указать команду %HELP,
AreaFix вышлет перечень допустимых команд).

AreaFix поддерживает сквозную подписку (uplink manager). То есть, даже если
на ноде нет какой-то эхи, но она есть у аплинка - можно подписываться на неё,
AreaFix сам отошлёт соответствующий запрос аплинку. Если от какой-то эхи
отписывается её последний подписчик, эха переводится в режим passive, а
аплинку отсылается запрос на отписку.

Для осуществления этой возможности необходимо регулярно запрашивать у
AreaFixов аплинков списки доступных эх (командами %LIST и %AVAIL) и обновлять
списки доступных эх (t-mail\fastecho\e<номер ноды>)

 2.3. Файлэхопроцессор (AllFix)

Как следует из названия, AllFix занимается обработкой и раздачей файлов,
проходящих по файлэхам. Все файлы расположены в каталоге t-mail\allfix.
Конфигурирование осуществляется при помощи утилиты asetup.exe

Не интересующие меня файлэхи находятся в режиме passthrough, остальные
накапливаются в каталоге \isiit\fido, причём для каждой файлэхи создаётся
свой подкаталог.

AllFix умеет создавать (и отправлять в заданные эхи) анонсы новых файлов, а
также производить поиск в коллекции файлов по имени и описанию. На /201 ноде
анонсы отправляются в эхи kiev.allfix.announce и pnt.201.tech.info, запросы
принимаются и обрабатываются в эхе kiev.allfix.

Помимо файлэх, AllFix может просматривать и произвольные заданные
пользователем каталоги (на /201 в таких каталогах хранится более половины
коллекции файлов). Для этого эти каталоги оформляются в виде областей BBS; на
/201 ноде, где нет BBS, это осуществляется при помощи связки BLstBBS+AllFix
(подробнее см. в разделе о BLstBBS). Для того, чтобы отличать новые файлы от
старых, AllFix в каждом таком каталоге хранит файл files.fix с параметрами
файлов. Чтобы пересоздать эти файлы, необходимо запустить
allfix\fixutil.exe BuildDataBase; но при этом потеряется информация о новых
файлах, уже сформированная для анонса. Чтобы она не потерялась, нужно
использовать allfix\builddat.bat

В каталоге t-mail\allfix содержатся два подкаталога - bad и dupes. Они
соответствуют аналогичным областям fastecho и служат для тех же целей.

В процессе работы AllFix создаёт флажок t-mail\allfix\allfix.bsy. Если AllFix
упал в процессе работы, этот флажок необходимо удалить вручную, иначе
дальнейшая работа AllFixа будет блокирована.

Для нормальной работы AllFix необходимо зарегистрировать. Подходящий для
текущей версии (4.41 beta 3) ключ создаёт утилита AFX440RG.EXE

 2.3.1. Автоматическая подписка

Как и FastEcho, AllFix поддерживает автоматическую подписку на файлэхи,
только его робот называется не AreaFix, а AllFix. Точно так же поддерживается
сквозная подписка, для которой тоже необходимы списки доступных файлэх
(t-mail\allfix\f<номен ноды>). Списки тоже нужно запрашивать у аплинков,
единственное отличие - AllFix не понимает команды %AVAIL, только %LIST

 2.4. Гейт Fido<->Internet (LuckyGate)

Одно из последних приобретений /201 ноды - гейт Fido-Internet. Он работает в
паре с uupc; все файлы гейта лежат в каталоге t-mail\gate.

В принципе, он позволяет гейтовать и эхоконференции, но в настоящее время я
использую его только для гейтования нетмейла.

Принцип работы гейта:

1) Fido->Internet. Письмо должно быть написано на адрес 2:46/128, 2:50/128
или 2:463/201.128, в поле имени должен быть указан интернетовский адрес (или,
если он слишком длинный - в поле имени должно стоять uucp, а первой строчкой
письма - To: интернетовский адрес). Тогда при запуске утилиты fido2rel.com
(она вызывается в начале uupc.bat) письмо будет перекодировано в
интернетовский формат, снабжено соответствующим обратным адресом и уложено в
spool для отправки.

Примечание: чтобы ответ по обратному адресу пришёл именно на наш гейт, письмо
должно быть отправлено только по адресу 2:463/201.128

2) Internet->Fido. Письмо, написанное на один из адресов:

Имя_Фамилия@pПойнт.fНода.nСеть.zЗона.fidonet.org

или

Имя_Фамилия%pПойнт.fНода.nСеть.zЗона[email protected]

попадёт в каталог spool\fidonet, и при запуске утилиты rel2fido
(она вызывается в конце uupc.bat) будет перекодировано в фидошный формат и
уложено в t-mail\mail. Очевидно, что извне на гейт письмо может прийти,
только если оно будет снабжено вторым адресом (именно он подставляется в
качестве обратного, если писать в интернет по адресу /201.128); первая же
форма адреса годится для локальных пользователей домена mfer.freenet.kiev.ua

 2.5. Трекер (NetMgr)

Трекер может выполнять (и выполняет) множество задач, связанных с обработкой
нетмейла. Можно перенаправлять письма, формировать автоматические ответы,
отсылать копии на другие адреса, запускать внешние утилиты etc.

Все файлы (включая регистратор) лежат в каталоге t-mail\netmgr. Настройки
хранятся в файле netmgr.cfg.

На /201 ноде Netmgr, помимо роутинга почты для избранных адресов, занимается
перенаправлением почты с uue, упаковкой нетмейла в bink-style outbound и
вызывает HoldMan.

 2.6. Редактор почты (GoldEd)

Вообще-то обычно я пользуюсь своим пойнтовым GoldEDом, в котором указан путь
к нетмейловому каталогу ноды - для большинства задач этого достаточно. Однако
иногда необходимо заглянуть в служебные области тоссера на ноде, поэтому в
каталоге t-mail\golded развёрнут и сконфигурирован этот редактор.

 2.7. Генератор файллиста (BLstBBS)

Поскольку /201 нода отдаёт фреки, необходимо вести файллист - список
имеющихся в наличии файлов. Существует множество генераторов файллиста, я
пользуюсь BLstBBS (лежит в каталоге t-mail\blstbbs).

Для составления файллиста необходимо, чтобы во всех каталогах, перечисленных
в blstbbs.dir, содержались файлы с описаниями. Традиционно эти файлы
называются files.bbs; это обычные текстовые файлы, содержащие имена файлов и
их описания. Для их редактирования удобно использовать оболочку, которая их
понимает (FAR, DOS Navigator, Connect Shell etc.)

Помимо собственно генерации файллиста BLstBBS обновляет список каталогов, из
которых T-Mail и HoldMan отдают файлы по запросам, а также список областей
для анонсов AllFix. В заголовке файллиста (blstbbs.hdr) содержится всякая
полезная информация о работе ноды и том, что на ней есть.

Создание файллиста осуществляется запуском t-mail\bbslist.bat (он
автоматически запускается раз в сутки). При добавлении/удалении/модификации
существующих областей необходимо запустить blstbbs\newareas.bat, а затем,
войдя в allfix\asetup.exe->BBS new file dirs, внести в список анонсов новые
области. Примечание: создаваемые на ноде новые файлэхи не вносятся
автоматически в файллист, это нужно делать вручную.

Раз в неделю файллист /201 ноды запускается в файлэху N463.FILELST

 2.8. Прочие утилиты

 2.8.1. Генератор статистики в эхе (Stat)

Находится в каталоге t-mail\stat. В течение месяца он (будучи подписан как
/201.12345) собирает статистику по траффику в эхе pvt.201, а в начале
следующего месяца публикует её в этой эхе.

 2.8.2. Подрезатель логов (LogMan)

Практически каждая утилита ведёт .log-файл, в котором протоколируются все её
действия, которые могут быть интересны для последующего анализа. Все логи
собраны в каталоге t-mail\log. Поскольку логи растут неограниченно,
необходимо их время от времени подрезать, удаляя старую информацию. Для этой
цели используется t-mail\log\logman.exe (или его win32-версия logman-n) с
конфигурационным файлом logman.ctl.

 2.8.3. Генераторы статистики загрузки линий (T-Hist и T-LAn)

Эти программы, анализируя логи и служебные файлы T-Mailа, формируют наглядную
статистику загрузки линий. T-Hist - поменьше, T-Lan - побольше. T-Hist
вызывается при помощи t-mail\stat.bat, результат - log\t-hist.txt, T-Lan -
при помощи log\edka.bat, результат - log\*.st?

t-hist.txt раз в сутки запускается в эху pvt.201.tech.info

 2.8.4. Отправка файлов (Attach)

Часто требуется сформировать файл-аттач для какой-нибудь системы. Простейший
способ это сделать - использовать утилиту attach.exe из комплекта T-Mail. Она
позволяет отправить файл любым способом, который поддерживается T-Mail.

 2.8.5. Холд-менеджер (HoldMan)

Одно из нововведений на /201 ноде. Мне надоело вручную исполнять кучу просьб
"пожалуйста, выложи файл на холд", и я написал эту утилиту (holdman.exe).
Сама по себе она умеет немного - NetMgr, просматривая нетмейловый каталог,
вызывает её для писем, адресованных to: HoldMan, затем HoldMan анализирует
запрос, ищет файлы по каталогам, и если находит - вызывает attach.exe с
соответствующими параметрами. Список найденных файлов holdman передаёт
обратно NetMgrу, который и отправляет уведомление заказчику.

Я планирую сделать Holdmanа более умным и самостоятельным, но всё упирается в
нехватку свободного времени :(

 2.8.6. Просмотр нодлиста (T-Node)

Утилита T-Node.exe работает в комплексе с T-Mail и предназначена для удобного
просмотра нод- и пойнтлистов, генерации файловых запросов, отправки файлов
etc.

 2.8.7. Просмотр и редактирование очереди (T-Queue)

Утилита T-Queue.exe работает в комплексе с T-Mail и позволяет просмотреть
содержимое очереди (файлов, предназначенных для отправки), добавить файлы в
очередь, выборочно удалить файлы etc.

 2.8.8. Attach Manager (TAM)

Утилита TAM.exe работает в комплексе с T-Mail и позволяет выполнять различные
действия с bink-style outbound (сортировать аттачи, удалять залежавшиеся
файлы, переносить почту для заданной системы в персональный файлбокс или
указанный каталог etc.).

 2.8.9. Постеры текстов (Txt2Msg, Txt2Pkt)

Эти утилиты позволяют отправить произвольный (но не слишком большой) текст
нетмейлом или в заданную эху. Как правило, используются для автоматического
постинга всякой статистики, правил конференций etc.

 2.8.10. Хост VGA Planets

Это, в общем-то, не фидошный софт. Но установлен он в комплекте с нодой
(t-mail\vgaplan), а часть игроков получает и отправляет ходы по почте.
Правила запуска соответствующих .bat файлов записаны в events.ctl вместе с
прочими событиями, остальное - уже за пределами темы этого файла, ибо
относится исключительно к тонкостям VGA Planets

 2.9. Чего на 201 ноде нет, но могло бы быть

Подумавши, я вспомнил только два распространённых сервиса, не реализованных
на 2:463/201...

  2.9.1. BBS

BBS (Bulletin Board System) - пакет, позволяющий пользователям, имеющим
модем и обычную терминальную программу, делать в режиме on-line всё то, что в
сети Fido делается off-line (получать и передавать файлы, обмениваться
почтой и даже получить доступ к фидошным эхам). Существует множество BBSного
софта (Maximus, Remote Access etc.), кое-что есть и в коллекции /201 ноды.

BBS на 2:463/201 нет по следующим причинам:

1) Мне жаль тратить ценное время работы линии на медленный и
непроизводительный online доступ; в наше время в Киеве уже вполне достаточно
фидошников, чтобы любой желающий, проявив небольшую активность, мог
установить себе комплект фидошного софта и получить пойнтовый адрес.

2) Установка BBSного софта хоть и достаточно проста, но всё же требует
времени, которого у меня нет.

 2.9.2. FAQ сервер

FAQ сервер - это программа, анализирующая запросы в нетмейле и высылающая в
ответ нетмейлом соответствующие текстовые файлы из коллекции, имеющейся на
ноде. Прикрутить такой сервер - дело элементарное, но я не могу придумать,
какие же тексты распространять таким образом :)

 3. Обязанности сисопа

В общем, я уже упомянул выше практически все действия, которые сознательный
сисоп должен регулярно выполнять. Но для удобства я перечислю всё это в
сжатом виде (всё-таки памятка, как-никак).

 3.1. Доставка почты

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

1) личная почта (нетмейл)
2) эхоконференции
3) файлэхи
4) фреки

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

 3.2. Свежие нодлисты

Для своевременного реагирования на изменение телефонов и времени работы
станций, а также смены людьми адресов, необходимо использовать самые свежие
из доступных версии нод- и пойнтлистов. Соответствующие файлы приходят по
файлэхам NET_463, N463-PNT (эти две - самые важные, потому что киевские), а
также куче других (R46_PNT, PNTLIST etc.), в виде архивов (ZIP, ARJ etc.) или
незапакованными. Их нужно разворачивать в каталог t-mail\nodelist
(пойнтлисты 50 региона - в t-mail\nodelist\source), удалять старые версии и
запускать nodelist.bat для компиляции всего этого счастья.

Если параметры каких-то узлов прописаны в subst.lst, необходимо отслеживать
состояние этих узлов и своевременно модифицировать содержимое subst.lst.
Кроме того, если меняются параметры непосредственных линков, необходимо
отражать их в subst.lst, пока изменения не попадут в нодлисты.

У этого вопроса есть и обратная сторона: обо всех изменениях в режиме работы
ноды необходимо сообщать своим пойнтам и непосредственным линкам, а если эти
изменения затрагивают первую (нодлистовую) линию - информировать письмом
сетевого координатора. В настоящее время им является Владимир Лиман 2:463/2.

Ещё время работы и номера телефонов /201 ноды перечислены в следующих файлах:
blstbbs\blstbbs.hdr, mfert201.nfo (это просто копия blstbbs.hdr),
allfix\template\reports.apl и filefind.apl. Их тоже необходимо
корректировать.

 3.3. Слежение за новостями

Необходимо быть в курсе событий сети, чтобы своевременно узнавать о таких
жизненно важных вещах, как падение и появление хабов, всяких нововведений в
организационных вопросах, да и просто иметь представление о личностях других
сисопов - глядишь, когда-нибудь придётся работать вместе.

Для этого существует ряд специализированных эх (N463.SYSOP, R46.SYSOP,
R50.SYSOP etc.). Сисопу ноды желательно регулярно читать эти эхи (для
киевских нод, естественно, наиболее важна N463.SYSOP). Кроме того, самый
простой способ оповестить всех об изменениях на ноде - это написать в эту эху
соответствующее письмо.

Кроме того, практически каждая нода имеет свою приватную эху для пойнтов и
непосредственных линков - их тоже просматривать не вредно. Так, например,
приватка нашего хаба /666 называется pvt.yana, /707 - pvt.moon, /166 -
pvt.166 etc.

В понятие "слежение за новостми" входит и своевременная реакция на нетмейл.
Сисоп крупной ноды (а /201, пожалуй, уже можно считать крупной) ежедневно
получает от 5-20 писем, касающихся только технических вопросов, не говоря
уже об обычном личном нетмейле.

 3.4. Уборка мусора

Вообще-то /201 нода долго росла и настраивалась на длительную работу в
автопилоте, и последние длительные праздники показали, что худо-бедно она уже
с этим справляется. Но всё же ничто не заменит чутких рук и зоркого глаза
заботливого сисопа :)

Итак, для нормальной работы ноды нужно хотя бы раз в 2-3 дня (а если есть
возможность - ежедневно) выполнять следующие действия:

1) Контролировать, что все линии нормально работают, когда нужно, и не
работают, когда не нужно. Зависшие машины перегружать, залипшие модемы -
аналогично, более серьёзные проблемы решать творчески путём правки конфигов.

2) Просматривать протоколы дозвонки. Если несколько ночей подряд нет связи с
важным линком - выяснять и устранять причину, если кто-то левый нагло
ломится, мешая дозваниваться остальным - проводить воспитательную работу.
Если какая-то нода долго не отвечает на звонки (определяется по счётчику
попыток в окне очереди T-Mail) - снимать прозвонку, выяснять, не поменялся ли
режим работы ноды, всё ли там в порядке etc.

3) Просматривать очередь (при помощи утилит T-Queue, T-Quebbs или просто в
окне очереди T-Mail). Если кто-то из пойнтов и даунлинков не справляется с
выгребанием своей доли (количество файлов на холде принимает угрожающие
размеры) - действовать по обстоятельствам. То есть уведомить его нетмейлом,
чтобы умерил аппетиты, временно перевести его в %pause по эхам/файлэхам,
выборочно вручную поудалять скопившуюся почту, наладить TAM, чтобы он
прибивал завалявшиеся файлы (сейчас парочка пойнтов живут на этом режиме).

4) Контролировать своевременную отработку событий. В events.ctl прописано
достаточно много запусков разных программ, например, ежедневный вызов
log\oneday.bat, где собраны все операции, которые должны выполняться раз в
день.

5) Проверять, чтобы оставшиеся после ошибок флаги занятости не мешали работе
утилит.

6) Просматривать и чистить временные каталоги (t-mail\temp, fastecho\temp), а
также каталоги приходящей почты - t-mail\files для парольных сессий и
t-mail\uncheck для непарольных. Там со временем собирается разный мусор
(недокачанные файлы, .TICи без соответствующих файлов, файлы без .TICов
etc.). Убедившись, что файл лежит уже давно и никому не нужен, можно его
удалять или перекладывать в коллекцию файлов на фреке, если надо.

7) Следить, чтобы на сервере было достаточно свободного места.

8) Проверять, не замусорился ли каталог t-mail\mail - при нормальной работе
там должны быть только ждущие отправки транзитные письма, фреки и служебные
письма Poll.

9) Проверять, нет ли дупов и бэдов в каталогах allfixа и областях fastecho.
Если их регулярно появляется много и из одного источника - надо искать
причину (петлю, ошибочную подписку etc.) и устранять.

10) Просматривать подкаталоги g:\uupc\spool - всё ли нормально отсылается,
нет ли неотправленных из-за каких-то глюков писем.

11) Если приходят новые файлэхи - решить, представляют ли они интерес.  Если
да - в allfix\asetup.exe включить для них опцию Announce, внести каталог в
blstbbs\blstbbs.dir и запустить newareas.bat. Если нет - перевести файлэху в
режим passthrough (в том же asetup), а каталог удалить.

 3.5. Новые пойнты и линки

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

1) Для всех:

- запросить необходимую информацию (пароли на сессию и для роботов, для
пойнтов - ещё и информацию для строчки пойнтлиста);

- прописать пароль на сессию в t-mail\password.lst;

- в конце файла netmgr\netmgr.cfg добавить строчку для упаковки почты на этот
адрес (для локальных пойнтов - добавить адрес в строку вызова fastecho pack в
t-mail\packmail.bat);

- прописать новый адрес в asetup.exe->Node manager, взяв в качестве образца
какой-нибудь из ранее там прописанных (учитывая при этом особенности -
локальный это пойнт или нет, кто кому по договорённости будет прозваниваться,
то есть ставить атрибуты Hold или Direct etc.);

- аналогично, прописать в fesetup.exe->Node configuration; если это нода, от
которой планируется получать эхи, необходимо разрешить autocreate и настроить
Group area defaults;

- если это пойнт или дайнлинк, подписать его на эхи pvt.201 и
pvt.201.tech.info;

- отправить ему нетмейлом на старый адрес (если он у него есть) уведомление,
можно также оставить на холде для нового адреса письмо с перечнем сервисов и
особенностей ноды.

2) Только для нод:

- в events.ctl добавить адрес в список Direct;

- если необходимо самим прозваниваться на эту ноду, добавить адрес в строку
Poll;

- если прозваниваться на этот адрес ни в коем случае нельзя, добавить адрес в
строку Hold.

3) Только для пойнтов:

- внести нового пойнта в пойнтлист (nodelist\pvt.201). В общем, все поля там
достаточно наглядны, за исключением нескольких последних:

после номера телефона идут обозначения протоколов, поддерживаемых модемом;

затем - поддерживаемые протоколы отдачи фреков (зависит от используемого
мейлера; T-Mail - XX; FrontDoor, Bink, SF-Mail - XA);

затем, если система отвечает на звонки - время работы по Гринвичу в виде
фалжков U,Txy, где xy - обозначение начала и конца интервала (A - 0:00, a -
0:30, B - 1:00, b - 1:30, C - 2:00 etc.); чтобы не мучаться с переводом
вручную, есть утилитка nodelist\ut.com

- перекомпилировать нодлисты (nodelist\nodelist.bat)

- отправить новый сегмент сетевому пойнт-координатору. В настоящее время им
является Вадим Серков 2:463/11, так что отправка осуществляется командой
attach.exe pnt.201 2:463/11

 3.6. Переход на летнее/зимнее время

Два раза в год это событие вносит кратковременную неразбериху в работу
Fidonet, поскольку время работы указывается в нодлисте по Гринвичу. Для
смягчения последствий это время указывается с запасом в 1 час, чтобы при
сдвиге времени на час вперёд/назад не требовалось менять нодлист.

Всё большее количество утилит поддерживают переменную среды TZ (TIMEZONE),
позволяющую не морочиться с указанием смещения utc вручную, но, увы, пока ещё
не все, да и я пока не нашёл полного описания формата этой переменной :( Так
что вот перечень мест, где нужно внести исправления:

t-mail.ctl, переменная utc (лето +2, зима +3)
t-node.ctl, аналогично
allfix\asetup.exe, в общих настройках, аналогично - +2/+3
g:\uupc\conf\uupc.rc - лето TZ=UKR-2, зима UKR-3 (вот так вот криво и
            не как у людей)

 3.7. Автоподписка

Поскольку автоматическая сквозная подписка на эхи и файлэхи происходит по
заранее заготовленным спискам эх, необходимо эти списки обновлять хотя бы раз
в полгода. Для этого всем роботам AreaFix аплинков рассылаются запросы %LIST
и %AVAIL, а роботам AllFix - %LIST. Ответы записываются в файлы (по файлу на
ноду, эхи и файлэхи отдельно), из списка удаляются заголовки и прочая
служебная информация, а также список эх от самой /201 ноды, после чего список
сортируется, из него удаляются дупы, и новый список помещается на место
старого (при описании fastecho и allfix я уже говорил, как именовать и куда
класть эти файлы).

 4. Как получить ноду

А вдруг кому-то эта информация понадобится - меня, например, уже несколько
раз спрашивали.

Для получения ноды нужно сделать следующее:

1. Установить комплект софта и настроить его (какой комплект - вы уже имеете
представление из этого файла). Поскольку сразу нодой в Fido не становятся, а
прежде ходят в пойнтах, то пока на станции будет этот пойнтовый адрес.

2. Найти нетмейлового хаба, который согласится принять ноду к себе в
подхабник.

3. Найти [файл]эхохаба или могучего аплинка, который будет снабжать новую
ноду эхами и файлэхами.

4. Найти и прочитать экземпляр Fido policy.

5. По указанному там образцу составить заявку и отправить её сетевому
координатору, сопроводив форвардом письма от нетмейлового хаба, где он
соглашается взять к себе новую ноду.

6. Если в заявке обнаружатся ошибки - Лиман её вернёт для исправления. Если
всё будет правильно - Лиман ничего не скажет, и тогда нужно внимательно
просматривать новые сегменты нодлиста из NET_463, чтобы увидеть там свою
строчку.

7. Узнав из этой строчки свой нодовый адрес, окончательно донастроить софт,
сообщить своим непосредственным линкам etc.  Но сразу пользоваться этим
адресом в переписке нельзя. Дело в том, что киевский сегмент нодлиста выходит
с упреждением, а формально нода появится на свет только после попадания в
мировой нодлист. Этот момент легко определить - в расширении нодлистового
сегмента указан номер дня с начала года, когда этот сегмент вступит в силу.

Я мог бы рассказывать ещё долго, но это уже было бы простым пересказом
документации. Так что не буду.
 

                          Желаю удачи!

                              Andrzej Novosiolov, 2:463/201@fidonet