Руководство администратора сети в ОС Linux.

Каталог документации / Раздел "Документация для Linux" / Оглавление документа




     1. Предисловие

     В  последнее  время  Internet  очень  часто  оказывается в центре
внимания,  и серьезные люди часто болтаются по этому " Информационному
супершоссе". Компьютерные сети становятся такими же обыденными вещами,
как  телевизоры  и  микроволновые  печи.  Inetrnet  получает  необычно
широкое  освещение  в  печати, а ученые обсуждают в Usenet возможность
проведения   исследований   "Internet  культуры."  Различные  компании
работают над новыми методами передачи данных, например ATM, которые во
многих  случаях  позволяют  получить  большую  скорость  передачи, чем
сейчас.

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

     Разговор  о  компьютерных  сетях  очень часто означает разговор о
UNIX.  Конечно,  UNIX - не единственная сетевая операционная система и
не  всегда  она  будет  лидером,  но умрет она очень не скоро. Поэтому
особенно  интересным  для пользователя становится появление бесплатных
UNIXоидных  операционных  систем  для  PC  (386BSD,  FreeBSD и Linux).
Однако, Linux - не UNIX. Unix - зарегистрированная торговая марка, кто
бы  в  настоящее время не держал права на него, в то время как Linux -
oперационная  система, которая стремится предложить все функциональные
возможности,  требующие POSIX-стандарты для UNIX-подобных операционных
систем.

     Ядро  Linux  было написано в значительной степени Linus Torvalds,
человеком,  который  начал это проект, чтобы понять как работает Intel
i386  и  MINIX. MINIX -- другая, популярная тогда операционная система


для   PC,   предлагающая  многие  функциональные  возможности  Unix, и
написанная профессором A.С.Танненбаумом.

     Linux  попадает  под  GNU  Лицензию,  которая  позволяет свободно
распространять  код  (пожалуйста  читайте  GPL  в  приложении 20.3,где
написано,    что    значит    "свободнораспространяемое    программное
обеспечение").  Понемногу оставляющая трудности, связанные с маленьким
возрастом,   и   привлекающая  большой  и  все  возрастастающей  базой
бесплатных  прикладных  программ,  эта операционная система становится
все более распространенной. Ядро и C библиотека становятся так хороши,
что  большинство стандартного программного обеспечения компилируется с
тем  же  успехом,  что  и  на  любой  другой  Unix  системe, а широкий
ассортимент различных Linux позволяет Вам просто переписать его на ваш
жесткий диск и начинать работать.


     1.1. Документация о Linux

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

     Так  в  1992,  Lars  Wirzenius  и  Michael  K. Johnson предложили
организовать   проект   документации   для   Linux,   или  LDP  (Linux
Documentation  Project),  который стремится к обеспечению пользователя
полным набором документации. Коротко останавливаясь на вопросах типа "
Как?  ",  "Почему?",  или  "Что  -  значит  жизнь,  вселенная,  и  все
остальное?",   эти   руководства   пытаются   охватить   все   аспекты
управления  и  использования  Linux  пользователем,  не требуя от него
предварительного  знания  Unix.  Среди достижений LDP - Руководство по
установке, написанное Matt Welsh, Руководство по взлому ядера, Michael
K.  Johnson,  и  проект  создания  man-страниц,  скоординированный Rik
Faith,  который  пока  снабдил  Linux  450  страницами руководства для
большого  количества системных вызовов и Cи библиотек. Руководство для


администраторов  системы, написанное Lars Wirzenius, находится все еще
на стадии разработки. Руководство пользователя уже подготовлено.

     Однако,  книги LDP - не единственный источник информации о Linux.
В   настоящее   время,  имеются  больше  чем  дюжина  HOWTOs,  которые
отправлены  по почте к comp.os.linux.announce и регулярно архивируются
на различных FTP серверах.

     HOWTOs  -  короткие  документы,  состоящие из нескольких страниц,
которые  дают  Вам  краткое  представление  по  темам  типа  поддержки
Ethernet  под Linux, или конфигурации Usenet программного обеспечения,
а  также  ответы  на часто задаваемые вопросы. Они обычно обеспечивают
наиболее  точную  и современную информацию, доступную по даннной теме.
Список  доступных  HOWTO  приводится  в  "Аннотируемой Библиографии" в
конце этой книги.

     1.2. Об этой книге

     Когда я присоединился к LDP в 1992, я написал две маленькие главы
об  UUCP  и  smail,  которые  я  хотел  добавить  к  "Руководству  для
администратора  системы".  Разработка TCP/IP сети только начиналась, и
когда  те  "маленькие главы" начали расти, я решил, что было бы хорошо
иметь  Руководство  для  администратора  сети,  пошел и написал первую
версию Руководства Сети, которую и выпустил в сентябре 1993.

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

     Книга  организована  как  последовательность  шагов,  которые  Вы
должны  сделать,  чтобы  отконфигурировать  вашу  систему для работы в
сети.  Все  начинается с обсуждения основных концепции сетей вообще, и
сетей,  основанных на TCP/IP, в частности. Мы медленно пройдем путь от
конфигурирования  TCP/IP  на  уровне устройств к установке стандартных
приложений   типа  rlogin  и  подобных,  сетевой  файловой  системы, и
информационной  системы  сети.  К  этому  прилагается глава о том, как
сделать  вашу  машину  UUCP-узлом. Остаток книги посвящен двум главным
приложениям,  которые  запускаются  как  над  TCP/IP,  так и над UUCP:


электронная почта и новости.

     Email  часть  более  широко описывает механизмы транспортировки и
маршрутизации  почты, и множество схем адресации, с которыми вы можете
столкнутся.  Там  же  описывается конфигурирование и управление smail,
агента транспортировки почты, обычно используемого на меньших почтовых
центрах,  и  sendmail, который преддлагается для людей, которые должны
заниматся  сложной  маршрутизацией  или работать с большим количеством
почты. Глава Sendmail была написана Vince Skahan.

     Часть   News  пытается  дать  Вам  краткий  обзор  работы  Usenet
новостей,  наиболее  широко используемое в настоящее время программное
обеспечение  для  транспортировки  новостей  и  использование NNTP для
обеспечения  доступа  newsreader  к  местной сети. Книга заканчивается
короткой главой о наиболее популярных newsreaders для Linux.


     1.3. Официально Напечатанная Версия

     Осенью 1993, Andy Oram, человек который был в списке рассылки LDP
почти с самого начала, спросил меня относительно публикации моей книги
в  фирме O'Reilly и Партнеры. Я был воодушевлен этим; Я никогда не мог
вообразить,  что  моя  книга  пользуется  успехом.  Мы согласились что
O'Reilly  будет  печатать "Официальную печатную версию руководства для
администратора  сети",  в  то  время  как  Я  сохранил  первоначальные
авторские  права  так,  чтобы  книга  свободно  распространялась.  Это
означает    что    Вы    можете    выбрать:   получить   LaTeX   текст
распространяемый  по  сети ( DVI или PostScript версии), и распечатать
их.  Или  Вы  можете купить официально напечатанную версию у O'Reilly,
которая будет доступна несколько позже в этом году.

     Непонятно,  почему  Вам захочется заплатить деньги за что-то, что
Вы  можете  достать  бесплатно?  Не  сошел  ли Tim O'Reilly с ума, раз
пытается  продавать  то  что каждый может напечатать и даже продавать?
Или есть некое различие между этими версиями?

     Ответ  --  "это  зависит",  "нет,  определенно не," и "да и нет."
O'Reilly  и  Партнеры  рискует, публикуя это руководство, но Я надеюсь


что  это  окупится.  Если  это  произойдет, Я полагаю, что этот проект
сможет  послужить  как  пример  того  как мир бесплатного программного
обеспечения и компании могут сотрудничать, чтобы произвести что-нибудь
полезное и тем и другим. На мой взгляд, O'Reilly делает большую услугу
Linux  сообществу  (кроме  книге  доступной  в  вашем  местном книжном
магазине)  и тем, что это может помочь всем посмотреть на Linux как на
что-то  серьезное,  как  на  жизнеспособную  и  полезную  альтернативу
коммерческим UNIX операционным системам для PC.

     Так  что  же  относительно  различай между напечатанной версией и
электронной?  Andy  Oram  провел большую работу по преобразованию моей
ранней  версии  в  то, что можно печать. (Он просмотрел также и другие
книги  созданные  под  эгидой  LDP, и повышал как мог профессиональный
уровень нашей документации).

     С   тех   пор   Andy   начал   просматривать   это  Руководство и
редактировать  копии,  которые  Я  послал ему, книга стала значительно
лучше,  чем  еще  пол  года  назад.  И  если бы не он то книга была бы
гораздо  хуже  чем  есть сейчас Все его изменения тут же вставлялись в
электронную версию, и все последующие изменения, которые будут сделаны
к  Руководству  для  администратора  сети  во  время редактирования их
O'Reilly  так  же  будут  вставлены.  Таким  образом  не будет никаких
различай   между   этими  версиями.  Все  же,  версия  O'Reilly  будет
несколько  отличатся: С одной стороны, люди O'Reilly проделывают массу
работы  над  внешним видом книги на таком уровне который вы никогда не
получите  от  стандартного  TEXа  С  другой  стороны, там будет больше
картинок, и улучшенный алфавитный указатель.

     1.4. Дополнительная Информация

     Если  Вы  следуете  инструкциями  этой  книги,  и  что-нибудь  не
работает,  пожалуйста  будьте  терпеливы.  Некоторые  из ваших проблем
могут возникнуть из-за моих глупых ошибок, но могут также быть вызваны
изменениями  в  программном  обеспечении.  Лучше спросить относительно
своих  проблем  на comp.os.linux.help. Есть большая вероятность что Вы
не  единственный  кто  столкнулся  с  подобными вашим проблемами, и ее
решение   известно.  Если  Вы  имеете  возможность,  Вы  должны  также
попробовать   получить   самую   последнюю   версию  ядра  и  сетевого


программного  обеспечения  на  одном  из  Linux  FTP  серверах, или на
ближайшей от вас BBS.

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

     Другое  хорошее  место,  где  можно узнать о процессе разработки
организация   сети   HOWTO.  Ее  поддерживается  Terry  Dawson  HOWTOs
отсылаются  по  почте  на  comp.os.linux.announce  один раз в месяц, и
содержат  наиболее  современную  информацию. Текущая версия может быть
также получена на tsx-11.mit.edu, в /pub/linux/doc. Если свои проблемы
Вы  не  можете  решить другим путем, Вы можете также войти в контакт с
автором  этой  книги  по  адресу  данному  в  ведении. Но, пожалуйста,
воздержитесь  от  обращения  за  помощью  к  разработчикам.  Они и так
посвящают основную часть свободного времени Linux.

     1.5. Об Авторах

     1.  Olaf  был  UNIX пользователем и администратором пару лет пока
изучал  математику. В настоящее время он работает UNIX программистом и
пишет  книгу.  Одно  из его любимых спортивных состязаний делать такие
вещи  с  помощью  sed для которых другие люди использовали бы perl. Он
получает  от этого такое же удовольствие как другие люди от лазанья по
горам с палаткой и рюкзаком.

      2.                                                                
с  1987  и  в настоящее время управляет sendmail+IDA на приблизительно
300  UNIX  машинах для более чем 2000 пользователей. Он признался, что
провел  много бессонных ночей за редактированием sendmail.cf файлов до
открытия  sendmail+IDA  в  1990.  Он  также  признает,  что с тревогой
ожидает  поставки  первой perl версии sendmail, для неясных пока забав
(см. 4).

      3.     Terry    Dawson    может    быть    найден    по    адресу
[email protected].

      4. Вы думаете что Вы могли бы сделать это в sed, Vince?



     Olaf может быть найден по следующему адресу:

     Olaf Kirch
     Kattreinstr. 38 64295 Darmstadt Германия
     [email protected]

     Vince может быть найден на:

     Vince Skahan
     [email protected]

     Мы  открыты  для  ваших вопросов, комментариев, открыток, и т.д..
Однако, мы просим Вас писать нам только если это действительно важно.

     1.6. Благодарности

     Olaf благодарит всех людей, которые профессионально прочитали эту
книгу, и потратили свое время на исправление ошибок как грамматических
так и технических. Наиболее энергичный среди них был Andy Oram.

     Я  очень признателен Andres Seplveda, Wolfgang Michaelis, Michael
K.  Johnson,  и  всем  разработчикам  кто  потратил  свое  время чтобы
проверить  информацию,  находящуюся в данном Руководстве. Я также хочу
поблагодарить   всех  тех  кто  читал  первую  версию  Руководства  за
посланные  меня  исправления  и  предложения.  Вы  можете найти полный
список помощников в файле Thanks. И Наконец, эта книга не появилась бы
без поддержки Holger Grothe.

     Я  также  хотел  бы  поблагодарить  следующие  группы и компании,
которые  напечатали  первое  издание Руководства и пожертвовали деньги
или мне, или LDP в целом.

        + Linux Бригада Поддержки, Erlangen, Германия

        + S.u. S.E. GmbH, Fuerth, Германия

        + Linux Лаборатории Системы, Компания, Соединенные Штаты



     Vince благодарит Neil Rickert и Paul Pomes за большую помощь во время
работы с sendmail+IDA и Rich Braun за перевод sendmail+IDA на Linux.
Самая большая благодарность моей жене Susan за  всю поддержку в этом и других
проектах.

     1.7. Условные Обозначения

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

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

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

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

     Typewriter    Slanted    шрифт    используется   чтобы   отметить
meta-переменные  в  тексте, особенно в представление командной строки.
Например:

               $ Ls -l foo

               Где foo -- имя файла, типа /tmp.

'клавиша'  Представляет  клавишу,  которую надо нажать. Вы будете
часто видеть это в этой форме:

                Press 'return' to continue.

     <>  -  алмаз  с  краю, подобно черному алмазу на a лыжном склоне,
отмечает   "опасность"   или   "предостережение."   Читайте  параграфы


отмеченные этим значком более тщательно.


     $  И  # предшествует команде оболочки которую нужно выполнит. "$"
символ   используется  когда  команда  может  быть  выполнена  простым
пользователем;   "#"   означает  что  команда  требует  пользователя с
привилегией root.


     1.8. Проект linux документации
          
     Проект  linux  документации, или LDP, является свободной бригадой
авторов  и  редакторов,  которые  работают  вместе,  чтобы  обеспечить
завершенную  документацию  для  Linux  операционной  системы.  Главный
координатор  проекта  -  Matt  Welsh,  ему  помогает  Lars Wirzenius и
Michael K. Johnson.

     Это  руководство распространяется как часть LDP, который включает
в себя "Linux Руководство Пользователей", "Руководство Администраторов
Системы",  "Руководство  Администраторов Сети", и "Руководство хакеров
ядра".  Эти руководства доступны в формате LaTeX, .dvi и Postscript на
анонимном FTP ic.funet.fi, в каталоге /pub/OS/Linux/doc/doc-project, и
на tsx-11.mit.edu, в каталоге /pub/linux/docs/guides.

     Мы  поощряем  любого  кто  пожелает  помогать  нам улучшать Linux
документацию.  Если  Вы  имеете  доступ к электронной почте, Вы можете
присоединяться  к  DOC каналу списка рассылки linux-активистов посылая
почту на [email protected]

Со строкой:
  X-Mn-Admin:  join DOC

     в  заголовке  или как первая строка тела сообщения. Пустая почта,
без  дополнительной  строки, заставит mail-server отослать сообщение с
помощью.  Чтобы  оставить  канал,  пошлите  сообщение  тому  же самому
адресу, включив строку

   X-Mn-Admin: leave DOC



     1.9. Стандартная организация файлов системы

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

     Чтобы  улучшить  эту  ситуацию,  в  августе  1993 несколько людей
сформировали  Группу  Стандартов  Системы  Файлов в Linux, или коротко
FSSTND  После  шести  месяцев  обсуждения,  группа представила проект,
который   представляет   структуру   системных   файлов  и  определяет
местоположение наиболее необходимых программ и файлов конфигурации.

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

     Стандарт  системы  файлов  в  Linux  может  быть  получен на всех
основных  Linux  FTP серверах и их зеркалах; например, Вы можете найти
его  на sunsite.unc.edu в /pub/linux/docs. Daniel Quinlan, координатор
группы FSSTND, может быть найден по адресу [email protected]




     2. Общие сведения о сетях.

     2.1. Введение.

     Идея  сетей  также  стара,  как  и  вообще идея телекоммуникаций.
Рассмотрим людей, живших в каменном веке, когда для обмена сообщениями
между  людьми  использовались барабаны. Предположим пещерный человек А
хочет  пригласить  пещерного человека Б поиграть, но тот живет слишком
далеко и не может услышать барабана, в который бьет А. Каковы же могут
быть  действия  А? Он может а) пешком добраться до Б, б) взять барабан
побольше , или в) попросить В живущего на полпути между А и Б передать
сообщение. Позже это стали называть сетями.

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

     Здесь  будет  описано  два  типа сетей: те что базируются на UUCP
протоколе,  и  те  что базируются на TCP/IP. Это комплект протоколов и
программ,  которые предоставляют различные способы передачи информации
между  компьютерами.  В  этой  главе  мы  рассмотрим  оба типа сетей и
обсудим их основополагающие принципы.

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

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

     Связь  невозможна  без какого либо языка или кода. В компьютерных


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

     2.2. UUCP сети.

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

     UUCP  впервые  был  предложен  Bell лабораториями в 1977 году для
связи  между их Unix участками. В середине 1978 г. эта сеть объединяла
уже 80 машин. Она позволяла использовать электронную почту и удаленную
печать. Сегодня UUCP не ограничивается только Unix средами. Существует
масса как коммерческих так и бесплатных переносов данного протокола на
другие платформы, включая AmigoOS, DOS, Atari's TOS, и другие.

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

     Несмотря  на  эти  ограничения,  имеется  большое количество UUCP
сетей,  работающих  во  всем  мире  главным  образом  под  управлением
энтузиастов,  которые  предлагают  частный  доступ  к сети за разумные
цены. Главная причина популярности UUCP в том, что это очень дешево по
сравнению  с наличием компьютера, связанного кабелем с Intеrnet. Чтобы


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


     2.2.1. Как Использовать UUCP

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

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

     $ Uux -r swim! Lpr! Netguide.dvi

     Uux,  команда  из  UUCP  набора, передает работу swim. Эта работа
состоит  из входного файла, netguide.dvi, и запроса передать этот файл
команде  lpr.  -r  флаг  просит  uux  не  вызывать  отдаленную систему
немедленно,  а  сохранить  работу  до  установления  связи  с ней. Это
названо spooling (спулинг).

     Другое  свойство  UUCP, позволяет передавать задачи и файлы через
несколько  хостов.  Предположим swim, упомянутый в предыдущем примере,
связан  UUCP  с  groucho,  который  поддерживает  большой  архив  Unix
приложений.  Чтобы  загрузить файл tripwire-1.0.tar.gz на вашу машину,
Вы могли бы ввести

   $  uucp  -mr  swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz

     Эта  команда  попросит swim скачать файл с groucho, и послать его
вашей машине, где UUCP сохранит его в trip.tgz и уведомит Вас по почте
о получение этого файла. Все выполняется в три шага. Сначала, ваш хост
посылает  задачу  swim.  Когда  swim устанавливает контакт с groucho в
следующий  раз, он загружает файл. Заключительный шаг - передача файла
от swim вашему хосту.



     Наиболее  важная  услуга, предоставляемая UUCP сетями в наши дни,
--  электронная  почта  и  новости. Мы вернемся к этому позже, так что
здесь мы дадим только краткое описание.

     Электронная  почта (email) позволяет Вам обмениваться сообщениями
с  пользователями  на отдаленных хостах без необходимости иметь доступ
на  эти  хосты.  Задача  направления  сообщения  от  вашего участка до
участка  места  назначения  полностью  выполняется  системой обработки
почты.  В  UUCP среде, почта обычно транспортируется с помощью команды
rmail,   передовая   ей  адрес  получателя  и  само  сообщение.  Rmail
отправляет  сообщение  соседнему  хосту,  и  так  далее,  пока  оно не
достигнет  места  назначения.  Мы  будем  рассматривать это подробно в
главе 14 ..

     Новости(News)  могут  лучше всего быть описаны как распределенная
система информационного табло. Наиболее часто, этот термин относится к
Usenet  Новостям,  которые  являются  наиболее  широко известной сетью
обмена   новостями  с  приблизительно  120,000  участвующими  хостами.
Появление Usenet относятся к 1979 г, когда, после выпуска UUCP с новым
Unix  V7,  три  студента предложили идею всеобщего обмена информации в
пределах  Unix  сообщества.  Они  создали  несколько скриптов, которые
стали  первой  news  системой.  В 1980, эта сеть связывала duke, unc и
phs,  в  двух  Университетах  на  Севере Каролины. И Usenet в конечном
счете  рос  и рос. Хотя она появилась как uucp-основанная сеть, она не
могла ограничиваться только одним типом сети.

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

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



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

     2.3. TCP/IP Сети

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

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

     Решение,  которое  Unix  системы  и  большинство не-Unix участков
приняли известно как TCP/IP. В этой секции, мы будем рассматривать его
основные концепции.

     2.3.1. Введение в TCP/IP-сети.

     TCP/IP происходит от проекта, финансируемого американским DARPA (
Оборонное   Агентство  Продвинутых  Исследований)  в  1969.  Это  была
экспериментальная   сеть,   ARPANET,   которая   была  преобразована в
эксплуатационную в 1975, после того, как была доказана ее полезность.

     В  1983,  новый  протокол TCP/IP был принят как стандарт и от все


хостов  в  сети  требовалось  его использование. Когда ARPANET наконец
вырос в Inetrnet (ARPANET непосредственно окончил свое существования в
1990),  использование  TCP/IP распространилось и на сети вне Inetrnet.
Наиболее известные -- Unix локальные сети, но из-за появлении быстрого
цифрового  телефонного оборудования, типа ISDN, он также имеет большой
шанс стать протоколом транспортировки для телефонных сетей.

     Для  более  конкретного  рассмотрения  TCP/IP повсюду в следующих
секциях, мы будем пользоваться как примером Groucho Marx Университетом
(GMU),который   расположен  где-нибудь  в  Fredland,  большинство  его
отделов  используют  собственную  локальную  сеть, а другие используют
несколько  из  них.  Они  все  связаны,  и подключены к Inetrnet через
единственную быстродействующую линию.

     Предположите  что ваш Linux связан с сетью из Unix машин в Отделе
Математики,  и  имя  вашей  машины erdos. Для доступа к хосту в Отделе
Физики, называемого quark, вводите следующую команду:

     $ rlogin quark.physics
     Welcome to the Physics Department at GMU
     (ttyq2) login:

     В  приглашении  Вы вводите ваше имя, скажем andres, и ваш пароль.
Вам  дают shell(оболочку) на quark, к которой Вы можете обращаться как
будто  Вы  сидите  за  системной  консолью  quark.  После  того как Вы
покинете  оболочку,  Вы  возвращаетесь к приглашению вашей собственной
машины.  Сейчас  Вы использовали только одно из диалоговых приложение,
которые предлагает TCP/IP: remote login.

     Пока  вы  находитесь  на  quark, Вы можете захотеть управлять Х11
приложением.  Чтобы сказать этому приложению что Вы хотите видеть окна
на экране вашего хоста, Вы должны отрегулировать среду:

     $ export DISPLAY=erdos.maths: 0.0

     Если  Вы  теперь  запускаете ваше приложение, оно будет входить в
контакт  с  вашим  X-сервером  вместо  quark, и отображать все окна на
вашем экране. Конечно, это требует наличия у вас X11. TCP/IP позволяет


quark  и  erdos  послать  X11  пакеты  туда  и  обратно создавая у вас
иллюзию,  что  вы  находитесь  на  удаленной системе. Сеть здесь почти
прозрачна.

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

     Так,  можно  устанавливать  приложения  которые  требуют большого
количества  места  на  диске  (  типа  TeX ) только на одной машине, а
остальные  будут  лишь  экспортировать директории. Мы вернемся к NFS в
главе 12 ..

     Конечно,  это  не единственные примеры того, что Вы можете делать
по TCP/IP сетям. Ваши возможности почти безграничны.

     Теперь  мы  поближе  познакомимся  с  работой  TCP/IP.  Вы будете
нуждаться  в  этом чтобы понять как и почему Вы должны конфигурировать
вашу  машину.  Мы начнем с исследования аппаратных средств, и медленно
пойдем дальше.

     2.3.2. Ethernet

     Тип  аппаратных  средств  наиболее  широко используемый повсюду в
локальных  сетях обычно называют Ethernet. Он состоит из единственного
кабеля с хостами

     Присоединяемый  к  нему  через  connector,  tap или transceivers.
Простой  Ethernet  весьма  недорог,  хотя,  вместе  с сетью предлагает
скорость в 10 Мегабитов в секунду.

     Ethernet  бывает  трех видов: толстый и тонкий, соответственно, и


витая  пара. Тонкий и толстый Ethernet использует коаксиальный кабель,
отличающейся  по  ширине и способу подключения машины к кабелю. Тонкий
Ethernet  использует  "BNC"  connector  в  форме буквы Т, в который Вы
вставляете  кабель  и  вкручиваете  сзади  вашего  компьютера в гнездо
сетевой  платы. Толстый Ethernet требует, чтобы ВЫ проделали маленькую
дырку  в  кабеле,  и  воткнули transceiver "методом вампира". Один или
больше  хостов  может быть присоединено к одному transceiver. Тонкий и
толстый  кабель  Ethernet  может  иметь  длину  не  больше  200  и 500
метров,  соответственно,  и поэтому также названы 10base-2 и 10base-5.
Витая пара использует кабель сделанный из двух медных проводов которые
используются  в телефонии, но обычно требует дополнительных аппаратных
средств. Он также известен как 10base-T.

     Добавление  хоста к толстому Ethernet не слишком сложно, оно даже
не  вырубает  сеть. Чтобы добавлять машину к сети с тонким Ethernet Вы
должны  прервать работу сети по крайней мере на несколько минут потому
что Вы должны разрезать кабель чтобы вставить Т-connector.

     Большинство  людей  предпочитают  тонкой Ethernet, потому что это
очень дешево: карты PC стоят всего $50, а кабель находится в диапазоне
нескольких  центов  за  метр.  Однако, для больших сооружений, толстый
Ethernet  подходит  лучше  Например,  в  отделе  математики используют
толстый Ethernet, так что у них работа сети не будет прерваться каждый
раз, когда к сети добавляется новый хост.

     Один  из  недостатков  Ethernet технологии -- ограниченная длинна
кабеля, который позволяет использовать его только для локальных сетей.
Однако, несколько Ethernet сегментов могут быть связан друг с другом с
помощью   repeaters   (повторителей),  bridges  (мостов)  или  routers
(маршрутизаторов).  Repeaters  просто копируют сигналы между двумя или
больше сегментами так, что все сегменты вместе действуют как будто это
один  Ethernet.  Но  между  двумя  любыми  машинами сети не может быть
больше  четырех  repeaters.  Bridges  и  Routers  более  сложные.  Они
анализируют  поступающие  данные  и  отправляют их только тогда, когда
хоста получателя нет на местном Ethernet.

     Ethernet  работает подобно системной шине, где хост может послать
пакеты  до  1500  байтов  другому хосту на том же самом Ethernet. Хост


идентифицируется  адресом, состоящем из шести байт зашитыми в Ethernet
плату   при   ее   создании.   Эти   адреса  обычно  записываются  как
последовательность шестнадцатиричных чисел с двумя цифрами отделяемыми
двоеточиями, на пример aa: bb: cc: dd: ee: ff.

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

     2.3.3. Другие типы аппаратных средств

     В  больших  сооружениях,  типа Groucho Marx Университет, Ethernet
обычно  не единственный тип используемого оборудования. В Groucho Marx
Университет,  локальная  сеть каждого отдела связана с университетской
магистралью, которая является оптическим кабелем FDDI. FDDI использует
совершенно  другой  подход  к передаче данных, который основывается на
рассылке  определенных  символов,  и только если станция получает этот
символ, она может послать некий кусок информации. Главное преимущество
FDDI  - скорость, достигающая 100 Mbps, и максимальная длина кабеля до
200 км.

     Для дальней связи часто используются различные типы оборудования,
которые   основаны   на  стандарте  названном  X.25.  Большинство  так
называемых  "Общественных  Сетей  Данных",  подобно  Tymnet в США, или
Datex-P в Германии, предлагают свои услуги, основываясь именно на нем.
X.25   требует   специальных   аппаратных   средств,  а  именно  пакет
Assembler/Disassembler  или  PAD.  X.25  определяет  собственный набор
протоколов,  но часто используется чтобы соединить сети работающие под
TCP/IP  и  другими  протоколами. Так как IP пакеты не могут быть прямо
отображены  на  X.25  (  и  наоборот  ), они просто вставляются в X.25
пакеты и посылаются по сети.

     Часто,  радио  любители используют свое оборудование для создания
сети  из  своих  компьютеров;  это  называется  пакетное радио или ham
радио.  Протокол  используемый  ham  радио назван AX.25 (он получен из
X.25).



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

     2.3.4. Internet Протокол(IP)

     Конечно,  Вы  не  хотели бы чтобы ваша сеть ограничивалась только
Ethernet. Идеально, Вы хотели бы использовать сеть независимо от того,
какими аппаратными средствами это достигается.

     На  Пример,  в больших сооружениях типа Groucho Marx Университет,
Вы обычно имеете набор отдельных Ethernet, которые должны быть связаны
некоторым  образом.  В  GMU,  в математическом отделе используются два
Ethernets:  одна  сеть  быстрых  машин  для  профессоров  и  студентов
последних  курсов,  и  другая с медленными машинами для студентов (обе
связаны с FDDI).

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

     Поэтому,  этим  занимается  gateway. Gateway (назовем его sophus)
посылает  эти пакеты другому gateway (niels) в Отделе Физики, niels же
отправляет  их  на  требуемую машину. Поток Данных между erdos и quark
показывается на картинке 2.3.4 (с извинениями парню L. Steele).

     Эта   схема   направления  данных  отдаленному  хосту  называется
routing(маршрутизация),  а пакеты часто называют datagram(дэйтограмы).
Для   простоты,   обмен   дэйтаграмами  управляется  в  соответствии c
отдельным  протоколом,  который  является  независимым от используемых
аппаратных  средств:  IP,  или  Internet Протокол. В главе 3. мы будем
рассматривать IP и routing более подробно.

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


сети  в одну с виду однородную сеть. Это называется internetworking, в
результате получаем "мета-сеть" называемую intеrnet. Обратите Внимание
на   различие  между  inetrnet  и  Inetrnet  здесь.  Последнее  -  это
официальное название одного специфического глобального inetrnet.

     Конечно,  IP  также  требует машинонезависимой схемы адресования.
Это  достигается  с  помощью  назначая каждому хост уникального номера
размером в 32 бита, названного IP адресом. IP адрес обычно пишется как
четыре  десятичных  номера,  для  каждой  8-битовой части, разделенных
точками.  Например,  quark  мог  бы иметь IP адрес 0x954C0C04, который
будет  записан  как  149.76.12.4. Этот формат также назван dotted quad
notation.

     Теперь  мы  имеем  три  различных  типа  адресов: имя хоста, типа
quark,  IP  адрес,  и наконец, имеются адреса аппаратных средств, типа
адреса  Ethernet с 6 байтами. Все они так или иначе соответствуют друг
другу,  так,  когда  Вы  пишете  rlogin quark, программное обеспечение
находит  его  IP адрес; И когда IP пересылает данные в Ethernet Отдела
Физики, так или иначе по IP адресу выясняется Ethernet адрес.

     Мы  не  будем  здесь  вдаваться  в  подробности этого процесса, а
сделаем это в главе 3. Пока достаточно помнить что эти шаги называются
hostname  resolution,  поиск  IP  адреса  по  имени  хоста,  и address
resolution, поиск физического адреса по IP.

     2.3.5. IP на последовательных линий

     Для  последовательных  линий, стандартом "de facto" является SLIP
или IP для последовательных линий. Есть модификация SLIP -- CSLIP, или
сжимаемый   SLIP,   который  использует  сжатие  IP  заголовков  чтобы
оптимизировать  IP  для  относительно  низкой  пропускной  способности
последовательной  связи.  PPP, или Point-to-Point протокол -- еще один
протокол  для  последовательных  линий.  PPP  имеет  еще большее число
особенностей  чем SLIP, включая стадии переговоров о начале связи. Его
главное  преимущество  по  сравнению SLIP, то что он не ограничивается
только  транспортировкой  IP  дэйтаграм,  а  предназначен для передачи
любого типа дэйтаграм.



     2.3.6. Протокол Контроля Передачи (TCP)

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

     Очень  важно  знать  об  IP,  что  он не надежен. Предположим что
десять людей на вашем Ethernet начали загружать самый последний выпуск
XFree86  с  GMU  FTP сервера. Такая активность может оказаться слишком
большой  для  того  чтобы  gateway переварил ее, потому что он слишком
медленен, и ограничен количеством памяти. Теперь если Вы пошлете пакет
от  quark,  у  sophus  может не хватить места в буфере и поэтому он не
сможет отправить этот пакет. IP решает эту проблему просто забывая про
данный    пакет.    Пакет    безвозвратно   потерян.   Таким   образом
ответственность    за    целостность    данных    перекладывается   на
поддерживающие связь хосты.

     Это  происходит  в  соответствии  c  другим  протоколом, TCP, или
Протоколом  Контроля  Передачи,  который  надстраивается  над  IP  для
создания  связи  с проверкой целостности данных. Существенный плюс TCP
то,  что  он  использует  IP,  что создает иллюзию простой связи между
двумя  процессами  на  вашем хосте и отдаленной машине, так, что Вы не
заботитесь  о  том  как  и  по которому маршрут ваши данные фактически
путешествуют. A TCP создает дуплексную связь, позволяющую одновременно
как посылать так и получать информацию. Представте телефонную беседу.

     В  TCP  точки  связи определяются IP адресами хостов , и номерами
так   называемых   портов  на  каждом  из  хостов.  Порты  служат  для
определения  процесса  с  которым  устанавливается  связь.  Если опять
обратится  к  примеру  с  телефоном,  то  IP адрес соответствует кодам
городов,  а  номер порта местному номеру телефона. В примере с rlogin,
приложение-клиент  (rlogin)  открывает  порт на erdos, и соединяется с
портом  513  на  quark,  который  прослушивает  rlogind  сервер. Таким
образом  и  устанавливает  TCP  связь.  Используя  эту  связь, rlogind


выполняет  процедуру  определения  прав доступа, и запускает оболочку.
Стандартный  ввод/вывод  этой  оболочки перенаправляются на TCP связь,
таким  образом  все,  набранное  вами  в  rlogin на вашей машине будет
передано через TCP поток на стандартный ввод оболочки.

     2.3.7. Пользовательский протокол дэйтаграм(UDP)

     Конечно,  TCP  не  единственный  протокол  пользователя  в TCP/IP
сетях.  Хоть  он  и  подходит  для  приложений  подобных rlogin, но он
излишне надежен и не нужен для приложений типа NFS. Вместо, него в них
использует  UDP, или протокол пользовательских дэйтаграм. Подобно TCP,
UDP   также  позволяет  приложению  войти  в  контакт  с  приложением,
обслуживающим  определенный  порт  на  отдаленной  машине,  но  он  не
устанавливает  связь  для  этого. Вместо этого, Вы можете использовать
его чтобы посылать отдельные пакеты к месту назначения.

     Предположим,  что Вы установили директорию TeX с центрального NFS
сервера,  galois,  и  Вы  хотите просмотреть документ, описывающий как
использовать LaTeX. Вы запускаете ваш редактор, который сначала читает
указанный   файл.   Однако,  требуется  слишком  много  времени  чтобы
установить  TCP  связь с galois, послать файл , и повторять это снова.
Вместо  этого,  на запрос посланный к galois, тот посылает файл в паре
UDP   пакетов,   что   происходит  гораздо  быстрее.  Однако,  UDP  не
приспособлен  для борьбы с потерей пакетов. Этим приходится заниматься
NFS.

     2.3.8. Дополнительно о портах

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

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


несколько параллельных отдаленных входов на один и тот же хост, причем
все  используют  один самый 513 порт. TCP способен отличать этим связи
друг  от  друга,  потому что они все прибывают от различных портов или
хостов.  Например,  если  Вы  дважды  войдете на quark от erdos, тогда
первый  rlogin  клиент  будет использовать местный порт 1023, а второй
будет использовать порт 1022. Однако, будут соединяться с тем же самым
портом 513 на quark.

     Этот  пример  показывает  использование  портов  как  пункты, где
клиент   входит   в  контакт  с  определенным  портом  чтобы  получить
определенное  обслуживание.  Клиенту необходимо знать надлежащий номер
порта,  соглашение  о  назначении  этих номеров должно быть достигнуто
между   администраторами   обеих  систем.  Для  услуг  которые  широко
используются,   типа   rlogin,   эти   номера  должны  устанавливаться
централизованно.   Этим  занимается  IETF  (или  Проектирующая  задачи
Internet сила), которая регулярно выпускает RFC статьи. Которые, среди
прочего,  назначают  номера  портов  для  общеизвестных  услуг.  Linux
использует  файл,  в  котором  регистрируют названия доступного другим
сервеса  и  номера  портов,  к которым определенный сервес прикреплен,
называется он /etc/services. Он описан в секции 10.3.

     Стоит  заметить,  что  хотя  и TCP и UDP полагаются на порты, эти
номера  не  находятся  в  противоречии. Это означает что TCP порт 513,
например,  отличается  от  UDP порта 513. Фактически, эти порты служат
как  точки  доступа  для двух различных услуг, а именно rlogin (TCP) и
rwho (UDP).

     2.3.9. Библиотека гнезд(socket)

     В   Unixоидных  операционных  системах  программное  обеспечение,
выполняющее  все  задачи  и  протоколы описанные выше, обычно является
частью ядра, аналогично и в Linux. Интерфейс программирования наиболее
общий  для  мира  Unix  - Библиотека Гнезд Berkeley. Свое название она
получила  из-за  популярной  аналогии  которая рассматривает порты как
гнезда(розетки). Она обеспечивает (bind(2)) запрос, который определяет
отдаленный хост, транспортный протокол, и сервис, к которому программа
может  присоединится или слушать (используя connect(2), listen(2), and
accept(2)).



     Библиотека  гнезд  однако несколько более общая, она обеспечивает
не  только  класс  TCP/IPоснованных  гнезд  (AF INET гнезда), но также
класс,  который  управляется  локальной связью машины (AF UNIX класс).
Некоторые  версии  могут также управляться другими классами типа XNS (
Система Организации Сети Ксерокса ) протокол, или X.25.

     В Linux, библиотека гнезд -- часть стандартной libc C библиотеки.
В  настоящее  время, она поддерживает только AF INET и AF UNIX гнезда,
но ведется работа над включением поддержки для Novell протоколов, так,
чтобы  в конечном счете один или больше классов гнезд для него были бы
добавлены.

     2.4. Linux сети

     Будучи  результатом концентрации усилие программистов всего мира,
Linux  не был бы возможен без глобальной сети. Так что не удивительно,
что  уже на ранних стадиях разработки, несколько людей начали работать
над  сетевыми  возможностями.  UUCP  появился  в  Linux почти с самого
начала,  а работа над tcp/ip-основанной сетью была начата осенью 1992,
когда  Ross  Biro  и другие создали то, что теперь стало известным как
Net-1.

     Ross  прекратил  активную  разработку в Мае 1993, Fred van Kempen
начал  работать над новой версией, переделывая главные части кода. Это
усилие  известно  как  Net-2.  Первый  общественный релиз, Net-2d, был
сделан  летом 1992 (как часть 0.99.10 ядра), и с тех пор поддерживался
и  расширялся  несколькими  людьми,  наиболее  сильно  Alan  Cox,  как
Net-2Debugged.     После     тяжелой    отладки    и    многочисленных
усовершенствований  кода, он сменил название на Net-3. Эта версия кода
в настоящее время включена в официальные выпуски ядра.

     Net-3  предлагает драйвера устройств для разнообразного Ethernet,
а  также для SLIP (для работы сети по последовательным линиям), и PLIP
(  для  параллельных линий). С Net-3, Linux получил TCP/IP приложения,
которые  очень  хорошо  ведут  себя  в локальной сети и часто работают
быстрее   некоторых   коммерческих.   Существует  несколько  проектов,
развитие которых будет увеличивать многосторонность Linux. Драйвер для


PPP    (    протокол   point-to-point,   другой   способ   работы   по
последовательным  линиям),  является  в стадии Beta версии в настоящее
время,  а  AX.25  драйвер  для радио - в Alpha версии. Alan Cox создал
драйвер для Novell's IPX протокола, но завершающие усилия для создания
сети  совместимой  с  Novell  были  отложены  из-за  нежелания  Novell
обеспечить   необходимую   документацию.  Еще  один  проект  -  samba,
свободный NetBIOS сервер, написанный Andrew Tridgell.

     2.4.1.  Другие пути развития

     В  это  время,  продолжая  разработку,  Fred  предложил Net-2e, в
которой  сильно  пересмотрено вся структура организации сети. Во время
написания  этой  книги,  Net-2e  все еще Beta программное обеспечение.
Наиболее  интересен  в  Net-2e  - объединение DDI, Интерфейса Драйвера
Устройства.  DDI предлагает однотипный доступ и метод конфигурации для
всех устройств сети и протоколов.

     Пока   используется  TCP/IP  сеть  написанная  Matthias  Urlichs,
написавшего  ISDN  драйвер  для Linux и FreeBSD. Для этого, он встроил
BSD сетевой код в ядро Linux.

     В течение обозримого будущего, Net-3 скорее всего останется. Alan
в   настоящее  время  работает  над  AX.25  протоколом,  используемого
любителями  радио.  Несомненно,  скоро  будет  разработан "модуль" для
ядра,   который   позволит   Вам   добавлять   драйвера   к   ядру  не
переустанавливая систему.

     Хотя  эти различные реализации сети борются за обеспечение одного
и  того  же  сервеса,  основные их различия находятся на уровне ядре и
устройств.  Поэтому, Вы не сможете отконфигурировать систему используя
Net-2e ядро с утилитами от Net-2d или Net-3, и наоборот. Это относится
только  к  командам,  которые  имеют  дело с ядром; приложения и общие
сетевые команды типа rlogin или telnet пойдут на любом из них.

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


совместимыми с кодом представленным в ядре.

     2.4.2. Где получить код

     Самая  последняя  версия  сетевого  кода  может  быть получена на
различных   анонимным   FTP.   Официальный  FTP  участок  для  Net-3 -
sunacm.swan.ac.uk, отражаемый sunsite.unc.edu в system/Network/sunacm.
Самый  последний  комплект  Net-2e  доступен на ftp.aris.com. Matthias
Urlichs'    bsd    код    может    быть   взят   на   ftp.ira.uka.de в
/pub/system/linux/netbsd.

     Самые   последние  ядра  могут  быть  найдены  на  nic.funet.fi в
/pub/OS/Linux/PEOPLE/Linus;  sunsite  и  tsx-11.mit.edu  отражают  эту
дерикторию.

     2.5. Поддержка Вашей системы

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

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

     Результат  работы любого такого скрипта должен быть отправлена по
почте  администратору.  По  умолчанию,  большенство  приложений  будут
посылать  сообщения об ошибках, обычную статистику, или резюме logfile
к  root.  Этот  имеет смысл только если Вы часто входите в систему под
root;  еще  лучше,  если  почту  root  перенаправлять на ваше имя, как
описано в главе 15.



     Однако  как  бы  тщательно  Вы не конфигурировали ваш участок, по
закону  Мерфи проблемы обязательно появятся. Поэтому, при обслуживании
системы   от   жалоб   не   отвертеться.   Обычно,  люди  ожидают  что
администратор  системы  может  по крайней мере быть найден через email
как  root, но имеются также другие адреса, которые обычно используются
чтобы  найти  лицо  ответственное  за  определенный аспект управления.
Например,   жалобы  относительно  сбоев  в  конфигурации  почты  будут
обычно  адресованы  postmaster,  а  проблемы с системой новостей могут
быть  сообщены  newsmaster  или  usenet. Обращения к hostmaster должны
быть  перенаправлены лицу отвечающему за основные услуги сети и службу
имен DNS.

     2.5.1. Безопасность системы

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

     Здесь  мы  будет  обсуждать несколько примеров и основных методов
обеспечения  безопасности  системы.  Конечно, охваченные темы не могут
решить  всех  проблем  безопасности,  с  которыми  вы столкнетесь; они
просто служат иллюстрацией проблем, которые могут возникнуть. Поэтому,
необходимо   прочитать   хорошую   книгу   по  безопасности,  особенно
администратору  сетевой  системы.  Simon  Garfinkel "Практическая UNIX
Безопасность" ( см. [ GETST "безопасность"]) -- очень рекомендую.

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


так и низкие регистры и цифры.

     При  создании  сервиса  доступного по сети, постарайтесь дать ему
"наименьшие привилегии," удастовертесь что Вы не разрешаете ему делать
вещи,  которые не требуются для его работы. Например, Вы должны делать
программы  с привилегии root только, когда они действительно нуждаются
в   этом.  Например,  если  Вы  хотите  разрешить  бездисковым  хостам
загружаться  от  вашей  машины, Вы должны обеспечить TFTP (тривиальный
сервис  передачи  файла)  так,  чтобы  они  загружали  основные  файлы
конфигурации   из   дириктории   /boot.   Однако,  когда  используется
неограниченный  TFTP,  это  позволяет  любому  прочитать общедоступные
файлы  с  вашей  машины.  Если  это не то, что Вы хотите, почему бы не
ограничить TFTP сервис дирикторией /boot?

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

     Другой   важный   пункт   --  избегайте  "опасного"  программного
обеспечения.   Конечно,  любое  программное  обеспечение,  которое  Вы
используете  может  быть  опасно,  потому  что программное обеспечение
может  иметь ошибки, так что умные люди могли бы использовать их чтобы
получить доступ к вашей системе. Подобные вещи случаются и нет никакой
полной защиты против этого. Эта проблема касается как бесплатного, так
и  коммерческого  программного обеспечения. Однако, программы, которые
требуют специальных привилегий несоизмеримо опаснее чем другие, потому
что  любая  лазейка  может  иметь  непоправимые  последствия.  Если Вы
устанавливаете  сетевую  программу будте вдвойне осторожны и ничего не
пропускаете  в  документации,  чтобы случайно не нарушить безопасность
системы.  Вы не можете исключить того, что ваши предосторожности могут
потерпеть  неудачу,  независимо  от того насколько осторожный Вы были.
Поэтому  Вы  должны  удостовериться, что Вы обнаружите злоумышленников
сразу  же  после  их  появления. Хорошее начало -- проверка log файлов
системы,  но  злоумышленник  вероятно  умный  человек, и будет удалять
любые  очевидные  следы  перед  уходом.  Однако,  имеются  инструменты
подобно  tripwire,  которые  позволяют  Вам  проверять жизненно важные
системные  файлы и регистрировать были ли их содержание или разрешения


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

     2.6. Обзор следующих глав

     Следующие  несколько  глав  будут  иметь дело с конфигурированием
Linux   для   TCP/IP   сети,   и  с  управлением  некоторыми  главными
приложениями.  Прежде  чем  пачкать наши руки редактированием файлов и
подобными вещами мы немного исследуем IP в 3 главе. Если Вы уже знаете
относительно  IP  маршрутизации, и как выполняется address resolution,
Вы можете пропустить эту главу.

     Глава 4. Обсуждение основных проблем конфигурации, типа установка
ядра   и   введения   вашей   Ethernet   карты.   Конфигурация   ваших
последовательных  портов  охвачена  в  отдельной  главе, потому что их
обсуждение не относится только к TCP/IP сети, но и к UUCP.

     Глава  6.  Помогает Вам отконфигурировать вашу машину для TCP/IP.
Она также описывает несколько полезных инструментов, которые Вы можете
использовать  для  проверки  и отладки ваших установок Следующая глава
рассказывает  как  конфигурировать hostname resolution и объясняет как
установить сервер имен.

     Это сопровождается двумя главами показывающими конфигурирование и
использование SLIP и PPP. Глава 8. Объясняет как установить SLIP связь
и  дает  детальные рекомендации по запуску программ, которые позволяют
автоматизировать  большинство  необходимых  шагов. Глава 9. охватывает
PPP и pppd.

     Глава  10.  Дает  короткое  представление о некоторых из наиболее
важных  сетевых  приложений,  типа  rlogin,  rcp,  и  т.д.,  Она также
охватывает   услуги   inetd  и  описывает  как  Вы  можете  ограничить
определенные услуги для набора каких-либо хостов.

     Следующие   две   главы  обсуждают  NIS,  Сетевую  Информационную
Систему,  и  NFS,  Сетевую Файловую Систему. NIS - полезный инструмент


для   распространения   административной   информации   типа   паролей
пользователя  в  локальной  сети. NFS позволяет Вам распределить файлы
между несколькими хостами в вашей сети.

     Глава  13.  Дает  Вам  представление  об администрированию Taylor
UUCP, бесплатного UUCP пакета.

     Остаток  книги  посвящен  детальному  путешествию  по электронной
почте   и   Usenet  Новостям.  Глава  14.  представляет  Вам  основные
концепциям электронной почты, типа того как выглядит адрес электронной
почты и как система обработки почты получает ваше сообщение

     Главы 15. И 16. Охватывают установку smail и sendmail, два агента
транспортировки  почты,  которых  Вы  можете использовать в Linux. Эта
книга  описывает  оба  из  них,  потому  что  smail  более  легкий для
установки (для начинающих), в то время как sendmail более гибок.

     Главы  17.  И  18. Объясняют пути управления новостями в Usenet и
как  установить  и  использовать C news, популярный пакет программ для
управления Usenet новостями.

     Глава  19. Кратко охватывает запуск NNTP daemon, чтобы обеспечить
доступ к новостям для вашей локальной сети.

     Глава   20.   Наконец   показывает   Вам   как  конфигурировать и
обслуживать различные newsreader.



     3. Проблемы TCP/IP сети

     Теперь  обратимся  к деталям того как вы будете присоединять вашу
Linux  машину  к  сети  TCP/IP,  включая работу с IP адресами, именами
хостов, и чуть-чуть проблемы маршрутизации. Эта глава дает Вам основу,
которая  поможет Вам понять, что требуется для установки системы, в то
время  как  следующие  главы  будут  охватывать инструменты, с помощью
которых это достигается.


     3.1. Сетевой интерфейс

     Чтобы    скрыть   разнообразное   оборудование,   которое   может
использоваться   в   сетевой   среде,  TCP/IP  определяет  абстрактный
интерфейс,  через который можно обращаться к аппаратным средствам ЭВМ.
Этот  интерфейс  предлагает набор действий который является одинаковым
для всех типов аппаратных средств и в основном имеет дело с посылкой и
получением пакетов.

     Для   каждого   переферийного   устройства,   которое  Вы  хотите
использовать, в ядре должен быть представлен соответствующий интерфейс
Например,   Ethernet   интерфейсы  в  Linux  названы  eth0  и  eth1, а
интерфейсы   SLIP  --  sl0,  sl1,  и  т.д..  Эти  названия  интерфейса
используются  при  конфигурировании,  когда  Вы хотите определить ядру
специфическое   физическое   устройство.   Они   не   имеют   никакого
назначения кроме этого.

     Чтобы  работать  в  TCP/IP  сети,  данному интерфейсу должен быть
назначен  IP  адрес,  который  служит  как идентификатор при общении с
остальным  миром.  Этот  адрес  различен  в  зависимости  от  названия
интерфейса  упоминаемого выше; если Вы сравниваете интерфейс с дверью,
тогда адрес подобен пластине с именем, прикрепленной на ней.

     Конечно,  имеются  другие параметры устройства которые необходимо
отрегулировать;  один  из  них - максимальный размер дэйтаграм который
может  быть  обработан  данной  частью  аппаратуры,  также  называемый
Maximum  Transfer  Unit,  или MTU. Другие параметры будут представлены


позже.

       3.2. IP адреса

     Kак   упоминается   в   предыдущей   главе,   адреса   понятные в
соответствии c IP -- это 32-битовые числа. Каждая машине в данной сети
должен быть назначена уникальный адрес.

     В  локальной  сети,  которая  не  использует  TCP/IP  для связи с
другими   сетями,   Вы  может  назначить  эти  номера  согласно  вашим
персональным  предпочтениям.  Однако,  для  участков  Inetrnet, номера
назначаются NIC.

     Для более легкого чтения, IP адреса разбивают на четыре 8 битовых
числа,  названных octets. Например, quark.physics.groucho.edu имеет IP
адрес  0x954C0C04,  который  записывается как 149.76.12.4. Этот формат
часто называют dotted quad notation.

     Другая  причина для такой записи то, что IP адреса разбиваются на
номер  сети,  который  написан в первых octets, и номер хоста, который
является  остатком.  При  обращении к NIC за адресами, Вы не получаете
адрес  для  каждого отдельного хоста, которые Вы планируете поставить.
Вместо  этого, Вам дают сетевой номер, и позволяющий назначать машинам
любые IP адреса из заданного таким образом диапазона.

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

Класс A включает сети от 1.0.0.0 до 127.0.0.0. Сетевой номер содержится в
          первом octet, что предусматривает 24 разрядную хост часть, сеть
          приблизительно из 1.6 миллион хостов.

Класс B содержит сети от 128.0.0.0 до 191.255.0.0; сетевой номер находится в
          первых двух octets. Это предполагает 16320 сетей с 65024 хостами
          каждый.

Класс C диапазон сетей от 192.0.0.0 до 223.255.255.0, с сетевой номер


          содержится в первых трех octets. Это предполагает почти 2 миллиона
          сетей по 254 хоста.

Классы D, E, и F Адреса попадающие в диапазон от 224.0.0.0 до 254.0.0.0
          являются или экспериментальным, или сохранены для будущего
          использования и не определяют какую-либо сеть.

     Если  мы  вернемся  к  примеру  в предыдущей главе, мы увидим что
149.76.12.4,  адрес  quark,  относится  к хосту 12.4 в сети 149.76.0.0
класса B.

     Вы можете заметить, что в вышеупомянутом списке для каждого octet
в части хоста возможны не все значения. Это потому что номера хоста со
всеми  octets равными 0 или 255 сохранены для специальных целей. Адрес
в  котором  все  биты хост части -- ноль относится ко всей сети, а где
все биты хост части 1 назван broadcast (широковещательным) адресом. Он
относится   ко   всем   хостам   из  указанной  сети.  Таким  образом,
149.76.255.255  не  существующий  адрес  хоста,  он  относится ко всем
хостам сети 149.76.0.0.

     Имеются  еще  два  зарезервированных адреса, 0.0.0.0 и 127.0.0.0.
Первый  назван  default  route(путь  по умолчанию), последний loopback
(кольцевым)  адресом.  default route используется при маршрутизации IP
дэйтаграм, с которыми мы будет иметь дело ниже.

     Сеть  127.0.0.0  сохранена  для  IP  работы внутри хоста. Обычно,
адрес 127.0.0.1 будет назначен специальному интерфейсу на вашем хосте,
так   называемому   интерфейсу  loopback,  который  действует  подобно
закрытому  кругообороту.  Любой IP пакет переданный ему от TCP или UDP
будет  возвращен  к  ним  как  будто он только что прибыл из некоторой
сети.  Это  позволяет  тестировать сетевое программное обеспечение без
использования  "реальной"  сети.  Также  он  полезен,  когда Вы хотите
использовать  сетевое  программное  обеспечение  на  автономном хосте.
Например,  большое  количество UUCP участков не имеют IP связи вообще,
но все же хотят управлять INN системой новостей. Однако для правильной
работы под Linux, INN требует интерфейса loopback.

       3.3. Address Resolution(поиск по адресу).



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

     Именно поэтому необходим механизм, переводящий IP адреса в адреса
Ethernet.  Это  так  называемый  Address Resolution Protocol (Протокол
Решения  Адреса),  или  ARP. Фактически, ARP не ограничен Ethernet, он
используется  и  на  сетях  других  типов.  Идея, лежащая в основе ARP
аналогична  способу  применяемому  большинством людей, когда они хотят
найти господина X. Они ходят по толпе и выкрикивают его имя. И если он
там, он откликнется.

     Когда  ARP  хочет выяснять Ethernet адрес соответствующий данному
IP   адрес,   он   использует   особенность   Ethernet  известную  как
"broadcast"(широковещательное),    когда   дэйтаграмы   адресовываются
одновременно   всем  станциям  в  сети.  Широковещательная  дэйтаграма
посланная ARP содержит запрос с IP адресом. Каждый хост сравнивает его
с  собственным  адресом, и если они совпадают, возвращает ARP-ответ на
спрашивающий  хост.  Спрашивающий  хост  может теперь извлечь Ethernet
адрес отправителя из этого ответа.

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

     Давайте  пока  еще поговорим об ARP. Если хост обнаружил Ethernet
адрес,  он  сохранит  его  в  ARP  кэше,  чтобы, когда в следующий раз
потребуется  послать дэйтаграму рассматриваемому хосту, не требовалось
тратить  время  на  его  поиск.  Однако,  он не знает сохранить ли эту
информацию  навсегда;  например,  на  удаленном  хосте  могут поменять
Ethernet  карту,  так  что хранимая информация окажется не верной. Что
потребует   через   некоторое   время   еще  раз  полностью  повторить
описанную процедуру.



     Иногда,  также  необходимо  выяснять  IP адрес связанный с данным
Ethernet  адресом.  Это  случается,  когда  бездисковая  машина  хочет
загрузится  с сервера по сети, что является весьма общей ситуацией для
локальных   сетей.   Бездисковый  клиент,  однако,  не  имеет  никакой
информацию  относительно  себя  кроме  Ethernet  адреса!  Он  посылает
широковещательное  сообщение содержащее просьбу к серверу сообщить ему
его  IP  адрес.  Для  этого  существует  другой  протокол,  называемый
Reverse  Address  Resolution  Protocol  (Реверсивный ARP), или RARP. А
также   BOOTP  протокол,  который  служит  для  определения  процедуры
загрузки бездисковых клиентов по сети.

     3.4. IP маршрутизация

     3.4.1. IP Сети

     <> Когда Вы пишете письмо, Вы обычно помещаете на конверте полный
адрес:  страну,  штат,  почтовый  индекс,  и  т.д.. После того, как Вы
опускаете его в почтовый ящик, почта доставит его по месту назначения:
оно  будет  послано обозначенной стране, чья национальное почта пошлет
его  в  требуемый  штат, и т.д.. Преимущество этой иерархической схемы
довольно  очевидно: Везде, где Вы отправляете по почте письмо, местный
начальник  почтового  отделения  будет  точно знать, куда передать это
письмо,   и   не   должен   заботиться,  которым  путем  письмо  будет
путешествовать.

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

     3.4.2. Подсети

     Эта  структура  отражена  в разбиении IP адреса на хост и сетевую
части,   как  объяснено  выше.  ПО  умолчанию,  сеть  мест  назначения


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

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

     Подсеть  принимает  ответственность  за  доставку  дэйтаграм  для
определенного  диапазона  IP  адресов. Как с классами A, B, или C, она
идентифицируется  сетевой  частью  IP  адресов.  Однако, сетевая часть
теперь  расширена,  чтобы включить некоторые биты от хост части. Число
битов  которые  интерпритируются  как  номер  в  подсети  задается так
называемой  subnet(подсетевой) маской, или netmask. Это - 32 разрядное
число,  которое  определяет  разрядную  маску  для  сетевой  части  IP
адреса.

     Сеть  Groucho  Marx  Университета  - пример такой сети. Она имеет
класс  B  с  сетевым  номером  149.76.0.0,  и  netmask  поэтому  равен
255.255.0.0.

     Внутри,  сеть  GMU  состоит  из  нескольких  меньших  сетей, типа
локальных  сетей различных отделов. Так что диапазон IP адресов разбит
на  254  подсети,  от  149.76.1.0  до  149.76.254.0.  Например,  отдел
теоретической   физики   имеет   номер   149.76.12.0.  Университетский
оптиковолоконный  кабель  тоже  сеть с собственным номером 149.76.1.0.
Эти  подсети  имеют одинаковый сетевой IP адрес, в то время как третья
octet  используется,  чтобы  различать  их  между собой. Таким образом
они будут использовать подсетевую маску 255.255.255.0.

     Картинка   3.4.2   показывает   как   149.76.12.4,  адрес  quark,
интерпритируется  по-разному когда адрес принят как обычный адрес сети
класса B, и когда используется с подсетью.

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


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

     3.4.3. Gateways

     Subnetting  -  не  только  организационная  деление,  но  часто и
естественное  следствие  границ  аппаратных  средств.  Знания  хоста о
строении   данной  физической  сети,  типа  Ethernet,  являются  очень
ограниченными:  Единственные  хосты,  с которыми они способны говорить
непосредственно,  те,  что  находятся  в  той  же сети. Ко всем другим
хостам  они  могут  обращаться  только  через так называемый gateways.
Gateway  --  хост который связан с двумя или больше физическими сетями
одновременно  и  конфигурирован  так,  чтобы перекачивать пакеты между
ними.

     IP  достаточно  легко  распознать  находится  ли  хост на местной
физической   сети,   различные  физические  сети  должны  принадлежать
различным  IP  сетям.  Например  сетевой номер 149.76.4.0 сохранен для
хостов  в  локальной  сети математиков. При посылке дэйтаграм к quark,
сетевое  программное  обеспечение  на  erdos  немедленно  видит  по IP
адресу,  149.76.12.4,  что  хост  места  назначения находится в другой
физической  сети,  и поэтому может быть достигнут только через gateway
(sophus по умолчанию).

     Sophus   непосредственно  связан  с  двумя  отличными  подсетями:
отделом  математики,  и университетской магистралью. Они доступы через
различные  интерфейсы (eth0 и fddi0 соответственно). Но какой IP адрес
мы ему назначаем? 149.76.1.0 или 149.76.4.0?

     Ответ:   оба.   При   разговоре   с  сервером  в  локальной  сети
математиков,  sophus использует IP адрес 149.76.4.1, а при разговоре с
хостом на магистраль, он должен использовать 149.76.1.4.

     Таким  образом,  gateway  получает  по одному IP адресу на каждую
сеть,  к которой он подключен. Эти адреса (вместе с netmask) привязаны
к   интерфейсу  через,  который  обращаются  подсети.  Таким  образом,


интерфейсы и адреса sophus связаны так:

----------------------------------------
+-------+-------------+----------------+
| Интерфейс| адрес       |        Netmask |
+-------+-------------+----------------+
+-------+-------------+----------------+
| Eth0  | 149.76.4.1  | 255.255.255.0  |
| fddi0 | 149.76.1.4  | 255.255.255.0  |
| Lo    | 127.0.0.1   | 255.0.0.0      |
+-------+-------------+----------------+
+-------+-------------+----------------+

Последняя запись описывает loopback интерфейс lo.

На картинке 3.4.3 изображена топология части сети  Groucho Marx Университета
(GMU). Хосты, находящиеся в двух подсетях в то же самое время  показываются с
обоими адресами.

     Вообще, Вы можете не обращать внимание на различия между адресами
хоста  и  интерфейса.  Относитесь  к  адресу  хоста, который находятся
только  в  одной сети, как к адресу того и другого, хотя строго говоря
это  Ethernet  интерфейс  имеет IP адрес. Однако, это различие ощутимо
только, когда Вы работаете с gateway.

     3.4.4. Таблица маршрутизации

     Теперь сосредоточим наше внимание на том, как IP выбирает gateway
при доставке дэйтаграм к определенной сети.

     Как мы видели раньше erdos, когда передавал дэйтаграмы для quark,
проверил место назначения и нашел, что его нет в местной сети. Поэтому
он  посылает  ее gateway, sophus, который теперь сталкивается с той же
самой  задачей.  Sophus  определяет, что quark не находится в сетях, с
которыми  он непосредственно связан, так что он передает эту дэйтаграм
другому gateway, чтобы он перенаправил ее дальше. Правильный выбор был
бы  niels  (gateway  Отдела  Физики).  Но sophus нуждается в некоторой
информации чтобы определить подходящий gateway.



     Для   этого   используется   таблица  IP  маршрутизации,  которая
определяет   какие   сети   присоединены  с  помощью  каких  gateways.
Обязательно  должен  быть  указан  маршрут  по  умолчанию (the default
route),  по  которому  будут  направляться  все  пакеты  с  адресами в
неизвестных  сетях.  Этот  gateway связан с сетью 0.0.0.0.. На sophus,
эта таблица могла бы напоминать эту:

-----------------------------------------
+------------+-------------+------------+
| Сеть       | Gateway     | Интерфейс  |
+------------+-------------+------------+
+------------+-------------+------------+
| 149.76.1.0 | -           | Fddi0      |
| 149.76.2.0 | 149.76.1.2  | fddi0      |
| 149.76.3.0 | 149.76.1.3  | fddi0      |
| 149.76.4.0 | -           | Eth0       |
| 149.76.5.0 | 149.76.1.5  | fddi0      |
|...         | ...         | ...        |
| 0.0.0.0    | 149.76.1.2  | fddi0      |
+------------+-------------+------------+
+------------+-------------+------------+

     Маршруты  к  сетям,  с  которыми  sophus  связан  непосредственно
обозначаются "-" в столбце gateway.

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

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


демоне.  Для  маршрутизации  между  автономными системами используются
внешние  протоколы  маршрутизации типа EGP (Внешний Gateway Протокол),
или  BGP  (  Пограничный  Gateway  Протокол);  они ( а также RIP) были
предложены в gated демоне( University of Cornell's).

     3.4.5. Метрические значения

     Динамическая  маршрутизация  основанная  на  RIP  выбирает  самый
лучший  маршрут  к  некоторому  хосту  или сети, основываясь на наборе
"hops"(перелетов),  то  есть  gateways  дэйтаграм,  рассылаемых  перед
передачей  основной  информации. Чем более короткий маршрут, тем лучше
RIP  его  оценивает.  Очень длинные маршруты с 16 или больше перелетов
рассматриваются как неподходящие и отвергаются.

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

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

     3.5. The Internet Control Message Protocol
       (Межсетевой протокол контрольных сообщений)

     IP  имеет протокол-компаньон, что ж мы до сих пор не поговорили о


нем.   Это   межсетевой   протокол   контрольных   сообщений  (ICMP) и
используется  он  сетевым  кодом  ядра,  чтобы передавать сообщения об
ошибках   и  т.  п.  другим  хостам.  Например,  предположите  что  Вы
находитесь  на  erdos и хотите использовать telnet через 12345 порт на
quark,  но на этом порте отсутствует слушающий процесс. Когда приходит
первый  TCP  пакет  на  этот  порт,  ядро определит это и отошлет ICMP
сообщение.

     Имеются  множество  ICMP сообщений, большинство из них сообщают о
каких-либо   ошибках.   Однако,  имеется  очень  интересное  сообщение
названное   Перенаправляющим   сообщением   (Redirect   message).  Оно
генирируется  модулем  маршрутизации, когда он обнаруживает что другой
хост  использует его как gateway, хотя имеется более короткий маршрут.
Например,  после  загрузки  таблицы маршрутизации на sophus может быть
неполной: она содержит маршруты к сети математиков, к FDDI магистрали,
а по умолчанию указан gateway Groucho Вычислительного центра (gcc1).

     Поэтому,  любые  пакеты  для  quark  посылаются  через gcc1, хотя
быстрее  было  бы через niels (gateway в отделе физики). При получении
таких  дэйтаграм,  gcc1  будет  извещать  что это -- плохой маршрут, и
будет  отправлять  пакет  к  niels, в то же самое время возвращая ICMP
сообщение к sophus, показывая ему лучший маршрут.

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

     3.6. Система  имен областей (Domain Name System)

     3.6.1 Поиск по имени (Hostname Resolution)

< >   Как описано выше, адресация в TCP/IP сети крутится вокруг 32
      разрядных номеров. Однако, Вам будет трудно запомнить даже некоторые из


      них.  Поэтому, хосты чаще известны под "обычными", имена типа gauss или
      strange. Поэтому требуются программы для получения IP адреса по имени
      машины Этот процесс назван Hostname resolution.

     Приложение,  которое хочет найти IP адрес по данному имени хоста,
не  должен  пытаться сделать это собственными силами Вместо этого, оно
обращается  к библиотечным функциям, которые для этого и написаны, они
называются  gethostbyname  (3) и gethostbyaddr (3). Традиционно, эти и
ряд   других   процедур  были  сгруппированы  в  отдельной  библиотеке
названной resolver; в Linux, это часть стандартной libc.

     На  маленькой сети, подобной Ethernet, или даже на нескольких, не
очень  трудно  поддерживать  таблицу,  сопоставляющую имена хоста к IP
адресам.  Эта  информация  обычно  хранится  в  файле  /etc/hosts. При
добавлении  или перемещении хоста, или при переназначении адресов, все
что  Вы  должны  сделать  --  это  изменить файл hosts на всех хостах.
Очевидно,   что   это  будет  достаточно  трудно  в  сетях  с  большим
количеством машин.

     Одно  из  решений  этой  проблемы  -- NIS, Сетевая Информационная
Система  разработанная  Sun  Microsystems,  названное  YP, или Желтыми
Страницами.  NIS хранит hosts файл (и другую информацию) в базе данных
на  главном  хосте,  от которого клиенты могут восстановить свои файлы
если  это  необходимо.  Все еще, Этот способ подходит только для сетей
среднего  размера,  потому  что  он  требует  поддерживать полную базу
данных как на центральной машине, так и на всех остальных.

     В  Internet,  первоначально  информация  об  адресах  хранилась в
единственном  файле HOSTS.TXT. Этот файл поддерживался в NIC, и должен
был  загружаться  всеми  участвующими  участками.  Когда сеть выросла,
возникло   несколько   проблем.  Постоянное  обновление  и  постоянная
перекачка  файла  HOSTS.TXT  регулярно  требовали все больше ресурсов,
нагрузка  на  сервер,  который этим занимался стала слишком высока. Но
еще  большей  проблемой  стало  придумывание  новых  (не совпадающих с
преждними) имен.

     Вот  почему,  в 1984 г, введена новая схема -- DNS, разработанная
Paul Mockapetris и решившая обе проблемы одновременно.



       3.6.2.  О  DNS

     DNS  организовывает  имена хостов по областям(domain). Область --
набор  как-то связанных участков, это могут быть машины одной сети (на
пример все машины в университетском городке, или всех хосты в BITNET),
все    они   могут   принадлежать   определенной   организации   (типа
американского  правительства),  или  они  просто географически близки.
Например,   университеты   сгруппированы   в  edu  области,  с  каждым
Университетом   или  Коледжом,  использующим  отдельную  подобласть, в
которой  и  находятся  все  его хосты. Groucho Marx Университету можно
давать  groucho.edu  область,  Отделу математики -- maths.groucho.edu.
Хост на данной сети к имени области добавляет свое имя и таким образом
получает  свое  полное  имя  в  Internet  erdos  был  бы  известен как
erdos.maths.groucho.edu.

     Картинка 3.6.2 изображает пространство имен. Запись в корне этого
дерева,  которая  обозначена единственной точкой, весьма точно названа
областью  корня,  и  она  связана  со  всеми  другими областями. Чтобы
показать  что  в  данном  месте  пишется  полное  имя  хоста, а не имя
относительно  локальной  области, иногда после имени ставят точку. Это
значит, что последний компонент имени принадлежит области корня.

     В  зависимости  от местоположения в иерархии имени, область может
быть     названа     top-level,    second-level,    или    third-level
(верхнеуровневой,   второго   уровня,  или  третьего  уровня).  Больше
количество  уровней встречается редко. Вот несколько верхних областей,
которые Вы можете часто увидеть:

      edu ( Главным образом США ) образовательные учреждения подобно
           университетам, и т.д..

      com Коммерческие организации, компании.

      org некоммерческие организации. Часто частные UUCP сети находятся в этой
          области.

      net Gateways и другие административные хосты в сети.



      mil американские военные учреждения.

      gov американские правительственные учреждения.

      uucp Официально, все имена участков прежде используемые как UUCP имена
            без областей, были перемещены в эту область.

     Технически,  первый  четыре из них принадлежат американской части
Internet,  но  там встречаются и не американские участки. Это особенно
верно  для net области. Однако, mil и gov используются исключительно в
США.

     Вне  США,  каждая  страна  вообще использует собственную область,
названую  по  имени  страны  и  состоящая  из двух букв определенных в
ISO-3166.  Финляндия, например, использует fi область, fr используется
Францией,   de   Германией,   au   Австралией   и   т.д..   Ниже  этой
высокопоставленной области, NIC каждой страны может свободно раздавать
имена  хостам.  Австралия,  например,  имеет  области  второго  уровня
подобные  международным  высшим  областям, названным com.au, edu.au, и
так   далее.   Другие,   подобно   Германии,   не   используйте   этот
дополнительный  уровень,  но  используют слегка длинные имена, которые
непосредственно  относятся  к  организациям  управляющих специфической
областью. Например, на пример ftp.informatik.uni-erlangen.de.

     чонечно,  эти  национальные  области  не  подразумевают  что хост
расположенный  ниже  фактически расположен в той же стране; это только
сигнализирует  что  хост  регистрировался в NIC этой страны . Шведский
изготовитель   мог   бы   иметь   отделение  в  Австралии,  и  все  же
регистрировать все хосты в se области.

     Теперь,  организация  пространства  имен в иерархии имен областей
приятно  решает  проблему  уникальности  имен; с DNS, имя хоста должно
быть  уникально  только в пределах одной области Кроме того, полностью
квалифицированные  имена  весьма  легко  запомнить.  Но  DNS делает не
только  это:  он  позволяет Вам передать работу с подобластями местным
администраторам.  Например,  администратор  в  Groucho  Вычислительном
Центре   мог   бы  создать  подобласть  для  каждого  отдела;  мы  уже


столкнулись  с подобластями физиков и математиков. Когда он решит, что
сеть  в  Отделе Физики слишком большая и хаотичная, чтобы справиться с
ней из вне , он может просто передать контроль над physics.groucho.edu
областью  администраторам  этой сети. Тогда они свободны использовать,
любые  имена  хостов  и  назначать их IP адреса в пределах подсети без
вмешательства сверху.

     Так,  пространство имени раздроблено на зоны, которая управляется
своей  областью. Обратите Внимание На различие между зоной и областью:
область   groucho.edu   затрагивает   все   машины   в   Groucho  Marx
Университете,  в  то время как зона groucho.edu включает только хостов
которые  работают  в  компьютерном  центре непосредственно, например в
отделе  математики.  Хост  в  отделе физики принадлежат другой зоне, а
именно  physics.groucho.edu.  На  картинке 3.6.2, начало зоны отмечено
маленьким кружочком справа от имени области.

     3.6.3 Поиск имени с помощью DNS

     На  первый  взгляд,  все  эти  суета с областями и зонами кажется
делает  поиск  адреса  ужасно  сложным делом. В конце концов, если нет
центрального  органа  контролируещего  какие  имена  связаны  с  каким
адресом, тогда как - скромное приложение должно его узнавать?!

     Теперь  начинается  действительно техническая часть описания DNS.
Если  Вы  хотите  выяснять  IP  адрес erdos, тогда, DNS говорит, иди и
спроси людей, которые управляют им, и они ответят Вам.

     Фактически,  DNS  -  гигантская  распределенная  база данных. Это
осуществлено  посредством  так  называемых серверов имен(name server),
которые  снабжают  всех  информацией  о  данной области или нескольких
областях  сразу.  Для  каждой зоны имеются по крайней мере два сервера
имен, которые содержат всю информацию относительно хостов в этой зоне.
Чтобы  получить IP адрес erdos, все что Вы должны сделать -- обратится
к  серверу  имен  зоны  groucho.edu,  который и передаст Вам требуемые
данные.

     Легко  сказать,  а  как  это  сделать, подумали вы. Так как найти
сервер имен в Groucho Marx Университет? В случае если ваш компьютер не


оборудован address-resolving oracle, DNS также обеспечивает это. Когда
ваше  приложение хочет найти информацию относительно erdos, оно входит
в  контакт  с  местным  сервером имен, который проводит так называемый
итерационный опрос. Сначала он посылает запрос серверу имен об области
корня,  спрашивая  о адресе erdos.maths.groucho.edu. Сервер имен корня
сообщает,  что  это  имя не принадлежит зоне его полномочий, но вместо
этого отсылает к edu области. Таким образом, он предлагает Вам войти в
контакт  с  сервером  имен  зоны edu для получения большего количества
информации,  и  прилагает  список  всех  серверов имен edu вместе с их
адресами.  Ваш  местный  сервер  имен  пошлет  запрос  одному  из них,
например  a.isi.edu. Также как серверу имен корня, a.isi.edu знает что
люди  groucho.edu  управляют  свей  зоной  сами,  и направит Вас на их
сервера.  Местный  сервер имен запросит одного из них, который наконец
распознает имя, как принадлежащее к его зоне, и вернет IP адрес.

     Кажется,  что  для поиска одного IP адреса тратится слишком много
ресурсов.  но  это  не  сравнимо  меньше,  чем  при  преждней  схеме с
HOSTS.TXT.  Но  все  еще  имеются  места  для  усовершенствования этой
схемой.

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

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

     3.6.4 Областные сервера имен (Domain Name Servers)

     Сервера имен, которые содержат всю информацию относительно хостов
в  пределах  данной  зоны названы авторитарными для этой зоны и иногда
упоминаются как master name servers. Любой запрос относительно хоста в
пределах  этой  зоны  будет  в  конце  концов  передан  одному из этих
серверов.



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

     Одна из причин иметь несколько серверов имен состoит в том, чтобы
распределять  груз  работы,  другая -- надежность. Когда одна машина с
сервером  имен ломается, все запросы будут посылаться другим серверам.
Конечно,  эта  схема  не защищает Вас от сбоев сервера, при которых он
отсылает  неправильные ответы на все запросы DNS, например от ошибок в
программе сервера.

     Конечно,  Вы  можете также создать сервер имени, который не будет
авторитарным  для  любой области. Этот тип серверов используется чтобы
проверять  запросы  от местных приложений и кэшировать ответы. Поэтому
его называют caching-only сервером.

     3.6.5 База данных DNS

     Мы  видели, что DNS имеет дело не только с IP адресами хостов, но
также  обменивается информацией относительно серверов имен. В DNS базе
данных фактически имеется целая куча различных типов записей.

     Единица  информации  в  DNS  базе  данных названа resource record
(записью  ресурса),  или  RR.  Каждая  запись  имеет определенный тип,
описывающий  тип  данных,  которые  в ней записаны, и определяющий тип
сети,   к   которой   она   применяется.  Последний  используется  при
определении схемы адресования, типа IP адресов (IN класс), или адресов
в  Hesiod  сетях (используемые в MIT), и др. Основной записью ресурсов
является запись, которая связывает полное имя области с IP адресом.

     Конечно,  хост  может  иметь больше чем одно имя. Однако, одно из
этих  имен  должно  быть определенно как официальное, или каноническое
имя  хоста, в то время как остальные просто псевдонимы. Различие между
ними в том, что каноническое имя хоста связано с А записью, в то время
как   другие  только  с  записью  типа  CNAME,  которая  указывает  на


каноническое имя хоста.

     Мы  не  будем  приводить  здесь  все  типы записей, а сделаем это
позже, в другой главе, здесь же ограничимся кратким примером. Картинка
3.6.5  показывает  часть  базы  данных  области  которая  загружена на
сервере имен для зоны physics.groucho.edu.

     Кроме  A и CNAME записи, Вы можете видеть специальную, занимающую
несколько  строк,  запись  сверху  файла.  Это  -  SOA запись ресурса,
расшифровывается  Start of Authority (Начало Власти), которая содержит
общую  информацию  относительно зоны, для которой этот сервер является
авторитарным. Она включает, например, время жизни для всех записей.

     Обратите  Внимание  что  все имена в файле с примером, которые не
заканчиваются   точкой   интерпретируются   относительно   groucho.edu
области.  Специальное имя "@", используемое в SOA записи при обращении
к имени данной области.

     Мы видели, что сервера имен для groucho.edu области так или иначе
должен   знать  хоть  что-то  относительно  зоны  физиков  так,  чтобы
направлять   запросы  серверам  имен.  Это  обычно  достигается  парой
записей: NS запись дается FQDN, и А запись, ассоциирующая его имя с IP
адресом.  Так  как  эти записи появляются вместе, они часто называются
склеенными  записями.  Это -- фактически единственный случаи записи, в
которой  родительская  зона  держит  информацию  относительно хостов в
зоне  подчиненного.  Склеенные  записи указывающие на сервера имен для
physics.groucho.edu показаны на рисунке 3.6.5.

      ;
       ; Authoritative Information on physics.groucho.edu
      @                     IN    SOA          {
                           niels.physics.groucho.edu.
                           hostmaster.niels.physics.groucho.edu.
                           1034             ; serial no
                           360000           ; refresh
                           3600             ; retry
                           3600000          ; expire
                           3600             ; default ttl


                         }
      ;
      ; Name servers
                            IN    NS       niels
                            IN    NS       gauss.maths.groucho.edu.
      gauss.maths.groucho.edu. IN A        149.76.4.23
      ;
      ; Theoretical Physics (subnet 12)
      niels                 IN    A        149.76.12.1
                            IN    A        149.76.1.12
      nameserver            IN    CNAME    niels
      otto                  IN    A        149.76.12.2
      quark                 IN    A        149.76.12.4
      down                  IN    A        149.76.12.5
      strange               IN    A        149.76.12.6
      ...
      ; Collider Lab. (subnet 14)
      boson                 IN    A        149.76.14.1

      muon                  IN    A        149.76.14.7
      bogon                 IN    A        149.76.14.12
      ...

Картинка 5. фрагмент файла amed.hosts для Отдела Физики.

     3.6.6. Обратный поиск.

     После   обнаружения   IP  адреса,  принадлежащего  хосту,  иногда
желательно  выяснять  каноническое  имя хоста, соответствующее данному
адресу.   Это   называется   reverse  mapping(обратное  отображение) и
используется   несколькими  сервесами,  чтобы  проверить  идентичность
клиента.  При  использовании единственного hosts файла, обратный поиск
заключается   просто  в  проверке  этого  файла.  В  DNS,  конечно  не
проводится просмотр всего адресного пространсва. Вместо этого, создана
специальная  область, inaddr.arpa, она содержит IP адреса всех хостов.
в  перевернутой  dotted-quad  записи  Например,  IP  адрес 149.76.12.4
соответствует  имени  4.12.76.149.in-addr.arpa.  Тип  записи  ресурса,
связывающий это имя с именем, называется PTR.



      ;
      ; Zone data for the groucho.edu zone.
      @                   IN       SOA          {
                           vax12.gcc.groucho.edu.
                           hostmaster.vax12.gcc.groucho.edu.
                           233              ; serial no
                           360000           ; refresh
                           3600             ; retry
                             3600000          ; expire
                           3600             ; default ttl
                         }
      ....
      ;
      ; Glue records for the physics.groucho.edu zone
      physics             IN     NS        niels.physics.groucho.edu.
                          IN     NS        gauss.maths.groucho.edu.
      niels.physics       IN     A         149.76.12.1
      gauss.maths         IN     A         149.76.4.23
      ...

Картинка 6. фрагмент файла named.hosts для GMU.

     Создание  зоны  полномочий обычно означает что ее администраторам
дают  полный контроль над тем как назначать адреса и имена хостов. Так
как они обычно управляют одной или более IP сетями или подсетями, одна
DNS  зона может охватывать несколько IP сетей. Отдел Физики, например,
включает подсети 149.76.8.0, 149.76.12.0, и 149.76.14.0.

     Как  следствие,  новые  зоны  должны быть записаны в in-addr.arpa
области:        8.76.149.in-addr.arpa,       12.76.149.in-addr.arpa, и
14.76.149.in-addr.arpa.  Иначе,  установка  нового  хоста  в  Collider
лаборатории  требовала  бы  обращения  к  родительской  области  чтобы
отметится  в  ее in-addr.arpa файле. Зональная база данных для подсети
12 показана на картинке 3.6.6. Соответствующие склеенные записи в базе
данных зоны родителя показывается на картинке 3.6.6.

      ;


      ; the 12.76.149.in-addr.arpa domain.
      @                IN     SOA   {
                           niels.physics.groucho.edu.
                           hostmaster.niels.physics.groucho.edu.
                           233 360000 3600 3600000 3600
                         }
      2                IN     PTR       otto.physics.groucho.edu.
      4                IN     PTR       quark.physics.groucho.edu.
      5                IN     PTR       down.physics.groucho.edu.
      6                IN     PTR       strange.physics.groucho.edu.

Картинка 7. фрагмент файла named.rev для подсети 12.

      ;
      ; the 76.149.in-addr.arpa domain.
      @                   IN       SOA          {
                           vax12.gcc.groucho.edu.
                           hostmaster.vax12.gcc.groucho.edu.
                           233 360000 3600 3600000 3600
                         }
      ...
      ; subnet 4: Mathematics Dept.
      1.4              IN     PTR      sophus.maths.groucho.edu.
      17.4             IN     PTR      erdos.maths.groucho.edu.
      23.4             IN     PTR      gauss.maths.groucho.edu.
      ...
      ; subnet 12: Physics Dept, separate zone
      12               IN     NS       niels.physics.groucho.edu.
                       IN     NS       gauss.maths.groucho.edu.
      niels.physics.groucho.edu. IN  A 149.76.12.1
      gauss.maths.groucho.edu. IN  A   149.76.4.23
      ...

Картинка 8. фрагмент файла named.rev  для сети

     Одно важное следствие этого то, что зоны могут создаваться только
как  наборы  IP  сетей,  и,  даже  круче,  количество  нулевых битов в
netmasks должно выть кратно 8. Все подсети в Groucho Marx Университете


имеют  netmask  255.255.255.0,  так  что  in-addr.arpa зона может быть
создана  для  каждой  подсети.  Однако,  если netmask 255.255.255.128,
создание  зон  для  подсети 149.76.12.128 будет невозможно, потому что
нет  никакой  возможности  сообщить  DNS,  что  12.76.149.in-addr.arpa
область   была   раздроблена   на   две   зоны,   с   именами   хостов
располагающимися от 1 до 127, и 128 до 255, соответственно.




     4. Конфигурирование сетевых аппаратных средств.

     4.1. Устройства, драйвера, и все это

     До  сих  пор,  мы  весьма  немного  говорили относительно сетевых
интерфейсов  и  общих  проблем  TCP/IP,  но  не  говорили  о  том, что
происходит,  когда  "сетевой  код"  в  ядре  обращается  к  аппаратным
средствам.  Для  этого,  мы  должны  немного  поговорить  о концепциях
интерфейсов и драйверов.

     Во-первых,  конечно, имеются непосредственно аппаратные средства,
например  Ethernet  карта:  пластина  из  эпоксидной  смолы, утыканная
большим  количеством  крошечных  чипов  с  глупыми  номерами на них, и
воткнутая  в  слот  вашего  PC.  Это  -  то  что  мы  обычно  называем
устройством.

     Для   того   чтобы   использовать   Ethernet   карту,  необходимы
специальные  функции, расположенные в ядре вашего Linux, которые знают
как   работать   с  этим  устройством.  Это  так  называемые  драйвера
устройств.  Например,  Linux  имеет драйвера устройства для нескольких
марок  Ethernet плат которые очень похожи по выполняемым функциям. Они
известны  как  "Becker  Series  Drivers" ,и называются так по имени их
автора,  Donald  Becker.  Другой  пример  -  D-link  драйвер,  который
работает  с  адаптером  D-link пакетов, присоединяемым к параллельному
порту.

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

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


адреса Типичные основные адреса для Ethernet плат 0x300, или 0x360.

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

     Также,  во  время загрузки, ядро будет пытаться обнаружить только
одно  Ethernet  устройство. Если вы используете больше чем одну плату,
Вы должны явно сообщить ядру об этой плате.

     Другой  параметр,  который Вы могли бы сообщить ядру -- interrupt
request  channel  (канал  прерывания  запроса).  Компоненты аппаратных
средств  обычно  прерывают  ядро  когда  они  нуждаются  во  внимании,
например  когда  прибыли  данные,  или произошли другие события. В PC,
прерывание может происходить на одном из 15 каналов (0, 1, 3 и до 15).
Номер  прерывания назначенный компоненту аппаратных средств называется
interrupt request channel или IRQ.

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

     Интерфейсы   идентифицируются   посредством   имен.   Эти   имена
определенны  внутри  ядра,  это  не файлы устройств в директории /dev.
Типичные  имена  для  интерфейсов  Ethernet.  -  eth0,  eth1,  и  т.д.
Назначение  интерфейсов  для  определенных устройств обычно зависит от
способа,   которым   устройства   конфигурированы;   например   первая
установленная  Ethernet  плата  станет  eth0, следующая -- eth1, и так
далее.   Исключение  из  этого  правила  -  SLIP  интерфейсы,  которые
назначаются  динамически;  То  есть  всякий раз, когда устанавливается
SLIP связь, последовательному порту назначается интерфейс



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

     Во время загрузки, ядро показывает какие устройства обнаружены, и
какому  какой  интерфейс  будет  установлен. Фрагмент типичного экрана
загрузки:

     This processor honours the WP bit even when in supervisor mode. Good.
     Floppy drive(s): fd0 is 1.44M
     Swansea University Computer Society NET3.010
     IP Protocols: ICMP, UDP, TCP
     PPP: version 0.2.1 (4 channels) OPTIMIZE FLAGS
     TCP compression code copyright 1989 Regents of the University of California
     PPP line discipline registered.
     SLIP: version 0.7.5 (4 channels)
     CSLIP: code copyright 1989 Regents of the University of California
     dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95
     Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
     Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994

     Здесь  показано что ядро компилировалось с TCP/IP, и с драйверами
для  SLIP,  CSLIP,  и  PPP.  Третья  строка  c  низу сообщает, что был
обнаружен  адаптер d-link, и он установился как интерфейс dl0. Если Вы
имеете  Ethernet  карту,  ядро  обычно печатает строку, начинающуюся с
eth0,  и  сопровождаемую  типом  обнаруженной  карты.  Если  Вы имеете
Ethernet  карту,  но  не  увидели это сообщение, это означает что ядро
неспособно обнаружить вашу плату. Об этом мы поговорим позже.

     4.2. Конфигурирование ядра

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



     При   управлении  Linux  системой,  Вы  должны  быть  знакомы  со
строением  ядра.  Основы этого объясняются в "Installation and Getting
Started"  написанной Matt Welsh, который является также частью проекта
Linux документации. Потому, в этой секции мы будем обсуждать только те
стороны конфигурации Linux, которые относятся к сети.

     При  запуске  make  config,  сначала Вас спрашивают общие вопросы
конфигурации,  например  хотите  ли  Вы  в  ядре  иметь математический
эмулятор  или  нет,  и  т.д..  Один  из  этих вопросов -- хотите ли Вы
поддержку  TCP/IP  сети.  Вы  должны  ответить  y, чтобы получить ядро
способное работать с сетью.

     4.2.1. Опции ядра в Linux 1.0 и выше

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

     Последующий список вопросов относится к проблемам поддержки сети.
Точный    набор   опций   конфигурации   постоянно   меняется,   из-за
продолжающейся   разработки.   Типичный   список   опций  предлагаемых
большинством  версий  ядра  (в  основном  в 1.0 1.1) напоминает этот (
комментарии даются italics шрифтом):
     *
     * Network device support
     *
     Network device support? (CONFIG ETHERCARDS) [y]

     Несмотря  на  макро  название  указанное  в  скобках,  Вы  должны
ответить  на  этот  вопрос  y,  если  Вы хотите использовать любой тип
сетевых  устройств, независимо от того является ли оно Ethernet, SLIP,
или   PPP.   При  ответе  y,  поддержка  для  устройств  Ethernet-типа
разрешается   автоматически.   Поддержку   для  других  типов  сетевых
драйверов нужно разрешить отдельно:

     SLIP (serial line) support? (CONFIG SLIP) [y]
     SLIP compressed headers (SL COMPRESSED) [y]
     PPP (point-to-point) support (CONFIG PPP) [y]


     PLIP (parallel port) support (CONFIG PLIP) [n]

     Эти  вопросы  касаются  различных протоколов связи поддерживаемых
Linux.   SLIP  позволяет  Вам  транспортировать  IP  дэйтаграмы  через
последовательные линии. Опция сжатия заголовков обеспечивает поддержку
CSLIP,  позволяющий  сжимать  TCP/IP  заголовки  всего  в  три  байта.
Обратите  Внимание что эта опция ядра не включает CSLIP автоматически,
она просто обеспечивает необходимые функции для него.

     PPP  -  другой протокол для построения сетей на последовательными
линиях.  Он  еще  более  гибок  чем SLIP, и не ограничен только IP, но
также  поддерживает  IPX.  Так как поддержка PPP была закончена только
недавно, эта опция может быть не представлена в вашем ядре.

     PLIP обеспечивает пересылку IP дэйтаграм через параллельный порт.
Он  главным  образом  используется  для  того чтобы связаться с PC под
управлением DOS.

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

     NE2000/NE1000 support (CONFIG NE2000) [y]
     WD80*3 support (CONFIG WD80x3) [n]
     SMC Ultra support (CONFIG ULTRA) [n]
     3c501 support (CONFIG EL1) [n]
     3c503 support (CONFIG EL2) [n]
     3c509/3c579 support (CONFIG EL3) [n]
     HP PCLAN support (CONFIG HPLAN) [n]
     AT1500 and NE2100 (LANCE and PCnet-ISA) support (CONFIG LANCE) [n]
     AT1700 support (CONFIG AT1700) [n]
     DEPCA support (CONFIG DEPCA) [n]
     D-Link DE600 pocket adaptor support (CONFIG DE600) [y]
     AT-LAN-TEC/RealTek pocket adaptor support (CONFIG ATP) [n]
     *
     * CD-ROM drivers
     *


      ...

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

        NFS filesystem support (CONFIG NFS FS) [y]

     4.2.2. Опции ядра в Linux 1.1.14 и выше

     При  запуске  Linux  1.1.14,  в  который  добавили поддержку IPX,
процедура  конфигурации  слегка  изменена.  Общая  секция опций теперь
спросит   хотите   ли   Вы   поддержку  сети  вообще.  Что  немедленно
сопровождается парой вопросов о разных сетях.

     *
     * Networking options
     *
     TCP/IP networking (CONFIG INET) [y]

     Чтобы использовать TCP/IP сеть, Вы должны ответить на этот вопрос
y.  Если  Вы  отвечаете  n, Вы будете все еще способны собирать ядро с
поддержкой IPX.

    IP forwarding/gatewaying (CONFIG IP FORWARD) [n]

     Вы  должны  здесь  ответить  Y,  если  ваша система действует как
gateway  между двумя Ethernet, или между Ethernet и SLIP, и т.д.. Хотя
не   причинит   вреда   установить   ее   по   умолчанию,   но   чтобы
отконфигурировать хост как так называемый firewall, вы должны ответить
здесь  нет.  Firewalls  --  хосты  которые  связаны с двумя или больше
сетями,  но  не  позволяют  им общаться. Обычно они используются чтобы
обеспечить  пользователям сетей с доступом к Internet минимальный риск
проникновения  из вне. Пользователям позволяется входить на firewall и
работать с Internet, но машины компании будут защищены от нападений из
вне, потому что любые внешние хосты не могут пересечь firewall.
     *


     * (it is safe to leave these untouched)
     *
     PC/TCP compatibility mode (CONFIG INET PCTCP) [n]

     Эта  опция  работает  с  несовместимостью  с  некоторыми версиями
PC/TCP,  коммерческими TCP/IP выполненными для DOS. Если Вы разрешаете
эту  опцию,  Вы  все  еще  будете  способны общаться с нормальной Unix
машиной, но она вредна для медленных соединений.

     Reverse ARP (CONFIG INET RARP) [n]

     Эта   функция   включает  RARP.  RARP  используется  бездисковыми
клиентами  и  X-терминалами  во  время  загрузки для запроса своего IP
адрес.  RARP  необходим  только  для  работы  с этими клиентами. Самый
последний  пакет сетевых утилит (net-0.32d) содержит небольшую утилиту
rarp которая позволяет Вам добавлять системы в RARP кэш.

      Assume subnets are local (CONFIG INET SNARL) [y]

     При  посылки  данных  по  TCP ядро, перед передачей их IP, должно
разбивать  поток на несколько пакетов. Большие пакеты используются для
работы  в локальной сети типа Ethernet, меньшие в случае, когда данные
посылаются  куда-то  далеко.  Если  Вы  запрещаете  SNARL,  ядро будет
работать  только  с  локальными  сетями,  к которым он непосредственно
подключен.  Так,  если  Вы  посмотрите на сеть класса B в Groucho Marx
Университете,  там  большинство  хостов подключены к только одному или
двум  подсетям.  Если Вы разрешаете SNARL, ядро будет предполагать что
все  подсети местные и используют большие пакеты при разговоре с всеми
хостами в университетском городке.

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

      Disable NAGLE algorithm (normally enabled) (CONFIG TCP NAGLE OFF) [n]

     Правила  Nagle  используются  чтобы избежать посылки маленьких IP


пакетов,   также   названные  tinygrams.  Tinygrams  обычно  создаются
диалоговыми  сетевыми программами, которые передают отдельные символы,
типа  telnet  или  rsh.  Tinygrams может стать особенно неудобными при
связи  по  узкополосным  линиям.  Nagle  алгоритм пытается избегать их
сдерживая при некоторых обстоятельствах передачу TCP данных. Вам стоит
отключить  Nalge алгоритм, только если у вас есть серьезные проблемы с
получением пакетов.

     The IPX protocol (CONFIG IPX) [n]

     Это   опция   включает   поддержку   IPX,  транспортный  протокол
используемый  Novell  сетями.  Он  все  еще  в  разработке  и не очень
полезен.  Единственная  польза  -- обмен данными с IPX утилитами DOS и
передача  данных между вашими novell сетями через PPP связь. Поддержка
протоколов  высокого  уровня  для  Novell  сети в обозримом будущем не
будет, так как спецификации бесплатно не достать.

     В  ядре 1.1.16, Linux поддерживается еще один тип драйвера, dummy
driver  (фиктивный  драйвер).  Следующий  вопрос  появляется  в начале
секции драйверов устройств.

     Dummy net driver support (CONFIG DUMMY) [y]

     Фиктивный  драйвер  в  действительности делает немного, но весьма
полезен  на  автономном или SLIP хосте. Это в основном замаскированный
loopback интерфейс. Этот вид интерфейса нужен на хостах, которые имеют
SLIP но не имеют Ethernet, но хотят иметь интерфейс, который все время
держит ваш IP адрес. Чуть больше он обсуждается в секции 6.7.7 в главе
6 ..

     4.3. Путешествие по сетевым устройствам Linux

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

     В Linux имеются ряд стандартных имен интерфейсов, которые описаны
ниже.  Большинство  драйверов  поддерживают больше чем один интерфейс,


тогда интерфейсы перечисляются как в eth0, eth1, и т.д..

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

     ethn n-ая Ethernet карта. Это имя интерфейса генерируется для
          большенства Ethernet плат.

      dln Это интерфейс доступа к D-Link  DE-600 пакетному адаптеру (другое
          Ethernet устройство). Разница в том, что DE-600
          работает через параллельный порт.

      sln n-ый SLIP интерфейс. Первая последовательная линия отконфигурируемая под SLIP
          становится sl0, и т.д.. Ядро поддерживает  до четырех SLIP
          интерфейсов.

     pppn n-ый PPP интерфейс. Подобно SLIP интерфейсам, PPP интерфейс
          связан с последовательной линией, если только она отконфигурирована для
          PPP. В настоящее время поддерживается до четырех
          интерфейсов.

     plipn n-ый PLIP интерфейс. PLIP транспортирует IP дэйтаграмы по
          параллельным линиям. Поддерживается до трех PLIP интерфейсов.
          Они устанавливаются PLIP драйвером при загрузке системы,
          и отображают параллельные порты.

     Для  других  драйверов интерфейса, которые могут быть добавлены в
будущем, подобно ISDN или AX.25, будут предоставлены другие имена.

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


     4.4. Установка Ethernet



     Сейчас  Linux  поддерживает различные марки Ethernet карт. Больше
всего  драйверов  были  написаны  Donald Becker ([email protected]). Он
автор   семейства   драйверов   для   карт   основанных   на  National
Semiconductor  8390  чипе;  они  стали  известными  как  серия  Becker
драйверов.  Имеются  также драйвера для пары изделий для D-Link, среди
них  D-Link  адаптер,  который  предлагает  доступ  к  Ethernet  через
паралельный   порт.   Драйвер   для   этот  был  написан  Bjrn  Ekwall
([email protected]).   DEPCA   драйвер   был   написан   David  C.  Davies
([email protected]).                         

     4.4.1. Прокладка Ethernet кабеля.

     Если  вы устанавливаете Ethernet впервые в вашей жизни, несколько
сказанных  здесь  слов  могут  быть  вам  полезны.  Ethernet  -  очень
чувсвителен  к  правельности  прокладки  кабеля. Кабель должен с обоих
концов  закрыватся 50 Омным резистором и не каких ответвлений. Если Вы
используете  тонкий  кабель с T-образными BNC переходами, эти переходы
должны быть вкручены непосредственно в плату.

     Если  Вы  используете  толстый кабель, Вы должны присоеденять ваш
хост через transceiver. Вы можете воткнуть transceiver непосредственно
AUI порт на вашей плате, но можете также использовать кусок кабеля.

     4.4.2. Поддержка платы

     Полный  список  поддерживаемых  плат  доступен  в Ethernet HOWTOs
расположенных на comp.os.linux.announce Paul Gortmaker.

     Вот список наиболее широко известных платы, поддерживаемых Linux.
Полный  список в HOWTO приблизительно в три раза длиннее. Однако, даже
если  Вы  нашли  вашу  плату  в  этом списке, проверите сначала HOWTO;
иногда  существуют  важные  детали  относительно  работы этих карт. На
пример,  некоторые  DMA-основанные  Ethernet  платы  используют тот же
самый  DMA  канал  что  и  Adaptec  1542  SCSI  контролер.  Если Вы не
переместите  один из них на другой DMA канал, не удивляйтесь, что ваша
Ethernet  плата  пишет  данные  в  произвольные  места вашего жесткого
диска.



3Com EtherLink  поддерживаются и 3c503 и 3c503/16, как - 3c507 и 3c509. 3c501
          также поддерживается, но слишком медленна, чтобы ее покупать.

Novell Eagle NE1000 и NE2000, и разнообразные клоны. NE1500 и NE2100 также
          поддерживаются.

Western Digital/SMC WD8003 и WD8013 ( то же самое что  SMC Elite и SMC Elite
          Plus) поддержана также и более новая SMC Elite 16 Ultra.


Hewlett Packard HP 27252, HP 27247B и HP J2405A.


D-Link DE-600 pocket adaptor, DE-100, DE-200, и DE-220-T.. Имеется также
          комплект для DE-650-T, который является PCMCIA картой. (4)


DEC DE200 (32K/64K), DE202, DE100, и DEPCA rev E.


Allied Teliesis AT1500 and AT1700.

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


     4.4.3.  Автоматическое определение Ethernet

     Во  время загрузки, Linux попробует найти вашу плату и определить
ее тип. Карты ищутся по следующим адресам и в следующем порядке:

------------------------------------------------------
+--------------+-------------------------------------+
|карта         | адреса поиска                       |
+--------------+-------------------------------------+
|WD/SMC        | 0x300, 0x280, 0x380, 0x240          |


|SMC 16 Ultra  | 0x300, 0x280                        |
|3c501         | 0x280                               |
|3c503         | 0x300, 0x310, 0x330, 0x350, 0x250,  |
|              | 0x280, 0x2a0, 0x2e0                 |
|NEx000        | 0x300, 0x280, 0x320, 0x340, 0x360   |
|HP            | 0x300, 0x320, 0x340, 0x280, 0x2C0,  |
|              | 0x200, 0x240                        |
|DEPCA         | 0x300, 0x320, 0x340, 0x360          |
+--------------+-------------------------------------+
+--------------+-------------------------------------+

     Имеются  два  ограничения  autoprobing.  Во  первых,  он может не
распознавать   все   платы  должным  образом.  Это  особенно  касается
некоторых  из  дешевых  клонов  известных  плат, а также для некоторых
WD80x3 плат. Вторая проблема состoит в том, что ядро находит не больше
одной  платы.  Если  Вы  используете  больше  чем одну плату, или если
autoprobe  не  в  состоянии  обнаружить  вашу  плату,  Вы  должны явно
сообщить ядру основной адреса карты и имя.

     В Net-3, для этого Вы может использовать две различных схемы Один
путь  состoит  в  том,  чтобы  изменить или добавить информацию в файл
drivers/net/Space.c   в  исходном  коде  ядра,  который  содержит  всю
информацию  относительно  драйверов. Это рекомендуются только, если Вы
знакомы  с  сетевым кодом. Лучший путь состoит в том, чтобы обеспечить
ядро  этой  информацией  при  загрузке.  Если  Вы используете lilo для
загрузки вашей системы, Вы можете передавать параметры ядру, определяя
их   через   опцию   в  lilo.conf.  Чтобы  сообщить  ядру  о  Ethernet
устройстве, Вы можете передавать следующий параметр:

     ether=irq,base addr,param1,param2,name

     Первые  четыре параметра числовые, в то время как последний - имя
устройства. Все числовые значения необязательные; если они опущены или
равны  нолю,  ядро  будет  пробовать  само обнаружить эти значения или
использует значение установленное по умолчанию.

     Первый  параметр  устанавливает  IRQ  для  устройства. Если он не
указан,  ядро будет пробовать обнаружить IRQ канал само. 3c503 драйвер


имеет   специальную   особенность,   которая  позволяет  ему  выбирать
свободный   IRQ   (из   5,  9,  3,  4)  и  конфигурировать  плату  для
использования этой линии.

     addr  параметр задает основной адрес ввода-вывода платы; значение
ноль сообщает ядру исследовать адреса внесенные в следующий список.

     Следующие   два   параметра   могут   использоваться   по-разному
различными драйверами. Для плат с разделяемой памятью типа WD80x3, они
определяют  начальный  и  конечный  адреса разделенной области памяти.
Другие  карты  обычно  используют  param1  чтобы устанавливать уровень
отладочной  информации.  От  1  до 7 обозначают увеличивающиеся уровни
подробности,  в  то  время  как  8 выключает их; 0 обозначает значение
установленное  по  умолчанию.  3c503  драйвер  использует param2 чтобы
выбрать   внутренний  transceiver  (установленный  по  умолчанию)  или
внешний transceiver ( значение 1). Первый использует BNC; последний --
AUI порт.

     Если   Вы  имеете  две  Ethernet  платы,  Вы  можете  одну  плату
определять  автоматически,  а  параметры  второй платы с помощью lilo.
Однако,  Вы  должны  удостоверился,  что  драйвер  случайно не находит
вторую  плату, в то время как первая не будет регистрироваться вообще.
Это  можно  сделать, указывая в lilo избегать исследовать пространство
ввода-вывода занятое второй платой.

     Например,  прося  Linux  установить вторую Ethernet плату в 0x300
как eth1, Вы бы передали следующие параметры к ядру:

    Reserve=0x300,32 ether=0,0x300, eth1

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

     Reserve=0x340,32 ether=0,0x340, eth0

     Чтобы  выключить  autoprobing вообще, Вы можете определить addr в
-1:



     Ether=0,-1, eth0

     4.5. PLIP Драйвер

     PLIP  основан  на  IP для параллельных линий и используется, если
необходимо  соединить  две  машины.  Он использует параллельный порт и
специальный  кабель  и  позволяет достигать скоростей от 10Кбит/cек до
20Кбит/сек.

     PLIP  был  первоначально  разработан  компанией  Crynwr. Довольно
оригинальный  проект: в течение длительного времени параллельные порты
в  PC  использовались  в  основном для принтеров; то есть восемь линий
использовались  только  чтобы  послать  данные  с  PC  на периферийное
устройство  и  никуда  больше.  PLIP работает, обходя это ограничение,
используя   пять  линий  состояний  порта  для  ввода,  что  позволяет
передавать  по  пол-байта  за  раз  между  машинами. Этот режим работы
называется   mode   zero   PLIP   (0   способ   PLIP).   Сегодня,  эти
однонаправленные  порты кажется больше нигде не используются. Поэтому,
имеется также PLIP расширение, названное способом 1 который использует
полный 8 разрядный интерфейс.

     В  настоящее время, только Linux поддерживает 0 способ. В отличии
От  более  ранних  версий  PLIP, теперь он пытается быть совместимым с
PLIP  сделанным на Crynwr, а также PLIP драйвером в NCSA telnet. Чтобы
соединить  две  машины  использующие  PLIP,  Вам требуется специальный
кабель -- "Null Printer" или "Turbo Laplink" кабель. Вы можете сделать
его и сами. Приложение 20.3 описывает как.

     РLIP поддерживало большое количество людей. В настоящее время его
поддерживает Niibe Yutaka.

     Если   PLIP   компилируется  в  ядро,  он  устанавливает  сетевой
интерфейс   для   каждого   из   возможных   портов   принтера,  plip0
соответствует  параллельному  порту  lp0,  plip1  --  lp1,  и  т.д.. В
настоящее время интерфейсы отображаются на порты следующим образом:




--------------------------------
+-----------+-----------+------+
| Интерфейс | I/O порт  | IRQ  |
+-----------+-----------+------+
|plip0      | 0x3BC     | 7    |
|plip1      | 0x378     | 7    |
|plip2      | 0x278     | 5    |
+-----------+-----------+------+
+-----------+-----------+------+

     Если Вы отконфигурировали ваш порт принтера по-другому, Вы должны
изменить эти значения в drivers/net/Space.c в исходниках ядра Linux, и
собрать новое ядро.

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

     4.6. SLIP и PPP Драйвера

     SLIP (Serial Line IP), и PPP ( Point-to-Point Протокол ) - широко
используемые  протоколы  для посылки IP пакетов через последовательное
соединение.  Ряд учреждений предлагают телефонный SLIP и PPP доступ на
машины  которые  находятся  в  Internet,  таким образом обеспечивая IP
частным лицам.

     Чтобы запустить SLIP или PPP, не требуется модификации аппаратных
средств.  Вы  можете  использовать  любой последовательный порт. Более
подробно об этом написано в главе 5.




     5. Установка последовательных аппаратных средств

     Ходят слухи, что где-то там существуют люди, которые имеют только
один  PC  и  не  имеют денег на T1 Internet соединение. Чтобы получить
свою  ежедневную  дозу новостей и почты, они полагаются на SLIP связь,
UUCP  сети,  и  системы информационных табло (BBS), которые используют
телефонные сети.

     Эта  глава написана для всех тех людей, кто полагается на модемы.
Однако,  существует  большое количество деталей, в которые мы не будем
вдаваться,  например как конфигурировать ваш модем. Все эти темы будут
охвачены  в  создающемся  Serial HOWTO Greg Hankins, который регулярно
отправляется по почте к comp.os.linux.announce.


     5.1. Коммуникационное программного обеспечения для модемной связи

     Имеются  ряд коммуникационных пакетов доступных для Linux. Многие
из  них  -- это терминальные программы, которые позволяют пользователю
на брать номер другого компьютера и работать как будто Вы сидите перед
простым терминалом.

     Традиционная  терминальная  программа для Unix -- kermit. Имеются
более   удобные  программы,  которые  поддерживают  список  телефонных
номеров,  языки  для  написания  скриптов  запросов и описания входа в
удаленные  системы,  и  т.д.. Один из них -- minicom, который близок к
некоторый  терминальным программам для DOS. Имеются также Х-основанные
пакеты коммуникаций, например seyon.

     Также, доступны несколько linux-основанных BBS пакетов для людей,
которые  хотят  управлять  системой информационных табло. Некоторые из
этих    пакетов    могут    быть    найдены    на    sunsite.unc.edu в
/pub/Linux/system/Network.

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


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

     Основной  представитель  этого  вида  программного обеспечения --
UUCP.  UUCP -- это набор программы, которые позволяют копировать файлы
с  одного  хоста на другой, выполнять программы на отдаленном хосте, и
т.д..  Он  часто используется для транспортировки почты или новостей в
частных  сетях.  Ian  Taylor's UUCP пакет, который работает под Linux,
описан   в   следующей   главе.   Но   есть   и   другое  недиалоговое
комуникационное   программное  обеспечение,  например,  используемое в
Fido. Порты Fido приложений подобно ifmail также доступны.

     SLIP  находится  где-то посередине и используется как диалоговыми
так  и  не-диалоговыми  приложениями.  Множество людей используют SLIP
чтобы  дозвонится  до  университетской  сети  или  какого-либо другого
общественного SLIP сервера, чтобы управлять FTP сессиями, и т.д.. SLIP
может  также  использоваться  для  постоянной или полупостоянной связи
сеть-сеть, хотя здесь полезен скорее ISDN.


     5.2. Представления последовательных устройств

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

     В  Linux существует три класса tty: (виртуальные) консоли, псевдо
терминалы  (подобные  дуплексному  каналу,  используемому приложениями


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

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

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

     Существует  также некоторая двусмысленность относительно того как
измерять  скорость  линии.  Правильно - bit rate(побитовое измерение),
которое  связано со скоростью линии измеренной в битах за секунду (или
bps  для  краткости).  Иногда,  люди называют это Бод (Baud), что тоже
верно.  Эти  два  термина,  однако,  не взаимозаменяемы. Бод относит к
физической  характеристике  некоторого последовательного устройства, а
именно время за которое произошла передача импульса. Битовое измерение
обозначает текущее состояние существующей последовательной связи между
двумя  точками,  а  именно  средний число битов переданных за секунду.
Важно   знать   что   эти  два  значения  обычно  различны,  поскольку
большинство  устройств  кодируют  больше чем один бит за электрический
импульс.

     5.3. Доступ к последовательным устройствам

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



     Первые  файлы  требуются  в  случае,  если  порт используется для
входа;  они  имеет  главный  номер  4, и файлы названы ttyS0, ttyS1, и
т.д..  Вторые  используется  для выхода; файлы названы cua0, и т.д., и
имеют  главный  номер  5.  Незначительные  номера  одинаковы для обоих
типов.  Если  ваш  модем подключен к одному из портов от COM1 до COM4,
незначительный  номер  будет  номер  COM  порта  плюс  63.  Если  ваша
установка   отлична   от   этой,   например  при  использовании  платы
поддерживающей множество последовательных линий, пожалуйста обратитесь
к Serial Howto.

     Предположим,  что  ваш  модем  находится  на  COM2. Таким образом
незначительный  номер  будет  65, а главный номер для дозвона будет 5.
Следовательно,  должно  иметься  устройство  cua1  которое  имеет этот
номер.  Просмотрите  список  последовательный ttys в директрорие /dev.
Колонки  5  и  6  должны  показать  главные  и  незначительные номера,
соответственно:

     $ ls -l /dev/cua*
     crw-rw-rw-   1 root     root       5,  64 Nov 30 19:31  /dev/cua0
     crw-rw-rw-   1 root     root       5,  65 Nov 30 22:08  /dev/cua1
     crw-rw-rw-   1 root     root       5,  66 Oct 28 11:56  /dev/cua2
     crw-rw-rw-   1 root     root       5,  67 Mar 19  1992  /dev/cua3

     Если   нет   таких  устройств,  Вы  должны  создать  их:  войдите
супер-пользователем и наберите

     # mknod -m 666 /dev/cua1 c 5 65
     # chown root.root /dev/cua1

     Некоторые Люди предлагают создание символической связи /dev/modem
на ваше устройство модема, так, чтобы случайные пользователи не должны
были  запоминать  несколько  неинтуитивное  cua1. Однако, Вы не можете
использовать  modem  в  одной  программе,  а  реальное  название файла
устройства  в  другой.  Это  - потому что эти программы используют так
называемые   файлы  замка  (lock  files)  для  обозначения  того,  что
устройство используется. В соответствии с соглашением, имя файла замка
для cua1, например, является LCK..cua1. Использование различных файлов


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

     5.4. Аппаратные Средства для последовательных линий.

     Linux    в    настоящее    время    поддерживает    разнообразные
последовательные  платы,  которые используют стандарт RS-232. RS-232 в
настоящее   время   наиболее   общий   стандарт  для  последовательных
коммуникаций в мире PC.

     Хотя   аппаратные  средства  handshake  необязательны,  но  очень
полезны.   Они  позволяют  любой  из  двух  станций  сигнализировать о
готовности  получить  данные  или  о  том,  что  другая станция должна
подождать  пока  приемник  не  обработает  поступающие  данные.  Линии
используемые для этот названы "Clear to Send" (Чистыми для посылки или
CTS)  и  "Ready  to  Send"(Готовыми  послать или RTS), соответственно,
которые,  объясняют  второе  название  handshake аппаратных средств, а
именно "RTS/CTS".

     В  PC, интерфейс RS-232 обычно управляется UART чипом, полученным
из 16450 чипа, или более новой его версии, NSC 16550A. Некоторые марки
(  особенно  внутренних  модемов оборудованных набором чипов Rockwell)
используют  другие  чипы,  которые были запрограммированы, чтобы вести
себя так же как 16550-ые.

     Главное различие между 16450 и 16550 то, что последний имеют FIFO
буфер размером 16 Байт, в то время как первый только 1 байт

     Это  делает 16450 подходящими для скорости в 9600 Бод, в то время
как  для  больших  скоростей требуются чипы совместимые с 16550. Кроме
этих  чипов,  Linux  также  поддерживает  8250 чип, который был сделан
специально для PC-AT.

     В   стандартной   конфигурации,   ядро  ищет  четыре  стандартных
последовательных платы от COM1 до COM4. Они связываются с устройствами
с незначительными номерами от 64 до 67, так как описано выше.



     Если  Вы  хотите  отконфигурировать  ваши  последовательные порты
по-другому,   Вы  должны  установить  Ted  Tso's  setserial  команду в
rc.serial  скрипте.  Этот скрипт должен вызываться из /etc/rc во время
загрузки   системы.  Он  использует  setserial  чтобы  конфигурировать
последовательные устройства. Типичный rc.serial скрипт напоминает это:

     # /etc/rc.serial - serial line configuration script.
     #
     # Do wild interrupt detection
     /sbin/setserial -W /dev/cua*

     # Configure serial devices
     /sbin/setserial /dev/cua0 auto irq skip test autoconfig
     /sbin/setserial /dev/cua1 auto irq skip test autoconfig
     /sbin/setserial /dev/cua2 auto irq skip test autoconfig
     /sbin/setserial /dev/cua3 auto irq skip test autoconfig

     # Display serial device configuration
     /sbin/setserial -bg /dev/cua*


     Пожалуйста обратитесь к документации, которая поставляется вместе
с setserial для объяснения параметров.

     Если ваша последовательная карта не обнаружена, или setserial -bg
команда   показывает   неправильные   установки,   Вы   должны  будете
отконфигурировать    его    явно,   используя   правильные   значения.
Пользователи  с  внутренними  модемами оборудованными Rockwell набором
чипов  как сообщается испытывают эту проблему. Так, например, UART чип
называется  NSC  16450,  в  то  время как фактически это NSC 16550, Вы
должны    изменить    конфигурационную    команду   для   причиняющего
неприятность порта

/sbin/setserial  /dev/cua1  auto irq skip test autoconfig uart 16550


     Подобные  опции  существуют  и  для  того чтобы изменить основной


адрес,  и  IRQ  COM  порта.  Пожалуйста  обратитесь  к  man страницам,
setserial(8).

     Если  ваш  модем  поддерживает  аппаратные средства handshake, Вы
должны  удостовериться,  что  вы  разрешили  работу сними. Большинство
коммуникационных  программ по умолчанию не пытаются этим пользоваться.
Вы  должны  устанавливать  его  в  ручную.  Лучше  всего это сделать в
rc.serial скрипте, используя команду stty:

     $ Stty crtscts < /dev/cua1

Чтобы проверить действительно ли используется handshake

  $ Stty -a < /dev/cua1

     Это   команда  выдаст  Вам  состояния  всех  флагов  для  данного
устройства;  флаг показанный с предшествующим минусом как и в -crtscts
означает что флаг выключен.




     6. Конфигурирование TCP/IP  сети

     В этой главе, мы пройдем все шаги необходимые для создания TCP/IP
сети  на  вашей  машине.  Начнем  мы  с  назначения IP адресов и будем
медленно проходить весь путь конфигурирования интерфейсов TCP/IP , и в
конце  рассмотрим  несколько  инструментов,  которые весьма удобны для
решения проблем с установкой сети.

     Большинство  работ  охваченных  этой  главой,  Вы  должны сделать
только  один  раз.  Впоследствии,  Вы будете изменять конфигурационные
файлы только в случае добавлении новой системы к вашей сети, или когда
Вы  повторно  полностью  переконфигурируйте вашу систему. Некоторые из
команд  конфигурирования  TCP/IP, однако, должны выполнятся каждый раз
когда загружается система. Это обычно делает /etc/rc скрипт.

     Обычно,  специфическая  сетевая часть этой процедуры содержится в
скрипте  названном  rc.net или rc.inet. Иногда, Вы будете также видеть
два  скрипта  названные rc.inet1 и rc.inet2, где вышеупомянутый скрипт
инициализирует  сетевую часть ядра, в то время как последние запускают
основные  сетевые приложения. Дальше я буду твердо придерживаться этой
концепции.

     Ниже,  Я  буду  обсуждать  действия  выполняемые в rc.inet1, в то
время  как  приложения  будут  описаны  в  более поздних главах. После
окончания  этой главы, Вы должны установить последовательность команд,
которые должным образом конфигурируют TCP/IP сеть на вашем компьютере.
Вы   можете  заменить  любые  команды  в  rc.inet1  вашими  командами,
удостоверится   что   rc.inet1   выполняется  при  запуске  системы, и
перезагрузить  вашу  машину.  Сетевые  rc скрипты, которые вы получили
наряду с вашим Linux должны быть хорошим примером.

     6.1. Установка файловой системы proc

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


файловую  систему. Когда он установлен, Вы можете просматривать список
его  файлов и их содержание также как в любой другой файловой системе.
Типичными  представителями  являются  файл  loadavg,  который содержит
среднее  число  загруженности  системы  и  meminfo, который показывает
текущее  состояния памяти ядра и использование свопа. К этому, сетевой
код  добавляет  сeтевую  директорию.  Она содержит ряд файлов, которые
отображают  состояние вещей типа ARP таблицы, TCP соединений, и таблиц
маршрутизации.   Большинство   инструментов   администрирования   сети
получают информацию из этих файлов.

     Proc  файловая  система  (или  procfs)  обычно устанавливается во
время  загрузки  в  /proc.  Самый  лучший  метод  состoит в том, чтобы
добавить следующую строку в /etc/fstab:



    # procfs mont point:
     none            /proc           proc    defaults

     И выполнить "mount /proc" в вашем /etc/rc скрипте.

     Procfs  в  настоящее  время  отконфигурирован  в большинстве ядер
установленным  по  умолчанию.  Если procfs нет в вашем ядре, Вы можете
получить  сообщение  типа  "mount:  fs  type  procfs  not supported by
kernel".  Тогда Вы должны будите повторно собрать ядро и ответить "да"
когда вас спросят о поддержки procfs.

     6.2. Установка бинарников

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


netXXX.tar.gz,  где  XXX  - номер версии. Выпуск соответствующий Linux
1.0 -- 0.32b, самое последнее ядро ( 1.1.12 или позже ) требуют 0.32d.

     Если  Вы  хотите  собрать и установить стандартные TCP/IP сетевые
приложения самостоятельно, Вы можете получить исходники на большинстве
Linux  FTP  серверов.  Там  лежат  более или менее тяжело исправленные
версий программ от Net-BSD и другие исходники. Другие приложения, типа
Xmosaic,  xarchie,  или  Gopher и IRC клиенты нужно получать отдельно.
Большинство из них легко собирают, если Вы следуете всем инструкциям.

     Официальный   FTP   участок   для   Net-3  --  sunacm.swan.ac.uk,
отраженный  sunsite.unc.edu  в  system/Network/sunacm. Самый последний
Net-2e  комплект и бинарники к нему доступны на ftp.aris.com. Matthias
Urlichs   bsd   сетевой   код  может  быть  взят  на  ftp.ira.uka.de в
/pub/system/linux/netbsd.


     6.3. Другой пример

     Для  остатка  этой книги, позвольте мне представить новый пример,
который является менее сложным чем Groucho Marx Университет, и ближе к
задачам,  с  которыми  Вы  будете  фактически сталкиваться. Рассмотрим
виртуальную  пивоварню,  маленькую компанию, которая варит пиво. Чтобы
управлять  этим  бизнесом  более эффективно, в пивоварне хотят создать
сети из компьютеров, которые все оказались PC, управляемые Linux 1.0.

     На  том же самом этаже, только через коридор, имеется виртуальная
винодельня,  которая  работает  рядом  с  пивоварней. Там используется
собственный  Ethernet.  Весьма  естественно,  что  две  компании хотят
связать  свои сети. Как первый шаг, они хотят создать gateway, который
будет передавать дейтограмы между двумя полсетями. Позже, они также за
хотят  иметь UUCP связь с внешним миром. В конечном счете, они захотят
установить SLIP соединение чтобы соединяться иногда с Internet.

     6.4. Установка имени хоста

     Большинство,  если  не  все,  сетевые  приложения  используют имя
локального  хоста,  которое  устанавливается  к  некоторому  разумному


значению. Чтобы установить имя хоста наберите


     # hostname name

     Существует  общая  практика  использовать неквалифицированное имя
хоста, то есть без указания названия области для него. Например, хосты
в   Виртуальной   Пивоварне  могли  бы  быть  названы  vale.vbrew.com,
vlager.vbrew.com,    и    т.д..    Это   их   официальные,   полностью
квалифицированные  имена  области. Их локальные имена -- только первый
компонент  этого  имени,  типа  vale.  Однако, поскольку локальное имя
часто   используется   для   поиска   IP   адреса   хоста,  Вы  должны
удостоверится  что resolver библиотека способна найти IP адрес данного
хоста. Это обычно означает что Вы должны ввести имя в /etc/hosts ( см.
ниже ).

     Некоторые  Люди предлагают использовать команду domainname, чтобы
развить  идею ядра относительно имени области к остающейся части FQDN.
Таким   образом,   Вы  могли  бы  комбинировать  вывод  от  hostname и
domainname  чтобы  получить  снова  FQDN.  Однако, это в лучшем случае
правильно   на   половину   .  domainname  вообще  используется  чтобы
устанавливать  NIS область хоста, которая может полностью отличатся от
DNS области, к которой ваш хост принадлежит. NIS описан в главе 11 ..


     6.5. Назначение IP Адресов

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

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

     Хосты в пределах локальной сети обычно должны использовать адреса


от  той  же  самой  логической  IP  сети.  Если  Вы  имеете  несколько
физических сетей, Вы или должны назначить им различные сетевые номера,
или  использовать  подсети,  чтобы расколоть ваш диапазон IP адресов в
несколько подсетей.

     Если  ваша  сеть не связана с Internet, Вы свободны выбрать любой
правельный сетевой адрес. Вы только должны удостовериться, что выбрали
его  из  классов  A, B, или C, в противном случае большенство программ
будут работать не правильно. Однако, если Вы намереваетесь в ближайшем
будущем  выйти  в  Internet,  Вы должны получить официальный IP адрес.
Самый  лучший  путь  состoит  в  том,  чтобы попросить вашего сетевого
поставщика  помочь Вам. Если Вы хотите получить сетевой номер только в
случае  когда  вы  выбираетесь  в  Internet, запросите бланк заявки на
сетевой адреса от [email protected].

     Чтобы  оперировать  несколькими Ethernet (или другими сетями), Вы
должны  разбить вашу сеть в несколько подсетей. Обратите Внимание, что
подсети  требуются  только  в  случае,  если Вы имеете больше чем одну
сеть;  Point-to-point  связь  не учитывается. Например, если Вы имеете
один  Ethernet и один или более SLIP соединений с внешним миром, Вы не
нуждаетесь в подсети. Причина этого объясняется в главе 8..

     Как  пример,  менеджер сети пивоварни обращается к NIC за сетевым
номером класс В, и получает 191.72.0.0. Чтобы разместить два Ethernet,
он  решает  использовать  восемь  битов части хоста как дополнительные
подсетевые  биты. Это оставляет другие восемь битов для хоста, то есть
по  254  хостов  на  каждой  полсети.  Он  также  назначает  подсеть 1
пивоварне  и  2 -- винодельне. Их соответствующие сетевые адреса таким
образом 191.72.1.0 и 191.72.2.0. Сетевая маска 255.255.255.0.

     Vlager,  который  является  gateway  между  двумя сетями, получил
номер  хоста,  равный 1 на обоих из них, что дает ему IP адреса равные
191.72.1.1  и  191.72.2.1,  соответственно.  Картинка  показывает  две
подсети, и gateway.

     Обратите  Внимание  что  в этом примере Я использую сеть класса B
для  простоты; класс C сеть был бы более реалистичным. С новым сетевым
кодом, деление на подсети не ограничено границами байта, так даже сеть


класса  C  может  быть раздроблена на несколько полсетей. Например, Вы
могли  бы  использовать 2 бита части хоста для сетевой маски, что дает
Вам четыре возможные подсети с 64 хостами на каждой.

     6.6. Написание hosts и networks файлов

     После  того,  как  Вы  разбили  на  подсети  вашу сеть, Вы должны
подготовиться  к  некоторому  простому  виду  поиска  адреса  по имени
использующего файл /etc/hosts. Если Вы не собираетесь использовать DNS
или NIS для этого, Вы должны помещать все хосты в hosts файл.

     Даже  если  Вы  хотите  использовать DNS или NIS, Вы можете иметь
некоторое  подмножество  имен и в /etc/hosts. Например, если вы хотите
иметь  некоторый  вид  поиска  по  имени  даже  когда  никакие сетевые
интерфейсы  не  запущены,  например  во  время загрузки. Это не только
вопрос  удобства,  но  также  позволяет Вам использовать символические
имена хостов в ваших rc.inet скриптах. Таким образом, при изменении IP
адресов, Вы должны будите только копировать обновленный файл хостов на
все  машины,  вместо  того  чтобы  редактировать большое количество rc
файлов.  Обычно,  Вы  будете  помещать  все локальные имена и адреса в
hosts,  добавлением  их  на  любой  gateways  и  NIS сервера, если они
используется.

     Также,  в  течение  проверки,  Вы  должны удостовериться, что ваш
resolver использует информацию только из файла hosts. Ваше DNS или NIS
программное  обеспечение  может  прибыть  с  файлами примеров, которые
могут  дать  странные результаты при их использовании. Чтобы заставить
все  приложения  использовать  исключительно  /etc/hosts при поиске IP
адреса   хоста,   Вы   должны   отредактировать  файл  /etc/host.conf.
Закоментируйте  все  строки,  начинающиеся  с  ключевого слова order и
вставьте строку

   order hosts

     Конфигурация resolver библиотеки будет подробно описана в главе7.

     hosts  файл  содержит  по одной записи на строку, состоящую из IP
адреса,  имени  хоста и необязательного списка псевдонимов имени. Поля


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

     Имя  хоста  может  быть  также  полностью  квалифицированным  или
относительно  локальной  области.  Для  vale,  Вы  бы  ввели полностью
квалифицированное  имя, vale.vbrew.com и vale само по себе, так, чтобы
было известно и официальное имя и более короткое локальное.

     Пример  как  выглядит файл хостов Виртуальной Пивоварне дан ниже.
Два специальных имени , vlager-if1 и vlager-if2, дают адреса для обоих
интерфейсов используемых на vlager.



     #
     # Hosts file for Virtual Brewery/Virtual Winery
     #
     # IP            local       fully qualified domain name
     #
     127.0.0.1       localhost
     #
     191.72.1.1      vlager      vlager.vbrew.com
     191.72.1.1      vlager-if1
     191.72.1.2      vstout      vstout.vbrew.com
     191.72.1.3      vale        vale.vbrew.com
     #
     191.72.2.1      vlager-if2
     191.72.2.2      vbeaujolais  vbeaujolais.vbrew.com
     191.72.2.3      vbardolino   vbardolino.vbrew.com
     191.72.2.4      vchianti     vchianti.vbrew.com

     Точно  также  как  с IP адресами хостов, можно дать символическое
имя  сетевым номерам. Поэтому, файл хостов имеет компаньона названного
/etc/networks который отображает имя сети на сетевой номер и наоборот.
В  Виртуальной Пивоварне, мы могли бы устанавливать файл сетей подобно
этому:



     # /etc/networks for the Virtual Brewery
     brew-net      191.72.1.0
     wine-net      191.72.2.0


     6.7. Конфигурация интерфейса для IP

     После   установки   аппаратных   средств,  как  было  объяснено в
предыдущей  главе,  Вы должны дать знать об этом сетевому программному
обеспечению.  Пара  команд  используются чтобы конфигурировать сетевые
интерфейсы,  и  инициализировать  таблицу  маршрутизации.  Эти  задачи
выполняются  обычно  в  rc.inet1  скрипте,  при  загрузке системы. Эти
команды  называются  ifconfig ( где "если" относится к интерфейсу ), и
route.

     fconfig используется чтобы сделать интерфейс доступным для ядра,
что  включает  в  себя  назначение  IP  адреса  и  других параметров и
формирование  интерфейса,  также известное как "taking up". Активность
означает,  что  ядро  будет  посылать  и  получить  IP datagrams через
интерфейс. Самый простой путь установки

   # ifconfig interface ip-address

     Который  связывает  ip-адрес  с интерфейсом и активирует его. Все
другие  параметры устанавливаются по умолчанию Например, маска подсети
установленная по умолчанию получена из сетевого класса IP адреса, типа
255.255.0.0 для класса B адрес. ifconfig описан более подробно в конце
этой главы.

     route  позволяет  Вам добавлять или устранять маршруты из таблицы
маршрутизации. Это может быть использовано так

     route [add|del] target

     Где  add и del аргументы определяют добавлять или удалять маршрут
к таблице.




       6.7.1. Интерфейс loopback

     Сам  первый интерфейс который нужно сформировать и активизировать
-- интерфейс loopback:

   # ifconfig lo 127.0.0.1

     Иногда,   Вы   будете   также   видеть  фиктивное  имя  localhost
используемое  вместо  IP  адреса.  ifconfig  будет  искать имя в hosts
файле, где должна быть запись, объявляющая его как имя для 127.0.0.1:

     # Sample /etc/hosts entry for localhost localhost     127.0.0.1

     Чтобы просмотреть информацию о конфигурации интерфейса, Вы можете
вызвать ifconfig передав как аргумент имя интерфейса:


     $ ifconfig lo
     lo        Link encap Local Loopback
               inet addr 127.0.0.1  Bcast [NONE SET]  Mask 255.0.0.0
               UP BROADCAST LOOPBACK RUNNING  MTU 2000  Metric 1
               RX packets 0 errors 0 dropped 0 overrun 0
               TX packets 0 errors 0 dropped 0 overrun 0

     Как  Вы  можете видеть, интерфейс loopback получил netmask равную
255.0.0.0,  так  как  127.0.0.1  --  адрес  A  класса. Вы можете также
увидеть,  что  интерфейс  не  имеет множества общевещательных адресов,
который вообще-то бесполезны для loopback. Однако, если Вы используете
rwhod  демона  на  вашем  хосте,  Вы возможно будете должны установить
широковещательный  адрес  loopback  для того чтобы rwho функционировал
должным  образом.  Установка  этого адреса объясняется в секции "Все о
ifconfig".

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



     # route add 127.0.0.1

     Здесь, тоже можно использовать localhost вместо IP адреса.

     Затем,   Вы   должны  проверить  правильность  работы,  например,
используя  ping. ping - сетевой эквивалент звукового(sonar) устройства
и  используется  для  проверки  того  доступен  ли  данный IP адрес, и
измерения  интервала  времени  между  посылкой дэйтаграмы и получением
ответа. Время требуемое для этого часто называется roundtrip time.

     # ping localhost
     PING localhost (127.0.0.1): 56 data bytes
     64 bytes from 127.0.0.1: icmp seq=0 ttl=32 time=1 ms
     64 bytes from 127.0.0.1: icmp seq=1 ttl=32 time=0 ms
     64 bytes from 127.0.0.1: icmp seq=2 ttl=32 time=0 ms
     ^C

     --- localhost ping statistics ---
     3 packets transmitted, 3 packets received, 0% packet loss
     round-trip min/avg/max = 0/0/1 ms



     При  вызове  ping,  он  будет продолжать испускать пакеты пока не
будет прервано пользователем. ^C отмечает место где мы нажали Ctrl-C.

     Вышеупомянутый   пример   показывает,   что  пакеты  доставлены к
127.0.0.1 и ответ пришел к ping почти мгновенно. Это показывает что Вы
преуспели во введении вашего первого сетевого интерфейса.

     Если  вывод который Вы получаете от ping не походит на показанный
выше,  Вы  нарвались  на неприятности. Проверите ошибки в установочных
файлах.   Проверите  чтобы  ifconfig  и  маршрутизирующие  приложения,
которые   вы   используете,   были  совместимы  с  ядром,  которым  Вы
пользуетесь  и,  вообще,  что ядро компилировалось с разрешенной сетью
(Вы  увидите  это  по  отсутствию  директории  /proc/net  ).  Если  Вы
получаете  сообщение об ошибки, говорящее "Network unreachable" ,тогда
вероятно  вы  не  правильно использовали команду route. Удостоверитесь


что Вы используете тот же самый адрес, что Вы дали ifconfig.

     Шагов   описанных  выше  достаточно  чтобы  использовать  сетевые
приложения  на автономном хосте. После добавления вышеупомянутых строк
к rc.inet1 и проверки, что оба rc.inet скрипта запускаются из /etc/rc,
Вы   можете   перезагрузить  вашу  машину  и  попытаться  использовать
различные  приложения.  Например, "telnet localhost" должен установить
telnet соединение с вашем хостом.

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


     6.7.2. Ethernet интерфейсы

     Конфигурирование  интерфейса  Ethernet,  идет  почти  также как и
интерфейса  loopback,  он  только  требует  больше параметров когда Вы
используете подсети.

     В Виртуальной Пивоварне, мы разбивали на подсети IP сеть, которая
была  первоначально  класс B. При установке интерфейса для требовалось
бы написать:

      # ifconfig eth0 vstout netmask 255.255.255.0

     Эта   запись   назначает   eth0   интерфейсу   IP   адрес  vstout
(191.72.1.2).  Если  бы мы опустили netmask, ifconfig вывел бы netmask
из   класса  сети,  что  привело  бы  к  netmask  255.255.0.0.  Теперь
быстренько проверим:

     # ifconfig eth0
     eth0      Link encap 10Mps Ethernet HWaddr  00:00:C0:90:B3:42
               inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0
               UP BROADCAST RUNNING  MTU 1500  Metric 1
               RX packets 0 errors 0 dropped 0 overrun 0


               TX packets 0 errors 0 dropped 0 overrun 0

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

     Также   как  в  loopback  случае,  Вы  должны  теперь  установить
маршрутизационную  запись, которая сообщает ядру о сети, которая может
быть  достигнута через eth0. Для Виртуальной Пивоварни, Вы это сделали
бы так

     # route add -net 191.72.1.0

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

     Теперь,  что такое -net опция? Она используется, потому что route
может  работать  с маршрутами к сетям и с маршрутам к отдельным хостам
(как  Вы видели в localhost). Когда route получает адрес в dotted quad
стандарте, он пытается предположить принадлежит ли этот адрес сети или
хосту,  проверяя  биты  части  хоста.  Если  хост часть адреса - ноль,
маршрут предполагает, что это обозначает сеть, в противном случае, что
это адрес хоста.

     Поэтому, route решил бы, что 191.72.1.0 - адрес хоста, потому что
он  не  может  знать что мы используем подсети. Поэтому мы должны явно
сообщить, что это адрес сети, это делает -net флаг.

     Конечно, вышеупомянутая команда, немного утомительна для набора и


дает много ошибок. Более удобный подход -- использование сетевых имен,
которые  мы  определили  в /etc/networks. Это делает команду еще более
удобочитаемой;  и  даже -net флаг может быть теперь опущен, потому что
route теперь знает, что 191.72.1.0 обозначает сеть.

     # route add brew-net

     Теперь,  когда  вы  закончили  основные  шаги  конфигурации, надо
удостовериться  что  ваш  Ethernet  интерфейс  действительно  работает
правильно Выберите хост на вашем Ethernet, например vlager, и наберите

   # ping vlager
     PING vlager: 64 byte packets
     64 bytes from 191.72.1.1: icmp seq=0. time=11. ms
     64 bytes from 191.72.1.1: icmp seq=1. time=7. ms
     64 bytes from 191.72.1.1: icmp seq=2. time=12. ms
     64 bytes from 191.72.1.1: icmp seq=3. time=3. ms
     ^C

       ----vstout.vbrew.com PING Statistics----
     4 packets transmitted, 4 packets received, 0% packet loss
     round-trip (ms)  min/avg/max = 3/8/12

     Если  Вы  не  видите  вывод подобный этому, значит что-то не так.
Если  Вы сталкиваетесь с необычным количеством потерянных пакетов, это
означает  проблему аппаратных средств, типа плохого или отсутствующего
terminator,  и  т.д..  Если  Вы  не получаете пакеты вообще, Вы должны
проверить   конфигурацию   интерфейса   с  помощью  netstat.  Пакетная
статистика,  показанная  ifconfig,  должна сообщить Вам были ли вообще
посланы какие-то пакеты. Если у вас есть доступ к удаленному хосту, Вы
должны  сходить  к  той  машине и проверять там статистику интерфейса.
Таким образом, Вы можете точно решить, где пропали пакеты. Кроме того,
Вы  должны  посмотреть  маршрутизационную  информацию с помощью route,
чтобы  выяснить  имеют  ли  оба  хоста  правильные  записи  в  таблице
маршрутов.  route печатает всю таблицу маршрутизации, если его вызвать
без  аргументов(  -n  опция  указывает  печатать  вместо адресов имена
хостов):



     # route -n
     Kernel routing table
     Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
     127.0.0.1       *               255.255.255.255 UH    1      0      112 lo
     191.72.1.0      *               255.255.255.0   U     1      0       10 eth0

     Детальное  значение  этих  полей  объясняется  ниже в секции 6.9.
Колонка  Flags  содержит  список  флагов  устанавливаемых  для каждого
интерфейса.  U  -  всегда  устанавливают для активных интерфейсов, а H
сообщает,  что  адрес  места назначения обозначает хост. Если H флаг -
установлен  для маршрута, который Вы считаете сетевым маршрутом, тогда
Вы  должны использовать -net опцию с командой route. (Чтобы проверить,
используется  ли  маршрут,  который  Вы ввели, посмотрите на поле Use,
которое  находится  между  двум  сообщениями ping.) To check whether a
route  you  have entered is used at all, check if the Use field in the
second to last column increases between two invocations of ping.

     6.7.3. Маршрутизация через Gateway

     В  предыдущей  секции,  Я  охватил только случай введения хоста с
единственным  Ethernet.  Достаточно  часто,  однако, мы сталкивается с
сетями,  соединенными  с  помощью  gateway.  Этот gateway может просто
связывать  два или больше Ethernet, а может обеспечить связь с внешним
миром,  (например  с  Internet). Чтобы использовать gateway сервис, Вы
должны   обеспечить   сетевому   уровню   дополнительную  информацию о
маршрутизации.

     Например, Ethernet Виртуальной Пивоварни и Виртуальной Винодельни
связаны  через  такой  gateway, а именно хост vlager. Предположим, что
vlager  уже был отконфигурирован, и нам осталось только добавить новую
запись  в  таблицу маршрутизации vstout, которая сообщает его ядру что
он  может  достигнуть  всех  хостов  на  Сети Винодельни через vlager.
Соответствующее  описание  маршрута  показывается  ниже;  gw  ключевое
слово, которое сообщает что следующий аргумент обозначает gateway.

    # route add wine-net gw vlager

     Конечно,  любой  хост  в  сети  Винодельни,  с которым вы желаете


поговорить должен иметь соответствующую запись в таблице маршрутизации
для  Сети Пивоварни, иначе Вы были бы способны только послать данные с
vstout на vbardolino, но ответа вы не получите.

     Этот  пример  описывает только gateway который переключает пакеты
между  двумя  изолированными  Ethernet. Теперь предположите что vlager
также  имеет  соединение  с Internet ( работающее через дополнительную
SLIP  связь).  Тогда  мы  хотели  бы  чтобы дэйтаграмы для любой сети,
отличной   от   Пивоваренной,  передавались  vlager.  Это  может  быть
выполнено с помощью установки gateway по умолчанию для vstout:


 # route add default gw vlager

     Сетевое  имя default(по умолчанию) связано с адресом 0.0.0.0, что
обозначает  маршрут установленный по умолчанию. Вы не должны добавлять
это имя к /etc/networks, потому что это построено в route.

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

     6.7.4. Конфигурирование Gateway

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

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




     191.72.1.1      vlager      vlager.vbrew.com
     191.72.1.1      vlager-if1
     191.72.2.1      vlager-if2

     Последовательность команд для создания двух интерфейсов:



    # ifconfig eth0 vlager-if1
    # ifconfig eth1 vlager-if2
    # route add brew-net
    # riute add wine-net


     6.7.5. PLIP интерфейс

     При   использовании   PLIP   связи  для  соединения  двух  машин,
существуют  лишь  небольшие  отличия от того, что Вы должны делать при
использовании     Ethernet.     Вышеупомянутая     связь    называется
point-to-point(точка  с точкой) связь, потому что она соединяет только
два хоста ("точки"), в противоположность широковещательным сетям.

     Как   пример,   мы   рассматриваем  laptop  компьютер  некоторого
служащего  в  Виртуальной  Пивоварне,  который  связана с vlager через
PLIP.  Laptop  непосредственно  назван  vlite,  и  имеет  только  один
параллельный   порт.   В   о   время   загрузки,   этот   порт   будет
регистрироваться  как  plip1.  Чтобы  сформировать  связь,  Вы  должны
отконфигурировать интерфейс plip1, используя следующие команды:

     # ifconfig plip1 vlite pointopoint vlager
     # route add default gw vlager

     Первая  команда  конфигурирует  интерфейс,  сообщая ядру, что это
point-to-point связь, с удаленной машиной имеющей адрес vlager. Вторая
устанавливает  маршрут  по умолчанию, используя vlager как gateway. На
vlager,  подобная команда ifconfig необходима чтобы сформировать связь
и на vlager:



     # ifconfig plip1 vlager pointopoint vlite

     Интересно,   что  интерфейс  plip1  на  vlager  не  должен  иметь
отдельный IP адрес, но если хочется можете дать ему адрес 191.72.1.1.

     Теперь,  мы  отконфигурировали  маршрутизацию  от  laptop до Сети
Пивоварни;  что  но  все  еще отсутствует маршруту от любого из Хостов
Пивоварни  к  vlite.  Особенно  тяжелый  путь  состoит  в  том,  чтобы
добавлять  определенный маршрут к таблице маршрутизации каждого хоста,
который состоит в том чтобы объявить vlager как gateway к vlite:

     # route add vlite gw vlager

     Гораздо  лучше  иметь  дело  с  временными  маршрутами, используя
динамическую  маршрутизацию.  Один  из  способов сделать это состoит в
запуске  gated демона, который Вы должны устанавливать на каждом хосте
в  сети,  чтобы  он  распространял информацию о маршрутах динамически.
Самый  легкий  путь,  однако,  состoит в том, чтобы использовать proxy
ARP.  С proxy ARP, vlager будет отвечать на любой ARP pfпрос для vlite
посылая собственный Ethernet адрес. Результат этого то, что все пакеты
для  vlite  будут закачивать на vlager, который будет передавать их на
laptop. Мы будем возвращаться к proxy ARP в секции 6.10.

     Будущие   выпуски  Net-3  будут  содержать  инструмент  названный
plipconfig,  который  позволит  Вам  устанавливать IRQ порта принтера.
Позже, это может быть заменено более общей командой ifconfig.


     6.7.6. SLIP и PPP Интерфейсы

     Хотя  SLIP  и PPP соединения -- всего лишь простые point-to-point
связь  подобно PLIP соединениям, о них также есть некая дополнительная
информация. Обычно, при установке SLIP соединение требуется дозвонится
до    удаленного   участка   через   ваш   модем,   и   отрегулировать
последовательную  линию  для  SLIP  способа. PPP используется подобным
образом.  Инструменты  требуемые для создания SLIP или PPP связи будут
описаны в главах 8. и 9.



     6.7.7. Dummy(фиктивный) интерфейс

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

     Проблема  автономных  хостов  в  том,  что  они имеют только одно
активное  сетевое  устройство,  loopback  устройство,  которому обычно
назначен  адрес  127.0.0.1.  На в некоторых случаях, Вы должны послать
данные   к   "официальному"  IP  адресу  локального  хоста.  Например,
рассмотрите  laptop vlite, который был отъединен от сети Приложение на
vlite  может захотеть послать некоторые данные к другому приложению на
том  же  самом  хосте.  Поиск  vlite  в  /etc/hosts  выдает  IP  адрес
191.72.1.65,  таким  образом  приложение пытается послать данные этому
адресу.  Поскольку  интерфейс  loopback в настоящее время единственный
активный  интерфейс на машине, ядро не имеет никакую идей относительно
этого  адреса!  Как  следствие,  ядро  отказывается  от  дэйтаграмы, и
возвращает приложению ошибку.

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

     # ifconfig dummy vlite
      # route add vlite

      6.8. Все о ifconfig

     Имеются  еще  несколько  параметров для ifconfig, о которых мы не
писали раньше. Вот полное описание:


     ifconfig interface [[-net|-host] address [parameters]]

     interface  -  название  интерфейса,  и address - IP адрес который


требуется  назначить  для  интерфейса.  Это  может быть или IP адрес в
dotted  quad  формате  ,  или  имя,  которое  ifconfig  будет искать в
/etc/hosts  и  /etc/networks.  -net  и  -host опции вынуждают ifconfig
обращаться   с   адресом   как  сетевым  номером  или  адресом  хоста,
соответственно.

     Если   ifconfig  используется  только  с  именем  интерфейса,  он
показывает  конфигурацию  этого  интерфейса.  Когда  он вызывается без
параметров,    он    показывает    все    интерфейсы,    которые    Вы
отконфигурировали;  опция  -a вынуждает его показать и бездействующие.
Образец вывода для Ethernet интерфейса eth0 может напоминать это:

     # ifconfig eth0
     eth0      Link encap 10Mbps Ethernet  HWaddr 00:00:C0:90:B3:42
               inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0
               UP BROADCAST RUNNING  MTU 1500  Metric 0
               RX packets 3136 errors 217 dropped 7 overrun 26
               TX packets 1752 errors 25 dropped 0 overrun 0

     MTU  и  Metric поля показывают текущее MTU и метрическое значение
для  этого  интерфейса.  Метрическое значение традиционно используется
некоторыми операционными системами чтобы вычислить сложность маршрута.
Linux не использует это значение, но определяет его для совместимости.

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

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



     up    Эта опция делает интерфейс доступным для IP уровня. Эта опция
          подразумевается, когда дается IP адрес.

( Эта опция  соответствует UP RUNNING флагам)

     down Она делает интерфейс недоступным IP уровню. Она эффективно
          отключает любое IP движение через интерфейс.  Обратите Внимание, что
          она не удаляет все маршрутизационные записи, которые используют этот
          интерфейс. Если Вы постоянно выключаете некий интерфейс, Вы должны
          удалить эти записи предоставить, если возможно, альтернативные
          маршруты.

     netmask mask назначает маску подсети для использования интерфейсом.
          здесь можно давать как любой шестнадцатиричнре число с 32 битами,
          которому предшествует 0x, так и dotted quad десятичные номера.


     Pointopoint adress Эта опция используется для point-to-point IP
          соединений.  Эта опция необходима чтобы отконфигурировать, например,
          SLIP или PLIP интерфейсы.


(Если point-to-point адрес был установлен, ifconfig показывает POINTOPOINT
          флаг.)

      broadcast address широковещательный адрес обычно создается из сетевого
          номера установкой всех битов части хоста. Некоторые IP используют
          различную схему; эта опция помогает приспособиться к этим странным
          средам.

(Если broadcast address был установлен, ifconfig показывает BROADCAST флаг.)


      metric number Эта опция может использоваться для назначения метрического
          значения записи таблицы маршрутизации созданной для интерфейса. Эта
          метрика используется в RIP, для построения таблиц маршрутизации.
          Установленным по умолчанию оно равно нулю. Если Вы не используете
          RIP демона, Вы не нуждаетесь в этой опции вообще; если используете,


          Вы  редко должны будете изменять это значение.


      mtu bytes Эта опция устанавливает Maximum Transmission Unit
          (максимальную длину передаваемого пакета) Для Ethernets, MTU по
          умолчанию 1500; для SLIP интерфейсов 296.


      arp Это опция определенная для широковещательных сетей типа пакетного
          радио или Ethernet. Она позволяет использовать ARP, протокола поиска
          адреса, используемый для определения физического адреса хоста
          включенного  сеть. Для широковещательных сетей, включен по
          умолчанию.


(Если ARP не включен, ifconfig показывает флаг NOARP. )

     -arp запрещает использование ARP на этом интерфейсе.


     promisc Помещает интерфейс в promiscuous состояние. В широковещательной
          сети, это заставляет интерфейс получать все пакеты, независимо от
          того были ли они предназначены для другого хоста или нет. Это
          позволяет , используя фильтры пакетов, анализировать сетевой трафик.
          Обычно, это хорошая техника охоты на сетевые проблемы которые должны
          иначе интенсивно прибывать. С другой стороны, это позволяет врагам
          исследовать движение паролей по вашей сети и делать другие черные
          дела. Одна защита против этого типа нападения не позволять
          присоединятся к вашей сети чужим компьютерам.  Другая способ
          использовать безопасные опознавательные протоколы, типа Kerberos,
          или SRA login.  (Эта опция соответствует флагу PROMISC.)


     -promisc отказ от promiscuous способа.


     allmulti Multicast адреса -- некоторый вид широковещательных адресов
          позволяющих обращаться к группе хостов, которые не обязательно должны


          быть на той же самой подсети.  Multicast адреса еще не
          поддерживаются ядром.

( Эта опция  соответствует флагу ALLMULTI. )

    -allmulti отключает Multicast адреса.

     6.9. Проверка с помощью netstat

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

     6.9.1. Отображение таблицы маршрутизации

     При   вызове   netstat   с   -r  флагом,  он  показывает  таблицу
маршрутизации. На vstout, он выдаст:

     # netstat -nr
     Kernel routing table
     Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
     127.0.0.1       *               255.255.255.255 UH    1      0       50 lo
     191.72.1.0      *               255.255.255.0   U     1      0      478 eth0
     191.72.2.0      191.72.1.1      255.255.255.0   UGN   1      0      250 eth0

     -n  опция  заставляет  netstat печатать адреса как dotted quad IP
номера  вместо символических имен хостов и сетей. Это особенно полезно
когда  Вы  хотите  избежать поисков адреса по сети (например через DNS
или NIS сервер).

     Вторая     колонка     вывода    netstat    показывает    gateway
маршрутизационную  запись.  Если  gateway  не используется, печатается
звездочка.  Третья колонка "общность" маршрута. Когда дается IP адрес,
чтобы найти подходящий маршрут для него, ядро просматривает все записи
таблицы  маршрутизации,  берет  побитовое И адреса и genmask и лишь за
тем сравнивает результат с целью маршрута.



     Четвертая  колонка  показывает различные флаги, которые описывают
маршрут:

        G маршрут использует gateway.

        U интерфейс, который нужно использовать, работает.

        H Только отдельный хост может быть достигнут через данный маршрут.
          Например, для loopback записи 127.0.0.1.

        D устанавливается, если запись таблицы была произведена по приходу
          ICMP перенаправляемое сообщение ( см. секцию 3.5 ).

        M устанавливается, если запись таблицы была изменена ICMP
          перенапавляемым сообщением.

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

     6.9.2. Отображение статистики интерфейса

     Когда  вызывается  с -i флагом, netstat показывает статистику для
сетевых  интерфейсов.  Если,  кроме  того,  дается  -a опция, он будет
печатать все интерфейсы представленные в ядре, а не только те, которые
были отконфигурированы в настоящее время. На vstaout, вывод от netstat
будет напоминать это:

     $ netstat -i
     Kernel Interface table
     Iface   MTU Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flags
     lo        0   0   3185      0      0      0   3185      0      0      0 BLRU
     eth0   1500   0 972633     17     20    120 628711    217      0      0 BRU

     MTU  и Met поля показывают текущий MTU и метрическое значение для
этого  интерфейса.  RX  и  TX  колонки показывают сколько пакетов были


получены   или   переданы   без   ошибок   (RX-OK/TX-OK),  повредились
(RX-ERR/TXERR),  сколько было потеряно (RX-DRP/TX-DRP), и сколько было
потеряно из-за переполнения (RX-OVR/TX-OVR).

     Последняя  колонка  показывает  флаги,  установленные  для  этого
интерфейса.  Здесь  используется односимвольная версия флагов, которые
печатает ifconfig.

B  был установлен широковещательный адрес.

        L Этот интерфейс -- loopback устройство

        M интерфайс получает все пакеты ( promiscuous способ ).

        N Трейлеры избегаются.

        O ARP выключен для этого интерфейса.

        P Это - point-to-point соединение.

        R Интерфейс работает.

        U Интерфейс активен.


     6.9.3. Отображение соединений

     Netstat  поддерживает  множество опции для отображения активных и
пассивных гнезда. Опция -t, -u, -w, и -x показывают активные TCP, UDP,
RAW  ,  или UNIX гнезда. Если Вы зададите -a флаг, гнезда которые ждут
соединения  (то  есть слушают) также показываются. Это даст Вам список
всех серверов которые в настоящее время работают в вашей системе.

     Вызов netstat -ta на vlager даст:

     $ netstat -ta
     Active Internet connections
     Proto Recv-Q Send-Q Local Address    Foreign Address    (State)


     tcp        0      0 *:domain         *:*                LISTEN
     tcp        0      0 *:time           *:*                LISTEN
     tcp        0      0 *:smtp           *:*                LISTEN
     tcp        0      0 vlager:smtp      vstout:1040        ESTABLISHED
     tcp        0      0 *:telnet         *:*                LISTEN
     tcp        0      0 localhost:1046   vbardolino:telnet  ESTABLISHED
     tcp        0      0 *:chargen        *:*                LISTEN
     tcp        0      0 *:daytime        *:*                LISTEN
     tcp        0      0 *:discard        *:*                LISTEN
     tcp        0      0 *:echo           *:*                LISTEN
     tcp        0      0 *:shell          *:*                LISTEN
     tcp        0      0 *:login          *:*                LISTEN

     Видно,  что больше всего серверов просто ждут соединения. Однако,
четвертая  строка  говорит  о SMTP соединение с vstout, а шестая линия
сообщает о telnet соединение с vbardolino.

     При  использовании  -a  флага  будут отображаться все гнезда всех
семейств.


     6.10. Проверка ARP Таблицы

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

     Arp [-v] [ -t hwtype ] -a [hostname] arp [-v] [ -t hwtype ] -s hostname
     hwaddr arp [-v] -d hostname [ hostname ... ]

     hostname  аргумент  может быть как символическим именем, так и IP
адресом в dotted quad стандарте.

     Первая  строка отображает ARP запись для IP адреса или указанного
хоста  или  всех  известный хостов, если hostname не дается. Например,
вызов arp на vlager может выдать



     # arp -a
     IP address      HW type                 HW address
     191.72.1.3      10Mbps Ethernet         00:00:C0:5A:42:C1
     191.72.1.2      10Mbps Ethernet         00:00:C0:90:B3:42
     191.72.2.4      10Mbps Ethernet         00:00:C0:04:69:AA

     что показывает Ethernet адреса vlager, vstout и vale.

     При  использовании  -t  опции  Вы увидите информацию только о том
типе  аппаратных средств, который вы укажете. Это может быть ethernet,
ax25net,  или  pronet,  стоящие за 10Mbps Ethernet, AMPR AX.25, и IEEE
802.5 token ring оборудование, соответственно.

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

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

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

     -s  опция может также использоваться чтобы создать proxy ARP. Это
специальная техника когда хост, скажем gate, действует как gateway для
другого хоста назовем его fnord, делая вид что оба адреса относят тому
же  самому  хосту,  а именно gate. Это делается так: на gate создается
ARP  запись  о  fnord,  которая  указывает на его собственный Ethernet


интерфейс.  Теперь  когда хост посылает ARP запрос о fnord, gate будут
возвращать  ответ  содержащий собственный Ethernet адрес. Спрашивающий
хост будет тогда посылать все дэйтаграмы gate, который перенаправит их
к fnord.

     Эти  схема  может  быть  необходима,  например,  когда  Вы хотите
работать  с  fnord  из  DOS  машины с нестандартным TCP, которое плохо
работает  с маршрутизацией. Когда Вы используете proxy ARP, DOS машине
как  будет  казаться, что fnord находится в локальной подсети, так что
ей не требуется что-либо знать относительно маршрутов и gateway.

     Другое очень полезное приложение proxy ARP -- когда один из ваших
хостов действует как gateway к некоторому другой хост только временно,
например  по  телефону.  В  предыдущем  примере,  мы уже столкнулись с
laptop  vlite,  который  был связан с vlager через PLIP связь только в
небольшом промежутке времени. Конечно, это будет работать только, если
адрес хоста для, которого Вы хотите обеспечить proxy ARP, находится на
той  же  самой  IP подсети, что и ваш gateway. Например, vstout мог бы
быть  proxy ARP для любого хоста из подсети Пивоварни (191.72.1.0), но
никогда для хоста из подсети Винодельни (191.72.2.0).

     Требуемые  действия  для  обеспечения  proxy ARP для fnord дается
ниже; конечно, Ethernet адрес должен быть от gate.

     # arp -s fnord 00:00:c0:a1:42:e0 pub

proxy ARP запись может быть удалена снова используя:

    # arp -d fnord

     6.11. Будущее

     Linux  все  еще  развивается.  Главные  изменения в ядре принесет
очень  гибкую схему конфигурации, которая позволит Вам конфигурировать
сетевые  устройства  во время работы. Например, команда ifconfig будет
работать с аргументами, которые устанавливают IRQ линию и DMA канал.

     Другое  изменение  --  дополнительный mtu флаг для команды route,


которая   будет   устанавливать   Максимальный   размер   пакета   для
определенного маршрута. Этот маршруто-определенный MTU заменит MTU для
интерфейса.  Вы  будете  использовать  эту  опцию  для маршрутов через
gateway,  где  связь  между  gateway и хостом места назначения требует
очень  низкого  MTU. Например, предположите что хост wanderer связан с
vlager  через  SLIP  связь.  При посылке данных от vstout до wanderer,
сетевой  уровень  на  wanderer  использовал  бы пакеты до 1500 байтов,
потому  что  пакеты  посылаются  через  Ethernet. SLIP связь, с другой
стороны, используется с MTU 296, так что сетевой уровень на vlager был
бы   должен   разбивать   IP  пакеты  на  меньшие  фрагменты,  которые
вписываются  в  296  байтов.  Если вместо этого, Вы конфигурировали бы
маршрут  на  vstout  так,  чтобы  сразу  использовать  MTU  296, этого
относительно долгого разбиения можно избежать:

   # route add wanderer gw vlager mtu 296

     Обратите  Внимание  что  mtu  опция также позволяет Вам выборочно
отменить  результаты "Подсети Локальны" политики (SNARL). Эта политика
-- это опция конфигурации ядра и описана в главе 4.




     7. Названия  сервиса и конфигурация решающего устройства.

      Как уже обсуждалось в главе 3., TCP/IP сеть может полагаться  на
различные схемы, чтобы преобразовать имена  в  адреса.  Самый  простой
способ,  у которого еще нет никаких преимуществ над способом, где  все
пространство  имен было расщеплено на зоны, - таблица хостов,  сохраненная
в  /etc/hosts.  Это полезно только  для  малых  LAN,  которые  управляются
одним  единственным администратором, и не имеющих никакого IP общения с
внешним миром. Формат хост файлов был уже описан в главе 6.
      С другой стороны, Вы можете использовать  BIND  -  Berkeley  Internet
Name Domain Service - для перевода хостов в IP адреса. Конфигурация BIND
может быть настоящей хореей, но  если  только  вы  сделаете  это, то
изменения  в сетевой топологии могут быть легко измены. На Linux, как и на
многих  других Unix-подобных cистемах, обслуживание обеспечивается через
программу,  называемую named. При запуске, эта программа загружает множество
основных файлов  в  их собственный кэш, и ждет запрос от отдаленных  или
локальных пользовательских процессов. Имеющиеся способы требуют, чтобы Вы
обязательно ввели  имя  сервера  для каждого хоста.
      Эта глава делает немного больше, чем просто дает приблизительный
эскиз  того  как работает сервер. Если Вы планируете использовать BIND в
операционной  среде с более чем  малыми  LAN  и  возможно  Internet
uplink, то Вы  должны приобрести хорошую книгу по BIND, например Льюиса
Крикета  "DNS  and  BIND" (см. [GETST "liu-dns"]). Возможно Вы  захотите
проверить  примечания,  они содержатся в BIND источниках. Там также имеются
вопросы newsgroup для  DNS называемые comp.protocols.tcp-ip.domains.

      7.1 Библиотека решающих устройств.

      Когда мы говорим о " решающем устройстве ", то мы не подрузамеваем
никакого специального применения, поэтому достаточно  обратится  к
библиотеке  решающих устройств -  системе  функций,  которая  может  быть
найдена  в  стандарной библиотеке C. Центральные программы являются
gethostbyname(2) и gethostbyaddr(2),  которые  ищут  все  IP  адреса
принадлежащие  хосту,  и наоборот. Они могут быть сконфигурированы при
простом просмотре информации в хосте, при запросе ряда серверов, или при
использовании баз данных хоста NIS(а) (Network Information Service).
Другое  применение,  подобно  smail,  может включать различные драйверы для


любого из вышеперечисленного, и нуждается в особой осторожности.

      7.1.1 Файл конфигурации хоста.

      Центральный файл,  который  управляет  вашей  установкой  -
host.conf.  Он сообщает решающему устройству какой сервис использовать, и в
каком порядке.

      Опции в host.conf должны быть на отдельных строках. Области могут
быть отделены пустым пространством (spaces или tabs). Знак (#) вводит
строку, которая простирается вплоть до следующей строки.

      Доступны следующие опции:

      Order:   Эта опция определяет порядок в котором  перебераются  все
               доступные услуги. Valid опция -  связывает  запроса  сервера и
               поиск  хостов  в /etc/hosts, и nis для  NIS  поисков.  Любая
               или  все  из  них  могут  быть определены. Порядок, в которым
               они появляются на строках определяет порядок в котором будут
               перебираться определенные услуги.

      Multi:   Она может использоваться как опция. Эта опция  определяет,
               разрешено ли хосту в /etc/hosts иметь несколько IP адресов,
               которые обычно пазываются "multi - homed". Этот флаг не
               действует на DNS или NIS запросы.

      Nospoof: Как уже было объяснено в предыдущей главе, DNS позволяет Вам
               найти имя хоста принадлежащего IP адресу, используя inaddr.arpa
               область. Попытки серверов  поддержать  ложное  имя  хоста
               называется   "spoofing".Чтобы обезопасить себя от этого,
               решающее устройство может  быть сконфигурировано на
               проверку,  является  ли  настоящий  IP  адрес фактически
               связанным   с полученным именем хоста. Если нет, то этому имени
               будет  отказано  и  будет возвращен код ошибки. Это поведение
               зависит от того включен ли nospoof.

      Alert:   Эта  опция  может  использоваться  как  аргумент.  Если  эта
               опция включена, то любые попытки spoof (см. выше)  будут


               причинами того, чтобы  решающее устройство отправило бы
               сообщение к syslog оборудованию.

      Trim:    Эта опция берет имя области как аргумент, которое  будет
               удалено из имени хоста перед поиском. Это полезно для
               информационных элементов, где Вы могли бы только желать точно
               определить имя хоста с локальной областью. При поиски хоста с
               именем  локальной  области,  будет  удалено имя  этой области,
               таким образом легко осуществить поиск в /etc/hosts.

      Опция Trim позволяет  рассматривать  Ваш хост локальным для нескольких
областей.



      Типовой файл для vlager описывается ниже:

                 # /etc/host.conf
                 # We have named running, but no NIS (yet)
                 order   bind hosts
                 # Allow multiple addrs
                 multi   on
                 # Guard against spoof attempts
                 nospoof on
                 # Trim local dooain"(not really necessary).
                 trim    vbrew.com.

      7.1.2 Параметры среды окружения решающего устройства.

      Установки из файла host.conf могут быть отменены, используя ряд
параметров среды окружения. Они следующие:

      RESOLV  HOST  CONF.  Он  определяет  файл,  который  будет  считан
вместо /etc/host.conf.

      RESOLV SERV ORDER Отменяет order опцию, данную в host.conf.  Услуги,
данные как хосты, bind, и  nis,  отделенны  пробелом,  запятой,
двоеточием,  или точкой с запятой.



      RESOLV SPOOF CHECK Определяет критерии, принимаемые  против
spoofing.  Эта установка полностью отключается опцией off. Значения
предупреждают  spoof проверку , но включают  и  выключают  logging,
соответсвенно.  Значение  * включает spoof проверку, но оставляет logging
как определено в host.conf.

      RESOLV MULTI Эта среда окружения ( может быть вкл. или выкл.), может
быть  использована для отключения multi опции из tt host.conf.

      RESOLV OVERRIDE TRIM DOMAINS Эта среда  окружения  определяет  список
trim области, который отключает те, что даны в host.conf.

      RESOLV ADD TRIM DOMAINS Эта среда окружения определяет список trim
области, который добавляется в host.conf.



      7.1.3 Конфигурирование сервера поиска --- resolv.conf

      При  конфигурировании  библиотеки  решающего  устройства,
для  того  чтобы  использовать  BIND  обслуживание  для  поиска
хостов,  вы  обязательно  должны сообщить, какое имя сервера вы
используете. Существует отдельный файл, предназначенный специально для
этого, называемый resolv.conf. Если  этот  файл  не  существует  или  пуст,
то решающее устройство примет имя сервера, определенного для вашего
локального хоста.Если Вы запускаете сервер на  Вашем локальном хосте, то Вы
должны  установить  это имя отдельно, как это сделать, будет объяснено
позже в следующем разделе.  Если в локальпой уети есть  возможность
использовать  существующее  имя сервера, то этому должно отдаваться
предпочтение.
      Самая важная  опция  в  resolv.conf - nameserver,  которая
дает  IP  адрес  используемого сервера. Если Вы  определите  несколько
имен серверов используя nameserver опцию несколько раз, то они будут
проверяться в данном порядке. Поэтому Вы  должны  поместить  наиболее
надежный  сервер первым. Постоянно, могут поддерживаться не более трех
серверов.
      Если опция nameserver не дана, то решающее устройство попытается


соединиться с сервером на локальном хосте.
      Две других опции, domain и search  имеют  дело  с  заданными  по
умолчанию областями, которые беруться из имени хоста, если BIND не может
решить это с первого запроса. Опция search определяет список  названий
областей, которые необходимо проверить. Пункты списка отделены пробелом или
табуляцией.
      Если опция search не дана, то заданный по умолчанию список
поиска создается из локального имени области, используя само название
области непосредственно, плюс все родительские области вплоть до root.
Локальное название области может быть дано при использовании оператора
области; если ни  один из них  не  дан, то решающее устройство получит его
через getdomainname(2) системный вызов.

      Если это уж слишком для вас, рассмотрите пример resolv.conf
файла  для Virtual Brewery:

                 # /etc/resolv.conf
                 # Our domain
                 domain         vbrew.com
                 #
                 # We use vlager as central nameserver:
                 nameserver     191.72.1.1



      При определении имени vale, решающее устройство искало бы его и
в случае неудачи, vale.vbrew.com, и vale.com.

      7.1.4 Ошибкоустойчивость решающего устройства.

      Если  Вы  запускаете LAN внутри большей сети, Вы непременно должны
использовать центральные сервера, если  они  доступны.  Преимущество  этого
состоит в том, что они  разработают  богатые  кэши,  так  как  все  запросы
направлены к ним. Эта схема имеет недостаток: когда сгорел базовый кабель в
нашем университете при пожаре,  невозможно  было  дальше  работать  на  LAN
нашего отдела, потому что решающее устройство не могло достичь  какого-либо
из серверов. Не было login на X-terminals, не было печати на  принтерах, и
т.д.


      Хотя это не гоже для университетского городка, опускаться до пожаров,
каждый  обязан  соблюдать  технику  безопаности,  чтобы  избежать случаев
подобных этим.
      One - устанавливает локальный сервер, который определяет hostnames из
вашей локальной области, и делает вперед  все  запросы  для  других
hostnames  к главным серверам. Конечно, это применимо только тогда, когда
Вы используете вашу собственную область.
      В качестве альтернативы, Вы можете  сохранить  таблицу
сохраненных  хостов Вашей области или LAN в /etc/hosts. В /etc/host.conf Вы
можете  включить "order bind hosts" для того, чтобы решающее устройство
вернулась бы к хост файлу, если центральный сервер ослабел или вышел из
строя.

                            7.2 Запуск named.

      Программа, которая обеспечивает обслуживание имени области на
большинстве Unix машин обычно называется named. Эта программа
первоначально  разработанна  для  BSD  обеспечения клиентуры, и ,возможно,
для  других  серверов.  Эта  версия  в настоящее время используется на
большинстве Linux  инсталяционных  пакетов, как мне кажеться это BIND-
4.8.3. Новая версия, BIND-4.9.3, тестируется бетой в этот момент, и должна
быть скоро доступна на Linux.
      Этот раздел требует некоторого понимания как работает Domain
Name  System. Если следующее изложение будет  не  совсем  Вам  понятно,  то
Вам  следует перечитать главу 3., которая имеет более подробную  информацию
по  основам DNS.



      Named обычно запускается при начальной загрузке сичтемы,  и  работает
пока машина вновь не перезагрузится. Она черпает информацию из
конфигурационного файла называемого /etc/named.boot, и из различных файлов,
которые  содержат набор данных имен областей адресов. Далее они будут
называться  zone files. Форматы и семантика этих файлов будут объяснены в
следующем разделе.
      Для запуска named, просто введите в командной строке:

      # /usr/sbin/named



      Появится named, читает  named.boot  файл  и  zone  file,
установленные  там. Он  записывает    идентичность    процесса    id    к
/var/run/named.pid в  ASCII,  выгружая любые  zone  files  из  основных
серверов, в случае необходимости запускает  listening  на  порт  53  для
запросов DNS. (1)

                       7.2.1 Файл named.boot.

      Файл named.boot в основном очень мал и содержит еще немного
информации,  но содержит  указатели на главные файлы, содержащие zone
информацию, и указатели к другим серверам. Комментарии в файле начальной
загрузки  начинаются  с  точки  с  запятой  и простираются вплоть до
следующей линии. Прежде, чем мы обсудим  формат  named.boot файла более
подробно, мы рассмотрим типовой файл для vlager  представленный на рисунке
7.2.1. (2)

      Кэш и основные команды, показанные в этом примере  загружают
информацию  в named. Эта информация берется из главного файла,
определенного  во  втором аргументе. Он  содержат  текстовые  представления
DNS  источника  записи, которые мы рассмотрим ниже.

      1. Имеются различные named  binaries  касающиеся  Linux  FTP  sites,
каждые из которых не намного, но  отличаются  друг  от  друга.  Некоторые
имеют свой собственный pid файл, некоторые хранят его в /tmp или /var/tmp.
      2. Заметьте, что имена областей в этом примере даны без конечной
точки. Более ранние версии named принимают конечные точки в named.boot за
ошибку, и их отбрасывают. BIND-4.9.3, как уже упоминалось, устраняет это.



      ;
      ; /etc/named.boot file for vlager.vbrew.com
      ;
      directory     /var/named
      ;
      ;             domain                   file
      ;---------------------------------------------------


      cache         .                        named.ca
      primary       vbrew.com                named.hosts
      primary       0.0.127.in-addr.arpa     named.local
      primary       72.191.in-addr.arpa      named.rev

                     Рисунок 9. Named.boot файл для vlager.

      В этом примере, мы сконфигурировали named  как  основной  сервер  для
трех областей, как обозначено основными операторами в  конце  файла.
Первая  из этих строк, например, инструктирует named действовать как
основной  сервер для vbrew.com, принимая zone данные из файла  named.hosts.
Ключевое  слово каталога сообщает ему, что все zone files размещаются в
/var/named.

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

      Также  имеется  список  наиболее  важных  опций, которые   Вы
можете
      использовать named.boot:

      directory - определяет директорию, в которой zone files постоянно
находятся. Имена файлов  могут  быть  даны  относительно  этой
директории.Несколько  директорий  могут  быть  определены    неоднократно
используя directory. Согласно стандарту Linux filesystem, эта директория
должна быть /var/named.

      primary  - берет  имя  области  и  имя  файла  как  аргумент,
объявленный  локальным  сервером  авторитарно  для  named  области. Как
основной сервер, named загружает zone информацию из данного главного файла.



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



      secondary  - берет имя области, список адресов, и имя файла как
аргумент. Он объявляет локальный сервер вторичным главным сервером для
установленной области.Вторичный сервер задерживает авторитарные данные
поступающие  на  область, но он не собирает их из файла, и пробует
загрузить их  из  основного сервера. IP адрес, по крайней мере одного
основного  сервера,  должен  быть дан named(у) в списке адресов. Локальный
сервер войдет в контакт  с  каждым из них, пока он успешно не перенесет всю
зональную базу данных,  которая  затем будет сохранена в файле с резервной
копией,  данной  как  третий  аргумент. Если  ни  один  из  основных
серверов  не  отвечает,то  зональные   данные восстановятся из файла с
резервной копией взамен.named затем пытается обновить зональные данные  в
постоянные  интервалы. Это объясняется ниже с SOA типом записи.

      cache -Эта опция берет область и имя файла как аргументы. Этот файл
содержит подсказки сервера hints, который является списком  записей,
указывающих  на серверы. Но только NS и А записи будут признаны. Аргумент
области, в основном ,- источник имени области.Эта очень важно: если кэш
оператор не  пояляется в boot-файле, named не начинает  разрабатывать
локальный  кэш  вообще.  Это  строго ухудшит характеристику и увеличит
сетевую загрузку,  если  следующий  сервер делает запрос не на локальную
сеть. Кроме того,  named  не  будет  способен достичь всех серверов, и
таким образом это не  решит  проблему  адресов  за исключением тех, которые
авторитарны. Исключение из  этого  правила  -  это когда используются
серверы пересылки  (опция  механизмов  продвижения  дана ниже).

      forwarders -Этот оператор берет список адреса как аргумент.  IP
адреса в этом списке точно определяют список серверов, на  которые  named
может  сделать запрос, решается ли запрос из его локального  кэша.  Они
тестируются  по порядку, пока один из них не отвечает на запрос.

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





      Имеются две опции, которые мы не будем описывать здесь, это sortlist
и  domain.  Дополнительно,  имеются   две    директивы,    которые    могут
использоваться внутри zone файлов базы данных. Это -  $INCLUDE  и  $ORIGIN.
Так как они редко когда понадобятся, то мы не будем описывать их здесь.

      7.2.2 DNS файл базы данных.

      Основной файл включаемый named, подобно named.hosts, всегда  имеет
область соединенную с ним,  которая  называется  origin.  Это  -  область
название которой определено с кэшем и с основными командами. Внутри
основного  файла Вам  дозволено  определить  область  и  имена  хостов
относительно  этой области. Имя, данное в файле конфигурации, считается
абсолютным,  если оно  заканчивается  в  единственной  точке,  иначе   она
будет   рассматривается относительно origin. Весь оrigin может быть
упомянут, если Вы используете "@".

      Все данные, содержащиеся в основном файле определены в источнике
записей, или Rrs(resource records) для краткости. Они составляют самую
малую единицу информации доступную через DNS. Каждый способ  записи  имеет
тип.  Запись, например отображение имени хоста к IP адресу, и CNAME запись
ассоциируется с псевдонимом для хоста с его официальным именем. Например,
посмотрите на рисунок 7.2.3 на странице 116, которая показывает named.hosts
основной файл для virtual brewery.

      Способ записи в  основых  файлах  является  общим  форматом:

      [domain] [ttl] [class] type rdata

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

      domain Это имя области в которой появляется запись. Если  имя
области не дано, RR попытается обратиться к области из предыдущего RR.

      ttl Необходим для того чтобы заставить решающие устройства


отбрасывать информацию после определенного промежутка времени, каждый RR
ассоциируется с "time to live'',  или  ttl для краткости. Поле ttl
определяет время в секундах.



      information имеет силу после того, как она была найдено на  сервере.
Это - десятичное число с восемью разрядами.

      Если ttl значение не дано, то  будет  использоваться значение по
умолчанию  к значению минимального поля предшествующей SOA записи.

      class Это - класс адреса, подобно IN для IP адресов, или HS для
объекта  в Hesoid классе. Для TCP/IP сетей, Вам необходимо сделать это IN.
Если никакой класс поля не дан,то будет принят класс предшествующего RR.

      type Это описывает тип  RR.  Наиболее  общие  типы:  A,  SOA,  PTR,
и  NS. Следующие разделы описывают различные типы RR.

      rdata Это задерживает данные связанные с RR. Формат этого поля
зависит  от типа RR. Ниже, это будет описано для каждого RR поотдельности.

      following - незавершенный список RR,  который  нужно  использовать  в
DNS основном  файле.  Имеется  несколько  пар  из  них,  которые  мы  не
будем объяснять. Они  являются   экспериментальными, и вообще, небольшого
использования.

      SOA

      Это описывает зону власти  (SOA  означает  "  Start  of
Authority'').  Он сообщает что запись следующая за  SOA RR содержите
авторитарную информацию  для области.  Каждый  основной  файл,  включенный
основным  оператором  должен содержать SOA запись для этой зоны.  Источники
данных  содержат  следующиз поля:

      origin Это - каноническое имя хоста основного сервера для этой
области. Обычно дается как абсолютное имя.





      contact Это - email адрес человека ответственного за  поддержания
области, со знаком "@" в качестве точки.  Например,  если  ответственный в
Virtual Brewery - janet, то тогда это поле содержало бы janet.vbrew.com.

      serial Это - номер версии зонального  файла,  выраженный  как
единственное десятичное число. Всякий раз, когда данные меняются в
зональном  файле,  то это число должно быть увеличено.

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

      refresh Определяет  интервал,  в  секундах,  который  вторичные
серверы должны использовать между проверками SOA записей основного сервера.
Это - десятичный номер более чем с восемью разрядами.

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

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

      expire - определяет  время  в  секундах  после  которого  сервер
должен наконец-то отбросить все зональные данные, если невозможно  было
войти  в контакт с основным сервером. Этот промежуток времени в основном
должен быть очень большим. Craig Hunt (GETS "hunt - tcpip"]) рекомендует 42
дня.



      minimum - задает по  умолчанию  ttl  значение  для  исходных
записей, которые точно  не  определяют  его. Требует  другого  сервера,
чтобы отбросить RR при проверки после определенного кол-ва времени.



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

      minimum должен быть большим  значением,  особенно  для  LANs,  где
сетевая топология почти никогда не меняется. Значение в неделю или в месяц.
В случае, когда единственные Rrs могут часто изменяться, то Вы все еще
можете приписывать им различные ttl.

      A

      Ассоциирует IP адрес с hostname. Источник полей данных содержит адрес
в dotted quad notation.

      Для каждого хоста должна быть только одна запись. Hostname
используемый  в этой А записи рассматривается  служебным  или  каноническим
hostname.  Все другие hostnames - псевдонимы и должны  быть  отображены  на
каноническом hostname используя CNAME запись.

      NS

      Указывает на главный сервер подчиненной зоны.  Для  объяснения,
почему, каждый должен иметь NS  запись,  просмотрите  раздел  3.6.
Источник  полей данных содержит hostname сервера. Можно разрешить
дополнительный hostname к A записи, так называемый glue, которая  дает  IP
адрес сервера.

      CNAME

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



      PTR



      Этот тип записи используется, для того, чтобы  соединить  имя  в
Addr.arpa области с hostnaoes. Это используется для обратного отображения
IP  адресов к hostnames. Данный hostname должен быть каноническим hostname.

      MX

      Эта RR объявляет преобразователь почты для области.  Для  чего  надо
иметь преобразователи почты, обсуждено в разделе 14.4.1 в главе 14..
Синтаксис MX записи следующий:

      [domain] [ttl] [class] MX preference host

      host объявляет преобразователь почты для  области.  Каждый
преобразователь почты предпочитает целое число, связанное с этим хостом.
Агент переноса почты, то кто желает доставить почту к области, будет
перебирать все  хосты,  не  имеющие  MX записей в  этой  области,  пока
все  не  пойдет  успешно.  Сначала  будет пробоваться тот хост, у которого
самое низкое число, а дальше  все  хосты  с числом по возрастанию (это
число называется-preference value).

      HINFO Эта запись предоставляет информацию относительно  аппаратных
средств системы и программного обеспечения. Синтаксис этой записи:

      [domain] [ttl] [class] HINFO hardware software

      Аппаратная область идентифицирует аппаратные  средства,  используемые
этим хостом. Имеются специальные соглашения, чтобы точно определить  ее.
Список подходящих имен дан в "Assigned Numbers'' (RFС 1340). Если область
содержит пробелы, то это надо заключить  в  двойные  кавычки.  Имена
областей программного обеспечения  используються  операционной  системой.
И  снова, подходящее имя может быть выбрано из "Assigned Numbers'' RFC.

      7.2.3 Запись главных файлов.



      Рисунки 7.2.3, 7.2.3, 7.2.3, и 7.2.3  дают  примерные  файлы  для
названия сервера в brewery, размещенном на vlager. Вследствие характера
обсуждаемой сети  (единственная  локальная  вычислительная  сеть),  пример
-  довольно простой. Если ваши требования чересчур сложны, и  Вы  не
можете  запустить named, то вам поможет "DNS and BIND'' by Cricket Liu  and
Paul  Albitz  ([GETST "liu-dns"]).

                  &   "

      Кэш файл named.ca, который вы увидите на рисунке 7.2.3,  показывает
пример hint записи для root name сервера. Типичный кеш файл обычно
описывает около дюжины серверов, или около того. Вы можете получить текущий
список серверов для root области, используя nslookup, описанный ближе к
концу этой главы.(3)

              ;
              ; /var/named/named.ca          Cache file for the brewery.
              ;                We're not on the Internet, so we don't need
              ;                any root servers. To activate these
              ;                records, remove the semicolons.
              ;
              ; .                99999999   IN    NS  NS.NIC.DDN.MIL
              ; NS.NIC.DDN.MIL   99999999   IN    A   26.3.0.103
              ; .                99999999   IN    NS  NS.NASA.GOV
              ; NS.NASA.GOV      99999999   IN    A   128.102.16.10

                           Рисунок 10. Файл named.ca.

      7.2.4 Проверка установки сервера(Name Server Setup).

      3. Заметьте, что Вы не  сможете  сделать  запрос  для Вашего  сервера
на  root серверы,  если Вы не имеете какие-нибудь root server  hints:
Захватите  22! Чтобы выйти из этой дилеммы, Вы можете также попробовать
заставите nslookup использовать другой сервер, или Вы можете использовать
примерный  файл  на рисунке 7.2.3, и затем получить полный список
подходящих серверов.





            ;
            ; /var/named/named.hosts       Local hosts at the brewery
            ;                               Origin is vbrew.com
            ;
            @                   IN  SOA   vlager.vbrew.com. (
                                          janet.vbrew.com.
                                          16         ; serial
                                          86400      ; refresh: once per
day
                                          3600       ; retry:   ong howr
                                          3600000    ; expire:  42 days
                                          604800     ; minimum: 1 week
                                          )
                                IN  NS    vlager.vbrew.com.
            ;
            ; local mail is distributed on vlager
                                IN  MX    10 vlager
            ;
            ; loopback address
            localhost.          IN  A     127.0.0.1
            ; brewery Ethernet
            vlager              IN  A     191.72.1.1
            vlager-if1          IN  CNAME vlager
            ; vlager is also news server
            news                IN  CNAME vlager
            vstout              IN  A     191.72.1.2
            vale                IN  A     191.72.1.3
            ; winery Ethernet
            vlager-if2          IN  A     191.72.2.1
            vbardolino          IN  A     191.72.2.2
            vchianti            IN  A     191.72.2.3
            vbeaujolais         IN  A     191.72.2.4

                          Рисунок 11. Файл named.hosts.

      Существует  прекрасное  средство  для  проверки  действия установки


Вашего сервера(server setup). Оно называется nslookup, и может быть
использовано и в интерактивном режиме и из командной строки. В последнем
случае, Вы просто вызываете ее как

      nslookup hostname

      и она сделает запрос на сервер, определенный в resolv.conf,  для
hostname. (Если эти имена файла больше чем один сервер, nslookup выберет
какой-нибудь один)



             ;
             ; /var/named/named.local       Reverse mapping of 127.0.0
             ;                               Origin is 0.0.127.in-
addr.arpa.
             ;
             @                   IN  SOA   vlager.vbrew.com. (
                                           joe.vbrew.com.
                                           1          ; serial
            "   "                          360000     ; refresh: 100 hrs
                                           3600       ; retry:   one hour
                                           3600000    ; expire:  42 days
                                         ; minimum: 100 hrs
                                           )
                                 IN  NS    vlager.vbrew.com.
             1                   IN  PTR   localhost.

                          Рисунок 12. Файл named.local.

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

      Когда он вызывается без аргумента, nslookup отобразит  название
используемого сервера, и вступить в интерактивный режим. В " > "
приглашении(prompt),  Вы можете ввести любое имя для которого должен  быть
сделан  запрос.  По умолчанию, он опросит класс A записи,  содержащий  IP


адреса  в  отношении названия области.

      Вы можете изменить этот  тип,  используя  "set  type=type",  где
type(тип) является одним из исходных названий записи, описанных выше в
разделе  7.2, или ANY.

      Например, у Вас мог бы получиться следующий диалог:



            ;
            ; /var/named/named.rev         Reverse mapping of our IP
addresses
            ;                               Origin is 72.191.in-addr.arpa.
            ;
            @                   IN  SOA   vlager.vbrew.com. (
                                          joe.vbrew.com.
                                          16         ; serial
                                          86400      ; refresh: once per
day
                                          3600       ; retry:   one hour
                                          3600000    ; expire:  42 days
                                          604800     ; minimum; 1 week
                                          )
                                IN  NS    vlager.vbrew.com.
            ; brewery
            1.1                 IN  PTR   vlager.vbrew.com.
            2.1                 IN  PTR   vstout.vbrew.com.
            3.1                 IN  PTR   vale.vbrew.com.
            ; winery
            1.2                 IN  PTR   vlager-if1.vbrew.com.
            2.2                 IN  PTR   vbardolino.vbrew.com.
            3.2                 IN  PTR   vchianti.vbrew.com.
            4.2                 IN  PTR   vbeaujolais.vbrew.com.

                           Рисунок 13. Файл named.rev.




      $ nslookup
                 Default Name Server:  rs10.hrz.th-darmstadt.de
                 Address:  130.83.56.60

                 > sunsite.unc.edu
                 Name Server:  rs10.hrz.th-darmstadt.de
                 Address:  130.83.56.60

                 Non-authoritative answer:
                 Name:    sunsite.unc.edu
                 Address:  152.2.22.81


      Если Вы попробуете  сделать  запрос  на  имя,  которое  не  имеет
никакого связанного IP адреса, но другие записи были  найдены  в  DNS  базе
данных, то nslookup сообщит об ошибке: "No type A records found''. Однако,
Вы  можете заставить сделать запрос для записей других типов (не А), введя
"set  type" команду. Например, чтобы получить SOA запись unc.edu, Вы бы
ввели:



      > unc.edu
                 *** No address (A) records available for unc.edu
                 Name Server:  rs10.hrz.th-darmstadt.de
                 Address:  130.83.56.60

                 > set type=SOA
                 > unc.edu
                 Name Server:  rs10.hrz.th-darmstadt.de
                 Address:  130.83.56.60

                 Non-authoritative answer:
                 unc.edu
                         origin = ns.unc.edu
                      &  mcil addr = shava.ns.unc.edu
                         serial = 930408
                         refresh = 28800 (8 hours)


                         retry   = 3600 (1 hour)
                         expire  = 1209600 (14 days)
                         minimum ttl = 86400 (1 day)

                 Authoritative answers can be found from:
                 UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
                 SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

      Таким образом Вы можете сделать запрос для MX записей, и т.д.
Использование типа ANY вернет все исходные записи, связанные с данным
именем.

      > set type=MX
                 > unc.edu
                 Non-authoritative answer:
                 unc.edu preference = 10, mail exchanger =
lambada.oit.unc.edu
                 lambada.oit.unc.edu     internet address = 152.2.22.80

                 Authoritative answers can be found from:
                 UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
                 SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

      Практическое применение nslookup, помимо отладки, - получить текущий
список root серверов для файла named.ca. Вы можете  сделать  это,
запрашивая  все типы NS записей, связанные с root областью:



                 > set typ=NS
                 > .
                 Name Server:  fb0430.mathematik.th-darmstadt.de
                 Address:  130.83.2.30

                 Non-authoritative answer:
                 (root)  nameserver = NS.INTERNIC.NET
                 (root)  nameserver = AOS.ARL.ARMY.MIL
                 (root)  nameserver = C.NYSER.NET


                 (root)  nameserver = TERP.UMD.EDU
                 (root)  nameserver = NS.NASA.GOV
                 (root)  nameserver = NIC.NORDU.NET
                 (root)  nameserver = NS.NIC.DDN.MIL

                 Authoritative answers can be found from:
                 (root)  nameserver = NS.INTERNIC.NET
                 (root)  nameserver = AOS.ARL.ARMY.MIL
                 (root)  nameserver = C.NYSER.NET
                 (root)  nameserver = TERP.UMD.EDU
                 (root)  nameserver = NS.NASA.GOV
                 (root)  nameserver = NIC.NORDU.NET
                 (root)  nameserver = NS.NIC.DDN.MIL
                 NS.INTERNIC.NET internet address = 198.41.0.4
                 AOS.ARL.ARMY.MIL        internet address = 128.63.4.82
                 AOS.ARL.ARMY.MIL        internet address = 192.5.25.82
                 AOS.ARL.ARMY.MIL        internet address = 26.3.0.29
                 C.NYSER.NET     internet address = 192.33.4.12
                 TERP.UMD.EDU    internet address = 128.8.10.90
                 NS.NASA.GOV     internet address = 128.102.16.10
                 NS.NASA.GOV     internet address = 192.52.195.10
                 NS.NASA.GOV     internet address = 45.13.10.121
                 NIC.NORDU.NET   internet address = 192.36.148.17
                 NS.NIC.DDN.MIL  internet address = 192.112.36.4

      Полная система команд, доступных с nslookup может быть  получена  при
использовании команды help изнутри nslookup.

      7.2.5 Другие полезные инструментальные средства

      Имеется несколько инструментальных средств, которые помогут  Вам  с
Вашими задачами как BIND администратор. Я кратко опишу два из  них.
Пожалуйста  обратитесь к документации, которая  прилагается  с  этими
инструментальными средствами для выяснения того, как их использовать.



      hostcvt - средство,  которое  помогает  Вам  с   Вашей    начальной


BIND конфигурации, преобразовывая ваш /etc/hosts файл в главный файл  для
named. Оно генерирует оба и прямое (A) и обратное отбражение (PTR), и
заботится  о псевдонимах и т.п.  Конечно,  оно  не  будет  делать  всю
работу  за  Вас, поскольку Вы можете все еще захотеть настроить значения
блокировки по втемепи в SOA записи сами, например, или прибавить MX запись
и т.п. Но оно может  помочь сохранить Вам несколько таблеток аспирина.
Hostcvt - часть BIND  источника, но может также быть использован как
автономный пакет на несколько Linux FTP серверах.

      После установки  вашего  сервера,  Вы  можт  быть  захотите
проверить  Вашу конфигурацию. Идеальным (и, по  моему  мнению  тоже)
средством  для  этого является dnswalk, perl-based пакет который
прогуливается по вашей DNS  базе данных, выискивая  общие  ошибки  и
проверяет  совместимость  информации. Dnswalk был выпущен на
comp.sources.misc недавно, и должен быть доступен на всех FTP, которые
архивируют эту группу.



      8. Последовательная линия IP

      Порядковые  протоколы  линии  связи,  SLIP  и  PPP,  обеспечивают
Internet connectivity  для  плохой  связи.  Кроме    модема    и
последовательной оборудованной панели с FIFO буфером, никакие аппаратные
средства не  нужны. Использование его - не намного усложняется чем
использование mailbox, и поэтому  увеличивается число частных организаций,
которые предлагают  телефонный  вызов  по  номеру  IP  за доступную
стоимость каждому.

      Имеются оба драйвера доступные для Linux-  SLIP  и  PPP.  SLIP  был
там  в течение долгого времени, и работает достаточно  неплохо.  А PPP
драйвер  был разработан совсем недавно MIchael Callahan  и  Al  Longyear.
Этот  драйвер  будет описан в следующей главе.

      8.1 Общие требования.

      Для того, чтобы использовать  SLIP  или  PPP,  Вы  должны
сконфигурировать некоторую базисную работу  с  сетями,  как  описано  в


предыдущих  главах. Наконец Вы должны установить  looback  interface,  и
обеспечить  для  name resolution. При соединении с Internet, Вы несомненно
пожелаете использовать DNS. Самая  простая  опция  -  поместит  адрес
сервера  в  Ваш resolv.conf файл; этот сервер сделает запрос как только
SLIP  связь  будет активизированна.

      Однако, это решение не оптимально, потому что все поиски имен будут
все еще проходить через вашу SLIP/PPP связь. Если Вы волнуетесь
относительно ширины зоны, которую она требует, то Вы может также установить
cache-only сервер. Он действительно не обслуживающий, он только действует
как  переключатель  для всех DNS запросов, произведенных на Вашем хосте.
Преимущество этой схемы  - то, что она создает  кэш,  так,  чтобы
большинство  запросов  должны  быть посланы через последовательные линии
только один раз. Named.boot файл  для cache-only серверов, выглядит так:

      ; named.boot file for caching-only server
                 directory                            /var/named

                 primary       0.0.127.in-addr.arpa   db.127.0.0 ; loopback
net
                 cache         .                      db.cache   ; root
servers

      В дополнение к этому файлу, Вы также должны установить



      db.cache файл с подходящим списком root серверов. Это описывается
ближе  к концу главы "Конфигурация решающего устройства".

      8.2 SLIP Операция.

      Телефонный вызов IP  серверов  часто  предлагает  SLIP  обслуживание
через специальные пользовательские account(ы). После login в такой account,
Вы не входите в общую оболочку; взамен программа или script оболочки -
отключат SLIP  драйвер  серверов    последовательной    линии    и
сконфигурируют соответствующий сетевой interface. Затем Вы должны  сделать
тоже  самое  в конце связи.



      На некоторых операционных системах, SLIP драйвер --  user-space
программа; под Linux, это - часть  ядра,  которая  делает  его  намного
быстрее. Требуется, однако, чтобы порядковая линия явно была бы
преобразована  в  SLIP режим. Это выполнено посредством tty line
discipline,  SLIPDISC.  Пока  tty находится в обычной line discipline
(DISC0),  изменятся  данные  только  с процессвми пользователя, используя
normal read (2) и write(2) вызовы,  SLIP драйвер -  отключен  для  записи
или  чтения  из  tty,  пока  все  данные, поступающие на серейный порт,
будут пропущены SLIP драйвером.

      SLIP  драйвер  непосредственно  понимает  число  разновидностей  на
SLIP протоколе.  Кроме  обычного  SLIP,  он  также  понимает   CSLIP,
который выполняется так называемым Van Jacobson header compression на
выходящих  IP блоков.(1) Дополнительно, имеются шести-битовые версии для
каждого из  этих протоколов.

      Простой способ преобразовать последовательную линию  в  SLIP  режим
-  использовать slattach. Допустим, что у Вас есть модем на  /dev/cua3,  и
Вы удачно подсоеденились на SLIP сервер. Вы затем бы выполнили:

      #slattach /dev/cua3 &

      Это включит line discipline cua3 к SLIPDISC, и подсоединит ее к
одному  из interface SLIP сети. Если это ваша первая активная SLIP связь,
то линия  будет подсоединена к sl0; вторая была бы подсоединенп к sl1, и
так далее.  Текущие ядра поддерживают до восьми одновременных SLIP связей.

      1. Van Jacobson header compression описан в RFC 1441.



      Заданное по умолчанию оформление пакета, выбранное  slattach  -
CSLIP.  Вы можете выбрать любой другой режим, используя -p  переключатель.
Для  того, чтобы использовать normal SLIP (no compression), Вы должны
использовать

      # slattach -p slip /dev/cua3 &



      Другие режимы - cslip, slip6, cslip6 (для шести-битовой версии
Slip(а)),  и adaptive для адаптивного SLIP. Последние  оставляют  это  для
ядра,  чтобы выяснить, который тип оформления пакета SLIP использует remote
end.

      Заметьте, что Вы обязаны использовать такое же оформление, какое
имеет  Ваш peer. Например, если cowslip использует CSLIP,то  Вы  должны
использовать его же. Симптомы рассогласования будут такие, что  ping
незначительному  хосту  не вернет блоки огратно. Если другой хост pings
Вас,  то  Вы  можете  увидеть сообщение типа "Can't build ICMP header'' на
вашем  мониторе.  Один  способ избежать эту неприятность - надо
использовать adaptive SLIP.

      Фактически, slattach не только не позволяет Вам отключить  SLIP,  но
и  не позволяет отключает другие протоколы, которые  используют
последовательную линию также, как и PPP или KISS (другой протокол,
используемый  людьми в ham radio). Для деталей, обратитесь пожалуйста к
slattach инструкции стр. 8.

      После передачи линии SLIP  драйверу,  Вы  должны  сконфигурировать
сетевой interface. И снова,  мы  используем  стандарт  ifconfig  и  route
команды. Предположим, что из vlager мы соединилисьс сервером crowslip.
Тогда Вы должны выполнить:

      # ifconfig sl0 vlager pointopoint cowslip
                 # route add cowslip
                 # route add default gw cowslip

      Первая команда конфигурирует interface как point-to-point связь к
cowslip, в то время как вторая и третья команды прибавляет  route  к
cowslip  и  задает  по умолчанию маршрут, используемый cowslip как ворота.

      При демонтаже SLIP связи, Вы сначала должны удалить все  маршруты
cowslip, используя route c del опцией, уберите interface, и передаете
slatch  сигнал hangup(повесить трубку). Впоследствии Вы должны hangup
модем,  использующий Вашу терминал программу:





                 # route del default
                 # route del cowslip
                 # ifconfig sl0 down
                 # kill -HUP 516

      8.3 Использование dip

      Теперь  это все просто.  Однако,  Вы  могли   бы    захотеть
автоматизировать вышеупомянутые шаги так, чтобы Вы только  вызывли бы
простую команду, которая выполняет все те шаги, показанные выше. Это - то,
для чего нужен dip. (2) Текущее версия этого выпуска - версия 3.3.7.
Онаисправлялась несколькими людьми, поэтому Вы уже больъе нз сможете
говорить о dip как о программе. Эти различные элементы развития будут
"обнадеживающе" слиты в будущей версии.

      Dip обеспечивает интерпретатор простым языком, который  обрабатывает
модем для Вас, преобразуя линию в SLIP режим,  и  конфигурируя  interface.
Это довольно примитивно и ограниченно, но вполне подходяще  для
большинства  случаев. Новая версия dip(а) может описать большое количество
многосторонних  языков в один день.

      Чтобы было возможным сконфигурировать  SLIP  interface,  dip  требует
root привелегию. Это теперь было бы соблазнительно для того, чтобы  сделать
dip setuid к root, таким образом Все пользователи могли бы соединиться с
некоторым SLIP сервером без необходимости  прдеоставления  им  root
доступа.  Это очень опасно, потому что при установке фиктивных
interface(ов)  и  заданных по умолчанию маршрутов dip может разрушить
направление  на  вашей  сети. Даже еще хуже, это даст вашим пользователям
приоритет  на  подсоединение  к любым SLIP серверам, и начать опасную атаку
на  Вашу  сеть.  Так,  если  Вы хотите позволить Вашим пользователям
запустить SLIP связь, напишите  маленькие программки для каждого
предполагаемого SLIP  сервера,  и  вызовите  dip  со специфическим
script(ом), который установит связь. Эти программы могут быть затем
безопасно сделаны setuid root. (3)

      8.3.1 Типовой  Script(сценарий).



      Типовой script аоказан на рисунке 8.3.1. Он может использоваться для
связи с cowslip, вызывая dip со script именем как аргумент:

      2. Dip подразумевается Dialup IP. Он был написан Fred van Kempen.
      3. Diplogin может (или должен)  быть запущен setuid(ом). См. раздел в
конце этой главы.



                  # Sample dip script for dialing up cowslip

                  # Set local and remote name and address
                  get $local vlager
                  get $remote cowslip

       "          port cua3                # choose a serial port
                  speed 38400              # set speed to max
                  modem HAYES              # set modem type
                  reset                    # reset modem and tty
                  flush                    # flush out modem response

                  # Prepare for dialing.
                  send ATQ0V1E1X1\r
                  wait OK 2
                  if $errlvl != 0 goto error
                  dial 41988
                  if $errlvl != 0 goto error
                  wait CONNECT 60
                  if $errlvl != 0 goto error

                  # Okay, we're connected now
                  sleep 3
                  send \r\n\r\n
                  wait ogin: 10
                  if $errlvl != 0 goto error
                  send Svlager\n
                  wait ssword: 5


                  if $errlvl != 0 goto error
                  send hey-jude\n
                  wait running 30
                  if $errlvl != 0 goto error

                  # We have logged in, and the remote side is firing up
SLIP.
                  print Connected to $remote with address $rmtip
                  default                  # Make this link our default
route
                  mode SLIP                # We go to SLIP mode, too
                  # fall through in case of error

                 error:
                  print SLIP to $remote failed.

                     Рисунок 14. Типовой dip script.



      # dip cowslip.dip
                 DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)
                 Written by Fred N. van Kempen, MicroWalt Corporation.

                 connected to cowslip.moo.com with addr 193.174.7.129
                 #

      После соединения с cowslip и включением SLIP, dip отделится от
терминала  и отойдет к предоставлению возможности SLIP связи. Вы  сможзте "
затем  начать использовать обычные сетевые услуги на SLIP связи. Чтобы
завершить  связь, просто вызовите dip c опцией -k. Это пошлет  hangup
сигнал  dip  процессу, используя id dip запись в /etc/dip.pid: (4)

      # kill -k

      На dip script языке, ключевые слова имеющие префикс с символом $
обозначают различные имена. Dip имеет предопределенное множество
переменных,  которые будут  будут  перечислены  ниже.  $remote  и  $local,


например,   содержат hostnames локального и незначительного хоста,
вовлеченных в SLIP связь.

      Первых два оператора в типовом script - получают команды, которые
являются dip  способом  установки  переменных.  Здесь,  локальный  и
незначительный hostname установленн к vlager и cowslip, соответственно.

      Следующие пять операторов устанавливают  линию  терминала  и  модема.
Reset посылает reset строку  к  модему;  для  Hayes-совместимых  модемов,
это команда ATZ. Следующий оператор игнорирует реакцию модема,  так  что
login chat в линиях работал правильно.  Сhat  -  довольно прост:  он
просто  набирает  номер  41988,  номер  телефона  cowslip,  и подсоединятся
в  account  Svlager  через  пароль  hey-jude.  Wait  команда заставит dip
ждать строку, данную как его первый  аргумент;  номер,  данный как второй
аргумент делает wait time, если никакая строка не была получена. If команды
разбросаны в процедуре входа в систему, и проверяют то, что никакая ошибка
не появилась при выполнении этой команды.

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

      4. См. newsgroup alt.tla для более палиндромической забавы с
акронимами с тремя символами.



      8.3.2 Dip ссылка.

     "Хотя широко используемый, dip  не  был  еще  очень  хорошо  описан.
Поэтому, в этом разделе мы дадим ссылку  для  большинства  dip  команд.  Вы
можете получить краткий обзор всех команд, вызывая dip  в  test  режиме,  и
вводя help  команду.  Для  того,  чтобы  выяснять  относительно  синтаксиса
команды, Вы можете набрать его без каких-либо аргументов;  конечно  это  не
работает с командами, которым не нужны никакие аргументы.

                  $ dip -t


                 DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)
                 Written by Fred N. van Kempen, MicroWalt Corporation.

      DIP> help
                 DIP knows about the following commands:

                         databits default  dial     echo     flush
                         get      goto     help     if       init
                         mode     modem    parity   print    port
                         reset    send     sleep    speed    stopbits
                         term     wait

                 DIP> echo
                 Usage: echo on|off
                 DIP>

      На всем протяжении, примеры, которые выделяют DIP> prompt
показывают,  как ввести  команду  в  test  режиме,  и  что  output
производится.    Примеры, испытывающие недостаток в prompt должны
приниматься как script отрывок.

      8.3.2.1 Команды Модема.

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

      Команда  модема  выбирает  тип  модема.  В  настоящее  время,
единственый поддерживаемый тип - HAYES. Вы должны обеспечить dip типом
модема,  или  он откажется набирать номер и выполнять reset команды. Reset
команда  посылает reset строку на модем; используемая строка зависит от
избраннпго вами  типа модема. Для Hayes-совместимых модемов, это - ATZ.

      Flush code может использоваться для того, чтобы убрать все  реакции,
которые модем посылает so far. Иначе chat script мог бы быть  спутанным,
потому  что  он читает OK реакции из более ранних команд.





      Команда init выбирает initialization строку, которую нужно набрать
перед набором номера. Значение по умолчанию для Hayes модемов - "ATE0 Q0 V1
X1'', которая включает отображение на экране команд и long result code,  и
выбирает набор вслепую (нет проверки тона шкалы).

      Команда dial в конце посылает initialization строку  на  модем  и
набирает номер системы. Заданная по умолчанию dial команда для Hayes
модемов - ATD.

      8.3.2.2 echo и term.

      Команда ECHO служит как помощь в отладке, в которой использование
ECHO  ON делает dip ECHO на консоли и все посылает  к  порядковому
устройству.  Он может быть выключен снова, набирая ECHO OFF.

      Dip также позволяет  Вам  оставить  script  режим  временно  и
вступить  в terminal режим. В этом режиме, Вы можете использовать dip точно
так же  как и обычную terminal программу, пишущей в последовательную  линию
и  читющей  из  нее. Чтобы оставить этот режим, введите " Ctrl-] ".

      8.3.2.3 Get Команда.

      Get команда - dip  способ  установки  переменной.  Самая  простая
форма  - установить переменную как константу,  как  это  делалось  в
вышеупомянутом примере.  Вы  можете,   также  запросить  пользователя  для
входа определяя ключевое слов вместо значения:

      DIP> get $local ask
      Enter the value for $local:

      Третий  метод  состоит  в  том,  чтобы  попробовать  получить
значение  от отдаленного хоста. Причудливо, на первый взгляд, но это очень
полезно в некоторых случаях: некоторые SLIP серверы не позволяют Вам
использовать Ваш собственный IP адрес на SLIP  связи,  но  будет
приписывать  Вам  один  из объединения  адресов  всякий  раз,  когда  Вы


набираете  номер,   печатая сообщение, которое информирует Вас относительно
адреса к которому  Вы  были назначены. Если просмотры сообщения -  что  -
нибудь  вроде  этого  ``Your address: 193.174.7.202'', то следующий
фрагмент dip кода допустил бы Вас до подбора адреса:

      wait address: 10
      get $locip remote



      8.3.2.4 Print команда

      Это команда к ECHO тексту к dip консоли.  Любая  из  dip  переменных
может использоваться в print командах, такие как:

      DIP> print Using port $port at speed $speed
      Using port cua3 at speed 38400

      8.3.2.5 Переменные имена(Variable Names)

      Dip только понимает предопределенное множество переменных.
Переменное  имя всегда начинается с символа доллар и должен быть написан в
нижнем  регистре.

      $local и $locip переменные содержат название локального имени  хоста
и  IP адреса. Установка hostname заставляет dip сохранить каноническиий
hostname в $local, в то же самое время приписывая  $locip  соответствующий
IP  адрес. Аналогичная вещь случается при установке $locip.

      $remote и $rmtip переменные делают тоже самое для отдаленных  хостов
и адресов. $mtu содержит MTU значение для соединения.

      Эти  пять  переменных - единственые,  которые    могут    быть
назначены непосредственно используя get команду. Хост других переменных
может быть только установлен через соответствующие команды, но  может
использовать и print опрераторы; это - $modem, $port, и $speed.

      $errlvl - переменная, через  которую  Вы  можете  обращаться  к


результату
      последней выполненой команды. Уровень ошибки 0 указывает  на  успех,
в  то
      время как ненулевое значение обозначает ошибку.

      8.3.2.6 If и Goto Команды

      If команда - более условная штука, чем то что  обычно  подрузамеваят  
под
      if. Синтаксис:

      if var op number goto label

      где выражение должно быть  простым сравнением  между  одной  из
переменных $errlvl, $locip, и $rmtip. Второй операнд должен быть целым
числом; оператор op может быть один из ==,!=, <,>, < =, и > =.



      Команда goto делает выполнение из script  continue  строки,  несущей
эту метку. Метка должна появиться как первый токен в линии, и немедленно
должна оканчиваться двоеточием.

      8.3.2.7 send, wait и sleep

      Эти команды  выполняют  простые  chat  scripts  в  dip.  Send
выводит  его аргументы на последовательную линию.  Он  не  поддерживает
переменные,  но понимает все C-style backslash character  sequences  типа
\n  и  \b.  Знак тильды (~) используется как сокращение для каретки
return/newline.

      wait  берет  слово  как  аргумент,  и   просматривает    весь    вход
на последовательной линии, пока он не распознает это  слово.  Слово  само
по себе непосредственно не может содержать пробелы. Выборочно Вы  можете
дать wait timeout value как второй  аргумент;  если  ожидаемое  слово  не
получено внутри в течении заданного времени, команда возвратится со
значением $errlvl равным 1.



      Sleep оператор может быть  использован  для  того,  чтобы  ждать
некоторое количество  времени,   например, patiently    ждет    любую
login последовательность для завершения. И снова, интервал определен в
секундах.

      8.3.2.8 mode и default

      Эти команды используются для того, чтобы переключить последовательную
линию в SLIP режим и сконфигурировать interface.

      Mode команда - последняя команда, выполненная dip  перед  гонгом  в
daemon режиме. Пока ошибка не появляется, команда ничего не возвращает.

      Mode берет название протокола как аргумент. Dip постоянно распознает
SLIP и CSLIP как подходящие имена. Текущая версия dip не понимает adcptive
SLIP.

      После отключения SLIP  режима  на  последовательной  линии,  dip
выполняет ifconfig  для  того,  чтобы  сконфигурировать  interface  как
двухточечную связь(point-to-point  link),  и  вызвать  маршрут  к
множеству   маршрутов незначительного хоста.

      Если, кроме того, script выполняет  заданную  по  умолчанию  команду
перед mode, то dip также задаcт по умолчанию точку маршрута на SLIP связь.

      8.4 Запуск в server режиме

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



      Единственный способ сделать это - использовать dip в server режиме,
который может  быть  достигнут,  вызывая  его  как  diplogin.  Его  главный
файл конфигурации - /etc/diphosts, который присоединяет  login  имена  к
адресу этого  хоста.  В  качестве  альтернативы,  Вы  можете  также
использовать sliplogin, BSD-производное средство, которое описывает более


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

      Обе программы требуют, чтобы Вы установили один login  account  на
каждого SLIP клиента. Например, представте что Вы обеспечиваете  SLIP
обслуживание Arthur Dent в Dent.beta.com, Вы могли бы создать  account
названный  dent, добавляя следующюю строку к вашему файлу пароля(passwd
file):

      dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

      Впоследствии, Вы должны были бы установит пароль Dent(а), утилиту
passwd.

      Теперь, когда dent подключен, dip запустится как сервер. Чтобы
определить, действительно  ли  ему  разрешено  использовать  SLIP,  нужно
найти    имя пользователя в /etc/diphosts. Этот файл подробно описывает&
птава доступа  и параметры соединения для каждого SLIP пользователя.
Типовая запись для dent могла бы быть похожа на:

      dent::dent.beta.com:Arthur Dent:SLIP,296

      Первая из отделяемых двоеточием областей - имя пользователя под
которым  он должен войти. Вторая область может  содержать  дополнительный
пароль  (см. ниже). Третья -  hostname  или  IP  адрес  вызываемого  хоста.
Далее  идет информационная область без  специального  значения  (пока
еще).  Последняя область описывает параметры соединения. Это - список,
отделенный  запятыми, определяющий протокол (в настоящее время один из SLIP
и CSLIP),  следуя  за MTU.

      Когда dent входит в систему,  diplogin  извлекает  информацию
относительно него из diphosts файла, и, если вторая область  не  пуста,
подсказывает  " Пароль внешней защиты ''. Строка, введенная пользователем -
сравнивается  с (нешифрованным) паролем из diphosts. Если они не
соответствуют, то  попытка входа в систему будет отклонена.





      Это связь остается установленной, пока  пользователь  не
отсоединяется,  или модем  не бросает линию. Diplogin затем возвратит линию
к нормальной discipline line и выйдет.

      Diplogin  требует  привилегии  супер-пользователя. Если  Вы
запустили  dip setuid root, то  Вы должны сделать  diplogin  отдельной
копией  dip(а)  вместо простой связи. Diplogin может затем быть сделан
setuid, без воздействия  на состояние dip непосредственно.



      9. Двухточечный Протокол(point-to-point protocol)

      9.1 Распутывающий P's

      Точно так же как SLIP, PPP - протокол для того,  чтобы  посылать
датаграммы через последовательную связь, но он адресует пару вышеупомянутых
неточностей. Он позволяет сообщающиемся сторонам обсудить опции, такие как
IP  адрес  и максимальный датаграмный размер во время запуска, и
обеспечивает разрешение клкента. Для каждой из этих возможностей,  PPP
имеет  отдельный  протокол. Ниже,  мы  кратко  рассмотрим  эти  базисные
стандартные  блоки  PPP.  Это обсуждение  далеко  не  полно;  и  если  Вы
хотите выяснить что-либо  относительно  PPP,  то   я настоятельно
рекомендую Вам прочитать спецификацию в RFC 1548, также как  и dozen или
companion RFCs. (1)

      В самой основе PPP  лежит  управление  передачей  данных  высокого
уровня, сокращенно  HDLC(High-Level  Data  Link  Control  Protocol),(2),
который определяет границы вокруг ндивидуальных структур  PPP,  и
обеспечивает  16 разрядов  контрольной  суммы.  В  противоположность  более
примитивному оформлению SLIP пакета, PPP способен к захвату блоков из
других протоколовтаких как IP типа IPX Novell's, или  Appletalk.  PPP
достигает  этого,  добавляя область протокола к основному HDLC.

      LCP(Link Control Protocol),  Протокол  управления  связи,
используется  на вершине HDLC для оговора опций, имеющих  отношение  к
каналу  связи,  типа Maximum Receive Unit (MRU), которая заявляет


максимальный размер датаграммы одной стороны связи.

      Важный шаг в стадию конфигурации связи PPP клиентского разрешения.
Хотя  это не обязательно, это действительно должно было бы быть для  dial-
up  линий.  Обычно, вызываемый хост просит  клиента  зарегестрировать
себя, доказывая, что он  знает  некоторый  секретный  ключ.  Если  клиент
набрал неправильный ключ, то связь будет  прервана.  С  PPP,  разрешение
работает обеими способами; то есть вызывающий  может  также  просить,
чтобы  сервер опознал себя. Эти процедуры  установления  подлиности  не
зависят  друг от  друга. Имеются два протокола для различных типов
разрешения,  которые  мы  обсудим позже.  Они  именованы  "Протоколом
Установления  Подлинности  Пароля",  или PAP(Password Authentication
Protocol ),  или CHAP(Challenge  Handshake Authentication Protocol).

      Каждый сетевой протокол, который разбит поперек канала связи,  
пожобно  IP, AppleTalk, и т.д,  сконфигурирован  динамически,  используя
соответствующую Network Control Protocol  (NCP).  Например,  чтобы  послать
IP  датаграммы поперек

      1. Релевантные RFCs перечислены в  Annoted  Bibiliography  в  конце
этой книги.
      2. Фактически,  HDLC-  намного  более  общий    протокол,
изобретенный             Международной организацией по стандартизации



      связи, оба PPPs должны сначала обсудить, который из IP адресов
каждый  из  них использует.  Протокол  управления,  используемый  для
этого  -  IPCP,  the Internet Protocol Control Protocol.

      Помимо  посылки  стандарта  IP  датаграммы  поперек  связи,    PPP
также поддерживает Van Jacobson header compression IP датаграмм. Это -
метод  для того, чтобы сократить заголовки TCP блоков к всего трем байтам.
Это  также используется в CSLIP,  и  -  больше  относится  к  VJ  header
compression. Использование сжатия может быть заключено в лимите  времени
запуска  через IPCP.

      9.2 PPP на Linux



      На Linux, PPP функциональные возможности расщеплены на две части,
low-level HDLC драйвер, который размещен в ядре,  и  пространство
пользователя  pppd  daemon, которое обрабатывает различные протоколы
управления.  Текущее  разъединение PPP для Linux - linux-ppp-1.0.0, которое
содержит  ядро  PPP  модуля,  pppd,  и программа,  именованная  chat
используется  для  того, чтобы выполнить отдаленную связь.

      PPP kernel драйвер  был  написан  Michael  Callahan. Pppd  был
выведен  из PPP реализации для Sun и 386BSD машин, который был  написан
Drew Perkins и другими, и поддерживается Paul Mackerras. Это было
предоставлено к Linux Al Longyear. (3) chat был написан Karl Fox.(4)

      Точно  так  же  как и  SLIP,  PPP  выполнен  посредством  специальной
line discipline. Для того, чтобы использовать  последовательную  линию  как
PPP связь, Вы сначала должпы уутановить связь над вашим модемом как
обычно,  и впоследствии преобразовать линию к PPP режиму. В этом методе,
все  входящие данные  проходят  через  PPP  драйвер,  который  проверяет
входящие   HDLC структуры  для  соответствия  (каждая  HDLC  структура
несет   16    битов контрольной суммы). В настоящее время, он способен к
выбору,  используя  Van Jacobson header compression. Как только Linux
поддерживает IPX, PPP драйвер будет расширен для того, чтобы обрабатывать
IPX блоки.

      Kernel  драйверу  помогает  pppd,  PPP  daemon,  который  выполняет
целую инициализацию и опознавательный период, который является необходимым
перед тем, как фактическое сетевое движение может  быть  послано  поперек
связи. Поведение Pppd может подстраиваться, используя ряд опций. PPP -
комплексный, невозможно описать все из них в единственной главе.

      3. Оба автора сказали, что они будут очень заняты некоторое время для
того, чтобы вернуться. Если Вы имеете какие-либо вопросы относительно PPP
в  общем, то Вам  лучше  всего  спросить  бы  людей  относительно  NET
канала  Linux activists mailing list..
      4. [email protected].





      Эта книга, однако, не  может  покрывать  все  аспекты  pppd,  но
даст  Вам полное введение. Для более подробной информации, обратитесь  к
страницам  инструкции  и файлам README на pppd исходном распространении,
которое должно  помочь  Вам отсортировать большинство вопросов, эта глава
объясняет  как  это  сделать. Если у Вас остаются проблемы даже после
чтения всей документации, то Вы должны обратиться к newsgroup
сomp.protocols.ppp  для  справки,  которая  является местом где Вы узнаете
многое о pppd.

      9.3 Запуск pppd

      Когда  Вы  хотите  соединитьcя  с  Internet  через  PPP  связь,  Вы
должны
      установить базисные возможности работы с  сетями  типа  возврата
цикла,  и решающего  устройства.  Оба  были  описаны  в  предыдчщих"
главах.   Имеются некоторые вещи, которые нужно упоминать относительно
использования DNS  над последовательной связью; пожалуйста обратитесь к
SLIP главе для описания.

      Как вводный пример того, как устанавливать PPP связь  с  pppd,
представте, что Вы - во vlager снова. Вы уже соеденились с сервером по
телефону,  c3po, и зарегистрировались  на  ppp  account.  C3po  уже
запустила  свой  PPP драйвер. После выхода из коммуникационных программ,
которые Вы используете для соединения по телефону, Вам необходимо выполнить
следующую команду:

      # pppd /dev/cua3 38400 crtscts defaultroute

      Это переместит последовательную линию cua3 к  PPP  режиму  и
установит  IP связь с c3po. Скорость передачи,  используемая  на
последовательном  порте будет 38400bps. Опция crtscts  включает  аппаратное
рукопожатие  на  порт, который должен работать на скорости более чем 9600
бит\сек.

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


подробно  несколько позже.

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

      Pppd будет договариваться  о  IP  параметрах  с  peer  используя
IPCP,  IP управляет протоколом. Так как мы не точно определяли IP



      адрес к pppd выше, то  он  попробует  использовать  адрес,
полученный  при наличии решающего устройство, при просмотре  локального
hostname.  И  затем объявят этот адрес друг другу.

      Обычно, ничего не случается с этими значениями по умолчанию. Даже
если Ваша машина находится в Ethernet, Вы можете использовать тот же самый
IP  адрес для обоих. и для Ethernet, и для PPP  interface.  Но  тем  не
менее,  pppd позволяет Вам использовать различные адреса,  или  даже
спрашивать  Вашего peer для того, чтобы использовать некоторый
специфический адрес.  Эти  опции обсуждены далее.

      После прохождения  IPCP  периода  установки,  pppd  подготовит  Ваш
host's networking layer для того, чтобы  использовать  PPP  связь.  Сначала
будет сконфигурированн PPP сетевой interface как point-to-point связь,
используя ppp0 для первой PPP cвязи, которая является активной, ppp1  для
второй,  и так далее. Затем, он установит маршрутную  таблицу,  которая
указывает  на хост в другом  конце  связи.  В  примере,  показанном  выше,
pppd  сделает заданный по умолчанию сетевой маршрут  к  c3  опциии
defaultroute.  (5)  Он азаставляет все  датаграммы  к  хостам  не  на
вашей  локальной  сети  быть посланными  к  C3po.  Имеется  ряд  различных
маршрутов,   которые    pppd поддерживает, которые мы обсудим позже в этой
главе.

      9.4 Использование файлов опций

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


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

      Первый файл опций - /etc/ppp/options, который всегда просматривается
тогда, когда запускается pppd. При использовании  этого  для  установки
некоторых глобальных значений по умолчанию - хорошая идея, потому  что  это
позволит Вам сохранить пользователей от выполнения нескольких вещей,
которые  могут поставить под угрозу защиту. Например, чтобы pppd  запросил
некоторый  вид установления подлинности (или PAP или CHAP) от peer, Вы бы
добавили  опцию auth к  этому  файлу.  Эта  опция  необходима для того,
чтобы  стало невозможно установить PPP связь  с  любой  системой,  которая
не  в  наших опозназательных базах данных.

      Другой  файл  опций,  который  читается  после  /etc/ppp/options -
рpprc  в исходном каталоге пользователя. Он позволяет  каждому
пользователю  точно определить ее собственное множество опций по умолчанию.

      Типовой файл  /etc/ppp/options мог бы выглядеть следующим образом:

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



      # Global options for pppd running on vlager.vbrew.com
                 auth                 # require authentication
                 usehostname          # use local hostname for CHAP
                 lock                 # use UUCP-style device locking
                 domain vbrew.com     # our domain name

      Первыя две из этих опций обращаются  к  установлению  подлинности  и
будут объяснены ниже. Ключевое слово блокировки заставит pppd уступить
стандарту UUCP метод блокировки устройства. С этим собранием, каждый
процесс, который обращается к последовательному устройству, скажем
/dev/cua3,  создает  файл блокировки, названный LCK.. cua3 в UUCP катологе,
чтобы сообщить,  что  это устройство находится в использовании. Необходимо
предотвратить любые другие программы  типа  minicom  или  uuci  локального


устройства  в  то  время   как используется PPP.

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

      9.5 Набор номера с chat

      Одна из вещей, которая может испугать Вас как  неудобная  в
вышеизложенным примере - то, что Вы должны установить связь вручную прежде,
чем  Вы  могли бы запустить pppd. В отличие от dip, pppd не имеет
собственный script  язык для набора незначительной системы и регистрации,
но полагается на некоторую внешнюю программу или shell script для того,
чтобы  сделать  это.  Команда, которая будет выполнена может  быть  дана
pppd  с  connect  командой  line option. Pppd переназначит  вход  и  выход
к  последовательной  линии.  Одна полезная программа для этого - expect,
написанная  Don  Libes.  Она  имеет очень мощный язык основанный на Tcl, и
была  разработана  точно  для  этого сорта приложения.

      Pppd пакет идет с  подобной  программой  называемой  called  chat,
которая позволяет Вам определить UUCP-style chat script. В  основном,  chat
script состоит  из  чередующихся  последовательности  строк,  которые  мы
ожидаем получить от отдаленной системы, и ответов, которые мы  должны
послать. Мы будем называть  expect  и  send  строки,  соответственно.  Это
типичная выборка из chat script;

      ogin: b1ff ssword: s3kr3t



      Он сообщает chat чтобы ждать отает из отдаленной системы для  того,
чтобы  послать login prompt, и вернуть login имя b1ff. Мы только ждем ogin:
так чтобы было все равно стартует ли login prompt с верхнего регистра или с
нижнего регистра I, или приходит  искаженным.  Следующяя  строка  -  expect
string снова, которая заставит chat ждать пароль, и посылать свой пароль в
ответ.



      Вот это в основном и все то, для чего  предназначен  chat  scripts.
Полный script  для  соединения  с  PPP  сервером,  несомненно   должен
включать соотствующие  команды  модема. Представте,  что  ваш  модем
понимает  Hayes команды, и номер  телефона  сервера  был  318714.  Полный
вызов  chat  для установки связи с c3po был бы:

      $ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN

      По определению, первая строка должна  бы быть expect строкой, но так
как  модем не будет говорить что - нибудь прежде, чем мы пнули его,  мы
сделаем  chat так, чтобы он сначала ожидал, опрзделкв  пустую  строку.  Мы
продолжаем  и посылаем ATZ, reset команда для Hayes-совместимых модемов, и
ждем  реакцию (OK). Следующая строка посылает dial команду с номером
телефона для chat, и ожидает сообщение CONNECT в ответ. За  этим  следует
пустая  строка  снова, потому что мы не хотим посылать, но лучше подождать
для быстрого входа  в систему. Остаток от chat script работает точно так,
как описано выше.

      Опция -v делает caht log all activities к syslog daemon's local2
facility. (6)

      Определение chat script на командной строке несет оправданный риск,
потому что  пользователи  могут  просматривать  командную  строку
процессов    с использованием ps команды. Вы можете избежать этого, помещая
chat script  в файл, скажем dial-c3po. Вы можете заставить chat прочесть
script  из  файла вместо командной строки, давая ему опцию -f,
сопровождаемой  именем  файла. Завершением колдовства над pppd теперь
выглядело бы следующим образом:

      # pppd connect "chat -f dial-c3po" /dev/cua3 38400 -detach \
                         crtscts modem defaultroute

      6. Если Вы  редактируете  syslog.conf  так,  чтобы  переназначить
эти  log сообщения к файлу, удостоверитесь, что этот файл не всемирно
читаемый,  так как chat также регестрирует введенный chat script по
умолчанию  -  включая пароли и все.





      Помимо соединяющейся опции, которая определяет dial-up script, мы
добавили еще две опции  к  командной  строке: - detach,  которая  сообщает
рppd  не отделяться от консоли и стать процессом предпосылки. Ключевое
слово  модема заставит  его  выполнить  некоторые    модем-определенные
действия    на последовательном  устройстве,  подобно  "повесить  трубку"
прежде  и  после вызова. Если Вы не используете это ключевое слово, pppd не
будет определять DCD линию, и будет не обнаруженна неожиданно.

      Примеры, показанные выше были довольно  просты;  chct  позволяет
учитывать намного более комплексные chat script. Одна очень  полезная
особенность  - способность к точному определению строки на которой можно
прервать  chat  с ошибкой. Типичные аварийные строки - BUSY,  или  NO
CARRIER,  которые  ваш модем обычно генерирует, когда вызываемый номер
занят,  или  не  поднимают трубку. Для того, чтобы сделать chat
распознающим  их  немедленно,  скорее быстрее чем выйдет время, Вы можете
определить начало script, используя  ключевое слово ABORT.

      $ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

      В подобном режиме, Вы можете изменить значение блокировки  по
времени  для частей chat scripts, вставляя  TIME  OUT  опции.  Для
деталей,  пожалуйста обратитесь к chat(8) справочника.

      Иногда, вы может быть захотели бы иметь некоторый вид условного
извлечения частей chat script. Например,  когда  Вы  не  получаете
отдаленный end'slogin prompt, возможно Вы можете захотеть послать BREAK,
или возврат каретки.  Вы можете достичь этого, присоединяя sub-script к
expect строке.  Она  состоит из последовательности send- и expect- строк,
точно таких же  как  и  полный script непосредственно, который отделен
дефисами.  Sub-script  выполняется всякий раз, когда expected строка когда
не было ничего получено. В  примере изложенном выше, мы модифицировали бы
chat script следующим образом:

      ogin:-BREAK-ogin: ppp ssword: GaGariN

      Теперь, когда chat не видит, что отдаленная система  посылает


быстрый  вход  в систему, sub-script выполняется сначала посылая BREAK, и
затем ожидает  для входа в систему  снова.  Если  prompt  теперь  появится,
то  script  будет продолжаться как обычно, иначе это прервется с ошибкой.



      9.6 Отладка вашей PPP установки

      По умолчанию, pppd  регестрирует  любые  предупреждения  и  сообщения
об ошибках  к  syslog's  daemon  facility.  Вы  должны  добавить   записю   "
в syslog.conf, которая переназначит его к файлу, или даже  к  консоли,
иначе syslog  просто  отбросит  эти  сообщения.  Следующая  запись
посылает  все сообщения к /var/log/ppp-log:

      daemon.*                /var/log/ppp-log

      Если ваша PPP установка не работает, при просмотре этого log файла,
то  он должен дать Вам подсказку, что что-то идет неправильно. Если это не
помогает, то Вы можете включить особо отлаживающийся вывод, используя
опцию  отладки.  Это делает pppd log с содержанием из всех  управляющих
блоков,  посланных  или полученных к syslog. Все сообщения будут идти к
daemon facility.

      В заключение, наиболее  решительная  особенность - отключение
kernel-level отладки,  вызывая  pppd  с  опцией  kdebug.  Она
сопровождается   числовым аргументом, который является поразрядным  ИЛИ
следующих  значений:  1  для общих сообщении  отладки,  2  для  печати
содержания  всей  входящей  HDLC структуры, и 4 для того, чтобы сделать
драйвер принтера выходящим  на  HDLC структуру. Для того, чтобы  захватить
kernel  отлаживающее  сообщения,  Вы должны также запустить syslogd daemon,
кот или klogd daemon. Каждый из  них направляет kernel отладку к syslog's
kernel facility.

      9.7 IP опции конфигурации

      IРCP  используется  для  того,  чтобы  обговорить  пару  IP
параметров   в конфигурационной связи. Обычно, каждый  peer  может
посылать  IPCP запрос конфигурации, указывая,  которая  переменная хочет


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

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



      9.7.1 Выбор IP адресов

      В примере выше, у нау был pppd, связывающейся с c3po и
устанавливающий  IP связь. Никакие условия не принимались для того, чтобы
выбрать частный адрес IP на любом конце связи. Взамен, мы выбрали адрес
vlager's  как  локальный адрес IP, и позволяем c3po обеспечить себя
собственным. Иногда это  полезно иметь контроль над тем , какой адрес
используется на  одном  или  на  другом конец связи. Pppd поддерживает
отдельные разновидности этого.

      Чтобы просить о частных адресах, Вы вообще  обеспечиваете  pppd
следующеми
      опциями:

      local addr:remote addr

      Где local addr и remote addr  могут  быть  определены  или  в  dotted
quad notation, или как hostnames.(7) Это заставит pppd  попытаться
использовать первый адрес как собственный  адрес  IP,  и  второй  как
peer.  Если  peer отклоняет любой из них в течение IPCP  переговоров,
никакая  связь  IP  не будет установленна. (8)

      Если Вы хотите установить  локальный  адрес,  но  принимаете  любой
адрес, который  использует  peer,  Вы  просто  не  учитываете  remote  addr
part. Например, для того, чтобы vlager использовал IP  адрес  130.83.4.27
вместо собственного, Вы бы дали ему  130.83.4.27:  на  командной  строке.
Подобно установки remote адресов только, Вы покинули  бы  локальную
область адреса.


      Используя значение по умолчанию, pppd затем использует адрес,
связанный  с вашим hostname.

      Некоторые PPP серверы, которые обрабатывают множество клиентов,
приписывают адреса динамически:  адреса  назначены  системам  только  когда
существует обращение и требуются  после  того,  как  они  прекратили
регистрироваться снова.  Когда  происходит  соединение  с  таким
сервером,    Вы    должны удостовериться, что pppd не запрашивает какой-
либо IP адрес из сервера,  но когда адрес будет принят сервер попросит Вас,
чтобы  Вы  его  использовали. Это означает то, что Вы не должны определить
того, Вы  должны  использовать опцию noipdefault, которая заставит pppd
ждатю pegr, чтобы обеспечить адрес IP вместо использования адреса
локального хоста.

      7. Использование  hostnames  в  этой  опции  имеет  следствия    на
CHAP установления подлинности. Пожалуйста обратитесь к разделу на CHAP.
      8. Вы можете позволить peer PPP отменить ваши идеи относительно IP
адресов, давая  pppd  ipcp-accept-local  и  ipcp-accept-remote  опции.
Пожалуйста обратитесь к руководству для выяснения деталей.



      9.7.2 Направление через связь PPP

      После установки сетевого interface, pppd будет устанавливать  хост
маршрут только к своему peer. Если remote хост находится  на  LAN,  Вы
обязательно захотите быть способным соединится с хостами множествами
"позади"  Вашего peer; то есть сетевой маршрут должен быть установлен.

      Мы уже видели, что pppd можно попросить уствновить  заданный  по
умолчанию маршрут, используяю опцию defaultroute. Эта опция очень  полезна
если  PPP сервер, с которым Вы связались будет действовать как ваши
Internet ворота.

      Обратный случай, где ваша система действует как  ворота  для
единственного хоста, является также относительно простым для того, чтобы
быть выполненым. Например, возьмите некоторых служащих  в  Virtual
Brewery,  чья  локальная машина называется loner. При соединении с vlager


через PPP,  он  использует адрес на подсети Brewery.  В  vlager,  мы  можем
теперь  дать  pppd  опцию proxyarp,  которая  установит  полномочную  ARP
запись  для  loner.    Это автоматически сделает loner доступным для всех
и в Winery.

      Однако, вещи далеко не всегда просты как это иногда кажется, например
когда Вы соединяете две LAN. Это обычно требует добавления специального
сетевого маршрута, потому  что  эти  сети  могут  иметь  свой  маршрут
заданный  по умолчанию. Кроме того, имея обоих peer использование связи PPP
как  маршрут заданный по  умолчанию  генерировало  бы  цикл,  где  блоки  к
некзвеутным адресатам будут пинаться между peer пока их time-to-live
истечет.

      Как  пример,  предположите,  что  Virtual  Brewery  открывает
ветвь   в  каком-нибудь другом городе. Подразделение  запускает
собственную  Ethernet используя IP сетевой номер  191.72.3.0,  который
является  подсетью  3  из Brewery класса B сети. Они хотят соединиться с
Brewery's main Ethernet  via PPP для тго, чтобы модифицировать базы данных
заказчиков,  и  т.д.  Снова, vlager действует как ворота; peer вызывается
sub-etha  и  имеет  адрес  IP 191.72.3.1..

      Когда sub-etha соединится с  vlager,  она  примет  заданный  по
умолчанию маршрут к vlager как обычный. На vlager, мы будем должны
установить сетевой маршрут для подсети 3, который проходит к sub-etha. Для
этого, мы используем  особенность  pppd,  не  обсужденного  пока  -  ip-в
готовности команды. Это shell script или программа, размещенная  в
/etc/ppp,  которая выполнена после того, как  PPP  interface  был
сконфигурирован.  Когда  он существует, это вызывается со следующими пар



      ip-up iface device speed local addr remote addr

      Где iface называет сетевой  interface  используемым,  device - тропа
файла последовательного устройства  используемого  (/dev/tty,  если
stdin/stdout используется), и speed - быстродействие устройства.  Local
addr  и  remote addr дают IP адреса, используемые  в  обоих  концах  связи
в  dotted  quad notation. В нашем случае, ip-up script, может содержать


следующий  кодовый фрагмент:

      #!/bin/sh
                 case $5 in
                 191.72.3.1)            # this is sub-etha
                         route add -net 191.72.3.0 gw 191.72.3.1;;
                 esac
                 exit 0

      В подобном режиме, /etc/ppp/ip-down используется для того,  чтобы
отменить все действия ip-up после того, как связь PPP была демонтирована
снова.

      Однако, схемж матшрутов еще не полна. Мы установили маршрут входов
таблицы на оба PPP хоста, но пока, все другие хосты на обих сетях не  знают
ничего относительно  связи  PPP.  Это  не  большая  проблема,  если  все
хосты  в подразделении имеют свои, заданные по умолчанию маршруты в sub-
etha, и  все хосты в Brewery направляются к vlager по умолчанию. Если  это
не  так,  то ваша единственная опция будет использовать daemon маршрут
подобно  воротам. После создания сетевого маршрута передал бы по радио
новый маршрут ко  всем хостам на присоединенной подсети.

      9.8 Опции управления связью

      Выше, мы уже  столкнулись  с  LCP,  Протоколом  Управления  Связи,
который используется для того, чтобы заключить характеристики  связи,  и
проверить связь.

      Две наиболее важных опции,  которые  могут  быть  заключены  LCP -
максимум получает единицу и Асинхронное Отображение  Управляющего  символа.
Имеется ряд других LCP опций конфигурации, но  они  слишком
специализированны  для обсуждения их здесь. Пожалуйста обратитесь к RFC
1548 для описания этого.



      Асинхронное отображение управляющего символа,  разговорно
называемого  async отображение, используется на асинхронных связях типа


телефонных  линий  для опознавания  управляющих  символов,  которых
нужно    найти    (заменить специфической последовательностью с двумя
характерами). Например, Вы  может быть  захотите  избежать  XON  и  XOFF,
используемые    для    рукопожатия программного обеспечения, потому  что
некоторый  плохо  сконфигурированный модем мог бы удушить получения стоп-
сигнала. Ctrl-] (telnet символ ESC). PPP позволяет Вам выходить из любого
из знака с ASCII кодировкой от 0 до 31, точно определяя их в аsync
отображении.

      Async  отображение - растр  шириной  32  бита,  с  самым  младшим
битом, соответствующим ASCII NUL знаку, и старшим битом соответствующим 31
ASCII. Если бит установлен, то оп сообщает соответствующему знаку, который
должен выйти перед  посылкой  через  связь.  Первоначально,  async
отображение  - множество к 0xffffffff, то есть все управляющие символы
будут esaped.

      Для того, чтобы сообщить вашему peer, что это  он  не  должен
escaped  все управляющие символы, а только несколько из них, Вы можете
точно  определять новый asyncmap к pppd используя опцию asyncmap. Например,
если только ^S  и ^Q  (ASCII  17  и  19,  обычно  используемый  для
старт-сигнала(XON)    и стоп-сигнала(XOFF)) должно быть escaped, то Вам
надо использовать следующую опцию:

                 Asyncmap 0x000A0000

      Максимум получает единицу, или MRU, сообщает peer максимальный размер
HDLC рамки, которую мы хотим получить. Хотя это может напомнить Вам
значение MTU (Максимальная Порция обмена), то  эти  два  имеет  немного
общего.  MTU  - параметр kernel  устройства  работы  с  сетями,  и
описывает  максимальную структуру inerface делая его способным к обработке.
MRU более, чем совета к remote end для того, чтобы не генерировать любой
фрейм  больший  чем  MRU; interface должен однако быть способен 1500 байт.

      Выбор MRU не такой большой вопрос того что как связь способна к
пересылке, но того, что даст Вам самый  лучший  throughput.  Если  Вы
имеете  в  виду интерактивные приложения над связью, то установки  MRU  к
значениям всего 296 - хорошая идея, так, чтобы случайный больший  блок
(говорят,  из FTP сеанса) не сделал бы ваш курсор "jump''. Чтобы сообщить


pppd  чтобы  он запросил MRU 296, Вы бы дали ему   опцию  mru  296.  Малый
MRUs,  однако, только имеет смысл, если Вы не имеете эту опцию (это
отключается по умолчанию).



      Pppd понимает также пару LCP опций, которые конфигурируют полное
поведение процесса переговоров, типа максимального номера из  запросов
конфигурации, которые могут быть обменены перед тем как связь будет
прервана.
    &
"     В заключение, имеются две опции, которые обращаются к LCP ECHO
сообщениям. PPP определяет эти два сообщения, запрос ECHO и ответ ECHO.
Pppd использует эту особенность, чтобы проверить, действует ли связь  все
еще.  Вы  можете отключить  это  используя  опцию  lcp-echo-interval
вместе  со    временем мгновенно. Если никакие структуры не получены от
отдаленного хоста внутри  этого интервала, то pppd сгенерирует запрос ECHO,
и  будет  ожидает,  какой  ECHO ответ peer возвратит. Если  peer  не
возвращает ответ, то  связь  будет  прервана  после некоторого числа
посланных  запросов.  Этот  номер  может  быть  установлен используя опцию
lcp-echo-failure. По умолчанию, эта особенность отключена в целом.

      9.9 Общие рассмотрения защиты

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

      Одна проблема с pppd - то, что конфигурация сетевого устройства  и
таблицы маршрутов  требуют  привилегии  root.  Вы  будете  обычно
разрешать    эту сложность, выполняя  setuid  root.  Однако,  pppd
позволяет  пользователям установить различные защита-релевантные опции.
Для  защиты  против  любого нападения, пользователь может манипулировать
этими опциями, Вам предложат  установить  пару  значений  по   умолчанию
в    глобальном    файле /etc/ppp/options, подобно тем показанным в типов
9.4.  Некоторые  из  них, типа опознавательных опций, не могут быть


отменены пользователем, и так что они обеспечивают приемлемую защиту против
манипулирований.

      Конечно, Вы должны защитить себя от систем, с которыми PPP также
общается. Чтобы отразить хосты,  Вы  должны  всегда  иметь некоторый вид
установления подлинности от вашего peer. Дополнительно, Вы не должпы
позволять иностранным хостам использовать любой адрес IP  какой  они
выберут, но ограничьте их по крайней  мере  несколькими.  Следующий  раздел
будет связам с этими проблемами.



      9.10 Установление подлинности с PPP
      .10.1 CHAP против PAP

      С PPP, каждая система может требовать, чтобы peer  опознал  себя
используя однин из двух  опознавательных  протоколов.  Они - (PAP), и
(CHAP).  Когда  связь  установлена,  каждый может запросить другой, чтобы
опознать себя, независимо от того, является ли  это caller или callee. Ниже
я буду говорить о "клиенте " и " сервере " когда я захочу сделать различие
между  системой  опознания  и  authenticator.  PPP daemon может спрашивать
peer отно подлинности, посылая  однако  другой  LCP запрос конфигурации,
опознавающий желаемый протокол.

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

      CHAP  не  имеет  этих  недостатков.  С  CHAP,  authenticator    (то
есть сервер) посылает  беспорядочно  сгенерированную  "  challenge''
строку   к клиенту, наряду с hostname. Клиент  использует  hostname  для
того,  чтобы искать соответствующий шифр, объединяя это с challenge,  и
шифруя  строку, используя однонаправленную hashing function. Результат
будет  возвращен  на сервер наряду с hostname клиента.  Сервер  теперь
выполняет  то  же  самое вычисление, и подтверждает клиента.



      Другая особенность CHAP - то, что он не требуется опознания клиента
для  опознания  самого себя при запуске, но посылает challenges  в
определенные  промежутки  времени, чтобы удостовериться не был клиент
заменен  "злоумяшлепником  ",  например, только переключая телефонные
линии.

      Pppd хранит секретные ключи  для  CHAP  и  PAP  в  двух  отдельных
файлах, вназываемых  /etc/ppp/chap-secrets  и  pap-secrets  соответственно.
Входом отдаленного хоста в один или другой файл, Вы имеете хороший контроль
над CHAP или PAP предназначенный для этого, чтобы опознать нас с нашим
peer, и наоборот.

      По умолчанию, pppd не требует установления подлинности от remote,



      но соглашается опознавать себя когда запрошено remote. Так как CHAP
намного более сильна чем PAP, pppd пробует использовать вышеупомянутый
всякий  раз, когда это возможно. Если peer этого не поддерживает, или если
pppd не может найти CHAP шифр для remote системы в файле шифров chap, он
возвращается  к PAP. Если он  имеет  PAP  шифр  для  peer  также,  то  он
откажется опознавать в целом, и как следствие, связь закроется.

      Это поведение может быть  изменено  отдельными  способами. Например,
когда дается auth ключевое слово, pppd требует, чтобы peer опознал сам
себя. Pppd согласится использовать или CHAP или PAP для этого, как  только
это  будет имеет шифр для peer в CHAP или в базе данных  PAP
соответственно.  Имеются другие  опции,  чтобы  включить  или  выключить
частный    опознавательный протокол, но я не буду описывать их здесь.
Пожалуйста обратитесь к pppd (8) для деталей.

      Если все системы, с которыми Вы говорите PPP, соглашаются опознавать
самих себя  с  Вами,  Вы  должны  поместить  опцию  auth  в    глобальный
файл /etc/ppp/options и определить пароли для  каждой  системы  в  файле
шифров chap. Если система не поддерживает CHAP, добавьте запись к  файлу
pap шифров. Таким образом, Вы можете  удостовериться  в  том,  что  никакая
неопознанная система не соединяется с Вашим хостом.



      Следующие два  раздела  обсуждают  два  PPP  файла  шифров,  pap-
secrets  и chap-secrets.  Они  размещзны "в  /etc/ppp  и  содержат  тройки
клиентуры, серверов и паролей, необязательно сопровождаемых  списком  из
адресов  IP. Интерпретация клиента и областей сервера отлична для CHAP или
PAP, и  также зависит от того, опознаем ли мы себя самостоятельно с peer,
или  потребуем опознать сервер непосредственно с нами.

      9.10.2 Файл шифров CHAP

      Когда это должно опознать себя с некоторым сервером, используя  CHAP,
рppd ищет файл шифров PAP для записи с  клиентской  областью  равной
локальному hostname, и области сервера равной  к  remote  hostname
посланный  в  CHAP Challenge. При требовании peer к опознаванию себя, роли
просто  поменялись: pppd будет  затем  искать  запись  с  клиентской
областью  приравненной  к отдаленному hostname (посланный в CHAP ответ
клиенту) и область сервера приравненной локальному хосту.

      Следующее  - типовой файл шифров chap для vlager: (9)



      # CHAP secrets for vlager.vbrew.com
       #
       # client          server            secret                addrs
       #-------------------------------------------------------------------
---
       vlager.vbrew.com  c3po.lucas.com    "Use The Source Luke"
vlager.vbrew.com
       c3po.lucas.com    vlager.vbrew.com  "riverrun, pasteve"
c3po.lucas.com
       *                 vlager.vbrew.com  "VeryStupidPassword"
pub.vbrew.com

      При установлении PPP связи с c3po, c3po запрашивает vlager  опознать
себя, используя CHAP, посылая CHAP challenge. Pppd затем просматривает chap
шифры для записи с клиентской областью, приравненой к vlager.vbrew.com и
областью сервера  приравненной  к  c3po.lucas.com,  (10)  и  находит


первую  линию, показанную выше. Затем производится CHAP ответ от challenge
string и  шифра (Используйте Источник Luke), и посылает от c3po.

      В то же самое время, pppd составляет CHAP challenge  для  c3po,
содержащую уникальную  challenge  string,  и  пплноутью  квалифицированный
hostname vlager.vbrew.com. C3po создает CHAP ответ способом, который мы
только  что обсудили, и возвращает это  к  vlager.  Pppd  теперь  извлекает
клиентский hostname (c3po.vbrew.com) из ответа, и поисков файлов шифра chap
для линии, соответствующей c3po как клиент, и vlager как сервер. Вторая
линия  делает так что pppd объединяет CHAP  challe  pasteve,  шифрует  их,
и  сравнивает результат с с3po CHAР ответа.

      Произвольная четвертая область перечисляет адреса IP, которые
являются  для клиентуры, именованной в первой области. Адреса могут быть
даны  в  dotted quad notation или как hostnames, которые разысксканы  с
помощью  решающего устройства. Например, если запрос c3po, на использование
IP адреса во время IPCP переговора, который не в этом списке, запрос будет
отклонен,  и  IPCP будет выключено. В типовойфайле, показанном выше, с3po
следовательно  будет ограничен использованием собств Если область  адреса
пуста,  любые  адреса будут позволяться,  значение  которых  -
предотвращает  использование  IP  с клиентом.

      Третья линия в примере файле шифров chap позволяет любому хосту
установить связь PPP с vlager потому что  клиент  или  область  сервера
соответствует hostname. Единственое требование - то, что он знает  пароль,
и  использует адрес pub.vbrew.com. Вход с групповым  символом  hostnames
может  появится где-нибудь в файле шифров, так как pppd будет всегда
использовать  наиболее специфическую запись, которая применяется к паре
сервера / клиента.

      9. Двойные кавычки - не часть пароля, они просто  служат  для  того,
чтобы защитить незаполненное пространство внутри пароля.
      10. Этот hostname принимается из CHAP challenge.



      Имеются некоторые слова,  которые  нужно  упоминуть  относительно
способа, которым pppd  достигает  hostnames:  он  ищет  в  файле  шифров.


Как  было объяснено  прежде,  отдаленный  hostncme  всегда  обеспечивается
peer  в  CHAP Challenge или в Response packet. Локальный  hostname  будет
получен,  если вызвать gethostname функцию (2) по умолчанию. Если Вы
установили  название системы Вашему неквалифицированному hostname, то Вы
должны обеспечить его pppd областью.

      # pppd ...domain vbrew.com

      Это конкатенирует название Brewery области к vlager для  всех
установленых подлинностью действия. Другие опции, которые модифицируют
progpppd's  idea относительно локального hostname -  usehostname  и  name.
Когда  Вы  даете локальный IP адрес на командной строке, использующей
"local:varremote",  и local - название вместо dotted quad,  pppd
использует  это  как  локальный hostname. Для деталей, пожалуйста
обратитеськ pppd странице справочника (8).

      9.10.3 Файл шифров PAP.

      Файл шифров PAP очень похожа на тот, который используется CHAP.
Сначала две области всегда содержат название пользователя и  название
сервера;  третья часть задерживает шифр PAP. Когда remote посылает
опознающийся запрос, рppd использует  запись,  которая  имеет  область
сервера  равной    локальному hostname,  и  область  пользователя
приравненной  к  имени   пользователя, посланному в запросе. Когда
опознание себя с peer произойдет, pppd  выберет шифр, который будет послан
из линии с  область  приравненной  к  локальному имени пользователя, и
областью сервера приравненной к remote hostname.

      Типовой файл шифров PAP мог бы выглядить следующим образом:

      # /etc/ppp/pap-secrets
       #
       # user          server          secret          addrs
       vlager-pap      c3po            cresspahl       vlager.vbrew.com
       c3po            vlager          DonaldGNUth     c3po.lucas.com

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





      Вторая линия описывает, как пользователь  именнованняй  c3po,  должен
быть опознаным непосредственно с нами.

      Имя vlager-pap в столбце, который является именем пользователя, мы
посылаем к c3po. По умолчанию, pppd выберет локальный hostname как имя
пользователя, но Вы можете также определить различные названия, давая опцию
пользователя, сопровождаемую эти именем.

      При выборе записи из  файла  шифров  PAP  регистрируются  для
установления подлинности с peer, pppd должен знать название remote хоста.
Поскольку  это не имеет способа нахождения того, что Вы должны точно
определить  на  этой командной строке, используяе remotename  ключевого
слова,  сопровождаемого hostname peer. Для образца,  как  использовать
вышеупомянутую  запись  для установления подлинности с c3po, мы добавляем
опцию следования к  командной строке pppd's:

      \#{} pppd ... remotename c3po user vlager-pap

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

      Заметьте, что PAP довольно слабый опознавательный метод, и это
предполагает всякий раз, когда Вы используете CHAP,  если  это  возможно.
Мы  не  будем следовательно описывать PAP в  деталях  здесь;  если  Вы
заинтересованы  в использовании PAP, Вы найдете несколько больше в pppd
странице  справочника (8).

      9.11 Конфигурирование PPP сервера

      При  запуске  pppd,  поскольку    сервер - только    сущность
добавления соответствующей опции к  командной  строке.  Было  бы
идеальным,  если  Вы создали бы специальный account, скажем  ppp,  и


дадите  этому  script  или программе как оболочке входа в  систему,
которая  вызывает  pppd  с  этими опциями. Например, Вы бы добавили
следующую линия к /etc/passwd:


"
      ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin

      Конечно,  Вы  можете  захотеть    использовать   более
универсальные uids и gids чем те, что показанны выше. Вы также были  бы
должны установить пароль для вышеупомянутого account, использующего команду
passwd.

      Ppplogin script может быть выглядить следующим образом:

      #!/bin/sh
                 # ppplogin - script to fire up pppd on login
                 mesg n
                 stty -echo
                 exec pppd -detach silent modem crtscts

      Команда  mesg  блокирует  других  пользователей,  чтобы  записать  к
tty, используя,  на  пример,  команду  записи.  Команда  stty  выключает
знако-отображение на экране. Это необходимо, потому что иначе peer все
посылал бы используя отображение на экране. Наиболее важная опция  pppd,
данная  выше -detach, потому что это предотвращает pppd от  отсоединения
из  управления tty. Если мы не точно определим эту опцию, это будет  идти
к  предпосылке, создания shell script exit. Это было к зависанию. Silent
опция  заставляет pppd ждать, пока он не получит блок  от  системы  вызова
прежде,  чем  это начинает посылать.  Это  предотвращает  от  блокировки
по  времени,  когда система вызова медлена  в  обслуживании  PPP  наблюдать
DTR  линию,  чтобы видеть, понизил ли peer связь, и crtscts включает
аппаратное рукопожатие.

      Помимо этих опций, Вы могли бы захотеть вынудить некоторый  вид
опознания, например, точно определяя auth на командной строке pppd's, или в
глобальном файле опций. Руководство также обсуждает более специфические
опции для вкл. или выкл. индивидуальных опознавательных протоколов.





                    10. Различные сетевые приложения

      После успешной установки IP и решающего устройства, Вы должны
обратиться  к услугам  обеспечивающим  хорошую  работу  над  сетью.  Глава
начинается  с конфигурачия пескольких простых сетевых приложений, включая
Inetd сервер, и программы  из  rlogin  совокупности.  Незначительная
процедура   обращения связывает, с  помощью  интерфейса,  эти  услуги
подобно  Сетевой  Файловой системе (NFS). Сетевая Информационная Система
(NIS)  основана  на  том  же самом, имела дело с briefly. Конфигурация NFS
и NIS, однако берущяя большое количество памяти, будет описана в  отдельных
главах.  Это  применяется  к электронной почте и netnews также.

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

                           10.1 Inetd супер-сервер

      Часто, услуги  предоставляются  так  называемыми  daemons. Daemon
является программой, которая открывает некоторый порт, и связь. Если это
происходит, это создает дочерний процесс, который  принимает  связь,  в  то
время  как основной продолжает ждать дальнейших запросов. Это понятие имеет
недостаток что для каждого предлагаемого обслуживания,  daemon  должен
запускать  те, которые слушают порте для связи, для которых  это  вообще
означает  потери способов системы подобно пространст

      Таким образом, почти вся  Un*x  инсталляция  запускает  "  супер-
сервер  ", который создает гнезда для ряда услуг, и слушает на  них
одновременно  при использовании  отобранного  системного  вызова  (2).
Когда  отдаленный  хост запрашивает одну из услуг, супер-сервер замечает
этот  и  порождает  другой сервер, точно установленный для этого порта.

      Супер-сервер, обычно используемый - inetd, Internet Daemon. Это
начинается при начальной  загрузке  системы,  и  берет  список  услуг,  к


которым  он обращается из файла запуска, именованной /etc/inetd.conf.  В
дополнение  к тем вызываемым серверам, там есть ряд тривиальных услуг,
которые  являются на сформировавшимся inetd, неппсрежственно  вызываемым
внутренние  услуги. Они включают chargen  который  просто  генерирует  ряд
знаков,  и  daytime который возвращают system's idea

      Запись в  этой  картотеке  состоит  из  единственной  линии,
сделанной  из следующей области:



      service type protocol wait user server cmdline

      Значение каждой области следующие:

      Service дает сервисное имя. Service name должно быть  переведено  к
номеру порта, просматривая в файле services. Этот файл будет описан в
разделе 10.3.

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

      Protocol называется протоколом переноса,  используемым
обслуживанием.  Это должно быть подходящим названием протокола, найденное в
файле  протоколов, также объяснено ниже.

      wait эта опция применяется только на dgram гнездах. Это  может  быть
также wait или nowait. Если wait определен, то inetd только выполнит один
сервер для точно  установленного  порта  в  любое  время.  Иначе,  это
немедленно продолжит слушать на порте после извлечения сервера.

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


используется. Эти серверы должны точно определить nowait.

      Гнезда потока должны всегда использовать nowait.

      User это является идентичностью входа в систему  пользователя,
объясненный ниже. Это будет часто root user, но  некотпрые" услуги  могут
использовать различные  account.  Это  -  очень  хорошая  идея  к
применению   принципа наименьшего количества привилегии здесь, который
заявляет что Вы не  должны запускать команду ниже привилегированного
account если программа не требует этого для присущего функционирования. Для
примера,  NNTP  сервер  новостей будет запускать новости, пока ус риск
защиты (типа tftp, или finger)  будут управляться как nobody.



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

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

      Эта область пуста для внутренних услуг.

      Типовой  inetd.conf  файл  изображен  на  рисунке   10.1. Finger
service прокомментированног так чтобы это было не доступно. Это  часто
выполняется из соображений безопасности, потому что  может  использоваться
нападавшими для того, чтобы получить имя пользовател и на вашей системе.

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

      TFTP обычно используется клиентурой без диска и X терминалами при
загрузке их кода из сервера при начальной загрузке. Если Вы должны
запустить  tftpd для этой проблемы, удостоверитесь,  что  ограниченная


область  действия  к директориям клиентов будет восстановлена из файлов,
добавляя  те  названия каталогов к команде tftpd's линии. Это показано  во
второй  tftp  линии  в примере.

                       10.2 Tcpd средства управления доступом
  "
      Начиная с открытия компьютера  к  сети  средство  вовлекает  много
защиты, приложения разработанные так, чтобы  принять  меры  против  типов
решения. Некоторые  из  этих,  однако,  могут  быть  flawed  (наиболее
решительно демонстрированными RTM Internet  worm),  или  могут  не
различаться  между безопасными хостами,  из  которых  просьбы  о  частном
обслуживании  будут приняты, и опасными хостами, чьи запросы  должны  быть
отклонены.  Мы  уже кратко обсуждали finger и tftp услуги выше.



       #
       # inetd services
       ftp       stream tcp nowait root   /usr/sbin/ftpd    in.ftpd -l
       telnet    stream tcp nowait root   /usr/sbin/telnetd in.telnetd -
b/etc/issue
       #finger    stream tcp nowait bin    /usr/sbin/fingerd in.fingerd
       #tftp      dgram  udp wait   nobody /usr/sbin/tftpd   in.tftpd
       #tftp      dgram  udp wait   nobody /usr/sbin/tftpd  in.tftpd
/boot/diskless
       login     stream tcp nowait root   /usr/sbin/rlogind in.rlogind
       shell     stream tcp nowait root   /usr/sbin/rshd    in.rshd
       exec      stream tcp nowait root   /usr/sbin/rexecd  in.rexecd
       #
       #       inetd internal services
       #
       daytime   stream tcp nowait root internal
       daytime   dgram  udp nowait root internal
       time      stream tcp nowait root internal
       time      dgram  udp nowait root internal
       echo      stream tcp nowait root internal
       echo      dgram  udp nowait root internal
       discard   stream tcp nowait root internal


       discard   dgram  udp nowait root internal
       chargen   stream tcp nowait root internal
       chargen   dgram  udp nowait root internal

                     Рис. 15.   /etc/inetd.conf file.

      ограничить доступ к этим услугам " доверенные множества "  только,
которые невозможны с обычной установкой, где inetd  обеспечивает  эту
защиту  всей клиентуре.

     &Полззное средство для этого - tcpd, (1), так называемый daemon
wrapper. Для ТСP услуги Вы хотите проконтролировать или защищать его,
вызывая вместо его программу сервера. Tcpd  регестрирует  запрос  к  syslog
daemon,  проверяя позволяют ли remote хосту использовать  обслуживание,  и
только  если  это будет выполнено в реальной программе сервера. Заметьте,
что это не работа с udp-основанными услугами.

      Например, чтобы перенести finger daemon, Вы должны  изменить
corresponding линию в inetd.conf

            1. Написано Wietse Venema, [email protected].



       # wrap finger daemon
       finger  stream  tcp     nowait  root    /usr/sbin/tcpd   in.fingerd

      Без добавления какого-либо access контроля, это появится  у  клиенту
точно также как и обычная  установка  finger,  за  исключением  того,  что
любые запросы будут регистрироваться к syslog's auth facility.

      Управление  доступом  выполнено  посредством  двух    файлов,
называемых /etc/hosts.allow  и  /etc/hosts.deny.  Они  содержат  разрешение
входов  и отрицание доступа, соответственно, к некоторым услугам и хостам.
Когда tcpd обрабатывает  просьбу  о  обслуживании  finger  от
клиентского    хоста, именованного Biff.foobar.com, он просматривает
hosts.allow и hosts.deny  (в этом порядке) для соответствующей записи и
сервисного и клиентского  хоста. Если запись соответствия была найдена в


тся, независимо от любой  записи  в hosts.deny.  Если  соответствие
найдено  в  hosts.deny,  то  запрос  будет отклонен закрывая связь.схему.
Если никакое соответствие не найдено вообще, запрос будет принят.

      Входы в файл доступа выглядят следующим образом:

                 Servicelist: hostlist [: shellcmd]

      Servicelist - список сервисных имен из /etc/services,  или  ключевое
слово ALL. Чтобы соответствовать всем  услугам  за  исключением  finger  и
tftp, используйте "ALL"EXCGPT finger, tftp''.

      Hostlist - список имен хостов или адресов IP, или ключевых слов ALL,
LOCAL, или  UNKNOWN.  ALL  соответствует  любой  хост,  в  то  время  как
LOCAL соответствует имя хоста,  не  содержащие  точку.(2)  UNKNOWN
соответствует любым  множествам  чьи  названия  или  адреса  ошибочны.
Name    string, начинающееся с  точки  соответствует  всем  хостам,  чьи
области  является равными  этому  названию.  Например,.foobar.com  пара  -
Biff.foobar.com. Имеются  также  условия  для  IP  сетевых  адресов  и
подсет  к   странице справочника (5) для деталей.

      Для того, чтобы отказать в доступе к finger и tftp услугам, кроме
локальных хостов,  поместите  следующее  в  /etc/hosts.deny,  и    сделайте
пустым /etc/hosts.allow:

      2. Обычно только локальные имена хостов, полученные из поисков в
/etc/hosts не содержать никакой точки.



      in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain

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

                 in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
                       echo "request from %d@%h" >> /var/log/finger.log; \


                       if [ %h != "vlager.vbrew.com" ]; then \
                           finger -l @%h >> /var/log/finger.lы  отличны.
Область   псевдонимов позволяет  точно  определить  альтернативные  имена
для  того  же   самого обслуживания.

      Обычно, Вы не должны менять файл услуг, который приходит



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

       # The services file:
       #
       # well-known services
       echo           7/tcp                 # Echo
       echo           7/udp                 #
       discard        9/tcp  sink null      # Discard
       discard        9/udp  sink null      #
       daytime       13/tcp                 # Daytime
       daytime       13/udp                 #
       chargen       19/tcp  ttytst source  # Character Generator
       chargen       19/udp  ttytst source  #
       ftp-data      20/tcp                 # File Transfer Protocol (Data)
       ftp           21/tcp                 # File Transfer Protocol
(Control)
       telnet        23/tcp                 # Virtual Terminal Protocol
       smtp          25/tcp                 # Simple Mail Transfer Protocol
       nntp         119/tcp  readnews       # Network News Transfer
Protocol
       #
       # UNIX services
       exec         512/tcp                 # BSD rexecd
       biff         512/udp  comsat         # mail notification
       login        513/tcp                 # remote login
       who          513/udp  whod   "       # remote who and uptime
       shell        514/tcp  cmd            # remote command, no passwd
used


       syslog       514/udp                 # remote system logging
       printer      515/tcp  spooler        # remote print spooling
       route        520/udp  router routed  # routing information protocol


      Заметьте, что, например, обслуживание ECHO  предлагается  на  порте
7  для обоих и TCP и UDP, и этот порт 512 используется для двух различных
услуг, а именно для  СИСТЕМЫ  СПУТНИКОВОЙ  СВЯЗИ  КОМСАТ  daemon  (которые
сообщают пользователям относительно новой почты, смотри xbiff(1x)), над
UDP,  и  для remote execution (rexec(1)), используя TCP.



       #
       # Internet (IP) protocols
       #
       ip      0       IP              # internet protocol, pseudo protocol
number
       icmp    1       ICMP            # internet control message protocol
       igmp    2       IGMP            # internet group multicast protocol
       tcp     6       TCP             # transmission control protocol
       udp     17      UDP             # user datagram protocol
       raw     255     RAW             # RAW IP interface

            10.4 Дистанционное управление

      Очень общий механизм  для  клиент-сервера  приложения  обеспечивается
RPC, пакетом дистанционного управления. RPC был разработан  Sun
Micrsystems,  и эта система - набор инструментальных средств и библиотечных
функций. Важные приложения, сформированны на вершине RPC - NFS, Network
Filesystem, и  NIS, Network Information System, обе из которых будут
представлены  в  следующих главах.

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


преобразованны  к  так называемому  Внешнему  Представлению   Данных
(XDR)    отправителю,    и преобразованны обратно к машинно - локальному

      Иногда,  уточнения  к  RPC  приложению  вводят  несовместимые
изменения  в процедуре call interface. Конечно, при простом изменение
сервер разрушил бы все приложение, которые все еще ожидают original
behavior.  Следовательно, RPC программы имеют номера версии, приписываемые
к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с
помощью интерфейса этот счетчик. Часто, сервер может предлагать  несколько
версий  одновременно;  клиентура затем указывает номером версии версии они
хотят использовать.

      Сетевая  связь  между  RPC  серверами  и  клиентурой - особая. RPC
сервер предлагает один или более системных процедур; каждое  множество
называется программой,  и  однозначно  идентифицировано  номером
программы.    Имена обслуживания отбора списка существуют  для  того,
чтобы  запрограммировать числа обычно сохраняемые в /etc/rpc, выборка
которого  воспроизведена  ниже ра рисунке 10.4



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

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


portmapper  на  числа  порта  обслуживание,  которые могут быть достигнуты.

      Этот метод имеет частичный недостаток, что это  вводит  единственную
точку отказа, очень похожую на inetd daemon. Однако, этот  случай  немного
хуже, потому что когда portmapper умирает, вся RPC информация порта
теряется; это обычно значит, что Вы должны перезапустить все  RPC  серверы
вручную,  или перезагрузить целую машину.

      На  Linux,  portmapper  называется  rpc.portmap  и  постоянно
находится  в /usr/sbin. Кроме уверения того, что это начато из rc.inet2,
рortmapper  не требует любой работы по конфигурации.

      10.5 Конфигурирование r команд

      Имеется ряд команд для выполнения  команд  на  remote  хосте. Они -
rlogin, rsh, rcp и rcmd. Они все порождают оболочку на  remote  хосте  и
позволяют пользователю выполнять команды. Конечно, клиент  должен  иметь
account  на хосте, где команда должна быть выполнена. Таким  образом  все
эти  команды выполняют процедуру разрешения. Обычно, клиент сообщяет
название  входа  в систему пользователя на сервер, который



       #
       # /etc/rpc - miscellaenous RPC-based services
       #
       portmapper      100000  portmap sunrpc
       rstatd          100001  rstat rstat svc rup perfmeter
       rusersd         100002  rusers
       nfs             100003  nfsprog
       ypserv          100004  ypprog
       mountd          100005  mount showmount
       ypbind          100007
       walld           100008  rwall shutdown
       yppasswdd       100009  yppasswd
       bootparam       100026
  "    ypupdated       100028  ypupdate



                         Рис. 16.   A sample /etc/rpc file.

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

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

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

      Имеются два способа блокировать разрешение, для того чтобы проверить
r    команды. Каждый - для  супер  пользователя,  чтобы  позволить
некоторым  или   всем пользователям  зарегестрироваться  без  пароля.  Этот
доступ   управляется картотекой вызываемой /etc/hosts.equiv. Это содержит
список множеств и имен пользователя,  которые  рассматриваются
эквивалентными  пользователям   на локальном хосте. Альтернативная опция -
для пользователя  -  предоставление другим пользователям на некоторых  х
быть  перечислены  в  файле.rhosts  в директории пользователя. Для
соображений безопасности, эта картотека должна принадлежать пользователю
или супер пользователю, и не должна быть symbolic link, иначе это будет
игнорирован



      Когда клиент запрашивает r обслуживание, ее хост  и  название
пользователя ищются в файле /etc/hosts.equiv, и затем в файле.rhosts
пользователя. Как - пример,  предположим,   что    janet    работает "
гауссе    и    пытается зарегестрироваться в joe's account на euler. Следуя
далее, мы  обратимся  к Janet как клиентскому пользователю, и к Joe как к
Локальному  пользователю.


      Теперь, когда типы Janet

      $ Rlogin -l joe euler

      на гауссе, сервер сначала проверил  бы  hosts.equiv  (4),
предоставлен  ли Janet свободный доступ, и если нет, то он  попробует
просмотреть.Rhosts  в исходном каталоге joe's.

      Файл hosts.equiv на euler походит на это:

                 gauss
                 euler
                 -public
                 quark.physics.groucho.edu     andres

      Запись состоит из  названия  хоста,  необязательно  сопровождаемого
именем пользователем.  Если  название  множества  появляется   везде,    то
все пользователи от того множества будут допущены к  их  локальным  acount
без любых  проверок.  В  вышеизложенном    примере,    Janet    позволили
бы зарегестрироваться в ее account janet когда выходит из  гаусса,  и  тот
же самый применяется любому другому пользователю за исключением  root
Однако, если Janet захочет зарегестрироваться как joe ,  пароля как обычно.

      Если  название  хоста  сопровождается  названием  пользователя,  как
и   в последней линии вышеупомянутой типовой  картотеки,  то  этому
пользователю будет дан пароль-свободный доступ ко всем accont  за
исключением  accony\t root.

      Имени  хоста  может  также  предшествовать  знак  "минус",  как  на
записи "-общий". Это требует разрешения на все account  на  общем,
независимо  от того, что пользователи единичного права предоставляют в их
картотеке.rhosts.

      3. В NFS среде окружения, Вы были бы должны дать этому защиту  444,
потому что супер пользователь часто ограничивает в доступе  к  файлам  на
дисках, установленных через NFS.
      4. Заметить, что файл hosts.equiv не обыскан когда кто -то делает
попытку к регистрации как root.



                                   "   / 165 -

      Форматфайла.rhosts идентичен  таковому  hosts.equiv,  но  значение
немного отлично. Рассмотрите Joe's.rhosts файл на Euler:

      chomp.cs.groucho.edu
                 gauss      janet

      Первая запись допускает, что  joe  освобождают  acess  при
регистрации  из Chomp.cs.groucho.edu, но не воздействуют на права любого
другого account на euler или chomp. Вторая запись  -  небольшое  изменение
этого,  в  котором предоставляется janet свободный доступ к account  Joe
при  регистрации  из гаусса.

      Заметьте, что название хоста  клиента  получено  обратным  отбором.
Адрес вызывающего оператора к названию,  так,  чтобы  эта  особенность
failed  с хостами  к  решающему  устройству.  Имя  хоста  клиента
рассматривается  в соответствии с названим в хостах зарегистри рованных в
одном  из  следующих случаев:

      + Каноническиое имя хоста клиента (не  псевдоним)  буквально
соответствует имени хоста в файле.

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



                      11. Сетевая информационная система

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


множествами.  Мы  видели  перед  этим, что для решенияимени хоста, мощное и
сложное обслуживание существует, являющееся DNS. Для других задачи, имеется
нет  такого  специализированного обслуживания. Кроме того, если В малой
локальной вычислительной сетью с  no Internet activity, устанавливая DNS
может  показаться  утояыим  затруднение для многих администраторов.

      Это - то, почему Sun разрабатывало NIS, Сетевую Информационную
Систему. NIS обеспечивает обобщенные средства  доступа  к  базе  данных,
которые  могут использоваться для дизинформации данных типа этого,
содержали  в  passwd  и группах файлах всех множествах на вашей сети. Это
заставит  сеть  появиться только    как  единственная  система,  с  теми
же  самыми  account  на  всех множествах.  В   подобном  режиме,  Вы  может
использовать    NIS,    чтобы распределить hostname информационную форму
/etc/hos сети.

      NIS основан на RPC, и включает сервер, client-side библиотеку, и
несколько административных инструментальных  средств.  Первоначально,  NIS
назывался Желтые Страницы,  или  YP,  который  все  еще  широко
используется,  чтобы  неофициально обратиться к этой услуге. С другой
стороны, Желтые Страницы  - марка изготовителя Британской Телесвязи,
которая требует от Sun  убрать  то название. Поскольку вещи идут, некоторый
стержень имен с людьми, и  так  YP живет на префиксе к именам больш команд
типа ypserv, ypbind, и т.д. Сегодня, NIS доступны для виртуально  всего
Un*ces  и  там  даже  свободно реализуется. Каждый - из BSD разъединения
Сеть -2 выпуск, и был получен  из общей пожертвованной реализации сноски
области Sun. Библиотечная клиентская цифра из этого разъединения была в GNU
Libc в течение длительного  времени, в то время как административные
программы  только  недавно  пренесенные  к Linux Swen Thmmler. (1)  NIS
сервер  -  отсутствуетиз  реализации  сноски. Tobias Reber написал другой
NIS пакет, е средства и сервер; это  называется yps. (2)

      В настоящее время(постоянно), полная перезапись цифры NIS, называемой
NYS, сделанная Peter Eriksson, (3), который поддерживает  оба,  и  plain
NIS  и Sun's much пересмотренным NIS.

      1. [email protected]. NIS клиентура доступнаы  как  yp-
linux.tar.gz  из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от
этой записи) - yps-0.21  и  может  быть  получена  из ftp.lysator.liu.se в


/pub/NYS каталоге. 3. [email protected].



      +. NYS не только обеспечивает  множество  NIS  инструментальных
средств  и сервера, но  и  также  прибавляет  новое  множество
библиотечных  функций, которые будут наиболее возможными для того, чтобы
попасть в стандарт libc в конечном счете. Это включает новую
конфигурационную схему  порции  hostname решения,  которое  заменяет
текущую  схему    использованную    host.conf. Особенности этих функций
будут обсуждены ниже.

      Эта глава сосредоточится на NYS  скорее  чем  на  двух  других
пакетах,  к которому я буду относить как " традиционную " NIS  цифру.  Если
Вы  хотите запустить этих пакетов, то команд, описанных в этой  главе
может  быть  не достаточно. Чтобы получать дополнительн ую информацию,
пожалуйста  найдите стандартную книгу по NIS, типа NFS Hal Stern's и NIS
(см. [GETST "строгий - nfs"]).

      В настоящее время, NYS - все еще развивается, и  следовательно
стандартные Linux утилиты типа сетевых программ или входа в систему
программ,  еще  не знает NYS схему конфигурации. Пока NYS соединяется  в
mainstream  libc  Вы должны перетранслировать все эти binaries,  если  Вы
хотите  заставить  их использовать NYS. В любом из  этих  приложений
формирования  файла,  точно определите -lnsl как последнюю опция libc к
компоновщику.  Это  связывается на релевантных функциях из libnsl, NYS
стандарной библиотекы для C.

                            11.1 Знакомство с NIS

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

      Отпбражения сами по себе  обычно  генерируются  из  текстовых  файлов
типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные


отображения  - созданы, один для каждого типа клавиши. Например,  Вы
можете  искать  хост файл для имени хоста также как  для  адреса  IP.
Соответственно,  два  NIS отображения получены из  файла,  вызываемый
hosts.byname  и  hosts.byaddr, соответственно. Таблица 11.1 списков общих
отображений и файлов из кооторых они сгенерированны.

      4. DBM - простая библиотека  управления  базой  данных  которая
использует метод хеширования, чтобы ускорить операцию исследования. Имеется
свободная DBM реализация из  GNU  проектируемая  вызываемой  Gdbm,  который
является частью большинства Linux распространен ия.



              -----------------------------------------------------------
              +-----------------+---------------------------------------+
              |Master File      | Map(s)                                |
              +-----------------+---------------------------------------+
              +-----------------+---------------------------------------+
              |/etc/hosts       | hosts.byname       hosts.byaddr       |
              |/etc/networks    | networks.byname    networks.byaddr    |
              |/etc/passwd      | passwd.byname      passwd.byuid       |
              |/etc/group       | group.byname       group.bygid        |
              |/etc/services    | services.byname    services.bynumber  |
              |/etc/rpc         | rpc.byname         rpc.bynumber       |
              |/etc/protocols   | protocols.byname   protocols.bynumber |
              |/usr/lib/aliases | mail.aliases                          |
              +-----------------+---------------------------------------+
              +-----------------+---------------------------------------+

      Таблица 1. Некоторый стандарт NIS отображения и соответствующие
чайлы.

      Имеются другие файлы и отображения, которые Вы можете  найти  в
любом  NIS пакете или  другом.  Они  могут  содержать  информацию  для
приложений  не обсуждаемых в  этой  книге,  типа  bootparams  отображения,
которое  может использоваться некоторыми BOOTP серверами, или подобно
которому в настоящее время не  имеют  любую  функцию  в  Linux
(Ethers.byname  и  ethers.byaddr отображения).



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

                 $ ypcat -x
                 NIS map nickname translation table:
                         "passwd" -> "passwd.byname"
                         "group" -> "group.byname"
                         "networks" -> "networks.byaddr"
                         "hosts" -> "hosts.byname"
                         "protocols" -> "protocols.bynumber"
                         "services" -> "services.byname"
                         "aliases" -> "mail.aliases"
                         "ethers" -> "ethers.byname"
                         "rpc" -> "rpc.bynumber"
                         "netmasks" -> "netmasks.byaddr"
                         "publickey" -> "publickey.byname"
                         "netid" -> "netid.byname"
                         "passwd.adjunct" -> "passwd.adjunct.byname"
                         "group.adjunct" -> "group.adjunct.byname"
                         "timezone" -> "timezone.byname"



      NIS сервер традиционно называется ypserv. Для  средней  сети
единственного сервера обычно хватает; большие сети могут выбирать несколько
серверов  на различных машинах и различных сегментах сети, чтобы уменьшить
загрузку  на машинах сервера и программах  маршрутизации.  Они
синхронизированы,  делая один из них главным сервером, к другие
подчиненными серверами.  Отображения будут созданы только на master
server's host. Оттуда, они распределены всем slaves/

      Вы отметили, что мы говорили относительно " сети " очень
неопределенно  все время; конечно имеется отличительное понятие в  NIS,
которое  относится  к такой сети, и которая является системой всех  хостов
та  часть  их  данных конфигурации системы сделанны через NIS:  NIS


область.  К  сожалению,  NIS области не имеют  абсолютно  ничего  общего  с
областями,  с  которыми  мы столкнулись в DNS. Избегая любой
неоднозначности через эту  главу,  я  буду всегда точно определять который
тип области

      NIS области имеют совершенно административную  функцию  только. Они
обычно невидимы для пользователей, кроме разделения паролей между всеми
машинами в области. Следовательно, название,  данное  NIS  области
релевантно  только администраторам. Обычно, любое название будет  как
длинный  поскольку  это отлично от любого другого NIS названия области  на
вашей  локальной  сети. апример, администратор в Virtual Brewery может
создайть две  NIS  области, одну для Brewery непосредственно,  и  о
которыу  она  называет  brewery  и winery, соответственно. Другая
совершенно  общая  схема  для  того,  чтобы просто использовать DNS
название  области  для  NIS.  Чтобы  установить  и показать NIS название
области  вашего  множества,  domainname.  Когда  она вызывается без любого
аргумента, это печатает текущее NIS название области; к множеству названия
области, Вы должны стать супер пользователеми ввести:

      # domainname brewery

      NIS  области  определяют,  какой  NIS  сервер-приложение  сделает
запрос. Например, программа входа в систему на множестве в Winery  должна,
сделать запрос NIS сервера Winery (или один из них, если они там были
отделены) для информации пароля пользователя; в то время как приложение на
Brewery  host должно приклеится к серверу Brewery'.

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





      Запрос,  любое  приложение,  сначала  выясняти  от  ypbind  который
сервер используется.

      Ypbind исследует серверы, передавая к локальной  IP  сети;  сначало
первый ответ принят, чтобы быть потенциально самым быстрым и будет
использоваться во всех последовательных запросах NIS. После того, как
некоторый  интервал истек, или если сервер становится недоступным, ypbind,
исследует  активные серверы снова.

      Теперь, спорная точка относительно динамического  связывания - то,
что  Вы редко нуждайтесь в этом, и что  это  вводит  задачу  защиты:
ypbind  слепо верит, кто бы ни отвечаел, который мог бы быть NIS  сервером
также  как  и "злоумышленник". Само собой разумеется это становится
затруднением  -  если Вы управляете вашими базами данных паролей над NIS.
Для принятия мер против этого, NYS не использует ypbind по умолчанию, но
подбирает сервер для имени хостаиз файла конфигурации.

      11.2 NIS против NIS +

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

      Традиционный NIS имеет RPC номер версии 2, в то время как NIS + -
версию  - 3.

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


заинтересованы  в  изучении большего, пожалуйста обратитесь к  NIS  Sun  +
справочника  администратора ([GETST "nisplus"]).

      11.3 Клиентская Сторона NIS



      Если Вы знакомы с записью или перенесением приложений сети, Вы
обязательно заметите, что большинство NIS отображений, перечисленных выше
соответствуют библиотеке  функций  в  библиотеке  C.  Например,  чтобы
получить   passwd информацию, Вы используете getpwnam (3)  и  getpwuid
функции  (3)  которая возвращает информацию счета, связанная с  данным
именем  пользователя  или численной идентичностью пользователя. При
нормальных  обстоятельствах,  эти функции  будут  выполнены  при  запросе
по  на  стандартном  файле,   типа /etc/passwd.

      Nis-знающяя реализация этих функций, однако, будет модифицированна, и
место обращения RPC для того, чтобы иметь NIS сервер для поиска имен
пользователя или идентичность. Это случается  полностью  с  приложением.
Функция  может также "конкатенировать " NIS отображение или "  заменить  "
первоначальную картотеку с этим. Конечно, это не относится к реальной
модификации  файла, это только означает то, что он появляется к приложению
как если бы файл был бы заменен или конкатенирован.

      Для  ттадиционных  NIS  реализаций,  там  использовались  общие
условия, относительно которых замененные отображения, и которые были
конкатенированы к исходной информации. Некоторые, подобно  passwd
отображениям,  требуемым kludgy modifications картотеки passwd, который,
когда выполнен неправильно, обнаружил бы защиту. Чтобы избежать этого
pitfalls,  NYS  использует  общую схему  конфигурации  это  определяет,
использует  ли  частное    множество клиентских функций первоначальную
карто  и  в  каком  порядке.  Это  будет описанный позже.

                             11.4 Запуск NIS Сервера

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


сервера  на вашей сети, Вы не должны будете установить ваш собственный
сервер;  в  этом случае, то Вы можете безопасно пропускать этот раздел.

      <>   Note  that  if  you are just going to experiment with the
           server, make sure you don't set it up for  a  NIS  domain
           name  that  is  already  in use on your network. This may
           disrupt the entire network service and make a lot of peo-
           ple very unhappy, and very angry.

      В настоящее время используются два  NIS  сервера,  свободно
доступные  для Linux, один содержится в yps  пакете  Tobias  Reber's,  и
другой  в  Peter Erikson's  ypserv  package.  Это  не  должно  иметь
значение,  который  Вы запускаете, независимо



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

      После установки программы сервера (ypserv) в /usr/sbkn, Вы  должны
создать каталог,  который  будет  проводить  отображение,  регистрируемо
на  Вашем сервере. При установке NIS области для brewery domain,
отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это
частную NIS  область, проверяя есть ли каталог отображений. Если Вы
блокируете  обслуживание  для некоторой NIS области, удостоверитесь удален
ли каталог также.

      Отображения обычно сохраняются в картотеках DBM, чтобы ускорить
поиски. Они создаются  от  главы,  регистрирующей  использование  программ,
называемой makedbm (для Tobias' сервер) или dbmload  (для  сервера
Peter's).  Они  не могут  быть  изменчивыми.  Преобразовани  е  главы
регистрирует  в   форму parseable dbmload обычно требуя  некоторого  awk
или  sed,  которые  имеют тенденцию, чтобы быть немного утомительными к
типу.  Следовательно,  Peter Eriksson's Ypserv пакет содержит Формирование
который делает всю работу  за Вас. Вы должны установить это как


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

      all: ethers hosts networks protocols rpc services passwd group netid

      Если Вы не хотите производить ethers.byname  и  ethers.byaddr
отображения, например,  просто  удалите  предпосылку  эфиров  из  этого
правила.Чтобы проверить вашу установку, это может  удовлетворять  тому,
чтобы  начать  с только  одного или двух отображении, подобно услугам. *
Отображения.

      После редактирования Формирования файла, в то время  как  Вы
находитесь  в каталоге отображений,  набирите  "make".  Это  автоматически
генерирует  и устанавливать отображения. Вы должны удостовериться,  чтобы
модифицировать отображения всякий раз, когда Вы изменяете главный  файл,
иначе  изменения останутся невидимыми для сети.

      Следующий раздел объясняет, кгк конфигурировать NIS  клиентский  код.
Если ваша установка не работает, Вы должны пробовать выяснить или любые
запросы достигнут вашего сервера или нет. Если Вы  точно  определяете
команду  -D, флажок линии к NYS серверу, то это печатает сообщения  отладки
на  консоли относительно всех входящих запросов NIS, и  возвращенных
результатов.  Они должны дать Вам подсказку относительно того, где задача
находится.  Tobias' сервер не имеет никакой такой опци



                    11.5 Установка NIS Клиента с NYS

      Через остаток от этой главы, мы опишем конфигурацию NIS клиента.

      Ваш первый шаг должен быть - сообщить NYS который  сервер
использован  для NIS обслуживания, устанавливая это в файле конфигурации
/etc/yp.conf. Очень прост типовой файл для множества сети Winery's  может
выглядеть  следующим образом:



      # yp.conf - YP configuration for NYS library.
           #
           domainname winery
           server vbardolino

      Первая формулировка сообщает всей NIS  клиентуре,  что  они
принадлежат  к Winery NIS области. Если Вы упускаете эту линию,  NYS
использует  название области, которой Вы приписывали  вашу  систему  через
команду  domainname. Сервер формулировки называется NIS сервером. Конечно,
IP адреса  адресуются к vbardolino, и должны быть хостом в файле хоста; в
качестве  альтернативы, Вы можете использовать адрес IP непосредственно с
формулировкой сервера.

      В форме, показанной выше, команда сервера сообщает, чтобы  NYS
использовал именованный сервер любой NIS области которой может быть. Если,
однако,  Вы перемещаете вашу  машину  между  различными  NIS  областями
часто,  то  Вы возможно захотите сохранить информацию для отдельных
областей  в  картотеке yp.conf. Вы можете иметь информацию относительно
серверов для различных NIS областей в Yp.conf, прибавляя NIS название
области к формулировке  сервера. Для образца, Вы могли бы измен"типовой
файл для портативной ЭВМ, чтобы  это выглядило подобно этому:

      # yp.conf - YP configuration for NYS library.
           #
           server vbardolino winery
           server vstout     brewery

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



      просто при установке желательной NIS области при начальной загрузке
введите команду названия.

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


hosts.byname,  и  испытанию, чтобы восстановить, используя ypcat утилиту.
Ypcat,  подобно  всем  другим административным NIS инструментальным
средствам, должен жить в /usr/sbin.

           # ypcat hosts.byname
           191.72.2.2      vbeaujolais  vbeaujolais.linus.lxnet.org
           191.72.2.3      vbardolino   vbardolino.linus.lxnet.org
           191.72.1.1      vlager       vlager.linus.lxnet.org
           191.72.2.1      vlager       vlager.linus.lxnet.org
           191.72.1.2      vstout       vstout.linus.lxnet.org
           191.72.1.3      vale         vale.linus.lxnet.org
           191.72.2.4      vchianti     vchianti.linus.lxnet.org

      Вывод, который Вы получаете, должен быть на подобие  вышепоказанного.
Если Вы получаете сообщение об ошибках взамен, которое говорит  "Can't
bind  to server which serves domain"  или  что-нибудь  на  подобие,  затем
или  NIS название области, которое не  имеет  сервер  соответствия,
определенный  в yp.conf, или сервер  -  unreachable  по  некоторым
причинам.  В  последнем случае, удостоверитесь в том, что ping множеству
производится положительный результат, и что это действительно  запу  Вы
можете  проверить  последний, используя rpcinfo, который должен произвести
следующий вывод:

      # rpcinfo -u serverhost ypserv
           program 100004 version 2 ready and waiting

      11.6 Выбор правых отображений

      Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы  должны
решить который  конфигурационный  файл,  чтобы  заменить  или  увеличить  с
NIS отображениями.  Обычно,  Вы  захотите  использовать  NIS  отображения
для множества и функций поиска пароля. Вышеупомяну тый особенно  полезен,
если Вы  не  запускаете  BIND.   Последний    разрешает    всем
пользователям зарегестрироваться на их account из любой системы в NIS
области; это обычно требует разделения  центрального  /местного  к  Это
объяснено  подробно  в разделе  11.7 ниже. Другое отображение, подобно
services.byname,  не  такое драматическое увеличение, но сохраняют Вас





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

      Вообще, Вы  хотите  иметь  некоторую  свободу  выбора  когда  поиск-
функция использует локальные файлы, и когда это  делает  запрос  NIS
сервера.  NYS позволяет Вам сконфигурировать порядок, в котором функция
обращается к этим услугам.  Это  управляется  через  картотеку
/etc/nsswitch.conf,   который замещает  обслуживание  названия,  но
конечно  не  ограничивает   название обслуживание. Для любой  из  функций
поиска  данных  это  содержит  линию, именующие услуги, чтобы использовать.

      Правильный порядок услуг зависит  от  типа  данных. Это  вряд  ли
то,  что services.byname  отображение  будет  содержать  отличие  входов
из  тех  в локальном файле услуг; это может только содержать больше. Так
хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и
проверять  NIS только если сервисное название не  было  найдено.  Hostname
информация,  с другой стороны, может изменятся пченю часто, так, чтобы DNS
или NIS  сервер всегда имел наиболее точный accoun файл сохран как
дублиррование, если  DNS и NIS терпел неудачу. В этом случае, Вы  захотели
бы  проверить  локальный последний файл.

      Пример  ниже  показывает,  как    сконфигурировать    gethostbyname
(2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они
будут перечисленны как услуги по очереди; если поиск идет  хорошо,  то
результат будет возвращен, иначе следующее обслуживание осуждено.

      # small sample /etc/nsswitch.conf
           #
           hosts:     nis dns files
           services:  files nis

      Полный список услуг, которые могут использоваться с записью в
Nsswitch.conf файле показыны  ниже.  Фактические  отображения,  файлы,
серверы  и  вещи, которые делают запрос зависят от названия записи.



      Nisplus или nis + использует NIS + сервер  для  этой  области.
Локализация сервера получена из картотеки /etc/nis.conf.

      Nis Использует текущий NIS сервер этой области. Локализация  сервера
делал запрос, сконфигурированный в картотеке yp.conf как  показано  в
предыдущем разделе. Для  записи  множеств,  отображения  Hosts.byname  и
hosts.byaddr делают запрос.

      -176 -

      dns использует DNS сервер. Этот служебный тип  полезен только для
записи хоста. Сервера делающие запрос,  все еще определяются в соответствии
cо стандартом resolv.conf файла.

       files использует локальный файл, такой как /etc/hosts файл для хост
записи.

      dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя,
используемое для файла - соответствующего NIS отображение.

      В настоящее время, NYS поддерживает следующие nsswitch.conf записи:
hosts,
      networks, passwd, group, shadow, gshadow, services, protocols, rpc, и
др. Другие записи возможно могут быть добавленны.

      Рисунок 11.6 показывает более полный пример, который демонстрирует
другую
     &осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях
хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS
или в DNS база данных. То есть NYS продолжит искать локальные файлы, только
если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой
причине. Локальные файлы будут затем только использоваться при начальной
загрузке и как backup, когда NIS сервер выключен.

      11.7 Использование passwd и группы Maps

      Одно из главных приложений NIS находится в синхронизации пользователя
и account информации относительно всех множеств в NIS области. К концу, Вы


обычно хранит только малый локальный файл /etc/passwd, к которому
добавлена site-wide информация из NIS отображений. Однако, просто
предоставления возможности NIS поиска для этого обслуживания в
nsswitch.conf не вполне достаточно.

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



                # /etc/nsswitch.conf
                #
                hosts:      nis dns [NOTFOUND=return] files
                networks:   nis [NOTFOUND=return] files

                services:   files nis
                protocols:  files nis
                rpc:        files nis

                Рисунок 17. Примерный nsswitch.conf файл.

      Если любая из числовых идентичности в /etc/passwd или /etc/group
отклоняется от тех, которые в maps, то Вы должны скорректировать файл
ownerships для всех файлов, которые принадлежат этому пользователю. Сначала
Вы должны заменить все uids и gids в passwd и в группах  новых значений;
затем найдите вуе фвйлы, которые принадлежат пользователям и былы только
что изменены, и в заключение замените их ownerships. Примите новости
используемые для того, чтобы иметь идентичность пользователя была бы 9, и
okir имел бы идентичность пользователя 103, которые были заменены на
некоторое другое значение; Вы могли бы затем выпорлнить следующие команды:

      # find / -uid   9 -print >/tmp/uid.9
      # find / -uid 103 -print >/tmp/uid.103
      # cat /tmp/uid.9   | xargs chown news


      # cat /tmp/uid.103 | xargs chown okir

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

      Сделав это, численный uid's и gid's на вашей системе согласиться с
теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет
- прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски
для пользователя и информации группы:



      # /etc/nsswitch.conf - passwd and group treatment
           passwd: nis files
           group:  nis files

      Это заставляет команду входа в систему, и всех ее друзей сначала
сделать запрос NIS maps, когда пользователь пробует log in, и если этот
поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы
удалите почти всех пользователей из Вашего локального файла, и только
оставите записи для root и generic accounts подобно почте. Это потому, что
некоторые насущные задачи системы могут требовать к map uids имя
пользователя или наоборот. Например, административный cron job может
выполнить команду su, для того чтобы временно стать новостями, или UUCP
      подсистема может отправлять по почте отчет состояния. Если новости и
uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению,
терпеть неудачу в течение&NIS"brownout.


      Имеются две большие проблемы: с одной стороны, установка, как уже
было описано в начале, до сих пор работает только для наборов программ
входа в систему, которые не используют теневой пароль, подобно тем, что
включены в util-linux пакет. Путаница при использовании теневых паролей с
NIS будет объяснена ниже. С другой стороны, команды входа в систему - не
единственые,  которые обращаются к passwd файлу - посмотрите на команду ls,
которую большинство людей использует почти постоянно.


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

      Но пока это еще не вся история. Вообразите, что случится если
пользователь захочет изменить свой пароль. Обычно, она вызовет passwd,
который считает новый пароль и модифицирует локальный файл passwd. Это
невозможно сделать с NIS, так как с тех пор файл локально больше не
доступен, но если пользователи подсоединились к NIS серверу, и вдруг
захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому,
NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который
делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост
сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и
обеспечивает его модифицируемой информацией пароля. Обычно, Вы
устанавливаете yppasswd для нормальной программы,  делая что - нибудь вроде
этого:

      # cd /bin
      # mv passwd passwd.old
      # ln yppasswd passwd





      В то же самое время Вы должны установить rpc.yppasswdd на сервер и
запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от
ваших пользователей.

      11.8 Использование NIS с Shadow Support

      Не имеется никакой NIS поддержки для мест, которые используют теневой
вход в систему набора программ. John F. Haugh, автор теневого набора
программ, недавно выпущенной версии теневых библиотечных функций, описанных
GNU библиотекой GPL к comp.sources.misc. Это уже имеет некоторую поддержку


для NIS, но она пока еще не полна, и файлы пока еще не добавлены к
стандарной библиотеке для C. С другой стороны, при публикации информации из
/etc/shadow через NIS вид поражения цели теневого набора программ.

      Хотя NYS функции поиска пароля не используют shadow.byname map или
что - либо аналогичное, очевидно NYS поддерживает использование локального
/etc/shadow файла. Когда NYS реализация getpwnam обращается к просмотру
информации, связанной  с данным login именем, средства, точно определенные
passwd записью в nsswitch.conf делают запрос. Nis обслуживание будет просто
искать имя в passwd.byname map на NIS сервере. Обслуживание файлов, однако,
проверит, существует ли /etc/shadow, и если существует, то попробует
открыть это. Если ни один из файлов не присутствует, или если пользователь
не имеет привилегию root, то происходит возвращение к обычной работе поиска
информации пользователя в /etc/passwd. Однако, если теневой файл существует
и может быть открыт, то  NYS извлечет пароль пользователя из shadow.
Getpwuid функция соответственно выполняется. В этом режиме, binaries,
компилируемый с NYS, будет иметь дело с локальной  установкой теневого
набора программ.

      11.9 Использование традиционного NIS кода.

      Если Вы используете код клиента, который находится в стандарте libc,
то конфигурация NIS клиента немного отлична. С одной стороны, это
использует ypbind daemon для того, чтобы передать информацию для активных
серверов скорее чем считывать эту информацию из файла конфигурации. Вы
следовательно должны удостоверится в том, что бужет запущен ypbind при
начальной загрузке. Он должен быть вызван после установленной NIS области,
и RPC portmapper тоже должен быть запущен. Вызов ypcat нужен для того,
чтобы проверить работает ли сервер так, как он должен (см. выше).

      Недавно, имелось некоторое число bug reports, которые сообщают, что
NIS терпит неудачу, сообщая при этом: "clntudp create: RPC: portmapper
failure - RPC: unable  to receive''.



      Это все из-за несовместимого изменения в способе, как ypbind
связывается с библиотечными функциям. Получая последние источники для NIS


утилит и  перетранслируя их, должна быть исправлена эта задача. (5)

      Также, способ традиционного NIS решает это,  как соединить NIS
информацию с этим из локальных файлов отклоняемую от используемого NYS.
Например, чтобы использовать NIS отображение пароля, Вы должны включить
следующую линию где-нибудь в Вашем /etc/passwd map:

           +: *:0:0:::

      Это маркирует место где функции поиска пароля  "вставляют" NIS
отображения. Вставка подобной линии (минус последние два двоеточия) в
/etc/group делают тот же самое для group. * maps. Для того, чтобы
использовать hosts.* maps, распределенные NIS, измените order line в
host.conf файле. Например, если Вы хотите использовать NIS, DNS, и файл
/etc/hosts (в том порядке), то  Вы должны изменить эту линию на:

      order yp bind hosts

      Традиционная NIS реализация не поддерживает никакие другие
отображения в настоящее время.

      5. Источник для yp-linux может быть получен из ftp.uniрaderborn.de в
каталоге /pub/Linux/LOCAL.



      12. Сетевая файловая система (NFS)

       NFS, the network file system, является возможно наиболее видной
сетью услуг, использующей RPC. Это позволяет обращаться к файлам на
отдаленных хостах точно
      тем же самым способом, как пользователь обратился бы к любым"
локальным файлам. Сделано возможным смешением kernel функциональных
возможностей на клиентской стороне (которая использует отдаленную файловую
систему) и NFS сервер на стороне сервера (который обеспечивает файл
данных). Этот доступ к файлу полностью очевиден  клиенту, и работает через
все разнообразие серверов и архитектуры хостов.



      NFS предлагает ряд преимуществ:


      + Данные, к которым обращаются все пользователи, могут быть сохранены
на центральном хосте, с клиенами устанавливающими этот каталог при
начальной загрузке. Например, Вы можете сохранить все accounts
пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount
/home от того хоста. Если оно установлено бок о бок с NIS, то  пользователи
могут затем войти в любую систему, и все еще работать на одном множестве
файлов.

      + Данные, потребляющие большие количества дискового пространства
могут быть сохранены в единственном хосте. Например, все файлы и программы
относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в
одном месте.

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


      Linux NFS - в значительной степени работа Rick Sladkey, (1), кто
написал NFS
      kernel код и большие части NFS сервера. Последний,  выводил из unfsd
пространства пользователя NFS сервер, первоначально написанный Mark Shand,
и hnfs Harris NFS сервер, написанный Donald Becker.

      Давайте теперь посмотрим том, как NFS работает: клиент может
запросить установить каталог от отдаленного хоста на локальном каталоге тем
же способом, и он может установить физическое устройство. Однако,
синтаксис, используемый для того, чтобы точно определить отличен ли
отдаленный каталог. Например, чтобы mount /home хост vlager к /users на
vale, администратор выпустил бы следующую команду на vale: (2)
   "
      1. Rick может быть найден в [email protected].


      # mount -t nfs vlager:/home /users



      mount затем попробует соединиться с mountd, устанавленный с daemon на
vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и
если так, вернет это  к file handle. Этот handle файл будет использоваться
во всех последовательных запросах к картотекам ниже /users.

      Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут
nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя
файла, к которому обращаются, и user's user и идентичность группы как
параметры. Они используются в определении прав доступа к точно
определенному файлу. Чтобы предотвратить от несанкционированного чтения или
модифицирования файла, пользователь и идентичность группы должны быть теме
же самыми на обоих хостах.

      На большинстве Un*x  реализаций, NFS функциональные возможности обоих
клиентов и сервер выполнены как kernel уровень daemons, которые начаты из
пространства пользователя при начальной загрузке системы. Они - NFS daemon
(nfsd) на хосте сервера, и  блок ввода - вывода Daemon (biod) выполняющийся
на клиентском хосте. Чтобы улучшить производительность, biod выполняет
асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также,
несколько nfsd daemons обычно запускается совместно.

      NFS реализация Linux, немного отлична в этом самом клиентском коде,
крепко объединена в файловой системе (VFS) уровень ядра и не требует
дополнительного управления через biod. С другой стороны код сервера
запускается полностью в пространстве пользователя, так, чтобы при запуске
нескольких копий сервера в одно и то же время было бы почти невозможным из-
за синхронизации. Linux NFS, в настоящее время также существует отсутствие
чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот
недостатолк в ближайшее время. (3)


      Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel
версии 1.0 не способен распределить память в кусках больших чем 4k; как
следствие, сетевой код не может обрабатывать датаграммы большие чем
приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это
значит, что передача к  и из NFS daemons выполняющейся на системах, которые
используют большие UDP датаграммы по умолчанию (например 8k на SunOS)


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

      2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount
видит из двоеточия то, что это определяет NFS объем.
      3. Задача с write-behind - то, что kernel буфер кэша индексирован
парами device/inode, и следовательно не может использоваться для nfs-
установленных файловых систем.





      12.1 Подготовка NFS

      Прежде, чем Вы можете использовать NFS, будь это сервер или клиент,
Вы должны удостовериться, что Ваше ядро имеет NFS поддержку, компилируемую
в. Более новые ядра для этого имеют простой интерфейс на proc файловой
системе, файл /proc/filesystems, который Вы можете отобразить используя
cat:

      $ cat /proc/filesystems
                   minix
                   ext2
                   msdos
           nodev   proc
           nodev   nfs

      Если nfs отсутствует из этого списка, то Вы должны скомпилировать
Ваше собственное ядро с включенным NFS. Конфигурирование kernel сетевых
опций объяснено в разделе " Kernel конфигурация " главы 4 ..

      Для более старых ядер до 1.1 Linux, самый простой способ выяснять
имеет ли ваше ядро включенную NFS поддержку - фактически попробовать
установить NFS файловую систему. Для этого, Вы могли бы создать каталог
ниже /tmp, и&поптобовать  установить локальный каталог на нем:



      # mkdir /tmp/test
      # mount localhost:/etc /tmp/test

      Если эта попытка установки выдает сообщениее об ошибках выводя, "fs
type nfs no supported by kernel'', то Вы не должны делать новое ядро с
включенной NFS. Любые другие сообщения об ошибках полностью безобидны, так
как Вы пока еще не сконфигурировали NFS daemons на вашем множестве.

      12.2 Установка NFS значения

      4. Как мне объяснил Alan Cox: NFS спецификация требует сервер к
потоку при каждой записи на диск прежде, чем он успевает вернуть
подтверждение. Так как BSD ядра только способны к, установленным по размеру
страницей, записям (4K), записанным по 4 куска по 1k каждый в bsd-based
NFS, серверу получает в результате 4 операции записи по 4k каждый.



      NFS значения (5) установлены таким же способом, как и обычные
файловые системы
      установленны. Вы вызываете mount, используя следующий синтаксис:

      # mount -t nfs nfs volume local dir options

      Nfs значение дано как отдаленный хост: отдаленная директория. С тех
пор как эта совокупность условных знаков является уникальной в NFS файловых
системах, то Вы можете не учитывать  nfs опцию -t.

      Имеется ряд дополнительных опций, которые Вы можете точно определить
установив над mounting NFS значение. Они могут также быть даны -o
переключателем в командной строке, или в области опций /etc/fstab записей
для значения. В обоих случаях, составные опции отделены друг от друга
запятыми. Опции, точно определенные на командной строке всегда отменяют те,
что были даны в файле fstab.

      Типовая запись в /etc/fstab могла бы быть такой:



      # volume              mount point       type  options
      news:/usr/spool/news  /usr/spool/news   nfs   timeo=14,intr

      Этот значение может затем быть установлено при использовании

      # mount news:/usr/spool/news

      В отсутствии fstab записи, NFS устанавливает просмотр вызовов
большинства uglier. Например, предположим, что Вы устанавливаете home
каталоги Ваших пользователей
      из машины, называемой moonshot, которая использует заданный по
умолчанию размер блока равный 4k для операции чтения - записи. Вы могли бы
уменьшить размер блока до 2k, чтобы подойти под размер Linux(овских)
датаграмм введя следующую команду:

      # mount moonshot:/home /home -o rsize=2048,wsize=2048

      5. Никто не говорит "файловая система", потому что здесь не
существует подходящей файловой системы.



      Список всех допустимых опций полностью описан в руководстве по
Nfs(5), которая идет вместе с Rick Sladkey's NFS-aware  mount  tool,
который может быть найден в Util-linux пакете Rik Faith). Следующее -
незавершенный список тех, которые Вы возможно захотели бы использовать:

      rsize=n и wsize=n - они точно определяют датаграмный размер,
используемый NFS
клиентурой при чтении и записи запросов, соответственно. В
настоящее время они  определенны по умолчанию - 1024 байтам,
из-за предела на UDP размере датаграммы, описанном выше.

      timeo=n - это устанавливает время (в десятках секунд),  сколько NFS
клиент будет ждать        запрос,
чтобы завершить работу. Значения по умолчанию - 0.7 секунды.

      hard - точно маркирует этот объем как hard-mounted. Это включено по


умолчанию.

      soft - soft-mount драйвер ( противоположный hard-mounted).

      intr - позволяет сигнализировать о том, что надо прервать NFS вызов.
Полезно для                 прерывания выполнения, когда сервер не
отвечает.

      Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер
стал временно недостижим. Они работают вместе следующим способом: всякий
раз, когда клиент ппсылвет запрос к NFS серверу, он ожидает, что  операция
закончится после данного интервала (точно установленным в опции блокировки
по времени). Если никакого подтверждения не получено внутри этого
промежутка времени, то появится так называемая minor  timeout
(незначительная остановка по времени), и операция повторится, но уже с
интервалом блокировки по времени вдвое большим. После достижения
максимальной блокировки по времени - 60 секунд, происходит глобальная
блокировка по времени.

      По умолчанию, глобальная блокировка по времени заставит клиента
напечатать сообщение на консоль и начинать все снова. В принципе это может
продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор
пока сервер не становится доступным, называются hard-mounted. В
противоположность им, soft-mounted значения генерируют ошибку ввода -
вывода для вызова процесс всякий раз, когда  происходит глобальная
блокировка по времени. Из-за того, что write-behind вводится буферным
кэшем, то это условие ошибки не распространяется непосредственно на процесс
прежде, чем это вызовет функцию записи 2 в следующий раз, так как программа
никогда не сможет убедиться в том что операция записи к soft-mounted
значению имела место вообще.



      Поставили ли Вы hard- или soft-mount значение - это не только вопрос
вкуса, но также и то, что Вы должны сделать с тем сортом информации,
которую Вы хотите получить от этого значения. Например, если Вы
устанавливаете ваши  Х программы NFS, Вы конечно не хотели бы, чтобы ваш X
сеанс шел бы "бешено" только потому, что кто -то привел сеть к останову,


запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet
разъем на некоторый момент. Используя hard-mounting, Вы удостоверяетесь в
том, что ваш компьютер будет ждать, пока не появится возможность заново
восстановить контакт с вашим nfs-сервером. С другой стороны, non-critical
данные, типа nfs-mounted news partititons или FTP врхив может быть также
soft-mounted, так что это не повесит ваш сеанс в случае, если отдаленная
машина должна стать временно "недостигаемой", или просто быть выключенной.
Если ваша сетевая связь с сервером - flakey или проходит через программу
маршрутизации, то Вы может также увеличивать начальную блокировку по
времени, используя опцию timeo, или hard-mount значение, но позволяйте
сигнализировать прерывание вызова NFS, так чтобы Вы могли прервать любой
hanging  file access.

      Обычно, mountd daemon будет иным способом следить, которые каталоги
были установлены, и какими хостами. Эта информация может быть отображена
при использовании программы showmount, которая также включена в NFS пакет
сервера. Linux mountd не делает этого.

      12.3 NFS daemon(область)

      Если Вы хотите обеспечить NFS обслуживание другим хостам, то  Вы
должны запустить nfsd и mountd daemons на вашей машине. Как rpc-основанные
программы, они не управляются inetd, но запускаются при начальной загрузке,
и регестрируют сами себя непосредственно с portmapper. Следовательно, Вы
должны удостовериться в том, что они запущенны только после того, как
rpc.portmap выполнилось. Обычно, Вы должны включить следующие две линии в
вашем rc.inet2 script:

      if [ -x /usr/sbin/rpc.mountd ]; then
                   /usr/sbin/rpc.mountd; echo -n " mountd"
      fi
      if [ -x /usr/sbin/rpc.nfsd ]; then
                  /usr/sbin/rpc.nfsd; echo -n " nfsd"
      if

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


пользователя и группу имен с этой самой численной идентичностью, то им
обязательно скажут разделить то же самое пространство uid/gid. Для примера,
когда Вы используете NIS, чтобы распределить passwd  информацию всем хостам
на вашей LAN.


     &
 "    В некоторых случаях,  они не соответствуют. Достаточно
модифицированного uid's и gid's клиента, чтобы соответствовать таковому
серверу, Вы может использовать ugidd  mapping  daemon, чтобы  работать
вокруг этого. Использование map daemon опцию объяснено ниже, Вы может
сообщить nfsd отобразить uid/gid  пространство сервера к пространству
uid/gid клиента при помощи ugidd на клиента.

      ugidd - rpc-основанный сервер, и запущен из rc.inet2 точно также как
и nfsd и mountd.

      if [ -x /usr/sbin/rpc.ugidd ]; then
                   /usr/sbin/rpc.ugidd; echo -n " ugidd"
      fi

      12.4 файл экспорта

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

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

      # exports file for vlager
           /home             vale(rw) vstout(rw) vlight(rw)
           /usr/X386         vale(ro) vstout(ro) vlight(ro)


           /usr/TeX          vale(ro) vstout(ro) vlight(ro)
           /                 vale(rw,no root squash)
           /home/ftp         (ro)

      Каждая линия определяет каталог, и хост, которому позволенно
установить его. Имя хоста - обычно полностью квалифицированное название
области, но может содержать * и ? универсальные символы, которые действуют
способом при котором они действуют сомместно с Bourne оболочкой. Например,
lab*.foo.com соответствует lab01.foo.com также как и laber.foo.com. Если
никакое имя хоста не дано, как с каталогом  /home/ftp в приоере выше, то
любому хосту позволено установить этот каталог.



      При проверке клиентского хоста против файла экспорта, mountd будет
искать hostname клиента используя gethostbyaddr(2) вызов. С DNS, этот вызов
возвращает каноническиий hostname клиента, так что Вы должны удостовериться
в том не используется ли псевдонимы в экспорте. Без использования DNS,
возвращенное имя -
      первый hostname, найденный в файле хоста, которая соответствует
адресу клиента.

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

      insecure - разрешает не-опознанный доступ из этой машины.

      unix-rpc - требует unix-области RPC установление подлинности из этой
машины.Оно           просто
требует, чтобы все запросы происходили из зарезервированного
internet порта (то есть номер порта должен быть меньше чем 1024). Эта
опция определена по умолчанию.

      secure-rpc - требует secure RPC установления подлинности от этой
машины. Это пока                 еще
не осуществленно. См.  Sun's документацию по Secure RPC.



      kerberos - требует Kerberos установления подлинности на доступ из
этой машины. Это              тоже
пока еще не осуществленно.  См. MIT документацию по Kerberos
опознавательной системе.

      root squash - это особенность защиты, которая отвергает super user на
точно
установленных хостах любых специальных прав доступа, отображая
        запросы из uid
0 на клиенте к uid 65534 (-2) на сервер. Этот uid не                    должен
быть связан ни с каким пользователем.

      no root squash - не делает запросы отображения из uid 0. Эта опция
включена по
умолчанию.

      ro - устанавливает значение read-only на файловую архитектуру. Эта
опция включена          по умолчанию.


      rw - устанавливает значение rgad-write на файловую архитектуру.



      link relative - преобразовывает абсолютные символьные связи (где link
contents начинается с наклонной черты вправо) в относительные связи вводя
необходимое число ../, чтобы добраться из каталога содержащего связь к root
на сервере. Эта опция имеет смысл только тогда, когда целая файловая
система хоста установлена, или некоторые из связей не могли бы быть  нигде,
или даже хуже, файлы на которые они никогда не указывали.

      Эта опция определена по умолчанию.

      link absolute оставляет вся символьные связи какими они и были
(нормальное поведение для Sun-supplied NFS серверов).

      map identity - map identity опция сообщает серверу, чтобы он принял
того клиента, который использует теже самые uid's и gid's как и сервер. Эта


опция определена по умолчанию.

      map daemon Эта опция сообщает NFS серверу принять, что клиента и
сервер не разделяют то же самое пространство uid/gid. nfsd затем построит
список идентичности отбора между клиентом и сервером, запрашивая client's
ugidd daemon.

      Ошибка, анализирующая файл экспорта сообщает  daemon syslogd's
оборудованию  всякий раз, когда nfsd или mountd запущен.

      Заметьте, что имена хостов получены из IP адреса клиента обратным
отбором, так что Вы должны иметь правильно сконфигурированное решающее
устройство. Если Вы используете BIND и очень security-conscious, то  Вы
должны включить spoof проверку в Вашем host.conf файле.

      12.5 Linux Automounter

      Иногда, это расточительно для установки всех NFS значений
пользователей, к которым возможно хотят обратиться.; или же  из-за острого
числа зачений которые должны быть установленны, или из-за времени, которое
требовалось бы при запуске. Жизнеспособный вариантдля этого - так
называемый automounter. Это - daemon, которая атоматически и понятно
устанавливает любое NFS значение как необходимо, и неустанавливает их ,
если они не были использованны в течении некоторого времени. Одна из умных
вещей относительно automounter - то, что возможно установить определенное
значение из любых мест. Например, Вы можете сохранить копии Ваших Х
программ  и файлов поддержки на двух или трех хостах, и все



      другин хосты устанавленные через NFS. При использовании automounter,
Вы можете точно определить всех трех из них, чтобы быть установленными на
/usr/X386; automounter  затем попробует установить любой из них, пока одна
из попыток установки не преуспевает.

      Automounter, обычно используемый с Linux называется amd. Сначала он
был написан Jan-Simon Pendry и был перенесен на Linux Rick Sladkey. Текущая
версия amd-5.3.



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




                        13. Управление Taylor UUCP

                             13.1 Хронология

      UUCP был разработан в конце семидесятых Mike Lesk в AT&T Bell
Laboratories, чтобы обеспечить простое соединение по модему. Так как
большинство людей, которые хотят иметь email и новости Usenet на своей
домашней машине все еще связываются через модемы, UUCP стал очень
популярен. Хотя имеется много реализаций, разработанных для различных
аппаратных платформ и операционных систем, все они совместимы с высокой
степенью.
      Однако, как это случилось с большинством программного обеспечения,
которое так или иначе стало "стандартом" за эти годы, нет такого UUCP,
который можно было бы назвать подлинным UUCP. Он подвергался  постепенному
процессу эволюции начиная с первой версии, которая была разработана в
1976.В настоящее время имеются две основных разновидности, которые
отличаются в основном поддержкой аппаратных средств и конфигурацией.Крпме 
них существуют различные реализации, немного отличающиеся деталями
элементами.
      Одна разновидность - это так называемая " Версия 2 UUCP ", которая
датируется 1977 годом и реализована Mike Lesk, David A. Novitz, и Greg
Chesson. Она все еще используется, хотя и устарела. Недавние реализации
Версии 2 обеспечивают многие из возможностей более новой разновидности
UUCP.
      Вторая разновидность была разработана в 1983, и обычно упоминается
как BNU (Basic Networking Utilities(базисные утилиты работы с сетями)),
HoneyDanBer UUCP, или HDB для краткости. Название получено из имен авторов,
P. Honeyman, D. A.Novitz, и B. E. Redman. HDB был задуман, чтобы устранить
некоторые из неточностей Версии 2  UUCP. Например, были добавлены новые
протоколы передачи, и буферный каталог был разбит так, что теперь имеется


каталог для каждого компьютера, с которым Вы связываетесь через UUCP.
      Реализация UUCP, в настоящее время распространяемого с Linux - Taylor
UUCP 1.04, (1), является версией,которую описывает эта глава. Версия Taylor
UUCP 1.04 была выпущена в феврале 1993. Кроме традиционных файлов
конфигурации, Taylor UUCP может быть скомпилирована так , чтобы понимать
новый стиль - a.k.a. " Taylor " - файлы конфигурации.
      Версия 1.05 была выпущена недавно, и скоро будет поставляться на
большинстве дистрибутивов. Различия между этими версиями обычно затрагивают
возможности, которые Вы никогда не будете использовать, так что Вы сможете
конфигурировать Taylor UUCP 1.05 используя информацию из этой книги.


                    1.Написано  Ian Taylor, 1993.



      С большинства дистрибутивов Linux, Taylor UUCP обычно компилируется
совместимым с BNU, или Taylor схемой конфигурации, или с обоими. Так как
последний намного более гибок, и, возможно, проще для понимания, чем
довольно часто запутанные файлы конфигурации BNU, ниже я буду описывать
схему Taylor.
      Цель этой главы не в том, чтобы дать Вао исчерпывающее описание опций
командной строки для команд UUCP, а в том, чтобы дать Вам введение в
установку  работающего узла   UUCP. Первый раздел дает введение в то, как
UUCP осуществляет удаленное выполнение и передачу файла. Если Вы не новичок
в UUCP, Вы можете пропустить этот раздел и перейти к разделу 13.3, который
объясняет различные файлы, используемые для установки UUCP.
      Мы примем, что Вы знакомы с пользовательскими программами набора
программ UUCP - uucp и uux. Для описания обратитесь пожалуйста к страницам
руководства.
        Кроме общедоступных программ - uux и uucp, набор программ UUCP
содержит ряд команд, используемых только для административных целей. Они
используются для контроля траффика UUCP через ваш узел, удаления старых
регистрационных файлов, или для компиляции статистики. Они не будут описаны
здесь, потому что они периферийные к основным задачам UUCP. Кроме того, они
хорошо документированы и довольно легки для понимания. Однако, имеется
третий класс, который включает рабочие программы UUCP. Они называются
uucico (где cico обозначает copy-in copy-out), и uuxqt, которая выполняет


работы, посланные из удаленных систем.

                       13.1.1 Подробная информация о UUCP

      Если Вы в этой главе не найдете то, что хотите, прочитайте
документацию,которая поставляется с пакетом. Это набор texinfo файлов,
которые описывают установку с использованием Taylor схемы конфигурации.
Texinfo может быть преобразован в DVI и GNU файлы информации, использующим
tex и makeinfo, соответственно.
      Если Вы хотите использовать файлы конфигурации BNU (или даже Версии
2), есть очень хорошая книга - " Управление UUCP и Usenet " ([GETST
"reilly-uucp"]). Другой хороший источник информации об UUCP для Linux -
Vince Skahan's UUCP-HOWTO , который можно взять на  comp.os.linux.announce.
      Имеется также newsgroup для обсуждения UUCP - comp.mail.uucp. Если у
Вас есть специфические вопросы о Taylor UUCP, может быть лучше задать их
тжм, чем на группах comp.os.linux.



                           13.2 Введение

                13.2.1 Обзор  Передач UUCP и удаленного запуска

      Ключ к пониманию UUCP - понятие задачи. Каждая передача, которую
пользователь инициализирует с помощью uucp или uux,  называется задачей.
Она состоит из программы,которая будет выполнена на удаленной системе, и
набора файлов, которые будут перемещены между системами. Одна из этих
частей может отсутствовать.
      Например,примем, что на вашей ЭВМ Вы выдали следующую команду,
которая заставляет UUCP копировать файл netguide.ps на ЭВМ pablo, и
выполнить команду lpr, чтобы напечатать файл.

      #     $ Uux -r pablo! Lpr! Netguide.ps

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


обычно находится в  /var/spool/uucp. В нашем примере, описание задачи
содержало бы информацию относительно удаленной команды, которая будет
выполнена (lpr), пользователя, который запросил выполнение, и пары других
предметов. В дополнение к описанию задачи, UUCP должен сохранить входной
файл (netguide.ps).
      Точное расположение и наименование буферных файлов может изменяться
в зависимости от некоторых опций  времени  компиляции. HDB-совместимые UUCP
вообще сохраняют буферные файлы в каталоге, именованном
/var/spool/uucp/site, где site - имя удаленной машины. Скомпилированный для
Taylor конфигурации, UUCP создаст подкаталоги в /var/spool/uucp/site для
различных типов буферных файлов.
      Через определенные интервалы UUCP связывается с удаленной системой.
Когда соединение установлено, UUCP передает файлы, описывающие задачу, плюс
все входные файлы. Входящие задачи не будут выполнены немедленно, а только
после  разрыва уоединения . Это делает программа uuxqt, которая также
заботится о пересылке любых задач, если они предназначены для другой
машины.
      Для различия между важными и менее важными задачами, UUCP с каждой
задачей связывает уровень приоритета . Это - один знак, в пределах от 0 до
9, от А до Z, и через z, в уменьшающемся старшинстве. Почта обычно
записывается в буферный файл с приоритетом B или C, в то время как новости
записываются с приоритетом N. Работы с более высоким приоритетом передаются
раньше. Приоритеты могут быть назначены используя опцию -g при вызове uucp
или uux.
      Вы можете также запретить передачу задач с приоритетом ниже данного в
определенное время. Это также называется максимальным приоритетом  буфера,
позволяемым  в течение диалога ( по умолчанию  z). Обратите внимание на
терминологическую неоднозначность : файл перемещен только, если он имеет
приоритет выше максимального приоритета буфера.

                     13.2.2 Внутренние работы uucico

      Чтобы понять, почему uucico должен знать некоторые вещи, приведем
быстрое описание того, как фактически происходит соединение с удаленной
системой.
        Когда Вы выполняете uucico -s система из командной строки,  сначала
происходит физическое соединение.Принимаемые действия зависят от типа
открываемого соединения. Например, при использовании телефонной линии, она


должна найти модем, и набрать номер.Если используется TCP, uucico должна
вызвать функцию gethostbyname (3), чтобы преобразовать имя в сетевой адрес,
выяснить, какой порт открывать, и связать адрес с соответствующим
гнездом(socket).
      После того, как соединение было установлено, должна выполниться
процедура идентификации пользователя. Она состоит из запроса удаленной
системой,  имени, и, возможно, пароля.Все это называется "login chat".
Процедура идентификации выполняется или обычным getty/login набором
программ, или - на гнездах TCP - непосредственно uucico . Если разрешение
на вход получено, удаленная систзма запускает uucico. Локальная копия
uucico, которая инициализировала соединение, назначается главной, удаленная
- подчиненной.
      Затем следует фаза рукопожатия(handshake phase): главный посылает
cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли
hostname право входить в неё, посылать и принимать файлы, и т.д.. Флаги
описывают (кроме всего прочего) максимальный приоритет буферизации
передаваемых файлов. Если возможно, счет диалога, или проверка порядкового
номера обращения происходит здесь. Благодаря этой возможностью, оба
поддерживают счет успешных соединений, которые сравниваются. Если они не
соответствуют,  рукопожатиe прерывается. Это помогает защищать себя от
самозванцев.
      В заключение, uucico пытаеться установить общий протокол передачи.
Этот протокол обеспечивает способ перемещения данных, проверку на
непротиворечивость, и повторную передачу в случае ошибки. Имеется
потребность в различных протоколах из-за отличающихся типов обеспечиваемых
соединений. Например, телефонные линии требуют " безопасный " протокол,
который включает в себя жестокую проверку ошибок, в то время как передача
TCP по существу надежна и может использовать более эффективный протокол,
который предшествует наиболее тщательной  проверке ошибок.




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


достаточно высоким. Когда передача завершена, она сообщает об этом
подчиненной системе,  подчиненный может теперь отключиться или принимать
диалог. Это - изменение ролей(назначений): теперь удаленная система
становится главной, а локальная становится подчиненной. Новый хозяин теперь
посылает файлы. Когда передача завершена, обе программы обмениваются
заключительными сообщениями, и закрывают соединение.
      Мы не будем вникать во все детали: пожалуйста обратитесь или к
исходным текстам  или к любой хорошей книге об UUCP для этого.Есть также
действительно старинная статья, касающаяся сети, написанной David A.
Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP
FAQ также обсуждает некоторые подробности UUCP. Это всегда есть на
comp.mail.uucp.

      13.2.3 Опции командной строки uucico

      Этот раздел описывает наиболее важные опции командной строки для
uucico. Для полного списка, пожалуйста обратитесь к странице руководства
uucico(1).
         -s  системный вызов по имени системы, если нет запрета в
             соответствии c ограничениями времени обращения.

         -S  системный вызов по имени системы безоговорочно.

         -r1 запукает uucico в режиме главного. Это опция по
             умолчанию,когда -s или -S  заданы.  Опция -r1 заставляет
             uucico пробовать вызывать все системы в sys", если не
             запрещено обращение и не настало ограничение
             времени повторения.


         -r0 запускает uucico в режиме подчинённого. Это - значение по
             умолчанию,когда -s или -S не заданы. В непривилегированном
             режиме, любой стандартный ввод - вывод соединяется с
             последовательным портом, порт TCP используется  если опция -p
             задана.






         -x typy, -X type Включают отладку заданного типа.Несколько типов
            могут быть разделены запятой.Следующие типы допустимы:
            abnormal, chat,handshake,uucp-proto, proto, port, config, spooldir,
            execute,incoming, outgoing. Использование all включает все опции
            Для совместимости с другими реализациями UUCP,взамен может быть
            определен номер, который включает отладку для первых n предметов"из 
            вышеупомянутого списка.


        Отладочные сообщения будут регистрироваться в файле DEBUG в
/var/spool/uucp.

              13.3 Файлы Конфигурации UUCP

      В отличие от более простых программ передачи файлов, UUCP был
разработан, чтобы обрабатывать все передачи автоматически.Если только все
установлено правильно, ежедневное вмешательство администратора не
необходимо.Вся необходимая информация сохраняется в паре файлов
конфигурации, которые постоянно находятся в каталоге /usr/lib/uucp.
Большинство этих файлов используется только при запросе снаружи.

            13.3.1 Нежное Введение в Taylor UUCP

      Сказать, что конфигурация UUCP является тяжелой,было бы замалчиванием
темы.Это - действительно запутанная тема, и иногда краткий формат файлов
конфигурации не делает вещи проще (хотя формат Talyor почти просто читается
по сравнению с более старыми форматами в HDB или Версии 2).
      Что бы дать Вам понять как взаимодействуют все эти файлы, мы
представим наиболее важное, и будем иметь просмотр в типовых входах этих
файлов. Мы не будем объяснять все подробно; более точные сведения даны в
отдельных разделах ниже.Если Вы хотите установить на  вашу машину  UUCP,
лучше всего начать с некоторых типовых файлов, и адаптировать их
постепенно.Вы можете выбирать из предложенного ниже,или того,что есть в
вашем дистрибутиве Linux.
      Все файлы,описанные в этом разделе хранятся в /usr/lib/uucp или в его
подкаталогах.Некоторые дистрибутивы Linux содержат UUCP binaries, которые
поддерживают и  HDB и Taylor конфигурации,и используют различные


подкаталоги для каждого набора файлов конфигурации.Есть обычно README файл
в /usr/lib/uucp.
      Чтобы UUCP работал правильно, эти файлы должны принадлежать
собственно пользователю uucp. Некоторые из них содержат пароли и номера
телефона, и следовательно должны иметь прва доступа 600. (2)
      Центральный файл конфигурации UUCP - /usr/lib/uucp/config
используется, чтобы установить общие параметры.Наиболее важный из них (и
теперь, единственный), является именем UUCP вашей  ЭВМ. В Виртуальном
Пивоваренном заводе, они используют vstout как их ворота UUCP:

       # /usr/lib/uucp/config - основной файл конфигурации  UUCP
hostname vstout
      Следующий важный файл конфигурации - sys файл.Он содержит всю
системно-привязанную информацию об участках сети, с которыми Вы связаны.Она
включает имя участка(ЭВМ),и информацию относительно связи
непосредственно,типа номера телефона при использовании связи
модема.Типичный cценарий (сценарий - коммандный файл - script,далее
сценарий) для модемной связи с pablo:
                 # /usr/lib/uucp/sys - имена соседей UUCP
                 #system pablo
                 system pablo
                 time            Any
                 phone           123-456
                 port            serial1
                 speed           38400
                 chat            ogin: vstout ssword: lorca
      Port задает порт,который нужно использовать,time определяет время в
которое система может вызываться.Сhat описывает сценарии входа в систему -
последовательность строк,которыми нужно обменяться,чтобы uucico
зарегистрировал в pablo.Мы опишем сценарий входа позже.Команда порта не
называет конкретный файл устройства типа /dev/cua1,но оба имени входят в
файл port.Вы можете назначить любое походящее имя.
        2.Обратите внимание, что хотя большинство команд UUCP должно
устанавливать setuid для uucp, Вы должны удостовериться, что  программа
uuchk - нет. Иначе  пользователи будут способны посмотреть пароли,даже если
они имеют режим 600.





      Файл port содержит информацию о связи непосредственно.Для  модемной
связи он описывает специальный файл устройства, который нужно использовать,
скорость,и тип оборудования, соединенного с портом.Пример ниже описывает
/dev/cua1 (a.k.a. COM 2),с которым соединен NakWell модем способный к
перздачз на  скорости до 38400bps.Имя порта должно соответствовать
имени,данному в файле "sys".
                 # /usr/lib/uucp/port - UUCP ports
                 # /dev/cua1 (COM2)
                 port            serial1
                 type            modem
                 device          /dev/cua1
                 speed           38400
                 dialer          nakwell
      Информация,имеющая отношение к программам набора номера
cохраняетсяняется в другом файле,называемом dial.Для каждого типа программы
набора номера он содержит последовательность команд,которые требуются,чтобы
вызвать удаленную машину по номеру телефона.Все это задано как chat
script(сценарий дружеской системы).Пример для вышеупомянутого NakWell мог
бы выглядеть следующим образом:
                       # /usr/lib/uucp/dial - per-dialer information
                 # NakWell modems
                 dialer          nakwell
                 chat            "" ATZ OK ATDT\T CONNECT
      Строка, начинающаяся с chat определяет дружескую беседу
модема,которая является последовательностью команд, посланных и полученных
от модема, чтобы инициализировать это и делать это,набирают желательный
номер."\T" последовательность будет заменен на номер телефона uucico.
      Чтобы в общем показать Вам, как uucico работает с этими файлами
конфигурации, предположим, что Вы дали команду:

                 $ Uucico -s pablo



           Рисунок 18. Взаимодействие  Файлов Конфигурации Taylor UUCP.

      Первым делом uucico ищет  pablo в "sys" файле.Из строки в файле "


sys" для pablo она видит,что должна использовать serial1 порт для установки
соединения.Файл port сообщает ей, что serial1 является портом модема,и что
есть подключенный модем NakWell .
      Uucico теперь ищет набор кода,описывающий NakWell модем,и найдя
первый,открывает /dev/cua1 последовательного порта и выполняет "дружескую
беседу" программы набора номера.То есть поуылазт "ATZ", ждет "OK " в
ответ,и т.д.. При столкновении с строкой "\T", он  заменяет номер телефона
(123 - 456) извлеченный из системного файла.
      После того,как соединение было установлено,Uucico  возвращается к
файлу "sys" и выполняет дружескую беседу входа в систему(login chat).В
нашем примере она ждет  приглашения "login: " затем послает имя
пользователя (neruda), затем ждет приглашения  "password:" ,и посылает
пароль "lorca".
      После завершения разрешения, удаленная система активизирует
собственный uucico.Они прводят фазу рукопожатия(handshake phase),описанную
в предыдущем разделе.

        Связи и зависимости  файлов конфигурации  также показаны на рисунке
13.3.1.
          13.3.2 Что  Должен Знать  UUCP

      Прежде, чем Вы начинаете писать файлы конфигурации UUCP, Вы должны
уяснить некоторую необходимую информацию.Сначала  Вы будете должны
выяснить,к какому последовательному порту присоединен ваш модем.Обычно
порты (DOS) COM1 - COM4 отображают на специальные файлы устройств /dev/cua0
- /dev/cua3.Большинство дистрибутивов, напр. Slackware,создают /dev/modem
ссылку как связь с соответствующим cua * файлом устройства,и конфигурируют
kermit,seyon и т.д. использовать этот обобщенный файл.В этом случае,Вы
должны также использовать /dev/modem в вашей конфигурации UUCP.
      Причина для этого то,что все программы  используют так называемые
файлы блокировки,чтобы сообщить,когда последовательный порт
используется.Имена этих файлов блокировки - конкатенация строки LCK .. и
имени файла устройства,например LCK .. cua1.Если программы  используют
различные имена для одного устройства,они будут быть не в состоянии
распознавать чужие файлы блокировки.Как следствие, они прервут чужие сеансы
начатые в то же самое время.Это - не маловероятное событие,если Вы
планируете чтобы ваш UUCP использовал  crontab.Подробности настройки
последовательных портов см. в главе 5 ..


      Затем Вы должны выяснить с какой скоростью  ваш модем и Linux могут
связыввться и установить максимальную эффективную скорость
передачи.Эффективная скорость передачи может быть намного выше чем
физическая скорость вашего модема.
      Например, много модемов посылают и получают данные со скоростью
2400bps (биты в секунду).При использовании протоколов сжатия типа V.
42bis,фактическая скорость передачи может достигать 9600bps.
      Конечно,если вы хотите,чтобы UUCP cделал что-нибудь,Вам для вызова
нужен номер телефона системы.Также Вам нужен идентификатор для  входа в
систему и возможно пароль для удаленной машины. (3)
      Вы  также должны знать,как регистрироваться в системе. Например,Вы
должны нажать КЛАВИШУ BREAK прежде, чем подсказка входа в систему
появляется? Что отображается: "login:" или "user:"? Это необходимо для
создания сценария дружеской беседы(chat script),который описывает uucico,
как регистрироваться.Если у Вас возникают затруднения,пробуйте вызывать
систему программой терминала подобно kermit или minicom,и записать
точно,что Вы  делаете.

          13.3.3 Наименование Места

      Как  и при работе с TCP/IP сетями,ваша главная ЭВМ(host)  должна
иметь имя для  UUCP сетей. Пока Вы просто хотите использовать UUCP для
передач файлов или соединения извне  непосредственно,или по локальной сети,
это имя не должно удовлетворять никакие стандартам. (4)
        3. Если вы собираетесь   пробовать UUCP, получите телефонный номер
ближайшего архива. Запишите имя и пароль - они общеизвестны. В
большинстве случаев  они   что - нибудь вроде /uucp uucp или
nuucp/uucp.
      4. Единственое ограничение - то, что имя не должно быть больше чем
7 символов, чтобы не путать  ЭВМ с файловыми системами, которые
накладывают узкое ограничение на имя файла.



      Однако, если Вы используете UUCP для почты или новостей, Вы должны
подумать о наличиb имени, зарегистрированног в UUCP Mapping project . UUCP
Mapping psojectо описан в главе 14 .., Даже если Вы делите домен, Вы можете
получить официальное имя UUCP для вашего участка сети.


      Часто, люди выбирают свое UUCP имя, чтобы соответствовать первому
компоненту  имени домена. Предположим, что адрес домена вашей ЭВМ -
swim.twobirds.com, тогда имя главной ЭВМ UUCP было бы swim.Обычно именно
так и бывает.Конечно, Вы можете также использовать любое UUCP имя.
      Однако   не стоит  использовать неквалифицированное имя  в адресе
почты, пока  Вы не зарегистрировали его как ваше официальное имя UUCP. (5)
      В  лучшем случае, почта на незарегистрированную  ЭВМ UUCP отправится
в мусорную корзину(big black bit bucket). Если Вы используете имя, уже
присвоенное некоторому другому месту, эта почта не будет направлена к тому
месту, и причине начальник почтового отделения никакой конец головных
болей.
      По умолчанию, набор программ UUCP использует  hostname как имя UUCP .
Это имя обычно устанавливается в сценарие /etc/rc.local. Если ваше имя UUCP
отлично от того, что Вы устанавливаете главным имя , Вы должны использовать
опцию hostname в файле конфигурации, чтобы сообщить uucico о вашем имени
UUCP. Это описано ниже.


            13.3.4 Taylor Файлы Конфигурации

      Теперь мы  вернемся к файлам конфигурации. Taylor UUCP получает
информацию из следующих файлов:

      config -Это  основной файл конфигурации. Вы можете определить ваше
имя UUCP здесь.

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

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


      5. UUCP  Mapping  Project  регистрирует все UUCP hostnames во всем
мире и проверяет их на уникальность. Чтобы зарегистрировать ваше имя UUCP,
спросите maintainers ЭВМ, которжя ограбатывает вашу почту; они  помогут
Вам с этим.






      dial  -   Описывает программы набора номера, используемые, чтобы
                установить телефонное соединение.

      Dialcode  Содержит расширения для символического сода набора
                (dialcodes).


      call       Содержит имя входа в систему и пароль, который нужно
                 использовать при вызове системы. Редко используется.


      Passwd     Содержит имена входа в систему, и системы паролей
                 используемые при регистрации . Этот файл используется
                 только, когда uucico делает собственную проверку пароля.

      Taylor файлы конфигурации состоят из строк, содержащих пары  ключевое
слово  - значение. Знак мусора представляет комментарий ,действующий до
конца  строки. Чтобы использовать знак мусора просто так , Вы можете ввести
его с наклонной чертой влево( with a backslash).
      Есть очень много опций, которые Вы можете изменять в этих файлах
конфигурации. Мы не можем описать все параметры здесь, и заденем лишь
наиболее важные.С их помощью вы сможете сконфигурировать модемную связь
UUCP. Дополнительные разделы описывают изменения, необходимые, если Вы
хотите использовать UUCP поверх TCP /IP или поверх последовательного
соединения. Полная описание дается в Texinfo документах, которые
распространяются вместе с исходным текстом  Taylor  UUCP.
      Если  Вы думаете, что сконфигурировали вашу систему UUCP полностью,
можете проверить вашу конфигурацию, используя uuchk (находится в
/usr/lib/uucp). Uuchk читает ваши файлы конфигурации, и печатает
детализированный отчет о значениях , используемых для каждой системы.

            13.3.5 Общие Опции Конфигурации - config файл

      Скорее всего Вы вообще не будете использовать этот файл, чтобы


описать  UUCP hostname. По умолчанию, UUCP использует имя, которое Вы
устанавливаете  командой"hostname, но  вообще это хорошая идея -
установить имя UUCP явно. Типовой config файл показывается ниже:



                 # /usr/lib/uucp/config - UUCP  main configuration file
                 Hostname vstout

            13.3.6 Как сказать UUCP о других системах - sys Файл

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

      Наиболее  важные элементы записи подробней описаны ниже .

            13.3.6.1 Имя Системы
      Каждое имя системы может появляться более только один раз. Если Вы
хотите использовать несколько наборы конфигураций для той же самой системы
(типа различных номеров телефона uucico, должен пробовать по очереди), Вы
можете определять альтернативы. Альтернативы описаны ниже.
      6. Старая Версия 2 UUCP не делает широковещательной передачи имени в
начале вызова; однако  более новые реализации (а также и Taylor UUCP)
делают это.



            13.3.6.2 Номер телефона

      Если связь с удаленной системой достигается по телефонной линии, поле
телефона определяет номер, который модем должен набрать для связи. Он может
содержать отдельные лексемы, интерпретируемые процедурой набора uucico's.


Знак  '=' означает " ждать вторичный тон набора кода", '_'  генерирует
паузу в одну секунду. Например, некоторые телефонные станции сбрасывают,
если Вы не делаете  паузу  между набором префиксного кода и номера
телефона.
      [Я  не знгю соответствующий Английский термин для этого , но Вы
знаете, что иногда на частной внутренней телефооной станции компании  Вы
должны набрать 0 или 9, чтобы получить выход наружу.]
      Любая встроенная символьная строка может использоваться, чтобы скрыть
место-зависимую информацию(например код области). Любая такая строка
транслируется с помощью файла  dialcode. Предположим, что Вы имеете
следующий dialcode файл:


                 # /usr/lib/uucp/dialcode - dialcode translation
                 Bogoham                           024881
                 Coxton                               035119


      С такими определениями Вы можете использовать номер телефона типа
Bogoham7732 в файле sys, это делает все немного проще.

            13.3.6.3 Опции Port  и Speed

      Опции Port и Speed используется, чтобы выбрать устройство,
используемое для вызова удаленной системы, и установки максимального
быстродействия. (7) вход системы может использовать или опцию единственные,
или обе опции в конъюнкции. При поиске подходящего устройства в файле port,
только те порты ,могут быть выбраны, которые соответствуют имени порта
и(или)  диапазону скоростей.
      Вообще, использование опции speed должен удовлетворить. Если Вы
имеете только одно последовательное устройство, описанное в port, uucico
будет всегда выбирать правильно, во всяком случае, так что Вы только должны
дать этому желательное быстродействие. Если у Вас несколько модемов,
присоединенных к вашей системе, Вы все еще часто не хотите к.

      7. Скорость в бодах Вашего tty (телетайпа) должна быть по крайней
мере так же высока, как максимально возможная скорость передачи.





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

          13.3.6.4 Login chat (Дружеская беседа Входв в уистему)

      Выше мы уже сталкивались с сценарием дружеской беседы входа в систему
(login chat script), который сообщает uucico, как регистрироваться в
удаленной системе. Он состоит из списка лексем(маркеров), определяя строки,
ожидаемые и посланные локальным процессом uucico. Усилие состоит в том,
чтобы заставить uucico ждать, пока удаленная машина не пошлет приглашение
входа в систему, затем послать имя входа в систему, ждать, пока удаленную
система пошлет приглашение на ввод пароля, и посылать пароль. Ожидание и
посылка строки чередуются. Uucico автоматически добавляет символ \r
возврата каретки к, любой посылаемой строке. Таким образом, простой
сценарий дружеской беседы походил бы на:


                login: vstout Password: catch22


      Обратите внимание, что  поля записи не содержат текста приглашений.
Удостоерьтесь, что вы войдете в систему , даже если система посылает Login
вместо login.
      Uucico также учитывает некоторые виды условного выполнения, например
в случае, если  getty удаленной машины должен быть сброшен перед посылкой
приглашения. Для этого  Вы можете присоединиться под-дружескую(sub-chat)
беседу к ожидающейся строке, смещение черточкой. Sub-chat выполняется
только если основное соединение не удалось, то есть произошла блокировка по
времени. Один из способов использовать эту возможность состоит в том, чтобы
послать BREAK, если удаленная система не отображает приглашение входа в
систему. Следующий пример дает всесторонний сценарий дружеской беседы,
который должен  работать и в случае, если Вы должны нажать Enter  прежде,
чем войти в систему. Пустая строка ("") говорит  UUCP ничего не ждать  и
продолжать посылать следующую строку немедленно.



                  "" \n\r\d\r\n\c login:-BREAK-login: vstout password:
catch22

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

                   \t Cимвол табуляции.


                   \r символ возврата каретки.


                   \s Пробел. Вы нуждаетесь в нем , чтобы включить пробел в
строку дружеской беседы.


                   \n перевод строки.


                   \\ обратный слэш ( Backslash).

      В посылаемой строке, следующие ESC-символы и последовательности
допустимы в дополнение к вышеупомянутым:




                  EOT -символ конца  передачи (^D).


                   BREAK -Символ прерывания .


                   \c Подавляет посылку возврата каретки в конце строки.




                   \d Задержка в течение 1 секунды.


                   \E  Дает возможность эхо - проверки.Требует, чтобы
uucico ждал ECHO всего, что это записывает, чтобы читаться в стороне от
устройства прежде, чем это может продолжать дружескую беседу. Это прежде
всего полезно когда используется в дружеских беседах модема (с которым мы
столкнемся ниже). По умолчанию эхо выключено.
                   \e Отключает проверку эхо.


                   \K То же самое, что и BREAK.





                   \p Пауза в долю секунды.

            13.3.6.5 Альтернативы

      Иногда желательно иметь несколько описаний для входа в одну систему,
например, если система может быть достигнута на различных  модемных линиях.
С Taylor UUCP  Вы можете делать это,  определив так называемую
альтернативу.
      Альтернативная строка сохраняет все установки из основной , и
определяет только те значения, которые должны быть отменены в заданной по
умолчанию , или добавиться к ней. Альтернатива - смещение из входа системы
строкой, содержащей  ключевое слово altgrnave.

      Чтобы использовать два номера телефона для pablo, Вы должны изменить
sys  следующим  образом:

                 system       pablo
                 phone        123-456
                 alternate
                 phone        123-455




      При вызове pablo, uucico теперь сначала наберет 123-456, и ,если
ничего не получается пробует альтернативу. Альтернативный вход сохраняет
все установки из основного входа системы, и изменяет  только номер
телефона.

            13.3.6.6 Ограничение  времени вызова
      Taylor UUCP обеспечивает ряд способов,обеспечивающих ограничение
времени обращения с  удаленной системы. Вам потребуется сделать это или из-
за ограничений, которае удаленная главная ЭВМ накладывает на услуги в
течение деловых часов, или просто избегать времен с высокими ценами за
услуги. Обратите внимание, что всегда возможно отменить ограничения времени
обращения, запустив  uucico с опцией -S или -f.
      По умолчанию, Taylor UUCP отвергнет соединения в любое время, так что
Вы должны использовать некоторый вид спецификации времени в  файле sys.
Если Вы не очень заботитесь об ограничении времени обращения, Вы можете
определить опцию времени со значением Аny (любой)  в вашем  файле sys.
      Самый простой способ ограничить время обращения - поле времени,
которое сопровождается строкой, состоящей из дня и подполя времени. День
может быть комбинацией  Mo, Tu , We, Th, Fr, Sa, Su или Any(любой),
Never(никогда), или Wk для дней недели. Время состоит из двух 24-часовых
значений часов, отделяемых черточкой. Они определяют диапазон, в течение
которого обращения допустимы. Комбинация этих лексем пишется без
интервалов. Любая лексема  дня и спецификация времени может быть
сгруппирована вместе с запятыми. Например, время MoWe0300-0730, Fr1805-2000
допускает обращаться в понедельник и среду от 3 д о 7.30 утра, и в пятницу
с 18.05 до 20.00. Когда поле времени охватывает полночь, и написано Mo1830-
0600, это фактически&ознвчает понедельник, между полночью и 6.00 утра, и
между 18.30 пополудни и полночью(понедельника).
      Специальные строки Any  и Never означают ВСЕГДА и НИКОГДА.
      Команда time задает параметр, который описывает время повтора в
минутах. Когда попытка установить соединение не удалась, uucico не
допустит другой попытки вызвать удаленную ЭВМ втечение некоторого
интервала. По умолчанию, uucico использует показательную функцию схемы
backoff , где  интервал повтора увеличивается с каждым последующим отказом.
Например, когда Вы определяете, что время повторения 5 минут, uucico
откажется вызывать удаленную систему втечение 5-ти минут после последнего
отказа.


      Команда timegrade разрешает  Вaм придать максимальную степень
буферизации к плану. Допустим, что Вы имеете следующие команды timegrade во
входе системы:



                 Timegrade N Wk1900-0700, SaSu
                 Timegrade C Any

      Это допускает задачи с приоритетом буферизации(spoolgrade) C и выше
(обычно почта имеет степень B или C), они  будут приняты всякий раз, когда
обращение установлено, в то время как новости (обычно поставленный в
очередь со степенью N) будут перемещены только  ночью и в входные.
      Точно так же как команда time, команда timegrade берет интервал
повторения в минутах как дополнительный третий параметр.
      Однако есть и недостатки высоких приоритетов буферизации:
опция timegrade применяется только к тому, что ваша система посылают;
удаленная система может все еще передать все, что угодно. Вы можете
использовать опцию calltimegrade, чтобы явно запросить послать только
работы выше некоторой данной степени буферизации ; но нет никакой гарантии,
это удовлетворит условиям этого запроса. (8)
      Аналогично, timegrade поле не проверяется, когда удаленная система
вызывает вашу, и любые работы, поставленные в очередь для системы вызова
будут ей посланы. Однако, удаленная система может явно запрашивать ваш
uucico, чтобы пграпичить себя некоторым приоритетом задач.


            13.3.7 Описание  устройств(Devices) - файл port

      Файл port сообщает uucico о доступных портах. Это могут быть порты
модема, другие типы  последовательных соединений  и гнезда TCP.
      Подобно  файлу sys, port состоит из отдельных кусков, начинающихся с
ключевого слова port, сопровождаемым именем порта. Это имя может
использоваться в описании порта в файле sys. Нет потребности в уникальности
имени файла; если существуют порты с одним и тем же именем, uucico
перепробует все  по очереди, пока это не найдет тот, который в настоящее
время не используется.
      Команда port должна обязательно сопровождаться именем типа, которое


задает какой порт  описан. Допустимые типы - modem, direct для прямых
соединений, и tcp для гнезд TCP. Если команда port отсутствует,  по
умолчанию тип порта - modem.
      В этом разделе, мы опишем лишь порты модема; порты TCP и прямые
соединения будут обсуждаться далее.
      8. Если удаленная система выполняет Talyor UUCP, это удовлетворит
условиям.



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


      В случае устройства модема, port также определяет, какой модем
соединен с портом. Различные типы модемов должны быть конфигурированы по-
разному. Четные модемы, что рекламация, чтобы быть Hayes совместимый не
должна быть действительно совместима друг с другом. Следовательно, Вы
должны сообщить uucico, как инициализировать Ваш модем и как соединяться с
требуемым номером. Taylor UUCP хранит описания всех программ набора номера
в файле dial. Чтобы использовать любую из них, Вы должны определить имя
программы набора номера, используя команду dialer.


      Иногда Вам подребуется использовать модем различными способами( в
зависимости систепы,которую  Вы вызываете. Например, некоторые старые
модемы не понимают, когда быстродействующий модем пытается соединяться на
скорости 14400bps; они просто пропускают строку вместо того, чтобы вести
переговоры на скорости в 9600bps. Если Вы знаете, что некоторые места
используют такой "немой" модем, для вызова их Вы должны настраивать ваш
модем иначе. Для этого  Вам нужно добавить строку port ... в  файл порт,
которая определит другую программу набора номера. Теперь Вы можете задать
новому порту другое имя, типа serial1-slow, и использовать директиву port
в описании  системы  в  файле sys.
      Лучший способ отличать порты состоит в том чтобы отличать порты по
скоростям, которые они поддерживают. Например, два описания порта для
вышеупомянутого могут выглядеть следующим образом:



               #NakWell modem; connect at hight speed
               port      serial1                  # port name
               type      modem                 #modem port
               device  /dev/cua1            # this is COM2
               speed  38400                  #support speed
               dialer   nakwel                #normal dialer


               # NakWell modem; connect at low speed
               port            serial1                # port name
               type            modem               # modem port
               device          /dev/cua1        # this is COM2
               speed           9600                # supported speed
               dialer          nakwell-slow  # don't attempt fast connect

      Tеперь запрос был бы на  serial1 как имя порта, но использовать
только 9600bps . Uucico сделает это автоматически
      9. Некоторые люди используют ttyS * устройства , которые
предназначены только для входа (dial-in).



       Используйте второй вход порта. Все остающиеся места, которые имеют
быстродействие 38400bps , будут вызываться, используя первый кусок в port/


            13.3.8 Как набирать номер - файл dial

      Файл dial описывает способ, которым используются различные программы
набора номера . Традиционно, переговоры UUCP программ набора номера быстрее
чем модемы, потому что  раньше было обычной практикой  иметь одно (дорогое)
автоматическое устройство набора, обслуживающее целый набор модемов.
Сегодня большинство модемов имеют  встроенную поддержку набора, так что это
различие становится более размытым.
      Однако  различные программы набора номера или модемы могут требовать
различной настройки. Вы можете описать каждый из них в файле dial. Куски в
файле dial начинаются с команды dialer, которая определяет имя программы


набора номера.
      Наиболее важная часть - дружеская беседа модема(modem chat),
определяется командой chat. Подобно дружеской беседе входа в систему(login
chat), она  состоит из последовательности строк uucico, посылаемых
программе набора номера и ответов, которые требуется получить. Они обычно
используются, чтобы сбросить модем к известному состоянию, и набирать
номер.Вот пример для Hayes-совместимого модема:


       # NakWell modem; connect at high speed
                 dialer          nakwell         # dialer name
                 chat            "" ATZ OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
                 chat-fail       BUSY
                 chat-fail       ERROR
                 chat-fail       NO\sCARRIER
                 dtr-toggle      true

      Дружеская беседа модема начинается с "", пустой ожидают строку.
Cледовательно uucico пошлет команду (ATZ) сразу же. ATZ - команда Hayes для
сброса модема.  Затем uucico ждет, пока модем не послал OK, и посылает
следующую команду, которая выключает локальный ECHO, и т.п.. После того,
как модем возвращает OK снова, uucico посылает команду набора (ATDT).
Escape-последовательность \T в этой строке заменяется  на номер телефона,
получаемый из  файла sys. Uucico затем ждет, пока модем не возвратит
COONECV, что говорит о том,что  соединение с удаленным модемом было
установлено успешно.




      Часто модем будет не в состоянии соединиться с удаленной системой,
например, если другая система говорит с кем -то еще и линия занята. В этом
случае, модем вернет  сообщение об ошибке, указывающее на причину отказа.
Дружеская беседа модема не способна  обнаружить такие сообщения; uucico
будет ждать требуемую строку пока не выйдет время ожидания. В файле
регистрации UUCP(log file) будет записано "timed  out in chat script"
вместо истинной причины.
      Однако, Taylor UUCP позволяет Вам сообщить uucico об этих сообщениях,


используя chat-fail  команду как показано выше. Когда uucico обнаруживает
chat-file строку при выполнении дружеской беседы модема(modem chat), то
прерывает обращение, и регистрирует сообщение об ошибках в  файле
регистрации UUCP(файле log).
      Последняя команда в примере, показанном выше говорит UUCP переключить
DTR строку перед стартом дружеской беседы модема. Большинство модемов может
быть сконфигурировано так , чтобы продолжить -ловушку при обнаружении
изменений в DTR строке, и перейти в командный режим. (10)

            13.3.9 UUCP поверх  TCP

      В первый момент это может показаться абсурдом,но на самом деле UUCP
поверх TCP не такая уж плохая идея, особенно при пересылке большого
количества данных типа Usenet новостей. На TCP -базированных  узлах,
новостями в основном обмениваются, используя NNTP протокол, в котором
статьи запрашиваются и посылаются индивидуально, без сжатия и прочей
оптимизации. Хотя и подходящая для  больших узлов с большим объемом
новостей (newsfeeds), эта методика не подходит для небольших участков сети,
которые получают  новости  медленным соединением типа ISDN. Им удобней
объединить качества TCP с преимуществами посылки новостей в больших
пакетах, которые могут быть сжаты и таким образом перемещаться с очень
низкими  затратами. Станжартпый способ передать эти пакеты состоит в том,
чтобы использовать UUCP поверх TCP.
      В файле sys, Вы определяете систему, которую нужно вызвать через TCP.

      10. Вы также можете сконфигурировать  модемы на сброс при обнаружении
перехода на DTR. Некоторые из них, однако,  не понимают таких вещей и
зависают.



                 system          gmu
                 address         news.groucho.edu
                 time            Any
                 port            tcp-conn
                 chat            ogin: vstout word: clouseau

      Команда address дает адрес IP главной ЭВМ, или ее полное имя


области(domain name). Соответствующий участок файла port выглядел бы:

                 port            tcp-conn
                 type            tcp
                 service         540

      Этот пример говорит, что соединение TCP должно использоваться, когда
файл sys ссылается на tcp-conn, и что uucico должен пытаться соединяться с
портом  TCP Э 540 на удаленной  ЭВМ. Это - заданный по умолчанию номер
порта обслуживания UUCP. Вместо номера порта, Вы можете также давать
символическое имя порта командой service . Номер порта, соответствующий
этому имени будет разыскскан в /etc/services. Общее имя для  UUCP-сервиса
- uucpd.

            13.3.10 Использование прямого соединения

       Допустим, что Вы используете прямое  соединение вашей системы vstout
с системой tiny.Как и в случае с  модемом, Вы должны описать вход в систему
в файле sys. Команда port идентифицирует последовательный порт tiny,
подключен к.

                system          tiny
                 time            Any
                 port            direct1
                 speed           38400
                 chat            ogin: cathcart word: catch22

      В файле port  Вы должны описать последовательный порт для прямого
соединения. Описание  программы набора номера не необходимо, так как нет  
никакой потребности в наборе.



                 port            direct1
                 type            direct
                 speed           38400




                  13.4 Что делать UUCP, а что нет - настройка доступа

                  13.4.1 Выполнение команд
      Задача UUCP состоит в том, чтобы копировать файлы от одной системы к
другой, и запрашивать выполнение некоторых команд на удаленных главных ЭВМ.
Конечно, Вы как администратор хотите управлять тем, какие права Вы
предоставляете другим системам - разрешать им делать что угодно -
определенно не  очень  хорошая идея.
      По умолчанию Taylor UUCP разрешает  выполняьь на вашей машине  лишь
rmail и rnews, которые обычно используются для  email и Usent новостей над
UUCP. Заданный по умолчанию путь поиска, используемый uuxqt - опция
времени компиляции, но обычно содержит /bin,/usr/bin, и /usr/local/bin.
Чтобы изменять набор команд для определенной системы, Вы можете
использовать ключевое слово commands в файле sys. Аналогично, путь поиска
может быть изменен с утверждением пути команды. Например, Вы можете
разрешить системе pablo выполнять команду rsmtp в дополнение к rmail и
rnews: (11)

                 system             pablo
                 commands      rmail rnews rsmtp


                  13.4.2 Передача файлов

      Taylor UUCP также позволяет описывать передачу файлов в
подробностях. Вы  можете запретить любой обмен с определенной  системой.
Только установите request в no, и удаленная система не сможет ни искать, ни
читать, ни посылать Ваешй никаких  файлов.

      11.rsmtp используется, чтобы поставить почте  пакет SMTP. Это
описывается в главах о  почте.



      Аналогично, Вы можете запретить  пользователям Вашей системы
пересылку файлов 'в' или 'из' системы,  установив transfer в no. По
умолчанию любая пересылка им  разаешается.
      


  "   Кроме того, Вы можете конфигурировать каталоги 'в' и 'из' которых
файлы могут быть скопированы. Обычно запрещают доступ с  удаленных систем к
определенным каталогам, но разрешают  своим  пользователям посылать файлы
со своего исходного каталога. Обычно, удаленным пользователям разрешается
получить файлы только от общего каталога UUCP, /var/spool/uucppublic. Это -
традиционное место , в котором хранятся  публично доступные файлы; очень
похоже на  FTP сервисы в Internet. На них обычно ссылаются используя символ
тильды.
      Следовательно, Taylor UUCP обеспечивает четыре различных команды
конфигурирования каталогов для посылки и получения файлов:local-send,
который определяет список каталогов из которых  пользователь может
запросить файлы; local-receive, которая задает список каталогов, в которые
пользователь может просить UUCP записать  файлы ;remote-recive и remote-
send, которые определяют то же самое для запросов в другую
систему.Рассмотрим следующий пример:

                 system          pablo
                 local-send      /home ~
                 local-receive   /home ~/receive
                 remote-send     ~ !~/incoming !~/receive
                 remote-receive  ~/incoming



       Команда local-send разрешает пользователям на вашей главной ЭВМ
посылать любые файлы ниже /home и из  от общего каталога UUCP в систему
pablo. Команда local-receive разрешает им получать файлы или в
общедеступный  каталог в uucppublic, или в любой общедоступный  каталоге
ниже /home. Команда remote-send разрешает pablo запрашивать файлы из
/var/spool/uucppublic или из любого общедоступного его  подкаталога . Это
сообщается к uucico восклицательным знаком,поставленным перед именем
каталога. В заключение, последняя строка разрешает  pablo записать  любые
файлы в каталог incoming.
       Одна из самых больших проблем при передаче файлов  используя UUCP -
это то, что  файлы записываются в обшедоступные каталоги. Это может
соблазнить нзкоторых пользователей вмешаться в личные дела других
пользователей, и т.д.. Однако  нет  никакого способа решения этой проблемы,
кроме отключения передач файлов UUCP вообще.






                       13.4.3 Пересылка

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

                $ Uucp -r seci! Uchile! ~/find-ls.gz ~/uchile.files.gz

      Эта методика прохождения работы через несколько систем называется
пересылкой. В вышеупомянутом примере причиной для использования пересылки
могло быть то, что seci имеет UUCP- доступ к uchile, а ваша главная ЭВМ
нет. Однако, если Вы используете  систему UUCP,  ограничте обслуживание
пересылки для некоторых ЭВМ,которым Вы доверяете, чтобы не ужасаться
телефонному счету,  если кто-нибудь решит скачать себе через вас исходные
тексты последего выпуска X11R6.
      По умолчанию, Taylor UUCP запрещает пересылку вооще. Чтобы давть
возможность пересылки определенной системе, Вы можете использовать команду
forward. Эта команда определяет список систем, которые могут
воспользоваться пересылкой через вас. Например, администратор UUCP seci
должен был добавить следующие строки к  файлу sys, чтобы разрешить pablo
запрос файлов из uchile:

                 ####################
                 # pablo
                 system          pablo
                 forward         uchile
                 ####################
                 # uchile
                 system          uchile
                 forward-to      pablo





      Строка  forward-to  для uchile необходима , чтобы любые  полученные
файлы  фактически передались pablo. Иначе UUCP пропустил бы их. Этот пример
разрешает uchile только посылать файлы pabno чзрез seci; иной другой путь
не допустим.
      Чтобы разрешить пересылку к любой системе, используйте специальное
ключевое слово ANY (обязательно заглавные буквы).

                  13.5 Настройка  вашей Системы.

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

                  13.5.1 Установка getty

      Если Вы хотите использовать последовательную линию, как dialin порт,
Вы должны запустить процесс getty на этот порт. Однако, некоторые
реализации getty не очень  подходят для этого, так как Вы обычно хотите
использовать последовательный порт для соединения 'в' и 'из'.Следовательно,
вы должны удостовериться, чтобы использовать getty, который может
использовать линию вместе с  другими программами (типа uucico, или
minicom). Одна из таких программ - это  uugetty из getty ps пакета.
Большинство дистрибутивов Linux-a имеет его; проверите наличие uugetty в
каталоге /sbin. Другая программа, которую я знаю - mgetty (нап. Gert
Doering-м), которая также поддерживает прием факсов. Вы можете найти
последние версии этих программ на sunsite.unc.edu (там же есть и исходные
тексты).
      Объяснение различий в способе  входа в систему между uugetty и mgetty
- вне  компетенции этого небольшого раздела; для подробной информации
обращайтесь пожалуйста к Serial HOWTO (Grag Hankins),а  также
кдокументации, которая сопровождает  getty ps и mgetty.

                  13.5.2 Обеспечение UUCP Счета(account)

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


взаимодействует с Вами. При установке имени для системы pablo, Вы
(например) можете дать ей имя Upablo, как имя пользовауеля.
      Для систем, которые подключаются через последовательный порт, Вы
должны добавить эти имена в  файл паролей системы, /etc/passwd. Хорошим
вкусом считается поместить все имена UUCP в специальную группу типа
uuguest.
      Домашний  каталог счета должен находиться в общем  каталоге
/var/spool/uucppublic; оболочка входа в систему -  uucico.



      Если Вы имеете теневой установленный набор программ пароля, Вы можете
делать это с командой useradd:

      # Useradd -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucico
uablo

      Если Вы не используете теневой набор программ пароля, Вам нужно
отредактировать /etc/passwd вручную и  добавить строку, анологичную
показанной ниже, где 5000 и 150 - числовой uid и gid, назначенные
пользователю Upablo и группе uuguest, соответственно.

                 Upablo: x: 5000:150: UUCP
Account:/var/spool/uucppublic:/usr/lib/ uucp/uucico


      После установки счета, Вы должны активизировать его,  установив
пароль командой passwd.
      Чтобы позволить UUCP соединяться с вами поверх TCP, Вы должны
установить inetd, чтобы обработать подключения на порте uucp. Это можно
сделать,  добавив следующую строку в /etc/inetd.conf: (12)

      uucp   stream  tcp   nowait  root  /usr/sbin/tcpd
/usr/lib/uucp/uucico -l

      С опцией -l  uucico  выполняет собственную проверку на вход в
систему.Она запросит имя и пароль также, как и стандартная программа login,
но положится на собственный файл  паролей вместо /etc/passwd. Этот  файл


паролей называется /usr/lib/uucp/passwd и содержит пары имен входа в
систему и паролей:

                  Upablo IslaNegra
                  Ulorca co'rdoba

      12. Обратите внимание, что обычно  tcpd имеет режим 700, так что Вы
вызвали это как корень пользователя, не uucp, поскольку Вы обычно делали
бы.


      Конечнп, этот файл должен принадлежать uucp и иметь доступ 600.

      Если эта база данных звучит подобно такой хорошей идеи, Вы хотели бы
использовать на нормальных последовательных входах в систему, также, Вы
будете разочарованы, чтобы слышать, что это не возможно в настоящее время
без главных искривлений. Сначала от, Вы нуждаетесь в Taylor UUCP 1.05 в
этом, потому что это разрешает, чтобы getty передал имя входа в систему
пользователя вызова к uucico использование опции -u. (13) Затем, Вы должны
прием getty, который Вы используете в вызов uucico вместо обычного
/bin/login. С getty ps, Вы можете делать это,  устанавливая опцию LOGIN в
файле конфигурации. Однако, это отключает интерактивные входы в систему в
целом(вполне). Mgetty, с другой стороны, имеет хорошую возможность, которая
разрешает, чтобы Вы вызвали различные команды входа в систему, основанные
на имени обеспеченный пользователь. Например, Вы можете сообщать, чтобы
mgetty использовал uucico для всех пользователей, которые обеспечивают имя
входа в систему, начинающееся прописной буквой U, но допускают каждого еще
обработано стандартной командой входа в систему.
      Защищайте ваших пользователей UUCP от вызывающих операторов, дающих
ложную систему и snarfing всю их почту, Вы должны добавить команды
вызываемого - входа в систему к каждому входу системы в системном файле.
Это описано в разделе 13.5.3 выше.

                  13.5.3 Защита против Жуликов

      Одна из самых больших проблем  UUCP - то, что система вызова может
назвать не свое имя; она объявляет имя вызываемой системе после
фактического входа, но сервер не может проверить этого. Таким образом,


нападающий может войти под своим именем UUCP, симулировать, что был кем -то
еще, и прочитатьчужую почту. Это особенно опасно, если Вы предлагаете вход
в систему через анонимный UUCP,чей  пароль общеизвестен.
      Если Вы не уверены, что Вы можете доверять всем системам, которые
вызывают вашу,  Вы должны принять меры против самозванцев/Для"этого
необходимо потребовать, чтобы каждая система использовала  имя входа в
систему,  заданное called-login в sys.Например:

                 system              pablo
                 called-login      Upablo

      13. Опция -u присутствует в версии 1.04 также, но ничего не делает.





      В результате этого  всякий раз, когда  система говорит, что она -
pablo, uucico проверит, регистрировалась  ли она как Upablo. Если же нет,
вызов будет отвергнут, а соединение разорвано. Вы должны делать это
привычка добавить команду вызываемого - входа в систему к каждому входу
системы, который Вы добавляете к вашему системному файлу. Важно, что Вы
делаете это для всего sytems, независимо от того, ли они будут когда-либо
вызывать ваше место или нет. Для тех мест, которые никогда не вызывают Вас,
Вы должны возможно установить вызываемый - вход в систему к некоторым
полностью поддельное имя пользователя, типа neverlogsin.


            13.5.4 Будте бдителны - проверки последовательности обращения

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


номер обращения, а вызываемый сверяет его со своим. Если они не
соответствуют, попытка соединения будет отклонена. Если начальный номер
выбирать произвольно, нападавшим будет нелегко угадать правильный
порядковый номер обращения.
      Но проверки последовательности обращения делают  для Вас  еще больше:
даже если некоторыq очень умный человек  обнарузит ваш порядковый номер
обращения также как ваш пароль, Вы pfvtnbnt это извне. Когда нападавший
вызывает вашу подачу UUCP, и захватывает вашу почту, это увеличит
порядковый номер обращения корма на один. В следующий раз Вы вызываете вашу
подачу и пробуете регистрировать в, удаленный uucico откажется от Вас,
потому что числа не соответствуют(согласовывают) anymore!
      Если Вы допустили проверки последовательности обращения, Вы должны
регулярно проверять ваши регистрационные файлы на сообщения об ошибках,
которые намекают на возможные причины. Если ваша система отклоняет
порядковый номер обращения,  система вызова предлагает, это, uucico
поместит сообщение в регистрационный файл, говорящий что - нибудь вроде  "
Вне обращения последовательности, отклонил ''. Если ваша система не
допущуна, потому что порядковые номера находятся вне синхронизации, в
регистрационном файле будет примерно следующее " рукопожатие потерпело
неудачу (RBADSEQ) ''.
      Чтобы включить  проверку последовательности обращения, Вы должны
добавить следующую команду к входу системы:

                 # enable call sequence checks
                 sequence        true

      Еще Вы должны создать файл, содержащий порядковый номер. Taylor UUCP
хранит порядковый номер в файле, называемом ".Sequence" в каталоге spool
удаленной системы. Он должен принадлежать uucp, и иметь режим 600 (то есть
чтение и запись разрешены  только uucp). Самое лучшее инициализировать этот
файл произвольным, согласованным начальным значением. Иначе нападающий
может подобрать номер,  пробуя все значения меньше, скажем, 60.
             # cd /var/spool/uucp/pablo
             # echo 94316 > .Sequence
             # chmod 600 .Sequence
             # chown uucp.uucp .Sequence




      Конечно, удаленная система должна дать возможность проверкам
последовательности обращения также, и  использовать то же самое начальное
значение, что и  Вы.

                  13.5.5 Анонимный UUCP

  "   Зсли Вы хотите обеспечивать анонимный UUCP- доступ к вашей системе,
Вы сначала должны саздать специальное имя для него(см. выше). Общей
практикой является дать ему имя входа в систему и пароль uucp. Кроме того,
Вы должны установить несколько опций защиты для неизвестных систем.
Например, Вы можете запретить им из выполнения любых команд на вашей
системе. Однако, Вы не можете задать эти параметры в  файле sys, потому что
команда  требует имени системы, которое Вы не знаете. Taylor UUCP решает
эту проблему через команду unknown.Команда unknown  может использоваться в
файле конфигурации, чтобы определить любую команду, которая может обычно
появляться во входе системы:


                 unknown         remote-receive ~/incoming
                 unknown         remote-send ~/pub
                 unknown         max-remote-debug none
                 unknown         command-path /usr/lib/uucp/anon-bin
                 unknown         commands rmail

      Это ограничит неизвестные системы разгрузкой файлов из подкаталогов
pub  и загрузкой файлов в каталоги ниже /var/spool/uucppublic. Следующая
строка говорит uucico  игнорировать любые запросы из удаленной системы,
чтобы включить отладку локально. Последние две строки разрешают неизвестным
системам выполнять rmail; но путь команды разрешает  uucico искать команду
rmail в частном каталоге, с именем anon-bin. Это позволяет Вам обеспечить
некоторый специальный rmail, что, например, может передавать  всю почту
супер-пользователю для исследования. Это разрешает, чтобы анонимные
пользователи достигли maintainer системы, но предотвращает в то же самое
время отправление  любой почты в другие места.
      Чтобы дать возможность анонимному UUCP, Вы должны определить по
крайней мере одно неизвестное утверждение в конфигурации. Иначе uucico
отклонит  неизвестные системы.



                  13.6 UUCP Протоколы низкого уровня

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

                  13.6.1 Краткий обзор протоколов



      Поскольку UUCP используется поверх различных типов соединений, типа
последовательных строк, TCP, или даже X. 25, специфические протоколы
низкого уровня необходимы. Кроме того, отдельные реализации UUCP
представили различные протоколы, которые делают приблизительно ту же самую
вещь(дело).
      Протоколы могут быть разделены на две категории: потоковые и пакетные
протоколы. Первые передают файл в целиком, возможно  вычисляя при этом
контрольную сумму . Нет непроизводственных затрат, но требуется надежное
соединение,так как  любая ошибка потребует повторной передачи файла. Эти
протоколы обычно используются над соединениями TCP, но не подходят для
использования над телефонными линиями. Хотя современные модемы  хорошо
исправляют ошибки, нельзя обнаружить  ошибку между вашим компьютером и
модемом.
      С другой стороны, пакетные протоколы разбивают файл на отдельные
куски равного размера. Каждый пакет посылается и получается отдельно,
контрольная сумма вычисляется, и квитирование возвращено датчику. Чтобы
делать это более эффективный, протоколы подвижного окна было изобретено,
которые учитывают ограниченный номер (окно) ожидающого обработки
acknoledgements в любое время. Это значительно уменьшает  время ожидания
uucico в течение передачи. Несмотря на это, относительно большие
непроизводительные затраты( по  сравнению с потоковым протоколом), делают
пакетный протокол неэффективным для использования поверч TCR.
      Ширина пути данных также дает различие. Иногда посылка восьмибитовых
символов над последовательным соединением невозможна, например, если


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

      Следующие протоколы доступны с Taylor UUCP 1.04:

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

      i - является двунаправленным пакетным протоколом, который может
          посылать и получать файлы одновременно. Требуется дуплексное
          соединение и восьмибитовый путь  данных.Он в настоящее время
          распознается только Taylor UUCP.


      t - протокол, предназначенный для использования над соединением TCP,
          или другими,  свободными от ошибок. Использует пакеты в 1024
          байтов и требует восьмибитового чистого соединения.

      e - аналог t, но только потоковый.

      f - предназначен для использования с надежным X. 25 соединением. Это
          потоковый протокол, желателен семибитовый путь данных.
          Восьмибитовые символы цитируются, что  может сделать передачу
          неэффективной.

      G - реализация g-протокола в System V Relgase"4. Также распознается и
          некоторыми другими версиями UUCP.



      а - протокол  similiar к ZMODEM. Требуется восьми разрядное
          соединение, цитируются некоторые управляющие символы подобно XON
          и XOFF.

                 13.6.2 Настройка Протокола Передачи

      Все протоколы учитывают некоторое изменение в размерах пакета,
блокировках по времени, и т.п.. Обычно  значения по умолчанию,
обеспечивающие работу при стандартных обстоятельствах, не оптимальны для
вашей системы. Протокол g, например, использует размеры окна от 1 до 7, и
размеры пакета в степенях 2 в пределах от 64 до 4096. (14), если ваша
телефонная линия обычно настолько шумная, что теряется более  5%  всех
пакетов, Вы должны уменьшить размер пакета и сократить окно. С другой
стороны, на очень хороших телефонных линиях непроизводительные затраты
протокола при посылке запроса черз каждые 128 байт могут оказзаться
расточительными, так что Вы можете увеличивать размер пакета до  512 или
даже 1024.
      Taylor UUCP обеспечивает механизм настройки этих параметров  командой
protocol-parameter в файле  sys. Например, чтобы установить пакет протокола
g в 512 байт при обмене с pablo:

                  system          pablo
                  protocol-parameter g  packet-size  512


      14. Большинство binaries включенных в дистрибутивы Linux
устанавливают по умолчанию размер окна 7 ,размер пакета  128 байт .



      Настраиваемые параметры и их названия изменяются от протокола к
протокола. Для полного списка см. документацию,поставляемую с Taylor UUCP.

            13.6.3 Выбор Специфических Протоколов

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


протоколов,  посылая Pprotlist, из#которого подчиненный может выбирать.
      Основываясь на типе используемого порта (модем, TCP, или прямой),
uucico составит заданный по умолчанию список из протоколов. Для модема и
прямых соединений, этот список обычно включает i, a, g, G,  j и f. Для
соединений TCP, список - t, e, я, a, перегрузка, G, j, и f. Вы можете
изменить этот заданный по умолчанию список командой protocols, которая
может быть определена во входе системы также как входе порта. Например, Вы
могли бы записать в файл  port примерно следующее:

                   port serial1
                   protocols      igG

      Это требует любого входящего или исходящего соединения через этот
порт, чтобы использовать i,g, или G., если удаленная система не
поддерживает никакой из них, диалог потерпит неудачу.

            13.7 Поиск неисправностей




      Этот раздел описывает возможные неисправности в  вашем соединении
UUCP, и дает возможные пути их исправления. Однако мы были просто не в
состоянии охватить все возможные варианты.
      В любом случае, включите отладку опцией -xall, и смотрите на вывод в
файле Debug в каталоге spool. Это поможет  Вам быстро распознть, где
происходит сбой. Также, я всегда находил полезным включать динамик модема,
когда соединение не удавалось. С Hayes-совместимыми модемами это можно
сделать, добавив " ATL1M1 OK "  к дружеской беседе модема в файле dial.


      Первым делом стоит проверить все ли права доступа к файлам
установлены  правильно. Uucico должен принадлежать uucp, и все файлы в
/usr/lib/uucp, /var/spool/uucp и /var/spool/uucppublic должены принадлежать
uucp. Имеются также некоторые скрытые файлы (15) в каталоге spool, которые
также должны  принадлежать uucp.

      Uucico может сказать   "Wrong time to  call "(" Неправильное время


вызова "). Это может значить,что в файле sys , Вы не определили команду
time, которая определяет, когда удаленная системв может вызываться, или
фактически запретили заход в текущее время. Если время  обращения не
задано, uucico принимает, что система никогда не может вызываться.
      Uucico жалуется, что система уже блокирована. Это означает ,что
uucico обнаружил файл блокировки для удаленной системы в /var/spool/uucp.
Файл блокировки может остаться старого обращения к системе, если ее работа
была прервана некорректно. Однако  также правдоподобно,  что естьдругой
процесс uucico, который пробует набрать удаленную систему и застревает в
сценарие дружеской беседы, и т.д.. Если этот процесс uucico не преуспел в
соединение с удаленной системой, уничтожте его, и удалите все файлы
блокировки, которые он оставил.
      Я могу соединиться с удаленной системой, но происходит сбой сценария
дружеской беседы: Рассмотрите текст, который Вы получаете от удаленного
места. Если он искажен, это может быть связано с быстродействием. Иначе,
подтвердите, соглашается ли это действительно,  тем, что ваш сценарий
дружеской беседы ожидает. Помните, что  сценарий дружеской беседы
начинается с ожидающейся строкой. Если Вы получаете подсказку входа в
систему, затем посылаете имя, но не получаете подсказку пароля, вставьте
некоторые задержки перед посылкой этому, или четному промежутку символы. Вы
можете быть слишком быстры для вашего модема.
      Мой модем не соединяется: Если ваш модем не указывает, что DTR линия
была установлена, когда uucico вызывает,возможно Вы задали неправильное
устройство uucico. Если ваш модем распознает DTR, сверьтесь с a
      15. То есть файлы, чьи имя начинает с точки. Такие файлы обычно не
отображаются командой ls.



      Программа терминала, которую Вы можете записывать к этому. Если это
работает, включите отображение на экране к \E в начале дружеской беседы
модема. Если это не делает ECHO ваши команды в течение дружеской беседы
модема, проверьте, является ли ваше быстродействие строки слишком высоко
или низпо для вашего модема. Если Вы видите ECHO, проверьте, отключили ли
Вы ответы модема, или устанавливаете их к кодам числа. Проверите, что
сценарий дружеской беседы непосредственно правилен. Не забудьте, что Вы
должны записать две наклонных черты влево, чтобы послать тот модему.
      Мой модем пробует соединятся, но не может: Вставьте задержку в номер


телефона. Это особенно полезно когда набор идет из внутренней телефонной
сети компании. Если вы обычно пользуетесь импульсным набором,попробуйте
тоновый. В некоторых странах мощности телефонных сетей нарастили недавно и
тоновый набор иногда помогает.
      log файл говорит, что я имею чрезвычайно высокие потери передачи: Это
похоже на проблему быстродействия. Возможно связь между компьютером и
модемом  также медленна (установите ее для самой высокой эффективной
скорости)? Или  это ваши аппаратные средства, которые являются также
медленно к сервисным прерываниям вовремя? С NSC 16550A chipset на вашем
последовательном порте, 38kbps  работает хорошо; однако, без FIFOs
(подобных 16450 чипам), 9600 бит\сек - верхний предел скорости. Также  Вы
должны удостовериться, что аппаратное рукопожатие допускается на
последовательной линии.
      Другая вероятная причина - аппаратное рукопожатие не допускается на
порте. Taylor UUCP 1.04 не имеет никаких средств для включения RTS/CTS
рукопожатия. Вы должны сделать это явно из rc.serial использование
следующей команды:

               $ Stty crtscts < /dev/cua3

      Я  регистрируюсь в, но происходит сбой рукопожатия: Хорошо, может
иметься ряд проблем. Вывод в регистрационном файле должен сообщить Вам
множество. Рассмотрите то, каким протоколам удаленные предложения места
(Это посылает строку Pprotlist в течение рукопожатия). Возможно они не
имеют любого в общем (Вы выбираете любые протоколы в системном или порт?).
      Если удаленная система посылает RLCK, имеется просроченный lockfile
для Вас на удаленной системе. Если  вы уже не соединены с удаленной
системой на жругой линии попросите удалить его.
      Если она посылает RBADSEQ, другое место имеет проверки счета диалога,
допускаемые для Вас, но числа не соответствовали. Если это посылает RLOGIN,
Вас не разрешали к входу в систему под этим идентификатором.



            13.8 Регистрационные Файлы

      При компилировании набора программ UUCP на использование регистрации
taylor-стиля, Вы имеете только три глобальных регистрационных файла,которые


находятся  в каталоге spool. Основной регистрационный файл называется Log и
содержит всю информацию относительно установленных соединений и
перемещенных файлов. Типичный Log-файл выглядит примерно так
      uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo
(port cua3)
      uucico pablo - (1994-05-28 17:15:39.25 539) Login successful
      uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful
      protocol 'g' packet size 1024 window 7)
      uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving
D.pabloB04aj
      ucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving
X.pabloX04ai
      uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving
D.pabloB04at
      uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving
X.pabloX04as
      uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving
D.pabloB04c2
      uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving
X.pabloX04c1
      uucico pablo - (1994-05-28 17:15:59.05 539) Protocol 'g' packets:
sent 15,
       resent 0, received 32
      uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26
seconds)
      uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing
X.pabloX04ai
       (rmail okir)
      uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing
X.pabloX04as
        (rmail okir)
       uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing
X.pabloX04c1
        (rmail okir)


      Следуящий"важный регистрационный файл - Stats, который содержит
статистику передачи файлов. Раздел Stats соответствующий вышеупомянутой


передаче походит на это:



      postmaster pablo (1994-05-28 17:15:44.78)
      received 1714 bytes in 1.802 seconds (951 bytes/sec)
      postmaster pablo (1994-05-28 17:15:46.66)
      received 57 bytes in 0.634 seconds (89 bytes/sec)
      postmaster pablo (1994-05-28 17:15:49.91)
      received 1898 bytes in 1.599 seconds (1186 bytes/sec)
      postmaster pablo (1994-05-28 17:15:51.67)
      received 65 bytes in 0.555 seconds (117 bytes/sec)
      postmaster pablo (1994-05-28 17:15:55.71)
      received 3217 bytes in 2.254 seconds (1427 bytes/sec)
      postmaster pablo (1994-05-28 17:15:57.31)
      received 65 bytes in 0.590 seconds (110 bytes/sec)


      Третий файл - Debug. В нем содержится отладочная информация. Если Вы
используете отладку, Вы должны удостовериться, что этот файл имеет режим
защиты 600. В зависимости от режима отладки, который Вы выбрали, он может
содержать имя  входа в систему и пароль, который Вы используете для
соединения с удаленной системой.
      Некоторые UUCP binaries включенные в дистрибутивы Linux-а
компилировались, чтобы использовать регистрацию HDB-стиля. HDB UUCP
использует целую связку регистрационных файлов, сохраненных в
/var/spool/uucp/.Log. Этот каталог содержит еще три каталога, которые
называются uucico, uuxqt, и uux. Они содержат  вывод, сгенерированный
каждой из соответствующих команд, сортируемый в различные файлы для каждой
системы. Таким образом, вывод  uucico при вызове системы pablo пойдет в
.Log/uucico/pablo, в то время как  uuxqt запишет в .Log/uuxqt/pablo.
Строки, записанные в различный lofiles -  такие же как и при регистрации
Taylor.
      Когда Вы включаете отладку с HDB-стилем, вывод пойдет в .Admin в
/var/spool/uucp. При соединении из вашей системы, информация об отладке
будет послана в Admin/audit.locan, в то  время как вывод  uucico при вызове
извне  будет идти к .Admin/audit.




                                                                                                                                                                                                                                                         
  



                                                                                                                                                                       

      14. Электронная почта

      Одно из наиболее видных использований сетей начиная с первых
сетей - это электронная почта. Она начиналась как простое
обслуживание, типа копирования файла одной машины для другой, и
конкатенирования его к mailbox файлу получателя. В основном email
этим и занимаеся, хотя возрастастающая сеть с комплексом требований
и увеличением загрузки сообщений сделала необходимой более
сложную схему.
      Были изобретены различные стандарты обмена почты. Много
усилий было приложено для создания " мульти-медийной почты '',
которая включает изображения и звук в сообщения почты.
      Очень большое количество программ транспортировки почты было
выполнено для системы Un*x. Одна из лучше всего известных - sendmail
Университета Berkeley. Первоначальный автор Eric Allman теперь
активно работает над sendmail снова. Имеются два Linux порта
доступных для sendmail-5.56c, один из которых будет описан в главе 16
.., в настоящее время разрабатываемая версия sendmail - 8.6.5.
      Почтовый агент, наиболее используемый с Linux - smail-3.1.28,
который написан и обеспечен авторским правом Curt Landon Noll и
Ronald S. Karr. Он включен в большинство поставок Linux. В
последующем, мы будем обращаться к нему просто как smail, хотя
имеются другие версии, которые полностью отличны, и которые мы не
описываем здесь.
      Сравнивая с sendmail, smail довольно молод. При обработке почты
без сложных требований маршрутизации, их возможности - довольно
близки. Для больших требований, однако, sendmail всегда побеждает,
потому что его схема конфигурации намного более гибка.
      И smail и sendmail поддерживают набор файлов конфигурации,
которые должны быть настроены. Кроме информации, которая


требуется для  запуска подсистемы почты (типа локального hostname),
имеется намного больше параметров, которые могут быть настроены.
Файл конфигурации sendmail сначала очень трудно понять Выглядит,
как будто ваша кошка ходила по вашей клавиатуре с нажатой клавишей
SHIFT. Smail файлы конфигурации более структурны и проще для
понимания чем sendmail, но не дают пользователю так много свободы в
настройке поведения mailer'ов. Однако, для малого UUCP или Internet
работа, требуемая для установки любого из них - приблизительно та же
самая.



      В этой главе, мы будем иметь дело тем, чем email является и с
какими проблемами Вы, как администратор будете должны иметь дело.
Главы 15. и 16. дадут инструкции по установке smail и sendmail впервые.
      К концу текущей главы мы кратко опишем установку пользователя
почты на многих Unix-подобных системах, включая Linux.
      Для получения более подробной информации относительно
электронной почты на Linux, пожалуйста обратитесь в Electronic Mail
HOWTO Vince Skahan, который зарегистрирован comp.os.linux.announce
регулярно.

     14.1 Что такое - Сообщения Почты?

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


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



      Большинство программного обеспечения для транспорта почты в
мире Unix использует формат заголовка, выделенный в RFC 822. Его
первоначальная цель - определить стандарт для использования на
ARPANET.
      RFC 822 однако - только самый общий. Более современные
стандарты были задуманы, чтобы справиться с возрастанием
потребностей как, например, шифрование данных, поддержка набора
интернационального символа, и мульти-средств расширения почты
(MIME).
      Всего эти стандарты, заголовка состоят из отдельных строк,
отделяемых символами перевода строки.
      Типичный заголовок почты может выглядеть следующим образом:
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994 Return-Path:
<brewhq.swb.de!ora.com!andyo>
Received: from brewhq.swb.de by monad.swb.de with uucp
(Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
(Smail3.1.28.1 #28.6) id <m0pqoQr-0008qhC>; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 -
0400 Date: Tue, 12 Apr 1994 15:56:49 -0400
      Message-Id: <199404121956.PAA07787@ruby>
      From: [email protected] (Andy Oram)
      To: [email protected]
      Subject: Re: Your RPC section
       Обычно, все необходимые поля заголовка генерируются Вашим
mailer`ом, например elm (электронная почта), pine, mush, или mailx.
Некоторые однако необязательны, и могут быть добавлены
пользователем. Электронная почта, например, позволяет Вам
редактировать часть заголовка сообщения.
From: Это содержит адрес email отправителя, и возможно "реальное


имя''.



To: Это - адрес email получателя.
Subject: Описывает содержание почты в нескольких словах. По крайней
мере должен.
Date: Дата посылки почты.
Reply-To: Определяет адрес для ответа получателя. Это может быть
полезно, если Вы имеете несколько адресов, но хотите получать
большую часть почты только на том, который Вы используете наиболее
часто. Это поле необязательно.
Oranization: организация, которая обладает машиной из который почта
исходит. Это поле необязательно.
Message-ID: строка, сгенерированная транспортировщиком почты. Она
уникальна для этого сообщения.
Received: Каждый пункт, через который проходит ваша почта (включая
машины отправителя и получателя) вставляет такое поле в заголовок,
указывая имя пункта, идентичность сообщения, время и дату получения
сообщения, из какого пункта оно происходит, и которое транспортное
программное обеспечение использовалось. Это сделано чтобы Вы
могли проследить путь сообщения сообщения.
X-заголовок: mail-программы не должны жаловаться на заголовки,
которые начинаются с X-. Они используются, чтобы воплотить
дополнительные возможности, которые еще не реализованы в RFC.
      Одно исключение к этой структуре - сама первая строка. Она
начинается с ключевого слова From, которое сопровождается пробелом
вместо двоеточия. Она содержит маршрут, время и дату, когда оно
было получено последней машиной,  обрабатывавшей его, и
необязательную часть, определяющую, от которой главной ЭВМ оно
было получено.



      Поле From предусмотрено для совместимости с несколько более
старым mailer'ами, и не используется особенно часто, за исключением
интерфейсами пользователя почты.



     14.2 Как Передается Почта?

      Вообще, Вы устанавлиаете почту, используя интерфейс подобный
mailx; или более сложный подобно elm, mush, или pine. Эти программы
называются средствами пользователя почты, или MUA для краткости.
Если Вы посылаете сообщение почты, программа интерфейса будет в
большинстве случаев вручать его другой программе, которая
называется средством транспорта почты, или MTA. На некоторых
системах, имеются различные средства транспорта почты для
локальной и отдаленной почты, на других, имеется только одно.
Команда для отдаленной обычно называется rmail, для другой - lmail
(если она существует).
      Локальное получение почты, конечно, больше чем конкатенация
входящего сообщения к mailxbox получателя. Обычно, локальный MTA
поймет совмещение имен (установка локальных адресов получателя,
указывающих на другие адреса), и пересылку (переназначение почты
пользователя к некоторому другому адресату). Также, сообщения,
которые не могут быть переданы, должны обычно быть bounced, то есть
возвращенны отправителю наряду с некоторым сообщением ошибки.
       Для отдаленного получения, используемое программное
обеспечение зависит от характера связи. Если почта должна быть
передана по сети, используя TCP/IP, обычно используется SMTP. SMTP
замещает Простой Протокол передачи Почты, и определен в RFC 788 и
821 RFC. SMTP обычно соединяется с машиной получателя
непосредственно.
      В UUCP сетях, почта непосредственно не будет обычно передана,
но будет послана на главную ЭВМ адресата рядом систем
промежуточного звена. Чтобы посылать сообщение по UUCP, MTA
будет обычно выполнять rmail на системе пересылки, используя uux, и
подавать это сообщение на стандартном вводе.
      Так как это выполняется для каждого сообщения отдельно, это
может производить значительную загрузку главного узлового хаба
почты, также как сотни малых файлов, занимающих
непропорциональное количество дискового пространства. (2)
Некоторые MTA следовательно позволяют Вам собирать отдельные
сообщения для отдаленной системы в одиночном командном файле.
Командный файл содержит команды SMTP, которые локальная главная
ЭВМ обычно выдала бы, если бы использовалось прямое SMTP


соединение. Это называется BSMTP, или пакетировка SMTP. Пакет
передается программе rsmtp или bsmtp на отдаленной системе, которая
будет проиведет ввод, как будто произошло нормальное SMTP
соединение.



     14.3 Email Адреса

      Для электронной почты, адрес состоит из по крайней мере имени
машины, обрабатывающей почту определенного человека, и
идентификацию пользователя, распознаваемую этой системой. Это
может быть имя входа в систему получателя, но может также быть что -
нибудь еще. Другая почтовая адресующая схема, подобно X.400,
использует более общий набор " атрибутов " которые используются,
чтобы искать главную ЭВМ получателя в X.500.
      Способ интерпретации машинного имени зависит от сети, в
которую Вы включены.
      Абоненты Internet твердо придерживаются RFC 822 стандарта,
который требует записи [email protected], где host.domain - полностью
квалифицированное имя главной ЭВМ области. В середине знак "в".
Потому что эта запись не включает маршрут до главной ЭВМ адресата,
но дает (уникальное) hostname взамен, это называется абсолютным
адресом.
      В оригинале UUCP среды, распространенная форма была
path!host!user (путь!главная ЭВМ!пользователь), где путь описывал
последовательность главных ЭВМ для достижения главной ЭВМ
адресата. Эта конструкция называется записью пути удара, потому что
метка восклицания называется "Ударом". Сегодня, много uucp-
подобных сетей приняли RFC822, и понимают этот тип адреса.



      Однако, имеется способ определить маршруты RFC822-
совместимыми способоами: < @hostA,@hostB: user@hostC > обозначает
адрес пользователя на hostC, где                 HostC должен быть
достигнут через hostA и hostB (в этом порядке).
      Этот тип адреса - часто называется адресом маршрута.


       Когда, имеется " % " оператор адреса: user%hostB@hostA будет
сначала послан hostA, который расширяет знак процента в знак "@".
Адрес - теперь user@hostB, и Mailer будет счастливо передавать ваше
сообщение к hostB, который передаст его пользователю. Этот тип
адреса иногда упоминается как "Ye Olde ARPANET Kludge''. Однако,
много средств транспорта почты генерируют этот тип адреса.
      Другие сети имеют различные способы адресации. Decnet-
основанные сети, например, используют два двоеточия как разделитель
адресов, производя адрес так - главная ЭВМ::пользователь. X.400
стандарт использует полностью отличную схему, описывая получателя
набором пар свойств, подобно стране и организации.
      В сети FidoNet, каждый пользователь идентифицирован кодом
подобно 2:320/204.9, состоящем из четырех чисел, обозначающих: зону
(2 - для Европы), сеть (320 для Парижа), узел (локальный узловой хаб),
и указатель (PC индивидуального пользователя). Fidonet адреса можгут
быть отображены на RFC 822; вышеупомянутое написали бы как
[email protected].

     14.4 Как Работает Маршрутизация?

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



      Имеется большое различие между UUCP способом маршрутизации
дескрипторов пункта, и способром, которым делает пункт Internet. В
Internet, основная работа направления данных на главную ЭВМ
получателя (если только известен адрес IP) выполнен IP уровнем
работы с сетями, в то время как в UUCP зоне, маршрут должен быть
обеспечен пользователем, или сгенерироваться средством передачи
почты.

     14.4.1 Маршрутизация Почты в Internet

      В Internet от главной ЭВМ адресата зависит полностью,


выполняется ли любая специфическая маршрутизация почты вообще.
Значение по умолчанию должно передать сообщение главной ЭВМ
адресата непосредственно, и оставлять фактическую маршрутизацию
данных IP транспортому уровню.
      Большинство пунктов будет обычно направлять всю почту к
доступному серверу почты, который способен обработать все это
движение. Чтобы объявить это обслуживание, пункт создает так
называемую запись MX для их локальной области в DNS базе данных.
MX замещает Экспреобразователь Почты и в основном заявляет, что
главная ЭВМ сервера желает действовать как механизм продвижения
данных почты для всех машин в этой области. MX записи можгут
также использоваться, чтобы обработать траффик для главных ЭВМ,
которые не соединены с Internet самостоятельно, подобно UUCP сетям,
или сетям компаний с главными ЭВМ, несущими конфиденциальную
информацию.
      MX записи также имеют приоритет, связанный с ними. Это -
положительное целое число, которое позволяет определить
очередность посылки почты.
      Предположите, что организация Foobar Inc, хочет всю их почту
обрабатывать их машиной, называемой mailhub. Они будут иметь запись
MX примерно так в DNS базе данных:
      foobar.com        IN   MX      5    mailhub.foobar.com



      Это объявляет mailhub.foobar.com как обработчик почты для foo-
bar.com со значением предпочтения 5. Главная ЭВМ, которая хочет
передавать сообщение [email protected],  проверит DNS для
foobar.com, и найдет запись MX, указывающую на mailhub. Если не
имеется никакого MX с предпочтением меньше чем 5, сообщение будет
передано на mailhub.

     14.4.2 Маршрутизация Почты в Мире UUCP

      Маршрутизация Почты на UUCP сетях намного больше сложна чем
на Internet, потому что транспортное программное обеспечение не
выполняет никакой маршрутизации непосредственно. В более ранних
временах, вся почта была должна быть адресована, используя пути


удара. Пути Удара определяли список главных ЭВМ для передачи
сообщения, отделяемые метками восклицания, и с последующим
именем пользователя. Чтобы адресовать письмо Janet Пользователю на
машине, именованной moria, Вы использовали бы путь
eek!swim!Moria!Janet. Это послало бы почту от вашей главной ЭВМ до
eek, оттуда на swim и в заключение к moria.
      Очевидный недостаток этой методики состоит в том, что требуется,
чтобы Вы помнили много относительно сетевой топологии, и т.д.
Намного хуже, то что изменения в сетевой топологии --- подобно
удаляемым связям или удаляемым главным ЭВМ --- могут заставлять
сообщения терпеть неудачу просто потому что Вы не знали бо
изменении. И в заключение, в случае, если Вы посылаете в различные
места, Вы будете  должны модифицировать все эти маршруты.
Первый шаг в идентификации hostname был основание UUCP
Отображающего Проекта. Он размещен в Rutgers Университете, и
регистрирует все официальные UUCP hostname, наряду с информацией
относительно их соседей UUCP и их географическего расположения,
создавая уверенность, что никакой hostname не используется дважды.
Информация, собранная Проектом Отображения издана как Карты
Usenet, которые распределены регулярно через Usenet. (4) типичный
вход системы в Карте (при удалении комментариев) походит на это:
4. Maps  for  sites registered with The UUCP Mapping Project
are distributed  through  the  newsgroup  comp.mail.maps;
other  organizations  may publish separate maps for their network.



      moria
      bert(DAILY/2),
      swim(WEEKLY)
      Этот вход говорит, что moria имеет связь с bert, которую она
вызывает дважды в день, и со swim, которую она вызывает
еженедельно. Мы возвратимся к формату файлов Карты позже.
      Используя информацию связности, обеспеченной в картах, Вы
может автоматически генерировать полные пути от вашей главной
ЭВМ до любого пункта адресата. Эта информация обычно сохраняется
в файле путей, также называемом pathalias база данных. Если Карты
устанавливают, что Вы можете достигать bert через ernie, то pathalias


вход для moria, сгенерированный из отрывка Карты выше выглядит
следующим образом:
      moria           ernie!bert!moria!%s
      Если, который Вы теперь даете адрес адресата [email protected], ваш
MTA,  выберет маршрут, показанный выше, и пошлет сообщение ernie с
адресом конверта bert! Moria! Janet.
      Формирование файла путей из полных карт Usenet - не очень
хорошая идея. Информация, обеспеченная в них обычно искажается, и
иногда устаревает. Следовательно, только ряд главных главных ЭВМ
использует полные UUCP всемирные карты, чтобы формировать их
файл путей.
      Большинство абонентов поддерживает информацию
маршрутизации для абонента в их соседстве(окрестностях), и посылают
почту абоненту, которого они не находят в их базах данных на более
интеллектуальную главную ЭВМ с более полной информацией
маршрутизации. Эта схема называется интеллектуально - главной
маршрутизацией.

     14.4.3 Смешивание UUCP и RFC 822

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



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


почты. Даже ворота почты не должны иметь информации
маршрутизации для каждой одиночной UUCP главной ЭВМ в мире. Им
нужно иметь маршруты к всем областям в их базах данных. Например,
pathalias вход, показанный ниже направляет всю почту для абонента в
sub.org области к smurf:
      .sub.org        swim!smurf!%s
      Любая почта, адресованная [email protected] будет послана swim с
адресом конверта smurf! Jones! Claire.
      Иерархическая организация области называет место, позволяет
серверам почты смешивать более специфические маршруты с менее
специфическими. Например, система во Франции может иметь
специфические маршруты для подобластей fr, но направлять любую
почту для главных ЭВМ в США область к некоторой системе в США.
Таким образом,, область-основанная маршрутизация (как эта методика
называется) значительно уменьшает размер баз данных маршрутизации
также как  административных необходимых непроизводительных
затрат.
      Основная польза использования имен области в UUCP среде то что
согласие с RFC 822, разрешает простой переход между UUCP сетями и
Internet. Многие UUCP области в настоящее время имеют связь с
воротами Internet, которые действуют как их интеллектуально -
главные. Посылка сообщений через Internet быстрее, и информация
маршрутизации намного более надежна, потому что главные ЭВМ
Internet могут использовать DNS вместо Карт Usenet.
      Чтобы быть доступным из Internet, uucp-основанные области
обычно имеют ворота в Internet, и объявляют запись MX для них (MX
записи были описаны выше). Например, примите, что moria
принадлежит orcnet.org области. Gcc2.groucho.edu действует как ворота
в Internet. Moria следовательно использовал бы gcc2 как
интеллектуально - главного (smart-host), так, чтобы вся почта для
иностранных областей была передан через Internet. С другой стороны,
gcc2 объявил бы запись MX для orcnet.org, и передавал всю входящую
почту для orcnet абонента к moria.
      Единственая остающаяся проблема состоит в том, что UUCP
транспортные программы не могут иметь дело с квалифицированными
именами области. Большинство UUCP программ было разработано,
чтобы справиться с именами пункта до восьми символов, и
использование не-алфавитно-цифровых символов типа точек -


полностью вне правил.



     Следовательно, некоторое отображение между RFC 822 именами и
UUCP hostname'ами необходимо. Один общий способ отображения
FQDN на имена UUCP состоит в том, чтобы использовать pathalias файл
для этого:
      moria.orcnet.org  ernie!bert!moria!%s
      Это произведет чистый путь uucp-стиля из адреса, который
определяет полностью квалифицированное имя области. Некоторые
mailer'ы обеспечивают специальные файлы для этого; sendmail,
например, использует uucpxtable.
      Обратное преобразование иногда требуется при посылке почты из
UUCP сети в Internet. Как только отправитель почты использует
полностью квалифицированное имя области в адресе адресата, этой
проблемы можно избежать не удаляя имя области из адреса конверта
при пересылке сообщения на smart-host. Однако, имеется все еще
некоторый UUCP абонент, который - не есть часть любой области. Они
- обычно определяются,  конкатенируя псевдо область uucp.

     14.5 Pathalias и Формат файла Карты

      Pathalias база данных обеспечивает главную, направляющую
информацию в uucp-основанных сетях. Типичный вход походит на этот
(имя пункта, и путь отделяется МЕТКАМИ ТАБУЛЯЦИИ):
      moria.orcnet.org  ernie!bert!moria!%s
      moria             ernie!bert!moria!%s
      Это направляет любое сообщение к moria через ernie и bert. moria
полностью составное имя и имя UUCP должно быть задано, если mailer
не имеет отдельного способа отображения между этими именами.



      Если Вы хотите направлять все сообщения на главные ЭВМ внутри
некоторой области на реле почты, Вы может также определять путь в
pathalias базе данных, давая имя области как целевой, с
предшествующей точкой. Например, если все главные ЭВМ в sub.org


могут быть достигнуты через swim!smurf, pathalias вход мог бы выглядеть
следующим образом:
      \&.sub.org        swim!smurf!%s
      Запись в pathalias файл является допустимой только, когда Вы
имеете пункт который не должен делать много маршрутизации. Если
Вы должны делать маршрутизацию для большого количества главных
ЭВМ, лучший способ - использовать pathalias команду, чтобы создать
файл из файлов карты. Карты могут поддерживаться намного проще,
потому что Вы можете просто добавлять или удалять систему,
редактируя вход карты системы, и вновь создавать файл карты. Хотя
карты, изданные Usenet Проектом не очень используются для
маршрутизации, UUCP сети могут обеспечивать информацию
маршрутизации в их собственном наборе карт.
      Файл карты в основном состоит из списка абонентов, печатая
абонентов каждого опроса системы. Имя системы начинается в первом
столбце, и сопровождается отделенным запятой списком связей.
Список может быть продолжен через символ перевода строки, если
следующая строка начинается с метки табуляции. Каждая связь состоит
из имени пункта, сопровождаемого стоимостью, данной в скобках.
Стоимость - арифметическое выражение, состоящеее из чисел и
символических издержек. Строки, начинающиеся знаком мусора
игнорируются.
      Например, рассмотрите moria, который опрашивает swim .tobirds.com
два раза в день, и bert.sesame.com только раз в неделю. Кроме того,
связь с bert использует медленный 2400bps модем. Moria издал бы
следующий вход карт:
      moria.orcnet.org
        bert.sesame.com(DAILY/2),
        swim.twobirds.com(WEEKLY+LOW)
      moria.orcnet.org = moria
      Последняя строка делала бы это известным под именем UUCP.
Обратите внимание, что это должно быть DAILY/2, при вызове два
раза в день фактически половины стоимость для этой связи.



      Использование информации из таких файлов карты, pathalias
способно вычислить оптимальные маршруты к любому пункту


адресата, перечисленному в файле путей, и производить pathalias базу
данных из этого, которая может использоваться для маршрутизации для
этого абонента.
      Pathalias обеспечивает пару других возможностей подобно
скрывающемуся пункту (то есть абонент, доступный только через
ворота) и т.д. См. страницу для pathalias для уточнения, также как для
полного списка издержек связи.
      Комментарии в файле карты вообще содержат дополнительную
информацию относительно абонента, описанного в этом. Имеется
жесткий формат,  чтобы определить их, так, чтобы это могло быть
восстановлено(отыскано) из карт. Например, программа, называемая
uuwho использует базу данных, созданную из файлов карты, чтобы
отобразить эту информацию приятно форматируемым способом.
      Когда Вы регистрируете ваш пункт в организации, которая
распределяет файлы карты, Вы вообще должны заполнить такой вход
карты.
Ниже - типовой вход карты (фактически, это - то для моего пункта):
      #N        monad, monad.swb.de, monad.swb.sub.org
      #S        AT 486DX50; Linux 0.99
      #O        private
      #C        Olaf Kirch
      #E        [email protected]
      #P        Kattreinstr. 38, D-64295 Darmstadt, FRG
      #L        49 52 03 N / 08 38 40 E
      #U        brewhq
      #W        [email protected] (Olaf Kirch); Sun Jul 25 16:59:32 MET
DST 1993
      #
      monad     brewhq(DAILY/2)
      # Domains
      monad = monad.swb.de
      monad = monad.swb.sub.org
      Незаполненное пространство после первых двух символов -
МЕТКА ТАБУЛЯЦИИ. Значение большинства полей довольно
очевидно; Вы получите детализированное описание в любой области,
в которой Вы регистрируетесь. L поле наиболее забавно: оно задает
вашу географическую позицию в lati-tude/longitude и используется, чтобы
рисовать карты postscript, которые показывают всех абонентов для


каждой страны.



     14.6 Конфигурирование elm

      Elm замещает " электронную почту " и является одним из наиболее
приемлемых инструментальных средств Unix. Она обеспечивает
полноэкранный интерфейс с возможностью справки. Мы не будем
обсуждать, здесь как использовать elm, и остановимся только на опциях
конфигурации.
      Теоретически, Вы можете выполнять неконфигурированный elm, и
все работает хорошо ---, если Вы очень удачливы. Но имеются
несколько опций, которые должны быть установлены.
      При запуске elm читает набор переменных конфигурации из elm.rc
файла в /usr/lib/elm. Затем, она будет пытаться читать файл .elm/elmrc в
вашем исходном каталоге. Вы  обычно не пишите этот файл
самостоятельно. Он создается когда Вы выбираете "сохранить опции" в
меню опций elm.
      Набор опций для частного elmrc файла также доступен в глобальном
elm .rc файла. Большинство установок в вашем частном elmrc файле
отменяет таковые глобального файла.

     14.6.1 Глобальные Опции elm

В глобальном elm .rc файле, Вы должны установить опции, которые
относятся к имени вашего host. Например, в Виртуальном
Пивоваренном заводе, файл содержал бы следующее:
      #
      # The local hostname
      hostname = vlager
      #
      # Domain name
      hostdomain = .vbrew.com
      #
      # Fully qualified domain name hostfullname = vlager.vbrew.com
      Этот набор опций ориентирует elm относительно локального
hostname. Хотя эта информация редко используется, Вы должны


установить эти опции.



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

     14.6.2 Национальный Набор Символов

      Недавно имелись предложения исправить RFC 822 стандарт, чтобы
поддерживать различные типы сообщений, типа простых текстовых,
двоичных данных, файлов Postscript, и т.д. Набор стандартов и RFC,
покрывающий эти аспекты, обычно упоминается как MIME, или
Многоцелевые Расширения Почты Internet. Между прочим, это также
позволяет получателю узнать, использовался ли набор символов
отличный от стандартного ASCII,  при написании сообщения. Это
обеспечивается elm до некоторой степени.
      Набор символов, используемый Linux внутренне, чтобы представить
символы обычно упоминается как ISO-8859-1, что является именем
стандарта, которому он соответствует. Это также известно как
Латинский -1. Любые символы в сообщении из этого набора символов
должны иметь следующую строку в заголовке:
      Content-Type: text/plain; charset=iso-8859-1
      Система получения должна распознать это поле и принять
соответствующие меры при отображении сообщения. Значение по
умолчанию для текстовых сообщений - значение charset us-ascii.
      Чтобы отображать сообщения с набором символов отличным от
ASCII, elm должен знать, как печатать эти символы. По умолчанию,
когда elm получает сообщение с charset полем отличным от us-ascii, она
пробует отображать сообщение, используя команду, называемую
metamail. Сообщения, которые требуют, чтобы мета почта отобразилась,
показываются с " M " в самом первом столбце в экране краткого обзора.
      Так как Linux набор символов - ISO-8859-1, вызов metamail не
необходим для отображения сообщения, использующего этот набор
символов. Если еlm знает, что дисплей понимает ISO-8859-1, она не
будет использовать metamail, а отобразит сообщение непосредственно.
Это может быть выполнено,  установкой следующей опции в


глобальном elm .rc:



      displaycharset = iso-8859-1
      Обратите внимание, что Вы должны установить эти опции даже,
когда Вы никогда не собираетесь посылать или получать сообщения,
которые фактически содержат символы отличные от ASCII. Это -
потому что люди, которые посылают такие сообщения обычно
конфигурируют их mailer'ом, чтобы поместить соответствующий тип
содержания: поле в заголовке почты по умолчанию, посылают или нет
они только ascii сообщения.
      Однако, установки этой опции в elm .rc не достаточно. Проблема
состоит в том, что при отображении сообщения, elm вызывает
библиотечную функцию для каждого символа, чтобы определить
является ли он печатаемым или нет. По умолчанию, эта функция
распознает только символы ASCII, и отображает все другие символы
как "^?". Вы можете преодолеть это,  устанавливая переменную среды
LC CTYPE как ISO-8859-1, которая сообщает, что библиотека приняла
символы Latin-1 как печатаемые. Поддержка для этих и других
возможностей доступна начиная с libc-4.5.8.
      При посылке сообщений, которые содержат специальные символы
из ISO-8859-1, Вы должны удостовериться, что установлены еще две
переменные в elm .rc файле:
      charset = iso-8859-1
      textencoding = 8bit
      Это заставит elm сообщить набор символов как ISO-8859-1 в
заголовке почты, и посылать это как 8 битовые значения (значение по
умолчанию - все символы 7 бит).
      Конечно, любая из этих опций может также быть установлена в
частном elmrc файле вместо глобального.



     15. Получение smail и Выполнение

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


smail в значительной степени совместим с sendmail в поведении, их
файлы конфигурации полностью отличны.
      Основной файл конфигурации - /usr/lib/smail/config. Вы всегда
должны редактировать этот файл, чтобы отразить значения,
специфические для вашего пункта. Другие файлы, которые
конфигурируют маршрутизацию и транспортные опции, могут также
использоваться.
      По умолчанию, smail передает всю входящую почту немедленно.
Если Вы имеете относительно высокий траффик, Вы может взамен
заставить smail, собирать все сообщения в так называемой очереди, и
обрабатывать их  равномерно.
      При обработке почты внутри TCP/IP сети, smail - часто
выполняются в daemon режиме: в загрузочное время системы, он
вызывается из rc.inet2, и помещает себя в фон, где ждет входящие TCP
соединения на SMTP порте (обычно порт 25). Это очень полезно
всякий раз, когда Вы ожидаете значительный траффик, потому что smail
не запущен отдельно для каждого входящего соединения.
      Smail имеет множество флагов, которые управляют этим
поведением. Удачно что, smail поддерживает ряд стандартных режимов
- операции, которые допускаются, когда Вы вызываете его
специальным именем команды, подобно rmail, или smtpd. Мы
столкнемся с большинством их при обсуждении различных
возможностей smail.
      Имеются две связи с smail, который Вы должны иметь при всех
обстоятельствах; а именно /usr/bin/rmail и /usr/sbin/sendmail. Когда Вы
составляете и посылаете сообщение почты средством пользователя
подобно elm, сообщение будет переправлено в rmail для получения. Тот
же самое случается с почтой, приходящей в через UUCP. Некоторые
версии elm, однако, вызывают /usr/sbin/sendmail вместо rmail, так что Вы
нуждаетесь в обоих. Например, если Вы храните smail в /usr/local/bin,
напечатайте в оболочке:



      # ln -s /usr/local/bin/smail /usr/bin/rmail
      # ln -s /usr/local/bin/smail /usr/sbin/sendmail

      Если, который Вы хотите углубиться далее в подробности


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

     15.1 UUCP Установки

      Чтобы использовать smail в uucp среде, базисная установка довольно
проста. Сначала, Вы должны удостовериться, что Вы имеете две
символических связи к rmail и sendmail, упомянутому выше. Если Вы
ожидаете получать SMTP пакеты от другого абонента, Вы также
должны сделать rsmtp связь к smail.
      В smail распределении Vince Skahan, Вы найдете типовой файл
конфигурации. Он называется config.sample и постоянно находится в
/usr/lib/smail. Вы должны копировать его в конфигурации и
редактировать его, чтобы отразить значения, специфические для вашего
пункта.
      Примите, что ваш пункт именован swim .tobirds.com, и
зарегистрирован в картах UUCP как swim. Ваш smarthost - ulysses. Тогда
ваш файл конфигурации должен выглядеть следующим образом:
      #
      # Our domain names
      visible domain=two.birds:uucp
      #
      # Our name on outgoing mails
      visible name=swim.twobirds.com #
      # Use this as uucp-name as well uucp name=swim.twobirds.com
      #
      # Our smarthost
      smart host=ulysses
      Первое утверждение сообщает smail относительно областей,
которым ваш пункт принадлежит. Вставьте их имена здесь, отделяемые
двоеточиями. Если ваше имя пункта зарегистрировано в картах UUCP,
Вы должен также добавить uucp.



      При отправке(получении) сообщения почты, smail определяет имя
вашего host, используя hostname системный вызов (2), и проверяет адрес


получателя для этого hostname. Если адрес соответствует одному из
имен, или неквалифицированному hostname, получатель,
рассматривается локальным, и smail пытается передавать сообщение
пользователю.
      Видимое имя должно содержать одиночное, полностью
квалифицированное имя области вашего пункта, которое Вы хотите
использовать при выходе почты. Это имя используется при
производстве адреса отправителя для всей почты. Вы должны
удостовериться, чтобы использовать имя, которое smail распознает
относительно локального host (то есть hostname с одной из областей,
перечисленных в атрибуте области).
      Последнее утверждение устанавливает путь, используемый для
маршрутизации smart-host (описанный в разделе 14.4). С этой типовой
установкой, smail будет передавать любую почту для отдаленных
адресов интеллектуальному host. Путь, заданный в интеллектуальном
атрибуте пути будет использоваться как маршрут до интеллектуального
host. Так как сообщения будут передан через UUCP, атрибут должен
определить систему, известную вашему UUCP программному
обеспечению. Пожалуйста обратитесь к главе 13. При создании пункта,
известного UUCP.
      Имеется одна опция, используемая в вышеупомянутом файле,
который мы не объяснили; это - имя uucp. Причина использовать
опцию: По умолчанию, smail использует значение, возвращенное
hostname (2) для uucp-специфических вещей типа возвращающегося
пути, данного в строке From заголовка. Если ваш hostname не
зарегистрирован в UUCP проекте, Вы должен сообщить, чтобы smail
использовал взамен ваше полностью квалифицированное имя области.
Это может быть выполнено,  добавлением опции имени uucp к файлу
конфигурации.
      Имеется другой файл в /usr/lib/smail, называемый paths.sample. Это -
пример файла путей. Однако, Вы не будете нуждаться в нем, если Вы
не имеете связей почты больше чем к одному пункту. Если нет, Вы
будете должны написать один непосредственно, или генерировать
один из карт Usenet. Файл путей будет описан позже в этой главе.






     15.2 Установки для локальной сети

      Если Вы имеете пункт с двумя или больше главными ЭВМ,
соединенными локальной сетью (LAN), Вы будете должны обозначить
один host, который обрабатывает ваше UUCP соединение со внешним
миром. Представте, что мы снова на Виртуальном Пивоваренном
заводе, и vstout установлен как UUCP ворота.
      В среде с сетевой структурой, самое лучшее хранить
пользовательские mailbox на одиночной файловой системе, которая nfs-
связана со всеми главными ЭВМ. Это позволяет пользователям
двигаться от машины до машины, без необходимости перемещать их
почту (или даже хуже, проверять приблизительно три или четыре
машины для недавно прибытой почты каждое утро). Следовательно,
Вы также хотите делать адреса отправителя независимыми от машины.
Общая практика - использовать область, как адрес отправителя, вместо
hostname. Janet, например, определил бы [email protected] вместо
[email protected]. Мы объясним ниже, как заставить сервер
распознать имя области как допустимое имя для вашего пункта.
      Другой способ хранения всех mailbox на центральном host состоит в
том, чтобы использовать POP или IMAP. POP замещает Протокол
Почтового отделения и допускает пользователей, обращаться к их
mailbox по TCP/IP. IMAP, интерактивный Протокол Доступа Почты
подобен POP, но более общий. И клиентура и серверы для IMAP и POP
была пренесена на Linux, и доступна из sunsite.unc.edu ниже
/pub/Linux/system/Network.

     15.2.1 Написание Файлов Конфигурации

      Конфигурация для Пивоваренного завода работает следующим
образом: все главные ЭВМ за исключением сервера почты vstout
непосредственно направляют всю почту к серверу, используя
маршрутизацию smart host. Vstout непосредственно посылает всю почту
реальному smart host, который направляет всю почту Пивоваренного
завода; этот host называется moria.
      Стандартный файл конфигурации для всех главных ЭВМ отличных
от vstout походит на это:

      #


      # Our domain:
      visible domain=vbrew.com
      #
      # What we name ourselves
      visible name=vbrew.com
      #
      # Smart-host routing: via SMTP to vstout
      smart path=vstout
      smart transport=smtp
      Это очень похоже на то, что мы использовали для uucp пункта.
Основное различие - то, что транспорт, используемый, чтобы послать
почту smart host, конечно, SMTP. Атрибут области заставит smail
использовать имя области вместо локального hostname на всей почте.
      На UUCP воротах vstout, файл конфигурации немного отличный:
      #
      # Our hostnames:
      hostnames=vbrew.com:vstout.vbrew.com:vstout
      #
      # What we name ourselves
      visible name=vbrew.com
      #
      # in the uucp world, we're known as vbrew.com
      uucp name=vbrew.com
      #
      # Smart transport: via uucp to moria
      smart path=moria
      smart transport=uux
      #
      # we're authoritative for our domain
      auth domains=vbrew.com
      Этот файл конфигурации использует отличную схему, чтобы
сообщить smail, чем локальный host вызывается. Вместо того, чтобы
давать список областей и позволять находить hostname системным
вызовом, он определяет список явно. Вышеупомянутый список
содержит, и полностью квалифицированные и неквалифицированные
hostname, и область. Это заставит smail распознать [email protected] как
локальный адрес, и передавать сообщение janet.





      Auth переменная областей называет области, для которых vstout
является авторитарным. То есть если smail получает любую почту,
адресованную host .vbre.com, где host не называет существующую
локальную машину, он отклоняет сообщение и возвращает это
отправителю. Если этот вход не представлен, любое такое сообщение
будет послано smart-host, который возвратит его к vstout, и так далее,
пока оно не будет отброшено из-за превышения максимального счета
посылки на небольшое расстояние.

     15.2.2 Выполнение smail

      Сначала, Вы должны решить,  выполниться ли, smail как отдельный
daemon, или управляет SMTP портом и smail вызывается только всякий
раз, когда SMTP соединение запрошено от некоторого клиента.
Обычно, Вы предпочтете операцию daemon на сервере почты, потому
что это загружает машину гораздо меньше чем порождение smail много
раз для каждого одиночного соединения. Поскольку сервер почты
передает большинство входящей почты непосредственно
пользователям, Вы выберете операцию inetd на большинстве других
главных ЭВМ.
      Для любого режима работы, который Вы выбираете для каждого
индивидуального host, Вы должны удостовериться, что Вы имеете
следующий вход в вашем файле /etc/services:
smtp            25/tcp          # Simple Mail Transfer Protocol
      Это определяет TCP число порта, которое smail должен
использовать для SMTP диалогов. 25 - стандарт, определенный
Назначенными Числами RFC.
      В daemon режиме, smail поместится в фон, и будет ждать соединения
на SMTP порте. Когда соединение происходит, он ветвится и проводит
SMTP диалог с равным процессом. Smail daemon обычно запускается,
как команда rc.inet2, используя следующую команду:
      /usr/local/bin/smail -bd -q15m
      -bd флаг включает daemon режим, а -q15m делает обработку
сообщений в очереди каждые 15 минут.





      Если Вы хотите использовать inetd взамен, ваш файл /etc/inetd.conf,
должен содержать строку:
      smtp    stream  tcp nowait  root  /usr/sbin/smtpd smtpd
      Smtpd должен быть символическая связь к smail двоичному. Не
забудьте, что Вы должны заставить inetd повторно-читать inetd.conf,
посылая ему сигнал HUP после создания этих изменений.
      Daemon режим и inetd режим взаимно исключающиеся. Если Вы
выполняете smail в deamon режиме, Вы должны удостовериться, и
прокомментировать любую строку в inetd.conf для smtp обслуживания.
При наличии inetd управления smail, удостоверитесь, что rc.inet2 не
запускает smail daemon.

     15.3 Если Не Проходит ...

      Если кое-что идет неправильно с вашей установкой, имеется ряд
возможностей, которые могут помочь Вам найти корень проблемы.
Первое место, которое нужно проверить - регистрационные файлы
smail. Они сохраняются в /var/spool/smail/log, и именованы logfile и
paniclog, соответственно.
      Типичный вход в logfile походит на это:
      04/24/94 07:12:04: [m0puwU8-00023UB] received
      |            from: root
      |         program: sendmail
      |            size: 1468 bytes
      04/24/94 07:12:04: [m0puwU8-00023UB] delivered
      |             via: vstout.vbrew.com
      |              to: [email protected]
      |         orig-to: [email protected]
      |          router: smart host
      |       transport: smtp



      Это показывает, что сообщение от root до [email protected]
было правильно передано host vstout над SMTP.
      Сообщения smail не могут быть переданы, генерацией входа в
регистрационном файле, но сообщение об ошибке передается:


      04/24/94 07:12:04: [m0puwU8-00023UB] received
      |            from: root
      |         program: sendmail
      |            size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] [email protected] ... deferred
(ERR 148) transport smtp: connect: Connection refused
Вышеупомянутая ошибка типична для ситуации, в которой smail
правильно распознает, что сообщение должно быть передан к vstout, но
не был способен соединиться с SMTP обслуживанием по vstout. Если
это случается, Вы или имеете проблему конфигурации, или поддержка
TCP отсутствует в вашем smail binaries.
Эта проблема не так уж необыкновена, как можно было думать. Имелся
бы исходник smail binaries, даже в некоторых распределениях Linux, без
поддержки для работы с сетями TCP/IP. Если дело обстоит так, Вы
должны компилировать smail самостоятельно. Устанавливая smail, Вы
можете проверять, имеет ли он TCP поддержку работы с сетями telnet к
SMTP порту на вашей машине. Успешное соединие с SMTP сервером,
показывается ниже:
      $ telnet localhost smtp
      Trying 127.0.0.1...
      Connected to localhost.
      Escape character is '^]'.
      220 monad.swb.de Smail3.1.28.1 #6 ready at Sun, 23 Jan 94
      19:26 MET
      QUIT
      221 monad.swb.de closing connection
      Если этот тест не производит SMTP заголовок (строка,
начинающаяся с 220 кода), сначала удостовертесь, что ваша
конфигурация действительно правильна прежде, чем компилировать
smail самостоятельно, как описано ниже.



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


Вам большое количество подсказок относительно того что,  идет
неправильно.

     15.3.1 Компиляция smail

      Если Вы знаете наверняка, что smail испытывает недостаток TCP
поддержки сети, Вы должны получить исходник. Он возможно
включен в ваше распределение, если Вы получили его через CD-ROM,
иначе Вы можете получать его из сети через FTP.
      При компилировании smail, лучше всего работать с набором файлов
конфигурации из newspak распределения Vince Skahan's. Чтобы
компилировать в TCP драйвере работы с сетями, Вы должны
установить макркоманду КОНФИГУРАЦИИ ДРАЙВЕРА в conf/EDITME
файле к или bsd-сети или arpa-сети. Вышеупомянутые подходят для
инсталляции LAN, но Internet требует arpa-сети. Различие между этими
двумя - в том, что последний имеет специальный драйвер для  BIND
обслуживания, которое способно распознать записи MX.

     15.4 Режимы доставки Почты

      Как отмечено выше, smail способен передать сообщения
немедленно, или ставить их в очередь для обработки позже. Если,
который Вы выбираете очередь, smail сохранит всю почту в каталоге
сообщений  /var/spool/smail.



      Вы можете выбирать один из трех режимов получения,
устанавливая атрибут режима получения в файле конфигурации как
активный, фоновый, или поставленный в очередь.
      Если Вы включаете формирование очереди, Вы должны
удостовериться, что  очередь проверяется регулярно; возможно каждые
10 или 15 минут. Если Вы выполняете smail в daemon режиме, Вы
должны добавить опцию -q10m в командной строке. В качестве
альтернативы, Вы можете вызывать runq из cron в этих интервалах.
Runq должен быть связан с smail.
      Вы можете отображать текущую очередь почты,  вызывая smail с -bp
опцией. Так же, Вы можете делать mailq связь с smail, и вызывать mailq:


      $ mailq -v
      m0pvB1r-00023UB From: root  (in /var/spool/smail/input)
                Date: Sun, 24 Apr 94 07:12 MET DST
        Args: -oem -oMP sendmail [email protected] Log of transactions:
Xdefer: <[email protected]> reason: (ERR 148) transport smtp: connect:
Connection refused
      Это показывает одиночное сообщение, в очереди сообщений. Файл
регистрации (который отображается, если Вы даете mailq -v опцию)
может давать дополнительную причину, почему оно все еще ждет
получения.
         Даже, когда Вы не используете формирование очереди, smail
будет иногда помещать сообщения в очередь, когда он находит
непосредственные сбои получения по нерезидентной причине. Для
SMTP соединений, это может быть недоступный host; но сообщения
могут также быть отсрочены, когда файловая система полна.



     15.5 Разнообразная конфигурация Опций

      Имеется очень большое количество опций, которые Вы можете
устанавливать в файле конфигурации, которые, хотя и полезны, но не
существенны для выполнения smail, и которые мы не будем обсуждать
здесь. Взамен, мы только упомянем несколько, что бы Вы могли
находить причины использовать их:
Если error copy postmaster - булева переменная установлена, любая
ошибка,  генерирует сообщение начальнику почтового отделения.
Обычно, это выполнено для ошибок, которые появляются из-за
дефектной конфигурации. Переменная может быть включена,  помещая
ее в файле конфигурации, с предшествующим плюсом (+).
max hop count  Если число переходов сообщения (то есть число главных
ЭВМ, уже пересеченных) равняется или превышает это число, попытки
получения приведут к сообщению об ошибках,  возвращаемому
отправителю. Это используется, чтобы предотвратить сообщения от
выполнения бесконечного цикла. Счет перходов вообще вычислен из
числа Received: поля в заголовке почты, но могут также быть
установлен вручную используя -h опцию в командной строке.
      Значение по умолчанию 20.


postmaster  Адрес постмастера. Значение по умолчанию - root.

     15.6 Маршрутизация и Получение Сообщений

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



      Транспортный модуль, в заключение, является ответственным за
любой метод получения, который был выбран. Он пробует передавать
сообщение, и в случае отказа или генерирует сообщение удара, или
задерживает его для более позднего повторения.
      С smail, Вы имеете много свободы в конфигурировании этих задач.
Для каждого из них, доступен ряд драйверов, из которого Вы можете
выбирать те, в которых Вы нуждаетесь. Вы описываете их smail в паре
файлов, а именно routers, directors, и transports в /usr/lib/smail. Если эти
файлы не существуют, приняты приемлемые значения по умолчанию.
Если Вы хотите изменить маршрутизацию smail, или изменить
транспорт, Вы должны получить типовые файлы из smail исходного
распределения, скопировать типовые файлы в /usr/lib/smail, и изменять
их согласно вашим потребностям. Типовые файлы конфигурации также
даны в Приложении(аппендиксе) 20.3.

     15.7 Маршрутизация Сообщений

      Когда дано сообщение, smail проверяет, если адресат - локальный
host, или отдаленный пункт. Если целевой адрес host является одним из
локального hostname, конфигурированного в конфигурации, сообщение
будет передано модулю управления. Иначе, smail вручает адрес ряду
драйверов программы маршрутизации, чтобы выяснить которому host'у
передано сообщение. Они могут быть описаны в файле routers; если
этот файл не существует, используется набор заданных по умолчанию


программ маршрутизации.
      Host адресата передается всем программам маршрутизации по
очереди, и находящий наиболее специфический маршрут будет выбран.
Рассмотрите сообщение, адресованное [email protected]. Одна
программа маршрутизации могла бы знать заданный по умолчанию
маршрут для всех главных ЭВМ в bar.com области, в то время как другая
имеет информацию для foo.bar.com непосредственно. Если там - две
программы маршрутизации, которые обеспечивают "лучшее
соответствие'', та что раньше в файле программ маршрутизации будет
выбрана.



      Эта программа маршрутизации теперь определяет транспорт,
который нужно использовать, например UUCP, и генерирует новый
адрес адресата. Новый адрес передан на транспорт наряду с host. В
вышеупомянутом примере, smail мог бы выяснять, что foo.bar.com
должен быть достигнут через UUCP использование пути ernie!Bert.
Тогда генерируется новая цель из bert!Foo.bar.com!user, и используется
UUCP транспорт, поскольку конверт адресован к ernie.
      При использовании заданной по умолчанию установки, следующие
программы маршрутизации доступны:
+  Если,  адрес host адресата может быть разрешен, используя
gethostbyname или gethostbyaddr вызов из библиотек, сообщение, будет
передано через SMTP. Единственое исключение - если адрес найден,
чтобы обратиться к локальному host.
      Smail также распознает адреса IP, которые пишутся как точечная
четверка, как допустимый hostname, если только они могут быть решены
через gethostbyaddr обращение. Например, scrooge@ [149.76.12.4] был
бы допустим, хотя это необычный почтовый адрес для scrooge на
quark.physics.groucho.edu.
      Если ваша машина находится на Internet, эти программы
маршрутизации - не то, что Вы ищете, потому что они не
поддерживают записи MX. См. ниже что делать в этом случае.
+  Если pathalias база данных (/usr/lib/smail/paths) существует, smail пробует
искать целевой host (минус любой конечный .uucp) в этом файле. Почта
к адресу, согласованному этой программой маршрутизации будет
передана используя UUCP, и используя путь, найденный в базе данных.


+ Адрес host (минус любой конечный .uucp) будет сравниваться с
выводом команды uuname, чтобы проверить является ли целевой host
фактически соседом UUCP. Если дело обстоит так, сообщение будет
передан использованием UUCP транспорта.
+ Если,  адрес не был согласован любой из вышеупомянутых программ
маршрутизации, он будет передан smart host. Путь smart host также как
транспорт, который нужно использовать установлен в файле
конфигурации.

      Эти значения по умолчанию работают для многих простых
установок, но сбоят при более сложной маршрутизации. Если перед
Вами стоит одна из проблем, обсужденных ниже, Вы будет должен
установить ваши собственные программы маршрутизации.
      Возможно самые плохие проблемы возникают, когда ваш host живет
в двойной области, и с телефонным вызовом по номеру IP и со связями
UUCP. smail будет пытаться передавать любую почту через SMTP. Это -
обычно не, что Вы хотите, потому что, даже если связь SLIP
активизирована регулярно, SMTP - намного медленнее чем посылка
почты над UUCP. С заданной по умолчанию установкой, не имеется
никакого способа выйти из smail.
      Вы можете избегать этой проблемы при наличии проверки файла
путей перед запросом решающего устройства, и помещении всех
необходимых главных ЭВМ в файл путей. Если Вы не хотите посылать
сообщения над SMTP когда-либо, Вы можете также закомментировать
решающие рограммы маршрутизации в целом.
      Другая проблема состоит в том, что заданная по умолчанию
установка не обеспечивает истинную маршрутизацию почты Internet,
потому что решающая программа маршрутизации не оценивает записи
MX. Чтобы давать возможность полной поддержке маршрутизации
почты Internet, прокомментируйте эту программу маршрутизации, и
разкомментируйте ту что используется BIND взамен. Имеются, однако,
smail binaries включенные в некоторые распределения Linux, которые не
имеют поддержки BIND. Если Вы даете возможность BIND, но
получаете сообщение в paniclog файле, говорящее "программа
маршрутизации inet hosts: драйвер связи не найден'', тогда Вы должны
получить исходники и перетранслировать smail (см. раздел 15.2 выше).
      В заключение, это вообще не очень хорошая идея - использовать
uuname драйвер.





     15.7.1 База данных путей

      Smail ожидает находить pathalias базу данных в файле путей в
/usr/lib/smail. Этот файл необязателен, так если Вы не хотите выполнять
любой pathalias вообще, просто удалите любой существующий файл
путей.
      Paths должен быть сортируемый файл ASCII, который содержит
входы, которые отображают имена пункта адресата UUCP. Файл
должен сортироваться, потому что smail использует двоичный поиск
пункта. Комментарии не позволяются в этом файле, и имя пункта
должно отделиться от пути, используя МЕТКУ ТАБУЛЯЦИИ. Pathalias
базы данных обсуждены подробнее в главе 14 ..
      Если Вы генерируете этот файл вручную, Вы должен
удостовериться, чтобы включить все допустимые имена для пункта.
Например, если пункт известен и  простым именем UUCP и полностью
квалифицированным именем области, Вы должны добавить вход для
каждого из них. Файл может сортироваться конвейерной пересылкой
его через команду sort.
      Если ваш пункт является только пунктом листа, то никакой файл
paths, не должен быть необходим вообще: только установите атрибуты
smart host в вашем файле конфигурации, и оставьте всю маршрутизацию
вашей подаче почты.

     15.8 Поставка Сообщений Локальным Адресам

      Обычно, локальный адрес - только имя входа в систему
пользователя, когда сообщение передается в его mailbox,
/var/spool/mail/user. Другие случаи включают отправку по почте списка
имен, и пересылку почты пользователем. В этих случаях, локальный
адрес расширяется до нового списка адресов, которые могут быть или
локальны или отдаленны.
      Кроме этих "нормальных" адресов, smail может обрабатывать другие
типы локальных адресатов сообщения, подобно именам файла, и
командам трубопровода. Они - не адреса, так что Вы не можете
посылать почте на /etc/[email protected].


      Имя файла - что-нибудь, что начинается с наклонной черты вправо
(/) или тильды (~). Письмо относится к исходному каталогу
пользователя, и возможно только, если имя файла принималось из a
.forward файл или вход пересылки в mailbox (см. ниже). При поставке
файла, smail конкатенирует сообщения к файлу, создавая его в случае
необходимости.



      Командой трубопровода может быть любая команда Unix, которой
предшествует символ трубопровода (|). Это заставляет smail вручать
команду оболочке наряду с аргументами, но без подачи " | ". Сообщение
непосредственно будет подано этой команде на стандартном вводе.
      Например, чтобы отправить почту в локальную newsgroup, Вы
могли бы использовать команду оболочки, именованную gateit, и
устанавливать локальный результат, который передает все сообщения
из этого списка в команду, используя " | gateit ".
      Если вызов содержит незаполненное пространство, он должен быть
включен в двойные кавычки. Из-за проблем защиты команда не
выполняется, если адрес был получен несколько сомнительным
способом (например, если файл, из которого адрес принимался, был
перезаписываем каждым).

     15.8.1 Локальные Пользователи

      Наиболее общий случай для локального адреса - обозначить mailbox
пользователя. Этот mailbox - локализовался /var/spool/mail, и имеет имя
пользователя. Если он не существует, он создан smail.
      Обратите внимание, что, хотя /var/spool/mail - в настоящее время
стандартное место, чтобы поместить mailbox файлы, некоторое
программное обеспечение почты может иметь другой paths,
компилируемый в, например /usr/spool/mail.
      Имеются два адреса которые требуются smail: mailer - daemon и
Постмастер. При производстве сообщения удара для почты undeliverable,
машинописная копия послана постмастеру объяснение исследования (в
случае, если это могло бы быть из-за проблемы конфигурации). Mailer -
daemon используется как адрес отправителя для сообщения удара.
      Если эти адреса не называют допустимые счета на вашей системе,


smail неявно отображает mailer - daemon как postmaser, и постмастера как
root, соответственно. Вы должны обычно отменять это совмещением
имени постмастера с тем, кто является ответственным за поддержание
программного обеспечения почты.



     15.8.2 Пересылки

      Пользователь может переназначать почту посылая ее к
альтернативному адресу, используя один из двух методов,
обеспечиваемых smail. Одна опция должна поместить
      Forward to recipient,...
в первой строке ее mailbox файла. Это пошлет всей входящей почте
заданному списку получателей. В качестве альтернативы, она могла бы
создавать a .forward файл в ее исходном каталоге, который содержит
отделенный запятой список получателей. С этим разнообразием
пересылки, все строки файла читаются и интерпретируются.
      Обратите внимание, что любой тип адреса может использоваться.
Таким образом, практический пример .forward файла мог бы быть
      janet, "|vacation"
      Первый адрес передает входящее сообщение mailbox janet, в то время
как команда vacation возвращает короткое уведомление отправителю.

     15.8.3 Специальные Файлы
      Smail способен обработать специальные файлы, совместимые с теми
что известны sendmail Berkeley. Входы в специальном файле могут
иметь форму
      alias: recipients
      recipients - отделенный запятой список адресов, которые будут
заменяться специально. Список получателей может быть продолжен
через символы перевода строки, если следующая строка начинается с
МЕТКИ ТАБУЛЯЦИИ.
      Имеется специальная возможность, которая позволяет smail
обрабатывать списки отправки по почте из специального файла: если
Вы определяете ":include:filename" как получателя, smail будет читать
заданный файл, и применять содержимое как список получателей.





      Основной файл побочных результатов исследования - /usr/lib/aliases.
Если Вы сделаете этот файл всемирно - перезаписываемым, smail не
будет передавать сообщения командам оболочки, данным в этом файле.
Типовой файл показывается ниже:
# vbrew.com /usr/lib/aliases file hostmaster: janet
      postmaster: janet
      usenet: phil
# The development mailing list. development: joe, sue, mark, biff
/var/mail/log/development
      owner-development: joe
# Announcements of general interest are mailed to all # of the staff
announce: :include: /usr/lib/smail/staff, /var/mail/log/announce
      owner-announce: root
# gate the foobar mailing list to a local newsgroup ppp-list: "|/usr/local/lib/gateit
local.lists.ppp"
      Если ошибка происходит при ипользовании адреса,
сгенерированного из специального файла, smail будет пытаться
посылать копию сообщения об ошибках к "специальному владельцу''.
Если адрес владельца не существует, никакое дополнительное
сообщение об ошибках не будет сгенерировано.

     15.8.4 Списки Отправки по почте

      Вместо того, чтобы использовать специальный файл, чтобы
отправить по почте по списку можно также управляться посредством
файлов в каталоге /usr/lib/smail/lists. Список отправки по почте,
именованный nag-bugs описан как lists/nag-bugs, должен содержать
адреса элементов, отделяемые запятыми. Список может быть дан на
нескольких строках, с комментариями.



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


сообщений в Sender: поле заголовка.

     15.9 UUCP-Транспорт

      Имеется ряд транспортировщиков, компилируемых в smail, которые
используют UUCP набор программ. В UUCP среде, сообщения обычно
передаются,  вызывая rmail на следующем host, давая ему сообщение на
стандартном вводе и адрес конверта в командной строке. На вашем
host, rmail должен быть связан с командой smail.
      При вручении сообщения на UUCP транспорт, smail
преобразовывает целевой адрес в путь удара UUCP. Например,
user@host будет преобразован host!user. Любое местонахождение " % "
оператора адреса сохраняется, так что user%host@gateway станет
gateway!User%host. Однако, smail никогда не будет генерировать такие
адреса самостоятельно.
      В качестве альтернативы, smail может посылать и получать BSMTP
пакеты через UUCP. В BSMTP один или большее количество
сообщений передаются в одиночном пакете, который содержит
команды, которые локальный mailer выдал бы, если бы реальное SMTP
соединение имело место. BSMTP часто используется с промежуточным
накоплением, чтобы сохранить дисковое пространство. Типовой файл
транспорта в приложении 20.3 содержит транспорт dubbed bsmtp
который генерирует частичные BSMTP пакеты в каталоге очередей.
Они должны быть объединены в конечные пакеты позже, при
использовании команды оболочки, которая добавляет
соответствующую команду HELO и QUIT.
      Чтобы давать возможность bsmtp транспорту для специфических
связей UUCP, Вы должны использовать так называемые файлы метода
(пожалуйста обратитесь к smail странице руководства для
подробностей). Если Вы имеете только одну связь UUCP, и используете
программу маршрутизации smart host, Вы даете возможность посылать
SMTP пакеты,  устанавливая интеллектуальную транспортную
переменную конфигурации как bsmtp вместо uux.
      Чтобы получать SMTP пакеты над UUCP, Вы должны
удостовериться, что Вы имеете команду распакетирования. Если
отдаленный пункт использует smail, Вы должны связать rsmtp с smail.
Если отдаленный пункт выполняет sendmail, Вы должны
дополнительно установить команду оболочки, именованную


/usr/bin/bsmtp, которая делает простой "запуск rsmtp".



     15.10 SMTP-Транспорт
      Smail в настоящее время поддерживает SMTP драйвер, чтобы
передавать почту по TCP соединениям. Это дает возможность посылки
сообщения любому числу адресов на одиночном host, с hostname,
определяемым или как полностью квалифицированное имя области
которое может быть использовано программным обеспечением работы
с сетями, или в точечной записи четверки, включенной в квадратные
скобки. Вообще, адреса, решенные любым BIND, gethostbyname или
gethostbyaddr драйверов программы маршрутизации будут переданы на
SMTP транспорт.
      SMTP драйвер будет пытаться соединяться с отдаленным host
немедленно через smtp порт как перечислено в /etc/services. Если это не
может быть достигнуто, или соединение прерывается, оно будет
повторно предпринято в более позднее время.
      Получение на Internet требует, чтобы маршруты до host адресата
были определены в формате адрес-маршрут, описанном в главе 14, а не
как путь удара. smail будет следовательно трансформировать
user%host@gateway, где gateway достигнут через host1!host2!host3, по
адресу исходного маршрута < @host2,@host3:user%host@gateway >,
который будет послан как конверт, адресованный host1. Чтобы давать
возможность этому преобразованию (наряду с встроенным драйвером
BIND), Вы должны редактировать вход для smtp драйвера в файле
transports. Типовой файл transports дан в Приложении 20.3.



     15.11 Квалификация Hostname

      Иногда желательно захватить неквалифицированные hostname (то
есть те, которые не имеют имени области) заданные в адресе
отправителя или получателя, например при переходе между двумя
сетями, где каждая требует полностью квалифицированных имен
области. На Internet -UUCP реле, такие hostname должны быть
отображены в uucp область по умолчанию. Другие изменения адреса


сомнительны.
      Файл /usr/lib/smail/qualify сообщает smail, которая область определяет
путь на который hostname. Входы в файле qualify состоят из hostname в
перевом столбце, сопровождаемым именем области. Строки,
содержащие знак мусора как первый символ рассматриваются
комментариями. Входы ищутся в порядке, в котором они появляются.
      Если никакого файла qualify не существует, никакая hostname
квалификация не  выполняется вообще.
      Специальный hostname * соответствует любому hostname, таким
образом допуская Вам отобразить все главные ЭВМ, не упомянутые
прежде в заданную по умолчанию область. Это должно использоваться
только как последний вход.
      В Виртуальном Пивоваренном заводе, все главные ЭВМ были
установлены так, чтобы использовать полностью квалифицированные
имена области в адресах отправителя. Неквалифицированные адреса
получателя, как рассматривается, находятся в uucp области, так что
необходим только одиночный вход в файле qualify.
      # /usr/lib/smail/qualify, last changed Feb 12, 1994 by janet
      #
      *            uucp



     16. Sendmail + IDA

     16.1 Введение в Sendmail + IDA

      Уже упоминалось, что Вы не реальный администратор системы
Unix, пока вы не редактировали sendmail.cf файл. Также скажут что вы
сумасшедший, если вы попытаетесь сделать это дважды :-)
      Sendmail - невероятно мощная программа. Также невероятно трудно
узнавать и понимать ее для большинства людей. Любая программа, чье
окончательное руководство (Sendmail, изданный O'Reilly and Associatеs)
состоит из 792 страниц, отпугивает большинство людей.
      Sendmail + IDA - это другое. Это удаляет потребность редактировать
всегда загадочный sendmail.cf файл и позволяет администратору
определять пункт-специфическую маршрутизацию и конфигурацию
адресации через относительно простые для понимания файлы


поддержки, называемые таблицами. sendmail + IDA может сохранять
Вам много часов работы и спокойствия.
      Сравниваясь с другими главными средствами транспорта почты, не
имеется ничего, что не может быть выполнено быстрее и проще с
sendmail + IDA. Типичные вещи, которые необходимы, чтобы
реализовать UUCP или Internet узел, станут простыми для выполнения.
Конфигурации, которые обычно являются чрезвычайно трудными,
просто создавать и поддержать.
      В этой запииси, текущая версия sendmail5.67b + IDA1.5 доступен
через анонимный FTP из vixen.cso.uiuc.edu. Она компилируется без
любого внесения исправлений, требуемого под Linux.
      Все файлы конфигурации, требуемые, чтобы получить исходники
sendmail + IDA, чтобы компилировать, устанавливать, и выполнять под
управлением Linux включены в newspak-2.2.tar.gz, который является
доступным через анонимный FTP на sunsite.unc.edu в каталоге
/pub/Linux/system/Mail.

     16.2 Файлы Конфигурации --- Краткий обзор

      Традиционный sendmail установлен через файл конфигурации
системы (обычно /etc/sendmail.cf или /usr/lib/sendmail.cf), который - не
относится к любому языку, который вы видели прежде.
Редактирование sendmail.cf файла, чтобы обеспечить настроенное
поведение может быть хорошим опытом.

      Sendmail + IDA делает такую работу по существу делом прошлого
при наличии всех опций конфигурации, с формированием
изображений при помощи таблицы с довольно простым, чтобы понять
синтаксис. Эти опции конфигурируются,  выполнением m4
(процессора макркоманд) или dbm (процессора базы данных) в ряде
файлов данных через Make-файлы, обеспеченные исходниками.
      Sendmail.cf файл определяет только заданное по умолчанию
поведение системы. Виртуально вся специальная настройка выполнена
через ряд необязательных таблиц а не  непосредственно редактируя
sendmail.cf файл.





     16.3 Sendmail.cf Файл

      Sendmail.cf файл для sendmail + IDA не редактируется
непосредственно, а генерируется из m4 файла конфигурации,
обеспеченного локальным администратором системы. В следующем,
мы обратимся к нему как к sendmail.m4.
      Этот файл содержит несколько определений и иначе просто
указывает на таблицы, где выполняется реальная работа. Вообще,
необходимо определить только:
+ Имена путей и имена файлов, используемые в локальной системе.
+ Имена пункта электронной почты.
+ Который заданный по умолчанию mailer (и возможно smart host)
желателен.
      Имеется большое разнообразие параметров, которые могут быть
определены, чтобы установить поведение локального пункта сети. Эти
опции конфигурации идентифицированы в файле ida/cf/OPTIONS в
исходном каталоге.
      Файл sendmail.m4 для минимальной конфигурации (UUCP или
SMTP со всей не-локальной почтой,  передаваемой непосредственно
соединенному smart-host) может быть в 10 или 15 строк, исключая
комментарии.



Mailertable определяет специальное поведение для отдаленных главных
ЭВМ или областей.
Uucpxtable включает получение почты UUCP на главные ЭВМ, которые
находятся в формате DNS.
Pathtable определяет UUCP пути на отдаленные главные ЭВМ или
области.
Uucprelays замыкает pathalias путь на общеизвестные отдаленные
главные ЭВМ.
Genericfrom преобразовывает внутренние адреса в обобщенные,
видимые внешнему миру.
Xaliases преобразовывает обобщенные адреса на\из допустимых
внутренних.
Decnetxtable преобразовывает RFC-822 адреса в адреса DECnet-стиля.



     16.3.1 Пример Файла Sendmail.m4

      Файл sendmail.m4 для vstout на Виртуальном Пивоваренном заводе
показывается ниже. Vstout использует SMTP, чтобы разговаривать со
всеми главными ЭВМ на LAN Пивоваренного завода, и посылает всю
почту для других адресатов к moria, host реле Internet, через UUCP.

     16.3.2 Обычно Используемые sendmail.m4 Параметры

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



dnl #------------------ SAMPLE SENDMAIL.M4 FILE ------------------
dnl # (the string 'dnl' is the m4 equivalent of commenting out a line)
dnl # you generally don't want to override LIBDIR from the compiled in paths
dnl #define(LIBDIR,/usr/local/lib/mail)dnl      # where all support files go
      define(LOCAL MAILER DEF, mailers.linux)dnl        # mailer for local delivery
      define(POSTMASTERBOUNCE)dnl       # postmaster gets bounces
      define(PSEUDODOMAINS, BITNET UUCP)dnl     # don't try DNS on these
dnl #-------------------------------------------------------------
      dnl #
      define(PSEUDONYMS, vstout.vbrew.com  vstout.UUCP vbrew.com)
      dnl               # names we're known by
      define(DEFAULT HOST, vstout.vbrew.com)dnl # our primary 'name' for
mail
      define(UUCPNAME, vstout)dnl       # our uucp name
      dnl #
dnl #-------------------------------------------------------------
      dnl #
      define(UUCPNODES, |uuname|sort|uniq)dnl   # our uucp neighbors
      define(BANGIMPLIESUUCP)dnl        # make certain that uucp
      define(BANGONLYUUCP)dnl   #  mail is treated correctly
      define(RELAY HOST, moria)dnl      # our smart relay host
      define(RELAY MAILER, UUCP-A)dnl   # we reach moria via uucp


      dnl #
dnl #--------------------------------------------------------------------dnl #
      dnl # the various dbm lookup tables
      dnl #
      define(ALIASES, LIBDIR/aliases)dnl        # system aliases
      define(DOMAINTABLE, LIBDIR/domaintable)dnl        # domainize hosts
      define(PATHTABLE, LIBDIR/pathtable)dnl    # paths database
      define(GENERICFROM, LIBDIR/generics)dnl   # generic from addresses
      define(MAILERTABLE, LIBDIR/mailertable)dnl        # mailers per host or
domain
      define(UUCPXTABLE, LIBDIR/uucpxtable)dnl  # paths to hosts we feed
      define(UUCPRELAYS, LIBDIR/uucprelays)dnl  # short-circuit paths
      dnl #
dnl #--------------------------------------------------------------------dnl #
      dnl # include the 'real' code that makes it all work
      dnl # (provided with the source code)
      dnl #
      include(Sendmail.mc)dnl     # REQUIRED ENTRY !!!
      dnl #
      dnl #------------ END OF SAMPLE SENDMAIL.M4 FILE -------



     16.3.2.1 Предметы, которые Определяют Пути

      dnl #define(LIBDIR,/usr/local/lib/mail)dnl  # where all support files go

      LIBDIR определяет каталог, где sendmail + IDA ожидает находить
файлы конфигурации, различные dbm таблицы, и специальные
локальные определения. В типичном двоичном распределении, это
компилируется в sendmail binary и не должно быть явно установлено в
файле send-mail.m4.
     Вышеупомянутый пример содержит dnl, который означает что эта
строка - по существу только для уточнения инфрмации комментария.
      Чтобы изменить расположение файлов поддержки на другое,
удалите dnl из вышеупомянутой строки, установите путь к
желательному расположению, и восстановите, и повторно установите
sendmail.cf файл.



     16.3.2.2 Определение Локального Mailer'а

      define(LOCAL MAILER DEF, mailers.linux)dnl  # mailer for local delivery
      Большинство операционных систем обеспечивает программу для
обработки локального получения почты. Программы такого рода для
многих из главных вариантов Unix уже встроены в sendmail binary.
      В Linux, необходимо явно определить соответствующий локальный
mailer, так как такая локальная программа не обязательно предоставлена
в распределении, которое вы установили. Это определяется LOCAL
MAILER DEF в файле sendmail.m4.
      Например, можно установить LOCAL MAILER DEF как mailers.linux.
      Следующий файл должен то быть установлен как mailers.linux в
каталоге, указанном LIBDIR. Это явно определяет программу в Mlocal
mailer с соответствующими параметрами, чтобы sendmail правильно
принимал почту, направленную для локальной системы.



      Если Вы не эксперт sendmail, Вы возможно не захотите изменять
следующий пример.
   # -- /usr/local/lib/mail/mailers.linux --
   #     (local mailers for use on Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog,  P=/bin/sh,         F=lsDFMeuP,   S=10, R=10, A=sh -c $u
      Имеется также встроенное значение по умолчанию для deliver в
Sendmail.mc файле, который включается в файл sendmail.cf. Чтобы
определить его, Вы не должны использовать mailers.linux файл и взамен
определить следующее в вашем файле sendmail.m4:
      dnl --- (in sendmail.m4) ---
      define(LOCAL MAILER DEF, DELIVER)dnl       # mailer for local delivery
      К сожалению, Sendmail.mc принимает, что deliver установлен в /bin,
что не так в Slackware1.1.1 (который устанавливает это в /usr/bin). В том
случае вы нуждаетесь в фальшивке со связью или переустановить deliver
из исходников в /bin.







     16.3.2.3 Обработка Bounced-почты

      define(POSTMASTERBOUNCE)dnl                # postmaster gets bounces
      Многие абоненты находят, что важно гарантировать, что бы почта
посылалась и получалась с гарантией 100 %. При исследовании sys-logd
файлов регистрации полезен локальный администратор почты чтобы
определить, была ли почта испорчена из-за ошибки пользователя или
ошибки конфигурации на одной из включаемых систем.
      Определение POSTMASTERBOUNCE приводит к копии каждого
плохого сообщения человеку, определенному как Постмастер системы.



      К сожалению, установка этого параметра также приводит к
рассекречиванию текста сообщения,  посылаемого Постмастеру.

     16.3.2.4 Возможности Имени Области

      define(PSEUDODOMAINS, BITNET UUCP)dnl       # don't try DNS on
these
      Имеются отдельные известные сети, которые обычно указаны в
адресах почты по историческим причинам, но это не допустимо для
целей DNS. Определение PSEUDODOMAINS предотвращает
бесполезные DNS попытки поиска, которые будут всегда терпеть
неудачу.

     16.3.2.5 Определение Локальной Системы

define(PSEUDONYMS, vstout.vbrew.com  vstout.UUCP vbrew.com)dnl      #
names we're known by
define(DEFAULT HOST, vstout.vbrew.com)dnl   # our primary 'name' for mail
      Часто, системы желают скрыть их истинное тождество, и служат
как ворота почты, или получатют и обрабатывают почту, адресованную
на " старые " имена.
      PSEUDONYMS определяет список всех hostname, для которых
локальная система примет почту.


      DEFAULT HOST определяет hostname, который появится при
возникновении сообщений на локальном host.



     16.3.2.6 Uucp-зависимые Аспекты

define(UUCPNAME, vstout)dnl                 # our uucp name
define(UUCPNODES, |uuname|sort|uniq)dnl     # our uucp neighbors
define(BANGIMPLIESUUCP)dnl                  # make certain that uucp
define(BANGONLYUUCP)dnl                     #  mail is treated correctly
      Часто, системы известны под одним именем для целей DNS и
другим для целей UUCP. UUCPNAME разрешает Вам определять
различные hostname, которые появляются в заголовках выхода почты
UUCP.
      UUCPNODES определяет команды, которые возвращают список
hostnames для систем, с которыми мы соединены непосредственно с
через UUCP соединения.
      BANGIMPLIESUUCP и BANGONLYUUCP гарантирует, что почта,
адресованная с UUCP синтаксисом обрабатывается согласно UUCP, а
не более современному DNS, используемому сегодня в Internet.

     16.3.2.7 Relay-Системы и Mailer'ы

define(RELAY HOST, moria)dnl     # our smart relay host
define(RELAY MAILER, UUCP-A)dnl             # we reach moria via UUCP
RELAY HOST определяет UUCP hostname интеллектуальной соседней
системы (способной послать почты в любую сеть мира).
RELAY MAILER определяет mailer, используемый, чтобы передать туда
сообщения.
      Важно обратить внимание, что устанавливающий эти параметры
приводит к посылке  вашей почты к этой отдаленной системе, которая
будет воздействовать на загрузку их системы. Убедитесь, что вы
получили явное соглашение отдаленного Постмастера прежде, чем Вы
конфигурируете вашу систему, чтобы использовать другую систему как
универсальный relay host.





     16.3.2.8 Различные Таблицы Конфигурации

define(ALIASES, LIBDIR/aliases)dnl      # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl  # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl  # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl          # mailers per host or
domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl        # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl        # short-circuit paths
      С этими макркомандами, Вы можете изменять расположение, где
sendmail + IDA ищет различные dbm таблицы, которые определяют
поведение системы. Вообще нужно оставить их в LIBDIR.

     16.3.2.9 Главный Файл Sendmail.mc

      include(Sendmail.mc)dnl   # REQUIRED ENTRY !!!
      Авторы sendmail + IDA обеспечивают файл Sendmail.mc, который
содержит "внутренности" того, что становится файлом sendmail.cf.
Периодически выпускаются новые версии, чтобы установить ошибки
или добавлить функциональные возможности без полного выпуска и
перетрансляции sendmail из исходников.
      Важно не редактировать этот файл.

     16.3.2.10 Так которые Входы Действительно требуются?

      Если не используются dbm таблицы, sendmail + IDA передает почту
через DEFAULT MAILER (и возможно RELAY HOST и RELAY
MAILER) определенный в файле sendmail.m4, используемом, чтобы
генерировать sendmail.cf. Легко можно отменить это поведение через
входы в domaintable или uucpxtable.
      Виртуально все системы должны установить DEFAULT HOST,
макркоманды PSEUDONYMS, которые определяют каноническиое имя
пункта, и DEFAULT MAILER. Если все что Вы имеете - это relay host и
relay mailer, Вы не должны устанавлвать эти значения по умолчанию,
так как это работает автоматически.





      UUCP главные ЭВМ будут возможно также должны установить
UUCPNAME как их официальное имя UUCP. Они также возможно
установят RELAY MAILER, и RELAY HOST, которые дают
возможность маршрутизации smart-host через relay почту. Транспорт
почты, который нужно использовать определен в RELAY MAILER и
должен обычно быть UUCP-A для UUCP абонента.
      Если ваш пункт только SMTP и использует "Domain Name Service ",
Вам следует заменить DEFAULT MAILER на TCP-A и возможно
удалить СТРОКИ RELAY HOST и RELAY MAILER.

     16.4 Просмотр Sendmail + IDA Таблиц

      Sendmail + IDA обеспечивает ряд таблиц, которые позволяют Вам
отменять заданное по умолчанию поведение sendmail (заданное в файле
sendmail.m4) и определять специальное поведение для уникальных
ситуаций, отдаленных систем, и Сетей. Эти таблицы обрабатываются
dbm используя Make-файл, обеспеченный распределением.
      Большинство абонентов будет нуждаться в некоторых из этих
таблиц. Если ваш пункт не требует этих таблиц, самая простая вещь,
возможно, сделать их файлами нулевой длины (командой touch) и
использовать заданный по умолчанию Make-файл в LIBDIR, а не
редактировать Make-файл непосредственно.

     16.4.1 Mailertable

      Mailertable определяет специальное обращение для специфических
главных ЭВМ или областей, основанных на отдаленном host или
сетевом имени. Это часто используется на абоненте Internet, чтобы
выбрать промежуточный relay host для почты или gateway, чтобы
достигнуть отдаленной сети, и определить специфический протокол
(UUCP или SMTP). UUCP абонент вообще не должен использовать
этот файл.
      Порядок важен. Sendmail читает файл, нисходяще и обрабатывает
сообщения согласно первому правилу, которому оно соответствует. Так
что вообще нужно поместить наиболее явные правила наверху файла и
более обобщенных правил ниже.





      Предположите, что Вы хотите направлять всю почту для отделения
Информатики в Университете Groucho Marx через UUCP relay host ada.
Чтобы сделать так, Вам нужен пункт в mailertable, который походит на
следующее:
      # (in mailertable)
      #
# forward all mail for the domain .cs.groucho.edu via UUCP to ada UUCP-
A,ada         .cs.groucho.edu
      Предположите, что Вы хотите чтобы вся почта к groucho.edu
области шла к другому relay host - bighub. Расширенные входы mailertable
выглядели бы подобно:
      # (in mailertable)
      #
# forward all mail for the domain cs.groucho.edu via UUCP to ada UUCP-A,ada
.cs.groucho.edu
      #
# forward all mail for the domain groucho.edu via UUCP to bighub UUCP-
A,bighub      .groucho.edu
      Как упомянуто выше, порядок важен. Реверсирование порядка из
двух правил, показанных выше приводит к передаче всей почты к
.cs.groucho.edu через более обобщенный bighub путь вместо явного ada
пути, который действительно желателен.
      # (in mailertable)
      #
# forward all mail for the domain .groucho.edu via UUCP to bighub UUCP-
A,bighub     .groucho.edu
      #
      # (it is impossible to reach the next line because
      #    the rule above will be matched first)
      UUCP-A,ada        .cs.groucho.edu
      #
      В примерах mailertable выше, UUCP-A mailer заставит sendmail
использовать UUCP получение с заголовками области.





      Запятая между mailer'ом и отдаленной системой сообщает о
передаче сообщения к ada для получения.
      Mailertable входы(пункты) имеют формат:
      mailer delimiter relayhost             host or domain
      Имеется ряд возможных mailer'ов. Различия - вообще в том, как они
обрабатывают адреса. Типичные mailer'ы - TCP-A (TCP/IP с адресами -
стиля Internet), TCP-U (TCP/IP с адресами uucp-стиля), и UUCP-A
(UUCP с адресами -стиля Internet).
      Символ, который отделяет mailer от host слева в строке mailertable,
определяет, как адрес изменяется mailertable.
! Отметка восклицания удаляет hostname получателя перед пересылкой
к mailer'у. Это может использоваться, когда Вы хотите послать почту в
неконфигурированный отдаленный пункт.
, Запятая не изменяет адрес всегда. Сообщение просто будет послано
через заданный mailer заданному relay host.
: Двоеточие удаляет hostname получателя только, если имеются
промежуточные главные ЭВМ между Вами и адресатом. Таким образом
из foo!bar!Joe будет удален foo, в то время как xyzzy!Janet останется
неизменным.

     16.4.2 Uucpxtable

      Обычно, почта на главные ЭВМ с полностью
квалифицированными именами области передается в стиле Internet
(SMTP), используя Domain Name Service (DNS), или через relay host.
Uucpxtable вынуждает получение через маршрутизацию UUCP,
преобразуя имя в отдаленный hostname UUCP-стиля.


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


прямой маршрут через RELAY MAILER и RELAY HOST или через DEFAULT
MAILER.
      Абонент Internet, который не входит в UUCP может не использовать
uucpxtable.
      Предположите, что Вы обеспечиваете обслуживание пересылки почты к
системе, называемой sesame.com в DNS и sesame в картах UUCP. Вы
нуждались бы в следующем входе uucpxtable, чтобы вынудить почту для их host
пройти через ваше прямое соединение UUCP.

      #============== /usr/local/lib/mail/uucpxtable ============
      # Mail sent to [email protected] is rewritten to sesame!joe and
      # therefore delivered via UUCP
      #
      sesame          sesame.com
      #
      #----------------------------------------------------------

      16.4.3  pathtable

      Pathtable используется, чтобы определить явную маршрутизацию на
отдаленные главные ЭВМ или сети. Файл pathtable должен быть в синтаксисе
pathalias-стиля, сортируемом в алфавитном порядке. Два поля на каждой строке
должны отделиться реальной МЕТКОЙ ТАБУЛЯЦИИ.
      Большинство систем не будет нуждаться в любых входах pathtable.

      #=============== /usr/local/lib/mail/pathtable ================
      #
      # this is a pathalias-style paths file to let you kick mail to
      # UUCP neighbors to the direct UUCP path so you don't have to
      # go the long way through your smart host that takes other traffic
      #
      # you want real tabs on each line or m4 might complain
      #
      # route mail through one or more intermediate sites to a remote
      # system using UUCP-style addressing.
      #
      sesame!ernie!%s        ernie
      #


      # forwarding to a system that is a UUCP neighbor of a reachable
      # internet site.
      #
      swim!%[email protected]    swim
      #
      # The following sends all mail for two networks through different
      # gateways (see the leading '.' ?).
      # In this example, "uugate" and "byte" are specific systems that serve
      # as mail gateways to the .UUCP and .BITNET pseudo-domains respectively
      #
      %[email protected]           .UUCP
      byte!%[email protected]          .BITNET
      #
      #=================== end of pathtable =======================

      16.4.4  domaintable

      Domaintable вообще используется, чтобы вынудить некоторое поведение
после того, как поиск DNS произошел. Это разрешает администратору делать
короткие имена доступными для обычно вызываемых систем или областей,
заменяя такое имя на соответствующее автоматически. Это может также
использоваться, чтобы заменить неправильный host или имена области на "
правильные ".
      Большинство абонентов не будет нуждаться в любых входах domaintable.
Следующий пример показывает, как заменить неправильные адреса на
правильный адрес:

      #============= /usr/local/lib/mail/domaintable =================
      #
      #
      brokenhost.correct.domain         brokenhost.wrong.domain
      #
      #
      #=================== end of domaintable ========================

      16.4.5  aliases

      Aliases(специальные возможности) разрешают ряд вещей:



+ Они обеспечивают короткое имя или общеизвестное имя для почты, которая
будет адресована к одному или большому количеству людей.

+ Они вызывают программу с сообщением почты как ввод для программы.

+ Они посылают почту в файл.

      Все системы требуют aliases для Постмастера.
      Всегда чрезвычайно важна защита при определении aliases, которые
вызывают программы или запись к программам, так как sendmail вообще
выполняет setuid-root.
      Изменения в файле aliases, не воздействуют до команды

      # /usr/lib/sendmail -bi

выполняемой, чтобы формировать требуемые dbm таблицы. Это может также
быть выполнено,  выполняя команду newaliases, обычно из cron.

      #--------------------- /usr/local/lib/mail/aliases ------------------
      #
      # demonstrate commonly seen types of aliases
      #
      usenet:           janet           # alias for a person
      admin:            joe,janet       # alias for several people
      newspak-users:  :include:/usr/lib/lists/newspak
      # read recipients from a file changefeed: | /usr/local/lib/gup
      # alias that invokes a program
      complaints:       /var/log/complaints
      # alias that writes mail to a file
      #
      # The following two aliases must be present to be RFC-compliant.
      # It is important to have them resolve to 'a person'
      # who reads mail routinely.
      #
      postmaster:       root            # required entry
      MAILER-DAEMON:  postmaster        # required entry
      #


      #-------------------------------------------------------------------

      16.4.6 Редко Используемые Таблицы

      Следующие таблицы доступны, но довольно нечасто используются.
Консультируйтесь с документацией, которая приходит с sendmail + IDA для
подробностей.

Uucprelays    Файл uucprelays используется для определения " короткого " пути
UUCP к особенно хорошо известному абоненту, а не используя путь через ряд
host или ненадежный путь, сгенерированный,  обрабатывая карты UUCP с
pathalias.

Genericfrom и xaliases    Файл genericfrom скрывает локальные usernames и адреса
от внешнего мира,  автоматически преобразуя(конвертируя) локальные
usernames в обобщенные адреса отправителя, которые не соответствуют
внутреннему usernames.
      Связанная утилита xalparse автоматизирует порождение файла genericfrom и
файла aliases так, чтобы и входящие и исходящие username трансляции
произошли из главного файла xaliases.

Decnetxtable перезаписывает адреса с определенным именем области в адреса
decnet-стиля, очень похоже на domaintable, может использоваться, чтобы
перезаписать адреса с не определенным именем области в адреса с
определенным именем области smtp-стиля.

      16.5 Установка sendmail

      В этом разделе, мы рассмотрим как установить типичное двоичное
распределение sendmail + IDA, и что должно быть выполнено, чтобы сделать
его локализованным и функциональным.
      Текущее двоичное распределение sendmail + IDA для Linux может быть
получено из sunsite.unc.edu в /pub/Linux/system/Mail. Даже если Вы имеете более
раннюю версию sendmail, я строго рекомендую, чтобы Вы использовали
sendmail5.67b + IDA1.5.
      Если Вы формируете sendmail из исходников, Вы должны следовать
советам  в README, включенном в исходное распределение. Текущие
исходники sendmail + IDA доступны из vixen.cso.uiuc.edu. Чтобы формировать


sendmail + IDA на Linux, Вы также нуждаетесь в Linux -специфических файлах
конфигурации из newspak-2.2.tar.gz, который является доступным на sun-
site.unc.edu в каталоге /pub/Linux/system/Mail.
      Если Вы предварительно установили smail или другое средство получения
почты, вам возможно нужно удалить (или переименовать) все файлы из smail
для безопасности.

      16.5.1 Извлечение двоичного распределения

      Сначала, Вы должны разпаковать файл архива в некотором безопасном
расположении:

$ gunzip -c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf -

      Если Вы имеете "современный" tar, например из недавнего Slackware, Вы
можете  сделать tar -zxvf filename.tgz и получить те же самые результаты.
      Распаковка архива создает каталог, именованный sendmail5.65b +IDA1.5+
mailx5.3b. В этом каталоге, Вы находите комплектное оборудование sendmail +
IDA плюс mailx. Весь paths файл ниже этого каталога отражает расположение,
где файлы должны быть установлены, так что безопасно подготовить команду
tar:

      # cd sendmail5.65b+IDA1.5+mailx5.3b
      # tar cf - . | (cd /; tar xvvpoof -)

      16.5.2 Формирование sendmail.cf

      Чтобы сформировать файл sendmail.cf, настроенный для вашего пункта, Вы
должны сщздать файл sendmail.m4, и обработать его с m4. В /usr/local/lib/mail/CF,
Вы найдете типовой файл называемый sample.m4. Копируйте его в
yourhostname.m4, и редактируйте, чтобы отразить ситуацию вашего пункта.
      В текущем разделе, я буду давать короткий краткий обзор макркоманд,
которые Вы должны изменить. Для полного описания того, что они делают,
пожалуйста, обратитесь к более раннему обсуждению sendmail.m4.

LOCAL MAILER DEF Определяет файл, который определяет mailer для
локального получения почты. См. раздел " Определение Локального Mailer'а "
выше.



PSEUDONYMS Определяет все имена, вашего локального host.

DEFAULT HOST Помещается в ваше полностью квалифицированное имя
области. Это имя появится как ваш hostname во всей выходящей почте.

UUCPNAME Помещается в ваше неквалифицированное hostnmae.

RELAY HOST и RELAY MAILER Если Вы говорите UUCP smart-host
установить RELAY HOST для UUCP имени вашего " интеллектуально
зависимого " uucp соседа. Используйте UUCP-A mailer, если Вы хотите
заголовки с определенным именем области.

DEFAULT MAILER Если Вы находитесь в Internet и используете DNS, Вы
должны установить его как TCP-A. Это сообщает, чтобы sendmail использовал
TCP-A mailer, который передает почту через SMTP используя нормальную RFC
адресацию для конверта. Абонент Internet возможно не должен определять
RELAY HOST or RELAY MAILER.

      Чтобы создать файл sendmail.cf, выполните команду

      # make yourhostname.cf

      Она обработает файл yourhostname.m4 и создаст yourhostname.cf из него.
      Затем, Вы должны проверить, делает ли файл конфигурации, который вы
создали,  то, что Вы ожидаете. Это объясняется в следующих двух разделах.
      Если вы удовлетворены его поведением, скопируйте его на место
командой:

      # cp yourhostname.cf /etc/sendmail.cf

      Теперь ваша система sendmail готова к действиям. Поместите следующую
строку в соответствующем файле запуска (вообще /etc/rc.inet2). Вы можете
также выполнить ее вручную, чтобы запустить его теперь.

      # /usr/lib/sendmail -bd -q1h

      16.5.3 Тестирование файла sendmail.cf



      Чтобы включить " проверочный " режим, Вы вызываете sendmail с -bt
флагом. Заданный по умолчанию файл конфигурации - файл sendmail.cf,
который установлен на системе. Вы можете проверять альтернативный файл,
используя -Cfilename опцию.
      В следующих примерах, мы проверяем vstout.cf файл конфигурации,
сгенерированный из файла vstout.m4.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      >

      Следующие тесты гарантируют, что sendmail способен получать всю почту
пользователей вашей системы. Во всех случаях результат теста должен быть
тот же самый и указывать на локальное имя системы с ЛОКАЛЬНЫМ
mailer'ом.
      Сначала проверите, как почта была бы передана локальному пользователю.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 me
      rewrite: ruleset  3       input: me
      rewrite: ruleset  7       input: me
      rewrite: ruleset  9       input: me
      rewrite: ruleset  9       returns: < me >
      rewrite: ruleset  7          returns: < > , me
      rewrite: ruleset  3          returns: < > , me
      rewrite: ruleset  0       input: < > , me
      rewrite: ruleset  8       input: < > , me
      rewrite: ruleset 20       input: < > , me
      rewrite: ruleset 20       returns: < > , @ vstout . vbrew . com , me
      rewrite: ruleset  8       returns: < > , @ vstout . vbrew . com , me
      rewrite: ruleset 26       input: < > , @ vstout . vbrew . com , me
      rewrite: ruleset 26       returns: $# LOCAL $@ vstout . vbrew . com $: me


      rewrite: ruleset  0       returns: $# LOCAL $@ vstout . vbrew . com $: me

      Вывод показывает как sendmail обрабатывает адрес внутренне. Он
вручается различным ruleset, которые анализируют его, вызывают другой
ruleset по очереди, и разбивают его в компоненты.
      В нашем примере, мы передали мой адрес к ruleset 3 и 0 (это - значение из
3,0 введенное перед адресом). Последняя строка показывает анализируемый
адрес возвращаемый ruleset 0.
      Затем, проверите почту пользователя вашей системы с синтаксисом UUCP.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 vstout!me
      rewrite: ruleset  3 input: vstout ! me
      [...]
      rewrite: ruleset  0 returns: $# LOCAL $@ vstout . vbrew . com  $: me >

      Затем, проверите почту, адресованную пользователю вашей системы с
синтаксисом Internet к вашему полностью квалифицированному hostname.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 [email protected]
      rewrite: ruleset  3 input: me @ vstout . vbrew . com
      [...]
      rewrite: ruleset  0 returns: $# LOCAL $@ vstout . vbrew . com $: me >

      Вы должны повторить вышеупомянутые два теста с каждым из имен,
которые Вы определили в PSEUDONYMS и параметрах DEFAULT NAME в
вашем файле sendmail.m4.
      Наконец, проверите что Вы можете отправлять почту вашему relay host.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE


      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 [email protected]
      rewrite: ruleset  3       input: fred @ moria . com
      rewrite: ruleset  7       input: fred @ moria . com
      rewrite: ruleset  9       input: fred @ moria . com
      rewrite: ruleset  9       returns: < fred > @ moria . com
      rewrite: ruleset  7       returns: < @ moria . com > , fred
      rewrite: ruleset  3       returns: < @ moria . com > , fred
      rewrite: ruleset  0       input: < @ moria . com > , fred
      rewrite: ruleset  8       input: < @ moria . com > , fred
      rewrite: ruleset  8       returns: < @ moria . com > , fred
      rewrite: ruleset 29       input: < @ moria . com > , fred
      rewrite: ruleset 29       returns: < @ moria . com > , fred
      rewrite: ruleset 26       input: < @ moria . com > , fred
      rewrite: ruleset 25       input: < @ moria . com > , fred
      rewrite: ruleset 25       returns: < @ moria . com > , fred
      rewrite: ruleset  4       input: < @ moria . com > , fred
      rewrite: ruleset  4       returns: fred @ moria . com
      rewrite: ruleset 26       retu rns  < @ moria . com > , fred
      rewrite: ruleset  0       returns: $# UUCP-A $@ moria $: < @ moria
                                                          . com > , fred >

       16.5.4 Помещение всего вместе -
              Интеграционная проверка sendmail.cf и таблиц

      Вы проверили что почта будет иметь желательное заданное по умолчанию
поведение и что вы будете способны и послать и получить законно
адресованную почту. Чтобы завершить установку, может быть необходимо
создать соответствующие dbm таблицы, чтобы получить желательные
конечные результаты.
      После создания таблиц, которые требуются для вашего пункта, Вы должны,
обработать их через dbm созданием make в каталоге, содержащем таблицы.
      Если Вы являетесь только UUCP узлом, Вы не должны создвать таблицы,
упомянутые в README.linux файле. Вы будете должны только подправить
файлы так, чтобы Make-файл работал.
      Если вы в UUCP и Вы разговариваете с абонентами в дополнение к
вашему smart-host, вы будете должны добавить входы uucpxtable для каждого


(или почта к ним также пройдет через smart host) и выполнить dbm для
пересмотренного uucpxtable.
      Сначала, Вы должны удостовериться что почта через ваш RELAY HOST,
посылается им через RELAY MAILER.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 [email protected]
      rewrite: ruleset  3       input: fred @ sesame . com
      rewrite: ruleset  7       input: fred @ sesame . com
      rewrite: ruleset  9       input: fred @ sesame . com
      rewrite: ruleset  9       returns: < fred > @ sesame . com
      rewrite: ruleset  7       returns: < @ sesame . com > , fred
      rewrite: ruleset  3       returns: < @ sesame . com > , fred
      rewrite: ruleset  0       input: < @ sesame . com > , fred
      rewrite: ruleset  8       input: < @ sesame . com > , fred
      rewrite: ruleset  8       returns: < @ sesame . com > , fred
      rewrite: ruleset 29       input: < @ sesame . com > , fred
      rewrite: ruleset 29       returns: < @ sesame . com > , fred
      rewrite: ruleset 26       input: < @ sesame . com > , fred
      rewrite: ruleset 25       input: < @ sesame . com > , fred
      rewrite: ruleset 25       returns: < @ sesame . com > , fred
      rewrite: ruleset  4       input: < @ sesame . com > , fred
      rewrite: ruleset  4       returns: fred @ sesame . com
      rewrite: ruleset 26       returns: < @ sesame . com > , fred
      rewrite: ruleset  0       returns: $# UUCP-A $@ moria $: < @ sesame
                                                           . com > , fred >

Если Вы имеете UUCP соседей кроме вашего RELAY HOST, Вы должны
гарантировать, что почта к ним имеет соответствующее поведение. Почта,
адресованная с синтаксисом стиля UUCP для host, с которым Вы говорите по
UUCP,  должна идти непосредственно к ним (если Вы явно не предотвращаете
это входом domaintable). Примите, что swim host - прямой сосед UUCP ваших
соседей. И при подаче swim!Fred sendmail должен произвести следующий
результат:



      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 swim!fred
      rewrite: ruleset  3       input: swim ! fred
      [...lines omitted...]
      rewrite: ruleset  0       returns: $# UUCP $@ swim $: < > , fred
      >

      Если Вы имеете входы uucpxtable, чтобы вынудить получение по UUCP для
некоторых UUCP соседей, которые посылают почту стиля Internet с
определенным именем области, это также должно быть проверено.

      # /usr/lib/sendmail -bt -Cvstout.cf
      ADDRESS TEST MODE
      Enter <ruleset> <address>
      [Note: No initial ruleset 3 call]
      > 3,0 [email protected]
      rewrite: ruleset  3 input: dude @ swim . 2birds . com
      [...lines omitted...]
      rewrite: ruleset  0 returns: $# UUCP $@ swim . 2birds $: < > , dude >

      16.6 Администрирование и Глупые Приемы Почты

      Теперь, когда мы обсудили теорию конфигурирования, установки, и
тестирования sendmail + IDA, давайте рассмотрим несколько моментов, чтобы
изучить вещи, которые случаются обычно в жизни администратора почты.
      Отдаленные системы иногда ломаются. Ошибка модема или сбой
телефонных линий, определения DNS установлены неправильно из-за
человеческой ошибки. Сети падают неожиданно. В таких случаях,
администраторы почты должны знать, как реагировать быстро, действенно, и
безопасно схранить почту, текущую через альтернативные маршруты, пока
отдаленные системы или поставщики услуг не могут восстановить
нормальные услуги.
      Остальная часть этой главы предназначена, чтобы обеспечить Вас
решениями для наиболее частыми " критическми состояниями электронной
почты ".



      16.6.1 Пересылка Почты В Отдаленную Систему

      Чтобы отправлять почту для специфического host или области в
обозначенную отдаленную систему, Вы вообще используете mailertable.
      Например, чтобы отправить почту для backwood.org к их закулисной
системе GATEWAY UUCP, вы поместили следующий вход в mailertable:

      UUCP-A,backdoor   backwood.org

      16.6.2 Почта Для Неконфигурированного Отдаленного Абонена

      Часто, главные ЭВМ Internet будут иметь проблему при получении почты в
не-конфигурированном отдаленном абоненте. Имеются отдельные варианты
этой проблемы, но общий признак - почта передается отдаленной системой
или никогда добирается туда вообще.
      Эти проблемы могут помещать локального администратора системы в
плохую позицию, потому что ваши пользователи вообще не заботятся о том
что Вы лично не управляете каждой системой во всем мире (или не знаете, как
получить отдаленного администратора, чтобы установить проблему). Они
только знают, что их почта не проходила желательному получателю на другом
конце и что вы являетесь вероятным виновным человеком.
      Конфигурация отдаленного пункта - их проблема, не ваша. Во всех случаях,
убедитесь, что ваш пункт способен связаться с не-конфигурированным
отдаленным пунктом. Если Вы не можете войти в контакт с Постмастером в
отдаленном пункте,  чтобы установить их конфигурацию своевременным
способом, Вы имеет две опции.

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

      braindead.correct.domain.com        braindead.wrong.domain.com



      Знак ! в mailertable передает почту их отдаленному пункту, как будто она
инициировалось локально на их системе. Обратите внимание, что это
изменяет только адрес конверта, так что соответствующий адрес возврата
будет все еще обнаруживаться в сообщении.

      TCP!braindead.correct.domain.com    braindead.wrong.domain.com

      16.6.3 Почта, которая будет перемещена через UUCP

      В идеальном мире (из перспективы Internet), все главные ЭВМ будут иметь
записи в Domain Name Service (DNS) и посылать почту с полностью
квалифицированными именами области.
      Если Вы, случается,  передаете через UUCP такому пункту, Вы можете
вынуждать почту пройти двухточечное соединение UUCP, а не через ваш
заданный по умолчанию mailer по существу " опуская область " их hostname
через uucpxtable.
      Чтобы вынуждать получение через UUCP для sesame.com, Вы поместили
бы следующее в ваш uucpxtable:

      # un-domainize sesame.com to force UUCP delivery
      sesame    sesame.com

      Результат - тот sendmail,  то определит (через UUCPNODES в файле
sendmail.m4) что Вы непосредственно соединены с отдаленной системой, и
будет ставить в очередь почту для получения через UUCP.

      16.6.4 Предотвращение Передачи Почты через UUCP

      Противоположное условие также происходит. Часто системы могут иметь
ряд прямых соединений UUCP, которые редко используются или они не так
надежны и всегда доступны как заданный по умолчанию mailer или relay host.
      Например, в Seattle области имеется ряд систем, которые обменивают
различные распределения Linux через анонимный UUCP, когда эти
распределения выпускаются. Эти системы говорят по UUCP только когда
необходимо, так что вообще быстрее и более надежно послать почту через
общие (и всегда доступные) главные ЭВМ.
      Легко можно предотвратить получение UUCP почты от host, с которым Вы
непосредственно соединены. Если отдаленная система имеет полностью


квалифицированное имя области, Вы может добавить вход в domaintable:

      # prevent mail delivery via UUCP to a neighbor
      snorkel.com       snorkel

      Это заменит любое вхождение имени UUCP на FQDN, и таким образом
предотвратит соответствие строкой UUCPNODES в файле sendmail.m4.
Результат - почта будет идти через RELAY MAILER и RELAY HOST (или
DEFAULT MAILER).

      16.6.5 Выполнение Очереди Sendmail по требованию

      Для обработки поставленных в очередь сообщений немедленно, просто
набейте "/usr/lib/runq ". Это заставляет sendmail выполнить очередь заданий,
немедленно а не ждать следующего планируемого.

      16.6.6 Статистика Почты

      Многие администраторы пунктов (и персонал) заинтересованы объемом
почты, передающейся к, из, и через локальный пункт. Имеется ряд способов
определить количество траффика почты.
+ Sendmail приходит с утилитой, называемой mailstats, которая читает файл
называемый /usr/local/lib/mail/sendmail.st и сообщает число сообщений и число
байтов, перемещенных каждым из mailer'ов используемых в файле sendmail.cf.
Этот файл должен быть создан локальным администратором вручную для
регистрации sendmail. Текущие показатели будут очищены, удаляя и вновь
создавая sendmail.st файл. Один способ состоит в том, чтобы делать следующее:

      # cp /dev/null /usr/lib/local/mail/sendmail.st

+ Возможно самый лучший способ делать качественный отчет относительно
того, кто использует почту и сколько объема проходит к, из, и через локальную
систему, состоит в том, чтобы включить отладку почты как syslogd (8). Вообще,
это означает выполнение /etc/syslogd daemon из вашего файла запуска системы
(который Вы должны создать во всяком случае), и добавление строки к
/etc/syslog.conf (5) который который выглядит примерно:

      mail.debug                         /var/log/syslog.mail



      Если Вы используете mail.debug и отправляете по почте большие объемв,
вывод syslog может стать большим. Выходные файлы из syslogd вообще
должны сдвигаться или очищаться на стандартном базисе из crond (8).
      Имеется ряд обычно доступных утилит, которые могут подводить итог
вывода регистрации почты из syslogd. Одна из наиболее известных утилит -
syslog-stat.pl, команда perl, которая распределена с sendmail + IDA.

      16.7 Смешивание и Соответствие Двоичных Распределений

      Не имеется никакой истинной стандартной конфигурации транспорта
электронной почты и средств получения и не имеется никакой " истинной
структуры каталога. "
      Соответственно, необходимо гарантировать, что все различные части
системы (USENET новости, почта, TCP/IP) договариваются о расположении
локальной программы получения почты (lmail, deliver, и т.д.), отдаленной
программы получения почты (rmail), и программы транспорта почты (sendmail
или smail). Такие предположения вообще не зарегистрированы, хотя
использование команды может помогать определять то, какие файлы и
каталоги ожидаются. Следующее - некоторые проблемы, которые мы видели в
прошлом с некоторыми доступными двоичными распределениями и
исходниками.

+ Некоторые версии распределения NET-2 TCP/IP имеют услуги,
определенные для программы, называемой umail а не sendmail.

+ Имеются различные порты elm и mailx, которые ищут средство получения
/usr/bin/smail а не sendmail.

+ Sendmail + IDA имеет встроенный локальный mailer для deliver, но ожидает,
что он расположен в /bin, а не в более типичном расположении Linux /usr/bin.

      16.8 Где Получить Подробную информацию

      Имеется много мест, где Вы можете искать подробную информацию
относительно sendmail. См. Linux MAIL Howto зарегистрированный регулярно
как comp.answers. Это также доступно для анонимного FTP на rtfm.mit.edu.
Однако, окончательное место находится в sendmail + IDA. Смотрите в каталоге


ida/cf ниже исходного каталога файлы DBM-GUIDE, OPTIONS, и Sendmail.mc.

      17. Netnews

      17.1 Usenet Хронология

      Идея относительно сетевых новостей была рождена в 1979 когда два
студента Tom Truscott и Jim Ellis подумали об использовании UUCP чтобы
соединять машины с целью информационного обмена среди пользователей
Unix. Они установили малую сеть из трех машин на Севере Каролины.
      Первоначально, траффик был обработан рядом команд оболочки (позже
перезаписан в C), но они никогда не были выпущены к общему. Они были
быстро заменены на "А" новости, первый общий выпуск программного
обеспечения новостей.
      "А" новости не был разработаны, чтобы обработать больше чем несколько
статей на группу в день. Когда объем продолжил расти, это было
перезаписано Мark Horton и Matt Glickman, и названо "B" выпуск (a.k.a. Bnews).
Первый общий выпуск Bnews был -  версия 2.1 в 1982. Он расширялся
непрерывно, с отдельными новыми добавляемыми возможностями. Текущая
версия - Bnews 2.11. Она медленно устаревает.
      Другая перезапись была выполнена и выпускалась в 1987 Geoff Collyer и
Henry Spencer; это - выпуск " "C", или Новости C.
      Выпуск Эффективности - Новости C, версия в настоящее время
включенная в большинство реализаций Linux.
      Все выпуски новостей до " " C " " является прежде всего целенаправленным
для сетей UUCP, хотя они могут использоваться в других средах также.
Эффективная передача новостей над сетями подобно TCP/IP, DECNet требует
новой схемы. Это было причиной почему, в 1986 появился " Сетевой
Протокол передачи Новостей '', NNTP. Он основан на сетевых соединениях, и
определяет ряд команд, чтобы в интерактивном режиме передать и отыскать
статьи.
      Имеется ряд nntp-основанных приложений, доступных из Сети. Один из
них - nntpd пакет Brian Barber и Phil Lapsley,
      Другие NNTP пакеты - INN, или Новости Internet. Это не просто передная
часть, но система новостей с собственными правилами.

      17.2 Что является Usenet, Во всяком случае?



      Одно из наиболее поразительных предложений относительно Usenet - то,
что это не часть любой организации, и не имеет централизованной сетевой
власти для управления. Фактически, это - все Usenet сведения, кроме
технического описания. Вы не можете определять, что это, Вы можете только
сказать чем это не является.
      С риском звучать глупо, можно было определить Usenet как
сотрудничество отдельных абонентов, которые обмениваются Usenet
новостями.
      Базисный модуль Usenet новостей - статья. У статьи есть так называемый
заголовок. Это очень похоже на формат заголовка почты, установленный в
Internet, стандарт RFC 822, в котором это состоит из отдельных строк текста,
каждое начинается с имени поля, завершенного двоеточием, которое
сопровождается значением поля. (1)
      Статьи представлены на рассмотрение в одну или большое количество
newsgroups. Можно рассматривать newsgroup форумом для статей в отношении
общего предмета. Все newsgroups организованы в иерархии, с именем каждой
группы, указывающим место в иерархии. Например, любой может видеть из
имени newsgroup, что comp.os.linux.announce используется для объявлений
относительно операционной системы Linux.

      17.3 Как в Usenet Обрабатывают Новости?

      Сегодня, Usenet вырос до огромных размеров. Узлы, которые несут все
netnews обычно передают что - нибудь вроде несерьезных шестидесяти
мегабайтов в день. (2) Конечно это требует намного больше чем обмен
файлами. Так что давайте рассмотрим способ, которым большинство системах
Unix обрабатывает Usenet новости.
      Новости распределены через сеть различными transports. Как историческая
среда используется UUCP, но сегодня основной траффик несет абонент Internet.
Используемый алгоритм маршрутизации называется лавинной
маршрутизацией: Каждый пункт поддерживает ряд связей к другому абоненту.
Любая статья, сгенерированная или полученная локальной системой новостей
будет послана к ним.
      Чтобы отличать статьи и распознавать дубликаты, Usenet статьи должны
нести ID сообщения (заданный в поле заголовка Message-ID:), которое
объединяет имя пункта регистрации и серийный номер в " <serial@site> ''. Для
каждой обработанной статьи, система новостей регистрирует ее ID в файл
хронологии, в котором проверяются все прибывающие статьи.


      Явное число статей обычно требует, чтобы к вышеупомянутой схеме были
сделаны уточнения. На сетях UUCP, обычто статьи за период времени
объединяются в одиночный файл, который сжимается и посылается к
отдаленному пункту. Это вызывается, пакетирование.
      Абонент, которые находятся в Internet вообще полагается на TCP/IP
программное обеспечение, которое использует Сетевой Протокол передачи
Новостей, NNTP. Он передает новости между узлами и обеспечивает Usenet
доступ к отдельным пользователям.

      18. "C" Новости

      Один из наиболее популярных пакетов программ для Netnews - Новости C.
Это было разработано для абонентов, которые несут новости по связям UUCP.
Эта глава обсудит центральные понятия Новостей C, и базисной установки и
задач сопровождения.
      Новости C (C News) сохраняют файлы конфигурации в /usr/lib/news, а
большинство binaries в каталоге /usr/lib/news/bin. Статьи сохраняются ниже
/var/spool/news. Вы должны удостовериться виртуально что все файлы в этих
каталогах принадлежат новостям пользователя, групповым новостям.
Большинство проблем является результатом файлов, являющихся недоступным
для Новостей C. Сделайте это правилом для Вас, определить новостями
пользователя, используя su прежде, чем Вы что - нибудь там измените.
Единственые исключения - setnewsids, которые используются, чтобы
установить реальный id пользователя некоторых программ новостей. Это
должно принадлежать root и должно иметь setuid набор битов.
      Далее мы описываем все файлы конфигурации C News подробно, и
показываем Вам, что Вы должны делать, чтобы сохранить ваш пункт в
рабочем состоянии.

      18.1 Поставка Новостей

      Статьи могут быть поданы C News отдельными способами. Когда
локальный пользователь отправляет по почте статью, newsreader обычно
вручает ее команде inews, которая завершает информацию заголовка. Новости
из отдаленного абонента, будь это одиночная статья или целый пакет, даны
команде rnews, которая сохраняет их в каталоге /var/spool/newsin.coming, откуда
они будут подняты в более позднее время newsrun. С любым из этих двух
методов, однако, статья будет в конечном счете вручена команде relaynews.


      Для каждой статьи, команда relaynews проверяет, если статья уже была
замечена в локальном пункте, ища id сообщения в файле хронологии. Двойные
статьи будут пропущены. Затем, relaynews рассматривает Newsgroups: строку
заголовка, чтобы выяснить, запрашивает ли локальный пункт статьи из любой
из этих групп. Если он это делает, и группа новостей перечислена в открытом
файле, relaynews пробует сохранять статью в соответствующем каталоге в
области хранения новостей. Если этот каталог не существует, он будет создан.
Id сообщения статьи будет регистрироваться в файле хронологии. Иначе,
relaynews пропускает статью.
      Если relaynews будет не в состоянии сохранять входящую статью, потому
что группа, в которой она была зарегистрирована, не перечислена в вашем
открытом файле, статья будет перемещаться в группу junk. relaynews также
проверит несвежие или статьи без дат и отклонит их. Входящие пакеты,
которые терпят неудачу по любой другой причине,  перемещаются в
/var/spool/news/in.coming/bad, и сообщение об ошибках регистрируется.

      18.2 Установка

      Чтобы установить C News необходимо раз'tar'ить файлы в их
соответствующие места, если Вы еше не сделали этго, и отредактировать
файлы конфигурации, перечисленные ниже. Они все расположены в
/usr/lib/news. Их форматы будут описаны в следующих разделах.
      Если Вы являетесь передающим пунктом (пунктом листа), Вы нуждаетесь в
строке, которая посылает все локально сгенерированные статьи к
ожидающему. Пусть ожидающий - moria, тогда ваш системный файл должен
выглядеть следующим образом:

        ME:all/all::
        moria/moria.orcnet.org:all/all,!local:f:

organization Имя Вашей организации. Например, "Виртуальный Пивоваренный
завод". На вашей местной машине, введите " частный пункт '', или что -
нибудь, еще, что Вы находите приятным. Большинство людей не будет
называть ваш пункт правильно отконфигурированным, если Вы не настроили
этот файл.

newsgroups ...



mailname Имя почты Вашего пункта, например vbrew.com.
whoami Имя Вашего пункта для целей новостей. Часто используется имя пункта
UUCP, например vbrew.

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

      Чтобы создавать начальную иерархию newsgroups, получите active и
newsgroups файл из пункта, который передает Вам, и установите их в
/usr/lib/news. Удалите все to.* группы из active файла, и добавте to.mysite и
to.feedsite, также как junk и control. To.* группы обычно используются для
обмена ihave/sendme сообщениями, но Вы должны создать их независимо от
того, планируете ли Вы использовать ihave/sendme или нет. Затем, замените все
числа статьи во втором и третьем поле active, используя следующую команду:

      # cp active active.old
      # sed 's/ [0-9]* [0-9]* / 0000000000 00001 /' active.old > active
      # rm active.old

      Вторая команда - вызов sed (1), одна из моих любимых команд Unix. Этот
вызов заменяет две строки цифр на строку нулей и строку 000001,
соответственно.
      В заключение, создайте каталог для хранения новостей и подкаталоги,
используемые для входящих и исходящих новостей:

      # cd /var/spool
      # mkdir news news/in.coming news/out.going
      # chown -R news.news news
      # chmod -R 755 news

      Если вы используете более поздний выпуск C News, Вы можете быть
должны создать каталог out.master в каталоге хранения новостей.
      Если вы используете newsreaders из другого распределения чем C News, Вы
можете находить, что некоторые ожидают хранилище новостей в
/usr/spool/news а не в /var/spool/news. Если ваш newsreader кажется,  не находит
статьи, создайте сноску из /usr/spool/news в /var/spool/news.
      Теперь, Вы готовы получать новости. Обратите внимание, что Вы не


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

      18.3 Системный файл

      Системный файл sys расположенный в /usr/lib/news, управляет иерархией
получения и передачи к другому абоненту. Хотя имеются инструментальные
средства сопровождения, именованные addfeed и delfeed, я думаю, что лучше
поддерживать этот файл вручную.
      Файл sys содержит входы для каждого пункта на который Вы передаете
новоси, также как описание групп, которые Вы примете. Вход выглядит
подобно

      site[/exclusions]:grouplist[/distlist][:flags[:cmds]]

      Входы могут быть продолжены поперек символов перевода строки,
используя наклонную черту влево (\). Знак мусора (*) обозначает комментарий.
      site является именем пункта к которому вход применяется. Каждый обычно
выбирает имя UUCP пункта для этого. Должен иметься вход для вашего пункта
в файле sys, или  Вы не будете получать никакие статьи самостоятельно.
      Специальное имя пункта ME обозначает ваш пункт.
      Так как C News проверяет пункт против имен пункта в Path: поле заголовка,
Вы должны удостовериться, что они действительно соответствуют. Некоторые
абонентв используют их полностью квалифицированное имя области в этом
поле, или специальное подобно news.site.domain. Чтобы предотвращать возврат
любых статей к этому абоненту Вы должны добавить их к списку исключения,
отделяя их запятыми.
      Для входа, обращающегося к пункту moria, например, поле пункта
содержало бы moria/moria.orcnet.org.
      Grouplist - отделенный запятой список групп и иерархий для этого
специфического пункта. Иерархия может быть определена,  давая префикс
иерархии (типа comp.os для всех групп, чьи имена начинаются с этого


префикса), необязательно сопровождаемый ключевым словом all (например
comp.os.all).
      Иерархия или группа исключается из пересылки, приписыванием метки
восклицания. Если newsgroup проверен против списка, самое длинное
соответствие, применяется. Например, если grouplist содержит

      !comp,comp.os.linux,comp.folklore.computers

      Никакие группы из comp иерархии за исключением comp.folklore.computers
и всех групп ниже comp.os.linux не будут поданы к тому пункту.
      Если пункт запрашивает послать все новости, что Вы получаете для себя,
введите все как grouplist.
Distlist - смещение из grouplist наклонной чертой вправо, и содержит список
распределений, которые будут посланы. Снова, Вы можете исключать
некоторые распределения,  предшествуя им с меткой восклицания. Все
распределения обозначены all. Опущение distlist подразумевает список всех.
      Например, Вы можете использовать дистрибутивный список all,!Local,
чтобы предотвратить посылку новостей для локального использования
отдаленному абоненту.
      Имеются обычно по крайней мере два распределения: world, который
является часто заданным по умолчанию используемым распределением когда
ни одно не определено пользователем, и local. Могут иметься другие
распределения, которые обращаются к некоторой области, штату, стране, и т.д.
В заключение, имеются два распределения, используемые только C News; это -
sendme и ihave, и используются для sendme/ihave протокола.

      Флаги

      Здесь описывются некоторые параметры для feed. Это может быть пусто,
или комбинация следующего:

F Этот флаг дает возможность пакетированию.

f Это почти идентично F флагу, но позволяет C News вычислять размер
исходящих пакетов более точно.

I Этот флаг заставит C News произвести список статей, подходящих для
использования ihave/sendme. Дополнительные изменения sys и batchparms


файлов требуются, чтобы дать возможность ihave/sendme.

n Это создает командные файлы для active NNTP клиентов передачи подобно
nntpxmit (см. главу 19.). Командные файлы содержат имя файла статьи наряду с
id сообщения.

L Это сообщает, чтобы C News передал только статьи, зарегистрированные в
вашем пункте. Этот флаг может сопровождаться десятичным числом n,
которое заставит C News передать статьи, зарегистрированные только внутри
n переходов из вашего пункта. C News определяет число переходов в поле
Path:.

u Это сообщает C News принимать только статьи из групп unmoderated.

m Это сообщает C News принимать только статьи из уменьшенных групп.
Вы можете использовать не больше одного из F, f, I, или n.
cmds Это поле содержит команду, которая будет выполнена для каждой статьи,
если пакетирование не допускается. Статья будет подана команде на
стандартном вводе. Это должно использоваться для очень малых потоков;
иначе загрузка на обеих системах будет слишком высока.
      Заданная по умолчанию команда

        uux - -r -z system!rnews

Вызывает rnews на отдаленную систему, подавая эту статью на стандартном
вводе.
      Заданный по умолчанию путь поиска для команд, данных в этом поле -
/bin:/usr/bin:/usr/lib/news/bin/batch. Последний каталог содержит ряд команд
оболочки, чьи имя начинается с via; они кратко описаны позже в этой главе.
      Если пакетирование допускается, использованием или F или f, или I или n
флагов, C News ожидает находить имя файла в этом поле, а не команду. Если
имя файла не начинается с наклонной черты вправо (/), оно принимается
относительно /var/spool/news/out.going. Если поле пусто, то значения по
умолчанию system/togo.
      При установке C News, Вы будете возможно должны написать ваш
собственный файл sys. Чтобы помочь Вам с этим, мы даем типовой файл для
vbrew.com ниже, с которого Вы могли бы скопировать то, в чем Вы
нуждаетесь.



      # We take whatever they give us.
      ME:all/all::

      # We send everything we receive to moria, except for local and
      # brewery-related articles. We use batching.
      moria/moria.orcnet.org:all,!to,to.moria/all,!local,!brewery:f:

      # We mail comp.risks to [email protected]
      ponderosa:comp.risks/all::rmail [email protected]

      # swim gets a minor feed
      swim/swim.twobirds.com:comp.os.linux,rec.humor.oracle/all,!local:f:

      # Log mail map articles for later processing usenet-
      maps:comp.mail.maps/all:F:/var/spool/uumaps/work/batch

      18.4 Файл active

      Файл active расположенный в /usr/lib/news перечисляет все группы,
известные в вашем пункте, и статьи в настоящее время интерактивные. Вы
редко будете должны изменять его, но мы объясним это ради законченности.
Входы имеют следующую форму:

      newsgroup high low perm

      Newsgroup, конечно, имя группы. Low и high - самые низкие и самые
высокие числа статей, в настоящее время доступных. Если ни одна не является
доступной в настоящее время, low = high + 1.
      Perm - параметр, детализирующий доступ пользователей в зависимости от
группы. Он принимает одно из следующих значений:

y Пользователям разрешают отправить по почте к этой группе.

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

x Эта группа была заблокирована локально. Это случается иногда, когда


администраторы новостей (или их старшие) закрывают статьи,
зарегистрированные в некоторых группах.

      Статьи, полученные для этой группы не сохранены локально, хотя они
посланы к абонентам, которые запрашивают их.
m Это обозначает уменьшенную группу. Когда пользователь пробует
отправлять по почте к этой группе, интеллектуальный newsreader сообщит
какая она, и пошлет статью регулятору взамен. Адрес регулятора принимается
из файла регуляторов в /usr/lib/news.
=real-group Это отмечает newsgroup как локальную специализацию для другой
группы, а именно real-группы. Все статьи, зарегистрированные в newsgroup
будут переназначены в нее.
      В C News, Вы вообще не будете должны обращаться к этому файлу
непосредственно. Группы могут быть добавлены или удаляться, локально
используя addgroup и delgroup (см. ниже в разделе 18.10). Когда группы
добавляются или удаляются для всего Usenet, это обычно делается,  посылая
newgroup или rmgroup сообщение управления, соответственно. Никогда не
посылайте такое сообщение самостоятельно! Для команд о том, как создавать
newsgroup, читайте ежемесячник в news.announce.newusers.
      Файл, близко связанный с active - active.times. Всякий раз, когда группа
создана, C News регистрирует сообщение в этот файл, содержащее имя
созданной группы, дату создания, было ли это выполнено в соответствии c
сообщением управления новой группы или локально, и кто сделал это. Это -
для удобства newsreaders, которые могут сообщать пользователю относительно
любой недавно созданной группы. Это также используется командой
NEWGROUPS NNTP.

      18.5 Пакетирование Статьи

      Newsbatches следуют за специфическим форматом, который является тем
же самым для Bnews, C News, и INN. Каждой статье предшествует строка:

      #! rnews count

Где count - число байтов в статье. Когда используется пакетное сжатие,
возникающий в результате файл сжат в целом, и содержит другую строку в
соответствии c сообщением, которое нужно использовать для распаковки.
Стандартное средство сжатия - упаковщик, который отмечен



      #! cunbatch

      Иногда, при необходимости посылать пакеты через программное
обеспечение почты, которое удаляет,  восьмой бит из всех данных, сжатый
пакет может быть защищен, используя, что называется c7-encoding; эти пакеты
будут отмечены c7unbatch.
      Когда пакет подан к rnews на отдаленном пункте, он проверяет эти
маркеры и обрабатывает пакет соответственно. Некоторые абоненты также
используют другие инструментальные средства сжатия, подобно gzip, и
предшествует таким файлам с zunbatch взамен. C News не распознает
ненормативные заголовки подобно этим; Вы должны изменить исходник,
чтобы поддерживать их.
      В C News, пакетирование статьи выполняется
/usr/lib/news/bin/batch/sendbatches, который берет список статей из site/togo файла,
и помещает их в отдельный newsbatches. Это должно быть выполнено раз в час
или даже более часто, в зависимости от объема траффика.
      Операция управляется batchparms файлом в /usr/lib/news. Этот файл
описывает максимальный пакетный размер, позволенный для каждого пункта,
программу пакетирования и необязательную программу сжатия, которую
нужно использовать, и транспорт для поставки к этому отдаленному пункту.
Вы можете определять параметры пакетирования, также как набор заданных
по умолчанию параметров для абонента, не явно упомянутого.
      Чтобы выполнять пакетирование для специфического пункта, Вы
вызываете это как

      # su news -c "/usr/lib/news/bin/batch/sendbatches site"

      Когда вызывается без аргументов, sendbatches обрабатывает все пакетные
очереди. Интерпретация " все " зависит от присутствия заданного по
умолчанию входа в batchparms. Если он найден, все каталоги в
/var/spool/news/out.going проверяются, иначе, он циклически проходит все
входы в batchparms. Обратите внимание, что sendbatches, при просмотре
каталога out.going, берет только те каталоги, которые не содержат никакую
точку или знак (@) как имена пункта.
      При установке C News, Вы наиболее вероятно найдете batchparms файл в
вашем распределении, который содержит приемлемый заданный по
умолчанию вход, так что имеется хорошая возможность не изменять файл. На


всякий случай, мы описываем формат. Каждая строка состоит из шести полей,
отделяемых пробелами или метками табуляции:

      site size max batcher muncher transport

      Значение этих полей следующие:
      site - имя пункта, к которому применяется вход. Togo файл для этого пункта
должен постоянно находиться в out.going/togo. Имя пункта /default/ обозначает
заданный по умолчанию вход.
      size - максимальный размер созданных пакетов статей (перед сжатием). Для
одиночных статей больших чем этот размер, C News делает исключение и
помещает их в одиночный пакет.
      max - максимальное число пакетов, созданных и планируемых для
передачи перед пакетированием для этого специфического пункта.
      C News определяет число поставленных в очередь пакетов, используя
queulen команду в /usr/lib/news/bin. Выпуск newspak Vince Skahan'а должен
содержать команду для bnu-совместимого UUCP. Если Вы используете
различные виды spool каталогов, например, Taylor UUCP, Вам может быть
необходимо написать ваш собственный.
      Поле batcher содержит команду, используемую для создания пакета из
списка статей в togo файле. Это - обычно batcher. Для других целей можно
обеспечивать альтернативные команды. Например, ihave/sendme протокол
требует, чтобы  список статей был превращен в сообщения управления ihave
или sendme, которые зарегистрированы в newsgroup to.site. Это выполняется
batchih и batchsm.
      muncher поле определяет команду, используемую для сжатия. Обычно, это -
compcun, команда, которая производит сжатый пакет. В качестве
альтернативы, Вы могли бы обеспечивать muncher, который использует gzip,
скажем gzipcun (чтобы быть чистым: Вы должны запись это непосредственно).
Вы должны удостовериться, что распаковщик на отдаленном пункте
исправлен, чтобы распознать файлы, сжатые с gzip.
      Если отдаленный пункт не имеет команды распаковки, Вы можете
определить nocomp, который не делает никакое сжатие.
      Последнее поле, transport, описывает транспорт, который нужно
использовать. Доступно несколько стандартных команд для различных
transports, чьи имена начинаются с via. Sendbatches передает им имя пункта
адресата в командной строке. Если batchparms вход не был /default/, он получает
имя пункта из поля site,  удаляя все последующее, включая первую точку или


наклонную черту вправо. Если вход был /default/, используются имена каталога
в out.going.
      Имеются две команды, которые используют uux, чтобы выполнить rnews на
отдаленной системе; viauux и viauuxz. Последняя устанавливает -z флаг для
(более старые версии) uux, чтобы отменить сообщения успеха для каждой
переданной статьи. Другая команда, viamail, посылает пакеты статей
пользователю rnews на отдаленной системе через почту.
      Все команды из последних трех полей нужно расположть или в
out.going/site или в /usr/lib/news/bin/batch. Большинство их - команды, так, чтобы
Вы могли легко приспосабливать новые инструментальные средства для
ваших персональных потребностей. Они вызываются как трубопровод.
Список статей подается дозатору на стандартном вводе, который производит
пакет на стандартном выводе. Это канально передается в muncher, и так далее.
      Типовой файл дан ниже.

# batchparms file for the brewery
# site        | size   |max    |batcher  |muncher    |transport
#-------------+--------+-------+---------+-----------+-----------
 /default/      100000  22      batcher   compcun     viauux
 swim            10000  10      batcher   nocomp      viauux

      18.6 Устаревшие Новости

      В Bnews, устаревание выполняться программой называемой expire, которая
принимает список newsgroups как аргументы, наряду с спецификацией времени
после которого статьи должны устареть.
      Иногда, Вы можете хотеть сохранять статьи из некоторых групп даже после
того, как они устарели; например, Вы могли бы хотеть сохранить программы,
зарегистрированные в comp.sources.unix. Это называется архивирование. Explist
разрешает Вам отмечать группы для архивирования.
      Вход в explist похож на это:

      grouplist perm times archive

      Grouplist - отделенный запятой список newsgroups, к которым вход
применяется. Иерархии могут быть определены префиксом имени группы,
необязательно конкатенированным ко всем. Например, для входа,
обращающегося к всем группам ниже comp.os, Вы могли бы вводить comp.os


или comp.os.all в grouplist.
      При устаревании новости из группы, имя будет проверено против всех
входов в explist в данном порядке. Первый соответствующий вход
применяется. Например, чтобы отбросить большую часть comp после четырех
дней, кроме comp.os.linux.announce, который Вы хотите хранить в течение
недели, Вы просто должны иметь вход для последнего, который определяет
семи-дневный период окончания, сопровождаемый входом для comp, который
определяет четыре дня.
      Поле perm детализирует, если вход применяется к уменьшенной, или
любой группе. Оно может принимать значения m, u, или x, которые
обозначают уменьшенный, неуменьшенный, или любой тип.
      Третье поле, times, обычно содержит только одиночное число. Это - число
дней после которых статьи будут устаревать, если они не были назначены,
искусственная дата окончания в поле Expires в заголовке статьи. Обратите
внимание, что это - число дней подсчитывается с поступления в ваш пункт, а
не с даты регистрации.
      Поле times может, однако, быть более сложно. Это может быть комбинация
до трех чисел, отделяемых от друг друга черточкой. Первое обозначает число
дней, которые должны пройти прежде, чем статья рассматривается
кандидатом на окончание. Редко полезно использовать значение отличное от
нуля. Второе поле - вышеупомянутое заданное по умолчанию число дней
после, которых оно будет устаревать. Третья часть - число дней после которых
статья будет устаревать безоговорочно, независимо от того, имеет ли она поле
Expires или нет. Если только среднее число дано, другие два берут значения по
умолчанию. Они могут быть определены, используя специальный /bounds/
входа, который описан ниже.
      Четвертое поле, archive, обозначает, должен ли newsgroup быть
заархивирован, и где. Если никакого архивирования не предназначено,
должна использоваться черточка. Иначе, Вы либо используете полное имя
пути (указывающее на каталог), или знак (@). Знак обозначает заданный по
умолчанию каталог архивов, который должен то быть дан doexpire,  используя
-a флаг в командной строке. Каталог архивов должен принадлежать news.
Когда doexpire архивирует статью из, скажем comp.sources.unix, он сохраняет ее
в каталоге comp/sources/unix ниже каталога архивов, создавая его если он не
существует. Каталог архивов непосредственно, однако, не будет создан.
      Имеются два специальных входа в вашем explist файле, на который doexpire
полагается. Вместо списка newsgroups, они имеют ключевые слова /bounds/ и
/expired/. Вход /bounds/ содержит значения по умолчанию для трех значений


поля времен, описанного выше.
      Поле /expired/ определяет, как долго C News будет содержать строки в
файле хронологии. Это необходимо, потому что C News не будет удалять
строку из файла хронологии, если соответствующая статья устарела, но будет
содержать ее в случае, если дубликат должен прибыть после этой даты.
      Простой explist файл с довольно плотными интервалами истечения
воспроизведен ниже:

      # keep history lines for two weeks. Nobody gets more than three months
      /expired/         x       14      -
      /bounds/          x       0-1-90  -
      # groups we want to keep longer than the rest
      comp.os.linux.announce    m       10      -
      comp.os.linux             x       5       -
      alt.folklore.computers    u       10      -
      rec.humor.oracle          m       10      -
      soc.feminism              m       10      -
      # Archive *.sources groups
      comp.sources,alt.sources  x       5       @
      # defaults for tech groups
      comp,sci          x       7       -
      # enough for a long weekend
      misc,talk         x       4       -
      # throw away junk quickly
      junk              x       1       -
      # control messages are of scant interest, too
      control           x       1       -
      # catch-all entry for the rest of it
      all               x       2       -

      С устареванием в C News, имеется ряд потенциальных проблем при
чистке. Например, ваш newsreader мог бы полагаться на третье поле файла
active, который содержит число самой низкой интерактивной статьи. При
истечении статьи, C News не модифицирует это поле. Если Вы хотите чтобы
это поле, представляло реальную ситуацию, Вы должны выполнить
программу, называемую updatemiin после каждого выполнения doexpire.

      18.7 Разнообразные Файлы



      Имеется ряд файлов, которые управляют поведением C News, но не
существенны для функционирования. Все они постоянно находятся в
/usr/lib/news. Мы опишем их кратко.

newsgroups Это - файл дополняющий active, который содержит список имен
newsgroup, наряду с кратким описанием основного предмета. Этот файл
автоматически модифицируется, когда C News получает сообщение
управления checknews (см. раздел 18.8).

localgroups если Вы имеете ряд локальных групп, таких что Вы не хотите,
чтобы C News жаловался относительно них, каждый раз когда Вы получаете
checknews сообщение, поместите их имена и описания в этом файле, точно так
же как они появились бы в newsgroups.

mailpaths Этот файл содержит адрес регулятора для каждой уменьшенной
группы. Каждая строка содержит имя группы, сопровождаемое адресом email
регулятора (отделеные меткой табуляции).
      Два специальных входа обеспечиваются как значение по умолчанию. Они
базовые и межсетевые. Оба обеспечиваются --- в записи bang-path --- путем к
самому близкому базовому пункту, и пункту, который понимает RFC 822
адреса (user@host).
      Вы не будете должны изменять межсетевой вход, если Вы имеете smail или
sendmail, потому что они понимают RFC 822 - адресацию.
      Базовый вход используется всякий раз, когда пользователь отправляет по
почте к уменьшенной группе, чей регулятор не перечислен явно. Если имя
newsgroup -- alt.sewer, и базовый вход содержит path!%s, C News отправит по
почте статью к path!alt-sewer, надеясь, что базовая машина способна передать
статью. Чтобы выяснить который путь использовать, спросите
администрацию новостей в пункте, который передает Вам. Вы можете также
использовать uunet.uu.net!%s.

distributions Этот файл не файл C News, но он используются некоторыми
newsreaders, и nntpd. Он содержит список распределений, распознанных вашим
пунктом, и описанием (встроенных) возможностей. Например, Виртуальный
Пивоваренный завод имеет следующий файл:

                        world           everywhere in the world


                        local           Only local to this site
                        nl                  Netherlands only
                        mugnet         MUGNET only
                        fr                  France only
                        de                  Germany only
                        brewery        Virtual Brewery only

log Этот файл, содержит файл регистрации всех действий C News. Он
вызывается регулярно, выполняя newsdaily; копии старых регистрационных
файлов сохраняются в log.o, log.oo, и т.д.

errlog Это - файл регистрации всех сообщений об ошибках, созданных C News.
Он не включают плохие статьи, и т.д. Этот файл будет отправлен по почте к
newsmaster (usenet по умолчанию) автоматически newsdaily, если он не-пуст.
Errlog очищается newsdaily. Старые копии сохраняются в errlog.o и т. д.

batchlog Он регистрирует все выполнения sendbatches. Он обычно мало
интересен. Он также зависит от newsdaily.

watchtime Это - пустой файл, создаваемый каждый раз при выполнении
newswatch.

      18.8 Сообщения Управления

      Usenet протокол новостей знает специальный класс статей, которые
вызывают некоторые ответы или действия системы новостей. Они
называются сообщениями управления. Они распознаются присутствием поля
Control в заголовке статьи, которое содержит имя операции управления,
которую нужно выполнить. Имеются отдельные типы этих операций, которые
обрабатываются командами оболочки, расположенными в /usr/lib/news/ctl.
      Большинство из них выполнит их действие автоматически во время
обработки статьи C News, без того, чтобы уведомить newsmaster. По
умолчанию, только checkgroups сообщения будут вручены newsmaster, но Вы
можете изменять это,  редактируя команды.

      18.8.1 Сообщение Отмена

      Наиболее широко известное сообщение - отмена, которой пользователь


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

      18.8.2 Newgroup и rmgroup

      Два сообщения имеют дело с созданием или удалением newsgroups - это
newgroup и rmgroup. Newsgroups ниже " обычной " иерархии могут быть
созданы только после того, как обсуждение и утверждение было проведено
среди Usenet читателей. Правила, обращающиеся к alt иерархии учитывают что
кое-что близко к анархии. Для подробной информации см. регулярные
регистрации в news.announce.newusers и news.announce.newgroups. Никогда не
посылайте newgroup или rmgroup сообщение самостоятельно, если Вы
определенно не знаете, что Вам позволено.

      18.8.3 Checkgroups Сообщение

      Checkgroups сообщения посылаются администраторами новостей, чтобы
для всех абонентов внутри сети синхронизировать их файлы active с фактами
Usenet. Например, коммерческие поставщики услуг Internet могли бы выпускать
такое сообщение к абоненту их заказчиков. Один раз в месяц "оффициальное"
checkgroups сообщение для главных иерархий зарегистрировано в
comp.announce.newgroups их регулятором. Однако, оно зарегистрировано, как
обычная статья, а не как управляющее сообщение. Чтобы выполнить
операцию checkgroups, сохраните эту статью в файл, скажем /tmp/check, удалите
все до начала сообщения управления непосредственно, и передайте это к
checkgroups команде, используя следующую команду:

#   su   news  -c  "/usr/lib/news/bin/ctl/checkgroups"  < /tmp/check

      Это модифицирует ваш newsgroups файл, добавляя группы, перечисленные
в localgroups. Старый newsgroups файл будет перемещаться в newsgroups.bac.
Обратите внимание, что регистрация сообщения локально редко будет


работать, потому что inews отказывается принимать это как статью.
      Если C News находит несоответствия между списком checkgroups и файлом
active, это произведет список команд, которые модернизируют ваш пункт, и
сообщат это администратору новостей. Вывод обычно походит на это:

      From news Sun Jan 30 16:18:11 1994
      Date: Sun, 30 Jan 94 16:18 MET
      From: news (News Subsystem)
      To: usenet
      Subject: Problems with your active file

Следующие newsgroups не допустимы и должны быть удалены.

        alt.ascii-art
        bionet.molbio.gene-org
        comp.windows.x.intrisics
        de.answers

Вы можете делать это,  выполняя команды:

/usr/lib/news/bin/maint/delgroup alt.ascii-art
/usr/lib/news/bin/maint/delgroup bionet.molbio.gene-org
/usr/lib/news/bin/maint/delgroup comp.windows.x.intrisics
/usr/lib/news/bin/maint/delgroup de.answers

      Следующие newsgroups отсутствовали.

        comp.binaries.cbm
        comp.databases.rdb
        comp.os.geos
        comp.os.qnx
        comp.unix.user-friendly
        misc.legal.moderated
        news.newsites
        soc.culture.scientists
        talk.politics.crypto
        talk.politics.tibet



      Когда Вы получаете такое сообщение от вашей системы новостей, не
отбрасывайте его вслепую. В зависимости от того, кто послал checkgroups
сообщение, оно может испытывать недостаток нескольких групп или даже
всех иерархий; так что Вы должны быть осторожны относительно удаления
любых групп. Если Вы находите группы,  перечисленные как отсутствующие и
Вы хотите иметь их в вашем пункте, Вы должны добавить их, используя
addgroup команду. Сохраните список отсутствующих групп в файле и
передайте его следующей небольшой команде:

  #!/bin/sh
  cd /usr/lib/news

  while read group; do
      if grep -si "^$group[[:space:]].*moderated" newsgroup; then
           mod=m
      else
           mod=y
      fi
      /usr/lib/news/bin/maint/addgroup $group $mod
  done

      18.8.4 sendsys, version, и senduuname

      В заключение, имеются три сообщения, которые могут использоваться,
чтобы выяснить относительно топологии сети. Это - sendsys, version, и senduu-
имя. Они заставляют C News возвращать отправителю файл sys, версию
программного обеспечения, и вывод uuname (1), соответственно. C News -
очень лаконично относительно сообщения version; оно возвращает просто
неукрашенное "C".
      Снова, Вы никогда не должны выдавать такое сообщение, если Вы не
уверенны, что это не может повредить вашей (региональной) сети. Ответы
sendsys сообщениям могут быстро положить сеть UUCP.

      18.9 C News в NFS Среде

      Простой способ распределять новости внутри локальной сети состоит в
том, чтобы хранить все новости на центральном host, и экспортировать
релевантные каталоги через NFS, так, чтобы newsreader мог просматривать


статьи непосредственно. Преимущество этого метода над NNTP - то, что
непроизводительные затраты, заключаемые в поиске и продевании нитки
статей являются значительно ниже. NNTP, с другой стороны, побеждает в
разнородной сети, где оборудование изменяется широко среди главных ЭВМ,
или где пользователи не имеют эквивалентных прав на машине сервера.
      При использовании NFS, статьи, зарегистрированные на локальном host
должны быть посланы к центральной машине. Также, Вы могли бы хотеть
защищать вашу область spool новостей,  экспортируя их только для чтения, что
требует пересылки к центральной машине, также.
      C News обрабатывает это очевидно. Когда Вы отправляете по почте
статью, ваш newsreader обычно вызывает inews, чтобы ввести статью в систему
новостей. Эта команда выполняет ряд проверок на статье, завершает
заголовок, и проверяет файловый сервер в /usr/lib/news. Если этот файл
существует и содержит hostname отличный от имени локального host, inews
вызывается на тот host сервер через rsh. Так как inews команда использует ряд
двоичных команд и файлов поддержки от C News, Вы должны также иметь C
News, установленный локально, или устанавливать программное обеспечение
новостей из сервера.
      Чтобы rsh вызов работал правильно, каждый пользователь должен иметь
эквивалентный вход на систему сервера, то есть вход котороый она может
регистрировать без запроса о пароле.
      Удостоверитесь, что hostname, данный в сервере буквально соответствует
выводу команды hostname (1) на машине сервера, иначе C News будет
зацикливаться навсегда при попытке получить статью.

      18.10 Инструментальные средства Сопровождения и Задачи

      Несмотря на сложность C News, жизнь администратора новостей может
быть довольно проста, потому что C News обеспечивает Вас расширенным
разнообразием инструментальных средств сопровождения. Некоторые из них
предназначены, чтобы быть выполненными регулярно из cron, подобно
newsdaily. Использование этих команд значительно уменьшает ежедневную
заботу и подачу требований вашей установки C News.
      Если не установлено иначе, эти команды расположены в
/usr/lib/news/bin/maint. Обратите внимание, что Вы должны стать пользователем
перед вызовом этих команд. При выполнении их как супер-пользователь эти
файлы могут стать недоступными C News.



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

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

addgroup Добавляет группу к вашему пункту локально. Соответствующий
вызов

                addgroup groupname y|n|m|=realgroup

      Второй аргумент имеет то же самое значение как флаг в файле active, что
любой может отправить по почте к группе (y), что никто не может отправить
по почте (n), что она уменьшена (m), или что она является специальной для
другой группы (=realgroup).
      Вы могли бы также использовать addgroup, когда первые статьи в недавно
созданной группе прибывают раньше чем сообщение управления newgroup,
которое предназначено, чтобы создать ее.

delgroup nозволяет Вам удалять группу локально. Вызовите это как

                delgroup groupname

      Вы все еще должны удалить статьи, которые остаются в каталоге spool. В
качестве альтернативы, Вы могли бы оставлять это натуральному ходу
событий (a.k.a. Expire) чтобы удалять их.

addmissing Добавляет отсутствующие статьи к файлу хронологии. Выполните


эту команду, когда имеются статьи, которые, кажется,  зависают навсегда.

newsboot Эта команда должна быть выполнена при начальной загрузке
системы. Она удаляет любые файлы блокировки, оставленные, когда
обработчики новостей уничтожались при закрытии системы, и закрывает и
выполняет любые пакеты, оставленные из NNTP соединений, которые были
завершены при закрытии системы.

newsrunning Это постоянно находится в /usr/lib/news/bin/input, и может
использоваться, чтобы отключить непакетирование входящих новостей,
например в течение работы. Вы можете выключить непакетирование вызовом

         /usr/lib/news/bin/input/newsrunning off

Оно включается, используя on вместо off.

      19. Описание NNTP

      19.1 Введение

      Из-за различного сетевого используемого транспорта, NNTP
обеспечивает(предусматривает) значительно отличные подходы к обмену
новостей C News. NNTP замещает " Сетевой Протокол передачи Новостей '', и
неспецифический пакет программ.
      Различные команды позволяют клиентуре отыскивать, посылать и
отправлять по почте статьи. Различие между посылкой и регистрацией - то,
что последний может включать статьи с незавершенной информацией
заголовка. Поиск статьи может использоваться клиентурой передачи новостей
также как newsreaders. Это делает NNTP превосходным средством для
обеспечения доступа к новостям для клиентуры в локальной сети.
      NNTP также обеспечивает активый и пассивный способы передачи
новостей, которые называются " pushing " и " pulling ". Выталкивание (pushing) - в
основном тоже что C News ihave/sendme протокол. Клиент предлагает статью
серверу через " IHAVE <varmsgid> ", и сервер возвращает код ответа, который
указывает, имеет ли он уже статью, или если она требуется. Если так, клиент
посылает статью, завершенную одиночной точкой в отдельной строке.
      Выталкивание новостей имеет один недостаток - это вызывает тяжелую
загрузку в системе сервера, так как она должна искать в базе данных


хронологий каждую одиночную статью.
      Противоположная методика - перемещать(pulling) новости. Клиент
запрашивает список всех доступных статей из группы, которые прибыли после
заданной даты. Этот запрос выполняется командой NEWNEWS. Из
возвращенного списка идентичности сообщения, клиент выбирает те статьи,
которые он еще не имеет, используя команду ARTICLE для каждой из них по
очереди.
      Проблема с перемещением новостей состоит в том, что требуется плотное
управление сервером, которое позволяет клиенту запрашивать группы и
распределения. Например, оно должно удостовериться, что никакой
конфиденциальный материал из локальных newsgroups не послан
несанкционированной клиентуре.
      Имеется также ряд команд удобства для newsreaders, которые разрешают им
отыскивать заголовок статьи и тело отдельно, или даже одиночные строки
заголовка из промежутка статей. Это допускает Вам, хранить все новости
относительно центрального host, со всеми пользователями сетьи, используя
nntp-основанные клиентские программы для чтения и регистрации. Это -
альтернатива к экспорту каталогов новостей через NFS, который описан в
главе 18 ..
      Полная проблема NNTP состоит в том, что она позволяет хорошо
осведомленному специалисту вставлять статьи в поток новостей с ложной
спецификацией отправителя. Это называется новостями faking. Расширение к
NNTP позволяет требовать установления подлинности пользователя для
некоторых команд.
      Имеется ряд доступных NNTP пакетов. Один из наиболее широко
известных - NNTP daemon, также известный как реализация ссылки.
Первоначально, он написан Stan Barber и Phil Lapsley, чтобы иллюстрировать
подробности RFC 977. Самая современная версия - nntpd-1.5.11, описана
ниже. Вы можете также получить исходники и компилировать ее
непосредственно.
      Nntpd пакет состоит из сервера и двух клиентов для перемещения и
выталкивания новостей, соответственно, также как inews замены. Они живут в
Bnews среде, но с небольшими дополнениями, они будут счастливы с C news,
также. Однако, если Вы планируете использовать NNTP для больше чем
предложения newsreaders доступа к вашему серверу новостей, реализация
ссылки не есть действительно опция. Мы следовательно обсудим только
NNTP daemon содержащийся в nntpd пакете, и не учтем клиентские программы.



      19.2 Установка NNTP сервера

      NNTP сервер называется nntpd, и может компилироваться двумя
способами, в зависимости от ожидаемой загрузки на системе новостей. Не
имеется никаких откомпилированных версий, из-за некоторых пункт-
специфических значений по умолчанию, которые являются жестко
закодированными в выполнимую программу. Вся конфигурация выполнена
через макркоманду definines в common/conf.h.
      Nntpd может быть конфигурирован или как автономный сервер, который
запускается при начальной загрузке системы из rc.inet2, или как daemon
управляемый inetd. В последнем случае Вы должны иметь следующий вход в
/etc/inetd.conf:

      nntp    stream  tcp nowait      news    /usr/etc/in.nntpd    nntpd

      Если Вы конфигурируете nntpd как автономный, удостовертеь, что любая
такая строка в inetd.conf прокомментирована. В любом случае, Вы должны
удостовериться, что имеется следующая строка в /etc/services:

      nntp    119/tcp   readnews untp    # Network News Transfer Protocol

      Чтобы временно сохранять любые входящие статьи, и т.д, nntpd также
нуждается в a каталоге .tmp в вашем spool новостей. Вы должны создать его
используя

      # mkdir /var/spool/news/.tmp
      # chown news.news /var/spool/news/.tmp

      19.3 Ограничение NNTP Доступа

      Доступ к NNTP ресурсам управляется файлом nntp access в /usr/lib/news.
Строки в файле описывают права доступа, предоставленные иностранным
главным ЭВМ. Каждая строка имеет следующий формат:

        site   read|xfer|both|no    post|no      [!exceptgroups]

      Если клиент соединяется с NNTP портом, nntpd, пытается получать
полностью квалифицированное имя области из адреса IP обратным поиском.


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

hostname Это - полностью квалифицированное имя области host. Если оно
соответствует каноническиому hostname клиента буквально, вход применяется,
и все последующие входы игнорируются.

IP address Это - адрес IP в точечной записи четверки. Если адрес IP клиента
соответствует этому, вход применяется, а все последующие входы
игнорируются.

domain name Это - имя области, заданное как *.domain. Если hostname клиента
соответствует имени области, вход соответствует.

network name Это - имя сети как определено в /etc/networks. Если сетевое число
адреса IP клиента соответствует сетевому числу, связанному с сетевым
именем, вход соответствует.

default  Значение по умолчанию соответствует любому клиенту.

      Входы с более общей спецификацией пункта должны быть определены
ранее.
      Второе и третье поле описывают права доступа, предоставленные клиенту.
Второе детализирует права, чтобы отыскать новости, перемещая (read), и
передавать новости,  выталкивая (xfer). Третье поле предоставляет клиенту
право отправить по почте статьи, то есть статьи с незавершенной
информацией заголовка, которая завершена программным обеспечением
новостей. Если второе поле содержит No, третье поле,  игнорируется.
      Четвертое поле необязательно, и содержит отделенный запятой список
групп, с отклоненным доступом для клиента.
      Пример nntp файла доступа показывается ниже:

      #
      # by default, anyone may transfer news, but not read or post


      default             xfer            no
      #
      # public.vbrew.com offers public access via modem, we allow
      # them to read and post to any but the local.* groups
      public.vbrew.com    read            post    !local
      #
      # all other hosts at the brewery may read and post
      *.vbrew.com         read            post

      19.4 NNTP Разрешение

      При печати прописными буквами лексем(маркеров) доступа подобно xfer
или read в nntp access файл, nntpd требует разрешения от клиента для
соответственных операций. Например, при определении права Xfer или
XFER, nntpd не будет допускать клиентские статьи к вашему пункту, если он не
передает разрешение.
      Процедура разрешения выполнена посредством новой команды NNTP,
именованной AUTHINFO. При использовании этой команды, клиент передает
имя пользователя и пароль к NNTP серверу. Nntpd проверит правильность их,
проверяя их против базы данных /etc/passwd, и проверит, что пользователь
принадлежит группе nntp.
      Текущая реализация NNTP разрешения только экспериментальна, и не
была выполнена очень переносимой. Результат - то, что это работает только с
базами данных паролей с простым стилем; теневые пароли не будут
распознаны.

      19.5 Nntpd Взаимодействие с C News

      При получении статьи, nntpd должен приписать ее к подсистеме новостей.
В зависимости от того, было ли это получено в результате команды IHAVE
или POST, статья вручена rnews или inews, соответственно. Вместо того, чтобы
вызывать rnews, Вы можете также конфигурировать rnews (во времени
компиляции) пакетировать входящие статьи и перемещать возникающие в
результате пакеты в /var/spool/news/in.coming, где они остаются для relaynews,
чтобы подбирать их в следующей выполненной очереди.
      Чтобы быть способным правильно выполнить ihave/sendme протокол, nntpd
должен быть способен обратиться к файлу хронологии. Во времени
компиляции, Вы следовательно должны удостовериться, что  путь установлен


правильно. Вы должны также удостовериться, что C news и nntpd
договариваются о формате вашего файла хронологии. C news использует dbm
хеш-функции, чтобы обратиться к нему; однако, имеется некоторое число
отличных и немного несовместимых реализаций dbm библиотеки. Если C news
был связан с различной dbm библиотекой чем Вы, имеете в вашем стандарте
libc, Вы должны линковать nntpd с этой библиотекой, также.
      Типичный признак того что nntpd и C news не соглашаются относительно
формата базы данных - сообщения об ошибках в файле регистрации системы,
что nntpd не может открыть его правильно, или двойные статьи, полученные
через NNTP. Хороший тест должен выбрать статью из вашей области spool,
сделать telnet к nntp порту, и предлагать, это к nntpd как показано в примере
ниже. Конечно, Вы должны заменить <msg@id> на ID-сообщение статьи,
которую Вы хотите передать к nntpd снова.

      $ telnet localhost nntp
      Trying 127.0.0.1...
      Connected to loalhost
      Escape characters is '^]'.
      201 vstout NNTP[auth] server version 1.5.11t (16 November
      1991) ready at Sun Feb 6 16:02:32 1194 (no posting)
      IHAVE <msg@id>
      435 Got it.
      QUIT

      Этот диалог показывает соответствующую реакцию nntpd; сообщение "Got
it" сообщает Вам, что уже имеется эта статья. Если Вы получаете сообщение
"335 Ok" взамен, поиск в файле хронологии, потерпел неудачу по некоторым
причинам. Завершите диалог печатая Ctrl-D. Вы можете проверять, что шло
неправильно,  проверяя файл регистрации системы; nntpd регистрирует все
виды сообщений в syslog. Несовместимая dbm библиотека обычно проявляется
в сообщении, жалующемся что dbminit потерпел неудачу.

      20. Конфигурация Newsreader

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


бесконечных споров.
      Имеется пара newsreaders, которые были пренесены на Linux. Ниже я буду
описывать базисную установку для трех наиболее популярных, а именно tin,
trn, и nn.
      Один из наиболее эффективных newsreaders это

$ find /var/spool/news -name '[0-9]*' -exec cat {} \; | more

      Это - способ, которым Unix читает новости.
      Большая часть newsreaders, однако, является намного более сложной. Они
обычно предлагают полноэкранный интерфейс с отдельными уровнями для
отображения всех групп, на которые пользователь подписался, для
отображения краткого обзора всех статей в одной группе. И для
индивидуальных статей.
      В уровне newsgroup, большинство newsreaders отображает список статей,
показывая их подчиненную строку, и автора. В больших группах, это
невозможно для пользователя, чтобы следить за статьями в отношении друг
друга, хотя возможно идентифицировать ответы на более ранние статьи.
      Ответ обычно повторяет первоначальную тему статьи, начинаясь с " " Re: ''.
      Здесь, мы не будем детализировать то, как интерфейсы пользователя
сформированы. Все newsreaders, в настоящее время доступные для Linux имеют
хорошую функцию справки, так что Вы должны исследовать дальше сами.
      В следующем, мы будем иметь дело только с административными
задачами. Большинство их касается создания баз данных и учет.

      20.1  Конфигурация tin

      Наиболее универсальный newsreader - tin. Он написан Iain Lea и - свободно
построен на более старом newsreader, именованном ТАСС.
      На 486DX50, он берет приблизительно 30 секунд, чтобы найти 1000 статей
при чтении непосредственно с диска. Над NNTP к загруженному серверу
новостей, это было бы что-нибудь более 5 минут. Вы можете уточнить это,
регулярно модифицируя ваш индексный файл с -u опцией, или  вызывая tin с -
U опцией.
      Обычно, tin формирует дамп баз данных в исходном каталоге пользователя
ниже .tin/index. Это может однако быть дорогостояще в терминах ресурсов, так
чтобы Вы хотели хранить одиночную копию их в центральном расположении.
Это может быть достигнуто,  делая tin setuid к новостям, например. Тогда tin


будет хранить, все подходящие базы данных ниже /var/spool/news/.index. Для
любого файла access или Escape оболочки, это переустановит эффективный
универсальный идентификатор к реальному универсальному идентификатору
пользователя, который вызвал это.
      Версия tin, включенного в некоторые распределения Linux не имеет
никакой компилируемой поддержки NNTP. Когда вызывается как rtin или с -r
опцией, tin пробует соединяться с NNTP сервером, заданным в /etc/nntpserver
файле или в NNTPSERVER переменной среды. Nntpserver файл просто
содержит имя сервера в одиночной строке.

      20.2 Trn Конфигурация

      Trn - преемник более старого newsreader, а именно rn (который означает
чтение новостей). " T " в имени замещает "связный". Он написан Wayne
Davidson.
      В отличие от tin, trn не имеет никакого средства для производства базы
данных поиска во время выполнения. Взамен, он использует базу
подготовленную программой, называемой mthreads, которая должна вызваться
регулярно из cron, чтобы модифицировать индексные файлы.
      Не выполнение mthreads, однако, не означает, что Вы не можете
обращаться к новым статьям, это только означает что Вы будете иметь все эти
" Novell выкупают Linix!! " статьи, рассеянные в вашем меню выбора статей,
вместо одиночного экземпляра (который Вы можете легко пропустить).
      Чтобы включить отсеивание для определенных newsgroups, mthreads
вызывается со списком newsgroups в командной строке. Список сделан как в
файле sys:

      mthreads comp,rec,!rec.games.go

Даст возможность отсеиванию для все comp и rec, кроме rec.games.go (люди,
кто играют, идут, не нуждаются в причудливых выборках). После этого, Вы
просто вызываете это без любой опции вообще, чтобы заставить это
обработать любые недавно прибывшие статьи. Отсеивание всех групп,
найденных в вашем файле active может быть включено,  вызывая mthreads со
списком группы.
      Если вы получаете новости в течение ночи, Вы будет обычно выполнять
mthreads один раз утром, но Вы можете также, делать так более часто если
необходимо. Абоненты, которые имеют очень тяжелый траффик, могут хотеть


выполнять mthreads в daemon режиме. Когда она начинается при начальной
загрузке, используя -d опцию, она помещает себя в фон, и пробуждается
каждые 10 минут, чтобы проверить, имеются ли любые недавно прибытые
статьи, и просеивает их. Чтобы выполнять mthreads в daemon режиме,
поместите следующую строку в вашу rc.news команду:

      /usr/local/bin/rn/mthreads -deav

      -a опция заставит mthread автоматически включить отсеивание для новых
групп, поскольку они созданы; -v дает возможность подробным
регистрационным сообщениям к файлу регистрации mthreads, mt.log в каталоге,
где Вы имеете установленный trn.
      Старые статьи, которые больше не доступны, должны быть удалены из
индексных файлов регулярно. По умолчанию, только статьи, чье число
является ниже метки ожидания, будут удалены. Статьи выше этого числа,
которые устарели (потому что самая старая статья была назначена на длинную
дату истечения полем заголовка Expires) могут быть удалены,  давая mthreads -e
опцию, чтобы вынудить " расширенную " чистку. Когда mthreads выполняется
в daemon режиме, -e опция заставит такое расширенное истечение выполнять
один раз в день, в полночь.

      20.3 Конфигурация  nn

      Nn написал Kim F. Storm, он утверждает, что цель newsreader не состоит в
том, чтобы читать новости. Имя расшифровывается как " Нет Новостей '', и
девиз - "Отсутствие новостей - хорошая новость. А nn лучше."
      Чтобы достигать этой честолюбивой цели, nn поставляется с большим
выбором инструментальных средств сопровождения, которые не только
позволяют проводить отсеивание, но также протяженные проверки на
непротиворечивости этих баз данных, учет, сбор статистики использования, и
ограничений доступа. Имеется также программа администрации, называемая
nnadmin, который позволяет Вам выполнять эти задачи в интерактивном
режиме.
      Nn диспетчер базы данных,  называется nnmaster. Он обычно выполняется
как daemon, начинается из команды rc.inet2 или rc.news. Он вызывается как

      /usr/local/lib/nn/nnmaster -l -r -C



      Это дает возможность отсеиванию для всех newsgroups, представленных в
вашем файле active.
      Также, Вы можете вызывать nnmaster периодически из cron, давая ему
список групп. Этот список очень похож на список в файле sys, за исключением
того, что он использует пробелы вместо запятых. Вместо группы  fake для всех,
пустой аргумент "" должен использоваться, чтобы обозначить все группы.
Типовой вызов

      # /usr/local/lib/nn/nnmaster !rec.games.go rec comp

      Обратите внимание, что порядок значителен: крайная левая спецификация
группы, которая соответствует, всегда выигрывает. Таким образом, если мы
поместили !rec.games.go после rec, все статьи из этой группы отсеились.
      Nn предлагает отдельные методы удалить устаревшие статьи из баз
данных. Первое,  чтобы модифицировать базу данных,  развертывая каталоги
групп новостей и отбрасывая входы, чья соответствующая статья является
больше не доступной. Это - заданная по умолчанию операция, полученная
вызовом nnmaster с -E опцией. Приемлемо быстро, если вы не делаете это
через NNTP.
      Метод 2 ведет себя точно подобно заданному по умолчанию устареванию,
выполненному mthreads, в котором она только удаляет те входы, которые
относятся к статьям, чье число ниже метки ожидания в файле active. Это
можно допускать, используя -e опцию.
      В заключение, третья стратегия должна отбросить всю базу данных и
переоформить все статьи. Это может быть выполнено,  давая -E3 к nnmaster.
      Список групп, которые устарели дется -F опцией в том же самом режиме
как выше. Однако, если Вы имеете nnmaster, выполняющийся как daemon, Вы
должны уничтожить его (используя -k) прежде, чем может произойти
устаревание, и перезапускать его с первоначальными опциями. Таким образом
соответствующая команда, чтобы выполнить expire на всех группах,
использующих метод 1:

      # nnmaster -kF ""
      # nnmaster -lrC

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


      Nnmaster полагается на файл, именованный GROUPS, который расположен
в /usr/local/lib/nn. Если он не существует первоначально, он будет создан. Для
каждой newsgroup, он содержит строку, которая начинается с имени группы,
необязательно сопровождаемого временной меткой, и флагами. Вы можете
редактировать эти флаги, чтобы дать возможность некоторому поведению для
рассматриваемой группы, но Вы не можете изменять порядок, в котором
группы появляются. Флаги и их эффекты детализированы в nnmaster странице
руководства, также.

                                APPENDIX A

      Null Кабель Принтера для PLIP

      Чтобы сделать Кабель Принтера для использования с PLIP соединением,
Вы нуждаетесь в двух соединителях с 25 штырьками (называемых DB-25) и
некотором кабеле с 11 проводниками. Кабель должен быть длиной 15 метров.
      Если Вы рассматриваете коннектор, Вы должны видеть крошечные числа в
основе каждого штырька. Для кабеля Принтера, Вы должны соединить
следующие штырьки обоих разьемов друг с другом:

+-------------------------------+
|D0     2       15      ERROR   |
|D1     3       13      SLCT    |
|D2     4       12      PAPOUT  |
|D3     5       10      ACK     |
|D4     6       11      BUSY    |
|GROUND 25      25      GROUND  |
|ERROR  15      2       D0      |
|SLCT   13      3       D1      |
|PAPOUT 12      4       D2      |
|ACK    10      5       D3      |
|BUSY   11      6       D4      |
+-------------------------------+

      Все остающиеся штырьки остаются не связанными. Если кабель
экранирован, экран должен быть соединен с DB-25 металлической оболочкой
на одном конце.



                                APPENDIX B

      Примеры smail Файлов Конфигурации

      Этот раздел показывает типовые файлы конфигурации для пункта UUCP в
локальной вычислительной сети. Они основаны на типовых файлах,
включенных в исходное распределение smail-3.1.28. Хотя я делаю слабую
попытку объяснить, как эти файлы работают.
      Первый показанный файл - файл программ маршрутизации, который
описывает набор программ маршрутизации для smail. Когда smail должен
послать сообщение к данному адресу, он вручает адрес всем программам
маршрутизации по очереди, пока одна из них не найдет соответствие.
Соответствие здесь означает что программа маршрутизации находит host
адресата в базе данных, буть это файл paths, /etc/hosts, или любой механизм
маршрутизации.
      Входы в smail файлах конфигурации всегда начинаются с уникального
имени, идентифицирующего программу маршрутизации, транспорт, или
руководитель. Они сопровождаются списком атрибутов, которые определяют
поведение. Этот список состоит из набора глобальных атрибутов, типа
драйвера, и частных атрибутов, которые понятны только этому
специфическому драйверу.
      Атрибуты отделяются запятыми, в то время как наборы глобальных и
частных атрибутов отделяются от друг друга, используя точку с запятой.
      В smail, Вы можете определять две программы маршрутизации в файле
программ маршрутизации, обе из которых используют pathalias драйвер. Этот
драйвер ищет hostnames в pathalias базе данных. Он ожидает имя файла в
частном атрибуте:

      #
      # pathalias database for intra-domain routing
      domain paths:
      driver=pathalias,         # look up host in a paths file
      transport=uux;            # if matched, deliver over UUCP
      file=paths/domain,        # file is /usr/lib/smail/paths/domain
      proto=lsearch,            # file is unsorted (linear search)
      optional,                 # ignore if the file does not exist
      required=vbrew.com,       # look up only *.vbrew.com hosts
      #


      # pathalias database for routing to hosts outside our domain
      world paths:
      driver=pathalias,         # look up host in a paths file
      transport=uux;            # if matched, deliver over UUCP
      file=paths/world,         # file is /usr/lib/smail/paths/world
      proto=bsearch,            # file is sorted with sort(1)
      optional,                 # ignore if the file does not exist
      -required,                # no required domains
      domain=uucp,              # strip ending ".uucp" before searching

      Второй атрибут глобальной переменной, данный в каждом из двух входов
программ маршрутизации выше определяет транспорт, который должен
использоваться, когда программа маршрутизации обрабатывает адрес. В нашем
случае, сообщение будет передано используя uux транспорт. Транспорты
определены в файле transports, который объяснсется ниже.
      Вы можете подстраивать,  которым транспортом сообщение будет
передаваться, если Вы определяете mathod файл вместо атрибута transports.
Файлы методов обеспечивают отображение целевого hostnames на transports.
Мы не будем иметь дело с ними здесь.
      Следующий файл программ маршрутизации определяет программы
маршрутизации для локальной вычислительной сети, которые сделают запрос
библиотеки решающих устройств. На host Internet, однако, Вы хотели бы
использовать программу маршрутизации, которая обрабатывает записи MX.
Вы должны следовательно разкомментировать альтернативную inet программу
маршрутизации, которая использует встроенный драйвер BIND smail.
      В среде, которая смешивает UUCP и TCP/IP, Вы можете сталкиваться с
проблемой, что Вы имеете главные ЭВМ в вашем файле /etc/hosts, с которыми
Вы имеете только случайный SLIP или PPP контакт. Обычно, Вы все еще
хотели бы посылать любую почту для них по UUCP. Чтобы предотвращать inet
драйвер главных ЭВМ от соответствия этих главных ЭВМ, Вы должны
поместить их в файл paths/force.
      Это - другая база данных pathalias-стилей, она проверяется прежде чем smail
делает запрос решающего устройства.

      # A sample /usr/lib/smail/routers file
      #
      # force - force UUCP delivery to certain hosts, even when
      # they are in our /etc/hosts


      force:
      driver=pathalias,         # look up host in a paths file
      transport=uux;            # if matched, deliver over UUCP
      file=paths/force,         # file is /usr/lib/smail/paths/force
      optional,                 # ignore if the file does not exist
      proto=lsearch,            # file is unsorted (linear search)
      -required,                # no required domains
      domain=uucp,              # strip ending ".uucp" before searching
      # inet addrs - match domain literals containing literal
      # IP addresses, such as in janet@[191.72.2.1]
      inet addrs:
      driver=gethostbyaddr,     # driver to match IP domain literals
      transport=smtp;           # deliver using SMTP over TCP/IP
      fail if error,            # fail if address is malformed
      check for local,          # deliver directly if host is ourself
      # inet hosts - match hostnames with gethostbyname(3N)
      # Comment this out if you wish to use the BIND version instead.
      inet hosts:
      driver=gethostbyname,     # match hosts with the library function
      transport=smtp;           # use default SMTP
      -required,                # no required domains
      -domain,                  # no defined domain suffixes
      -only local domain,       # don't restrict to defined domains
      # inet hosts - alternate version using BIND to access the DNS
      #inet hosts:
      # driver=bind,            # use built-in BIND driver
      # transport=smtp; # use TCP/IP SMTP for delivery
      #
      # defnames,               # use standard domain searching
      # defer no connect,       # try again if the nameserver is down
      # -local mx okay,         # fail (don't pass through) an MX
      #                         # to the local host
      #
      # pathalias database for intra-domain routing
      domain paths:
      driver=pathalias,         # look up host in a paths file
      transport=uux;            # if matched, deliver over UUCP
      file=paths/domain,        # file is /usr/lib/smail/paths/domain


      proto=lsearch,            # file is unsorted (linear search)
      optional,                 # ignore if the file does not exist
      required=vbrew.com,       # look up only *.vbrew.com hosts
      #
      # pathalias database for routing to hosts outside our domain
      world paths:
      driver=pathalias,         # look up host in a paths file
      transport=uux;            # if matched, deliver over UUCP
      file=paths/world,         # file is /usr/lib/smail/paths/world
      proto=bsearch,            # file is sorted with sort(1)
      optional,                 # ignore if the file does not exist
      -required,                # no required domains
      domain=uucp,              # strip ending ".uucp" before searching
      # smart host - a partically specified smarthost director
      # If the smart path attribute is not defined in
      # /usr/lib/smail/config, this router is ignored.
      # The transport attribute is overridden by the global
      # smart transport variable
      smart host:
      driver=smarthost,         # special-case driver
      transport=uux;            # by default deliver over UUCP
      -path,                    # use smart path config file variable

      Обработка почты для локальных адресов конфигурирована в файле
directors. Это сделано точно так же как файл программ маршрутизации, со
списком входов, которые определяют руководителя каждой. Руководители не
посылают сообщение, они просто выполняют всю переадресацию, которая
является возможной, например через aliases, пересылку почты, и т.п..
      При поставке почты к локальному адресу, типа janet, smail передает имя usr
всем directors по очереди. Если director соответствует, это или определяет
транспорт,  которым сообщение должно быть передано (например, к mailbox
файлу пользователя), или генерирует новый адрес (например, после
специальной оценки).
      Из-за включаемых проблем защиты, directors обычно делает множество
проверок того, могут ли файлы которые они используют быть
скомпрометированы или нет. Адреса, полученные несколько сомнительным
способом (например от world -перезаписываемый файл aliases) помечены как
небезопасные. Некоторые транспортные драйверы отвергнут такие адреса,


например транспорт, который передает сообщение файлу.
      Кроме этого, smail также связывает пользователя с каждым адресом. Любая
запись или операции чтения выполняется как пользователь. Для получения в,
скажем mailbox janet, адрес конечно связан с janet.
      Другие адреса, типа тех что получены из файла aliases, имеют других
пользователей, связанных с ними, например, пользователь nobody.
      Для подробностей этих возможностей, пожалуйста обратитесь к smail
manpage.

      # A sample /usr/lib/smail/directors file
      # aliasinclude - expand ":include:filename" addresses produced
      # by alias files
      aliasinclude:
      driver=aliasinclude,      # use this special-case driver
      nobody;                   # access file as nobody user if unsecure
      copysecure,               # get permissions from alias director
      copyowners,               # get owners from alias director
      # forwardinclude - expand ":include:filename" addrs produced
      # by forward files
      forwardinclude:
      driver=forwardinclude,    # use this special-case driver
      nobody;                   # access file as nobody user if unsecure
      checkpath,                # check path accessibility
      copysecure,               # get perms from forwarding director
      copyowners,               # get owners from forwarding director
      # aliases - search for alias expansions stored in a database
      aliases:
      driver=aliasfile,         # general-purpose aliasing director
      -nobody,                  # all addresses are associated
      # with nobody by default anyway sender okay,
      # don't remove sender from expansions
      owner=owner-$user;        # problems go to an owner address
      file=/usr/lib/aliases,    # default: sendmail compatible
      modemask=002,             # should not be globally writable
      optional,                 # ignore if file does not exist
      proto=lsearch,            # unsorted ASCII file
      # dotforward - expand     .forward files in user home directories
      dotforward:


      driver=forwardfile,       # general-purpose forwarding director
      owner=real-$user,         # problems go to the user's mailbox
      nobody,                   # use nobody user, if unsecure
      sender okay;              # sender never removed from expansion
      file=~/.forward,          # .forward file in home directories
      checkowner,               # the user can own this file
      owners=root,              # or root can own the file
      modemask=002,             # it should not be globally writable
      caution=0-10:uucp:daemon,
      # don't run things as root or daemons
      # be extra careful of remotely accessible home directories
      unsecure="~ftp:~uucp:~nuucp:/tmp:/usr/tmp",
      # forwardto - expand a "Forward to " line at the top of
      # the user's mailbox file
      forwardto:
      driver=forwardfile,
      owner=Postmaster,         # errors go to Postmaster
      nobody,                   # use nobody user, if unsecure
      sender okay;              # don't remove sender from expansion
      file=/var/spool/mail/${lc:user},
      # location of user's mailbox forwardto,
      # enable "Forward to " check
      checkowner,               # the user can own this file
      owners=root,              # or root can own the file
      modemask=0002,            # under System V, group mail can write
      caution=0-10:uucp:daemon, # don't run things as root or daemons
      # user - match users on the
      # local host with delivery to their mailboxes user:
      driver=user;              # driver to match usernames
      transport=local,          # local transport goes to mailboxes
      # real user - match usernames when prefixed with the string "real-"
      real user:
      driver=user;              # driver to match usernames
      transport=local,          # local transport goes to mailboxes
      prefix="real-",           # for example, match real-root
      # lists - expand mailing lists stored below /usr/lib/smail/lists
      lists:  driver=forwardfile,
      caution,                  # flag all addresses with caution


      nobody,                   # and then associate the nobody user
      sender okay,              # do NOT remove the sender
      owner=owner-$user;        # the list owner
      # map the name of the mailing list to lower case
      file=lists/${lc:user},

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

# A sample /usr/lib/smail/transports file
# local - deliver mail to local users
local:  driver=appendfile,      # append message to a file
      return path,              # include a Return-Path: field
      from,                     # supply a From  envelope line
      unix from hack,           # insert > before From in body
      local;                    # use local forms for delivery
      file=/var/spool/mail/${lc:user},
      # location of mailbox files group=mail,
      # group to own file for System V
      mode=0660,                # group mail can access
      suffix="\n",              # append an extra newline
      # pipe - deliver mail to shell commands
      pipe: driver=pipe,        # pipe message to another program
      return path,              # include a Return-Path: field
      from,                     # supply a From  envelope line
      unix from hack,           # insert > before From in body
      local;                    # use local forms for delivery
      cmd="/bin/sh -c $user",   # send address to the Bourne Shell
      parent env,               # environment info from parent addr
      pipe as user,             # use user-id associated with address
      ignore status,            # ignore a non-zero exit status


      ignore write errors,      # ignore write errors, i.e., broken pipe
      umask=0022,               # umask for child process
      -log output,              # do not log stdout/stderr
      # file - deliver mail to files
      file:     driver=appendfile,
      return path,              # include a Return-Path: field
      from,                     # supply a From  envelope line
      unix from hack,           # insert > before From in body
      local;                    # use local forms for delivery
      file=$user,               # file is taken from address
      append as user,           # use user-id associated with address
      expand user,              # expand ~ and $ within address
      suffix="\n",              # append an extra newline
      mode=0600,                # set permissions to 600
      # uux - deliver to the rmail program on a remote UUCP site
      uux:      driver=pipe,
      uucp,                     # use UUCP-style addressing forms
      from,                     # supply a From  envelope line
      max addrs=5,              # at most 5 addresses per invocation
      max chars=200;            # at most 200 chars of addresses

      cmd="/usr/bin/uux - -r -a$sender -g$grade $host!rmail $(($user)$)",
        pipe as sender,
      # have uucp logs contain caller
      log output,               # save error output for bounce messages
      # defer child errors,     # retry if uux returns an error
      # demand - deliver to a remote rmail program,
      # polling immediately demand: driver=pipe,
      uucp,                     # use UUCP-style addressing forms
      from,                     # supply a From  envelope line
      max addrs=5,              # at most 5 addresses per invocation
      max chars=200;            # at most 200 chars of addresses
      cmd="/usr/bin/uux - -a$sender -g$grade $host!rmail $(($user)$)",
        pipe as sender,
      # have uucp logs contain caller
      log output,               # save error output for bounce messages
      # defer child errors,     # retry if uux returns an error
      # hbsmtp - half-baked BSMTP. The output files must


      # be processed regularly and sent out via UUCP.
      hbsmtp: driver=appendfile,
      inet,                     # use RFC 822-addressing
      hbsmtp,                   # batched SMTP w/o HELO and QUIT
      -max addrs, -max chars;   # no limit on number of addresses
      file="/var/spool/smail/hbsmtp/$host",
      user=root,                # file is owned by root
      mode=0600,                # only read-/writeable by root.
      # smtp - deliver using SMTP over TCP/IP
      smtp:     driver=tcpsmtp,
      inet,
      -max addrs, -max chars;   # no limit on number of addresses
      short timeout=5m,         # timeout for short operations
      long timeout=2h,          # timeout for longer SMTP operations
      service=smtp,             # connect to this service port
      # For internet use: uncomment the below 4 lines
      # use bind,               # resolve MX and multiple A records
      # defnames,               # use standard domain searching
      # defer no connect,       # try again if the nameserver is down
      # -local mx okay,         # fail an MX to the local host

                                APPENDIX C

      Общая Публичная Лицензия GNU

      Имеется Общая Лицензия  GNU (GPL или copy-left), под которой Linux
запатентован. Она не воспроизведена здесь. Большая часть ядра Linux -
copyright (C) 1993 Linus Torvalds, и другое программное обеспечение
обеспечены авторским правом их авторами. Таким образом, Linux обеспечен
авторским правом, однако, Вы можете перераспределять его (копировать) в
соответствии с GPL (GNU GENERAL PUBLIC LICENSE).

      Глоссарий

      Огромная трудность в работе с сетями - помнить все сокращения и
термины. Имеется список тех что мы часто использовали в этом руководстве,
наряду с коротким объяснением.



ACU Автоматический Модуль Обращения. Модем.

ARP Протокол Разрешающей способности Адреса. Используется чтобы
отобразить IP адреса на адреса локальной сети на основе протокола CSMA-CD
(Ethernet).

ARPA Агентство Проектов Перспективного исследования, позднее управление
перспективных исследований Министерства обороны США. Основатель
Internet.

ARPANET Предок сегодняшнего Internet; экспериментальная сеть,
финансируемая Агентством Защиты Проектов Перспективного исследования
США (управление перспективных исследований Министерства обороны
США).

BBS Система BBS. Телефонный вызов по номеру mailbox.

BGP Протокол Ворот Границы. Протокол для обмена информации
маршрутизации между автономными системами.

BIND Berkeley Internet Name Domain сервер. Реализация сервера DNS.

BNU Базисные Утилиты Работы с сетями. Это - наиболее общее разнообразие
UUCP в настоящее время. Они также известны как HoneyDanBer UUCP. Это
имя происходит от имен авторов: P. Honeyman, D.A. Novitz, и B.E. Redman.
broadcast network Сеть, которая позволяет одной станции адресовать
датаграмму всем другим станциям в сети одновременно.

BSD Berkeley Распределение Программного обеспечения. Разновидность Unix.
CCITT (рус. МККТТ) Международная организация телефонных услуг, и т.д.
CSLIP Сжатая Последовательная IP Линия. Протокол для обмена IP пакетами
по последовательной линии, используя сжатие заголовка большинства
датаграмм TCP/IP.

DNS Domain name system.Это - распределенная база данных, используемая в
Internet для отображения имен host к адресам IP.

EGP Внешний Протокол Ворот. Протокол для обмена информации


маршрутизации между автономными системами.

Ethernet Технически, Ethernet - часть набора стандартов, изложенных ИИЭРом.
Аппаратные средства Ethernet используют одиночный фрагмент кабеля, часто
кабель соединяет ряд главных ЭВМ, и позволяет скорость передачи до
10Mbps. Протокол Ethernet определяет способ,  которым главные ЭВМ могут
связываться по этим кабелям.

FQDN Полностью Квалифицированное Имя Области. Hostname с именем
области, так, чтобы это был допустимый индекс в базу данных Имен Области.

FTP Протокол Передачи Файлов. Этот протокол одно из самых известных
обслуживаний передачи файла.

FYI  "Для Вашей Информации." Ряд документов с неофициальной
информацией относительно предметов Internet.

GMU Groucho Marx University. Фиктивный Университет, используемый
например через эту книгу.

GNU GNU не Unix - этот рекурсивный акроним - имя проекта Свободной
Ассоциации Программного обеспечения, чтобы обеспечить когерентный
набор инструментальных средств Unix, которые могут использоваться и
копироваться бесплатно. Все программное обеспечение GNU покрыто
специальным Объявлением об авторском праве, также называемым Общей
Публичной Лицензией GNU (GPL), или Copyleft.
HoneyDanBer Имя разнообразия UUCP. См. также BNU.

host Вообще, сетевой узел: кое-что, что является способным получать и
передавать сетевые сообщения. Это будет обычно Компьютер, но Вы можете
также думать о x-терминалах, или интеллектуальных принтерах.

ICMP    Internet Протокол Управляющих Сообщений. Протокол работы с
сетями, используемый IP, чтобы возвратить информацию ошибки host
посылки, и т.д.

IEEE   Institute of  Electrical  and  Eletronics  Engineers.Другая организация
стандартов. С точки зрения пользователя UNIX, их наиболее важное


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

IETF Internet Силы Проектироваия Задач.

internet  Компьютерная сеть, сформированная из коллекции индивидуальных
меньших сетей.

Internet   Специфический "мировой" internet.

IP Internet Protocol. Протокол работы с сетями.

ISO  Организация Международных эталонов.

ISDN Интегрированные Услуги Цифровой Сети. Новая технология передачи
данных, использующая цифровую вместо аналоговой схемы.

LAN Локальная вычислительная сеть. Малая компьютерная сеть.

MX Экспреобразователь Почты. Тип записи ресурса DNS, используемый для
маркировки host как gateway почты для области.

NFS Сетевая Файловая система. Стандартный протокол работы с сетями и
набор  программного обеспечения для доступа к данным относительно
отдаленных дисков очевидно.

NIS Сетевая Информационная Система. Rpc-основанное приложение, которое
позволяет совместно использовать файлы конфигурации типа файла паролей
между отдельными главными ЭВМ. См. также вход YP.

NNTP Сетевой Протокол передачи Новостей. Используется чтобы передать
новости по TCP сетевым соединениям.
octet  На Internet, технический термин, касается количества восьми битов.
Используется этот термин а не байт, потому что имелись машины на Internet,
которые имеют байт, по величине отличный от восьми битов.

OSI Соединение Открытых систем. Стандарт ISO на сетевом программном


обеспечении.
path  Часто используется в сетях UUCP как синоним для маршрута.

PLIP  Параллельная IP Линия. Протокол для обмена IP пакетами по
параллельной линии типа порта принтера.

PPP  Двухточечный протокол (из точки в точку). PPP - гибкий и быстрый
протокол связи, чтобы посылать различные сетевые протоколы типа IP или
IPX по двухточечному соединению. Кроме использования на
последовательных связях (модем), PPP может также быть использован как
протокол связи на ISDN.

RARP Обратный Протокол Разрешающей способности Адреса. Он разрешает
главным ЭВМ выяснять их адрес IP при начальной загрузке.

RFC Просьба о Комментариях. Ряд документов, описывающих стандарты
Internet.

RIP  Направляющий Информационный Протокол. Это - протокол
маршрутизации, используемый для динамической коррекции маршрутов
внутри (малой) сети.

RPC  Дистанционное управление вызовом. Протокол для выполнения
процедур внутри процесса на отдаленном host.

RR Сокращение для "запись ресурса".

RS-232  Это - очень общий стандарт для последовательных интерфейсов.

RTS/CTS  Разговорное название для аппаратного контакта, выполняемого
двумя устройствами, сообщающимися (поддерживающими связь) по RS-232.
Имя происходит от двух сокращений  RTS (" Готов Послать ''), и CTS (" Чист,
чтобы Послать '').

RTM Internet Worm   Вирусо-подобная программа, которая использовала
отдельные дефекты в VMS и BSD 4.3 Unix, чтобы распространиться через
Internet. Несколько "ошибок" в программе заставили ее размножаться
безпредельно, и вызвали падение больших частей Internet. RTM - инициалы


автора (Robert T. Morris), которые он оставил в программе.

SLIP  Последовательная IP Линия. Это - протокол для обмена IP пакетами по
последовательной линии, см. также CSLIP.

SMTP Простой Протокол передачи Почты. Используется для транспорта
почты по TCP соединениям, и также для транспортировки пакетов по связям

UUCP (batched SMTP).

SOA   Начало Полномочий. Тип записи ресурса DNS.

System V Разновидность Unix.

TCP Протокол Управления Передачей. Протокол работы с сетями.

TCP/IP Общее описание набора программ протокола Internet в целом.

UDP Протокол Датаграмм Пользователя. Протокол работы с сетями.

UUCP  Копирование из Unix в Unix. Набор программ сетевых транспортных
команд для сетей телефонных вызовов по номеру.

virtual beer   Виртуальное пиво любимый спиртной напиток Каждого Linux'ера.
Первое упоминание о виртуальном пиве, которое я помню, было в
примечании выпуска Linux  0.98.X kernel, где Linus упоминал "Oxford Beer Trolls"
в его разделе кредитов для посылки некоторого виртуального пива.

YP Желтые Страницы. Более старое имя для NIS, которое больше не
используется, потому что Желтые Страницы - марка изготовителя Британской
Телесвязи. Однако, большинство NIS утилит сохранило имена с префиксом yp.
Партнёры:
Хостинг:
Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру