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 может быть найден по адресу

terryd@extro.ucc.su.oz.au.

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

Olaf может быть найден по следующему адресу: Olaf Kirch Kattreinstr. 38 64295 Darmstadt Германия okir@monad.swb.de Vince может быть найден на: Vince Skahan vince@victrola.wa.com Мы открыты для ваших вопросов, комментариев, открыток, и т.д.. Однако, мы просим Вас писать нам только если это действительно важно.

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-активистов посылая почту на linux-activists-request@niksula.hut.fi Со строкой: 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, может быть найден по адресу quinlan@bucknell.edu.lex

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 (becker@super.org). Он автор семейства драйверов для карт основанных на National Semiconductor 8390 чипе; они стали известными как серия Becker драйверов. Имеются также драйвера для пары изделий для D-Link, среди них D-Link адаптер, который предлагает доступ к Ethernet через паралельный порт. Драйвер для этот был написан Bjrn Ekwall (bj0rn@blox.se). DEPCA драйвер был написан David C. Davies (davies@wanton.lkg.dec.com).

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, запросите бланк заявки на сетевой адреса от hostmaster@internic.net. Чтобы оперировать несколькими 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. Karl@morningstar.com.

Эта книга, однако, не может покрывать все аспекты 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, wietse@wzv.win.tue.nl.

# 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. swen@uni-paderborn.de. NIS клиентура доступнаы как yp-

linux.tar.gz из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от этой записи) - yps-0.21 и может быть получена из ftp.lysator.liu.se в /pub/NYS каталоге. 3. pen@lysator.liu.se. +. 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 может быть найден в jrs@world.std.com.

# 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: andyo@ora.com (Andy Oram) To: okir@monad.swb.de 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 стандарта, который требует записи user@host.domain, где 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; вышеупомянутое написали бы как Thomas.Quinot@p9.f204.n320.z2.fidonet.org.

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. Главная ЭВМ, которая хочет передавать сообщение joe@greenhouse.foobar.com, проверит 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 Если, который Вы теперь даете адрес адресата janet@moria.uucp, ваш 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 Любая почта, адресованная claire@jones.sub.org будет послана 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 okir@monad.swb.de #P Kattreinstr. 38, D-64295 Darmstadt, FRG #L 49 52 03 N / 08 38 40 E #U brewhq #W okir@monad.swb.de (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, например, определил бы janet@vbrew.com вместо janet@vale.vbrew.com. Мы объясним ниже, как заставить сервер распознать имя области как допустимое имя для вашего пункта. Другой способ хранения всех 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 распознать janet@vbrew.com как локальный адрес, и передавать сообщение 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: root@vstout.vbrew.com | orig-to: root@vstout.vbrew.com | router: smart host | transport: smtp Это показывает, что сообщение от root до root@vstout.vbrew.com было правильно передано 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] root@vstout.vbrew.com ... 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 root@vstout.vbrew.com Log of transactions: Xdefer: <root@vstout.vbrew.com> 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 адресата передается всем программам маршрутизации по очереди, и находящий наиболее специфический маршрут будет выбран. Рассмотрите сообщение, адресованное joe@foo.bar.com. Одна программа маршрутизации могла бы знать заданный по умолчанию маршрут для всех главных ЭВМ в 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/passwd@vbrew.com. Имя файла - что-нибудь, что начинается с наклонной черты вправо (/) или тильды (~). Письмо относится к исходному каталогу пользователя, и возможно только, если имя файла принималось из 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 joe@sesame.com 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!%s@gcc.groucho.edu 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 # %s@uugate.groucho.edu .UUCP byte!%s@mail.shift.com .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 me@vstout.vbrew.com 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 fred@moria.com 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 fred@sesame.com 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 dude@swim.2birds.com 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 jack@ponderosa.uucp ponderosa:comp.risks/all::rmail jack@ponderosa.uucp # 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.