Restricting NNTP Access

Linux Network Administrators Guide
Назад Глава 22. NNTP и nntpd Daemon Вперед

Ограничение доступа к NNTP

Доступ к ресурсам NNTP управляется файлом nntp_access в /etc/news. Строки в этом файле описывают права доступа, предоставленные удаленным системам. Каждая строка имеет следующий формат:

site read|xfer|both|no post|no [!exceptgroups]

Когда пользователь соединяется с портом NNTP, nntpd пытается получить полное доменное имя машины по его IP-адресу, используя обратный поиск. Hostname пользователя и адрес IP проверяются для поля site каждой записи в том порядке, в который они появляются в файле. Совпадение может быть частичным или точным. Если оно точное, применяются соответствующие определения; если оно частичное, оно применяется только если нет никаких других подходящих соответствий. site может быть определен одним из следующих путей:

Hostname

Полное доменное имя машины. Если оно посимвольно совпало с каноническим hostname клиента, запись применяется, а все остальные записи игнорируются.

IP address

IP-адрес в формате четырех чисел, разделенных точками. Если IP клиента совпадает с этим, запись применяется, и все остальные записи игнорируются.

Domain name

Доменное имя, определенное как *.domain. Если hostname пользователя соответствует имени домена, запись применяется.

Network name

Имя сети, определенное в /etc/networks. Если адрес подсети пользовательского IP-адреса совпадает с адресом подсети, связанным с этим именем сети, запись применяется.

Default

Строка default соответствует всем клиентам.

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

Вторые и третьи поля описывают права доступа, предоставленные пользователю. Второе поле детализирует права на получение новостей (pulling, (read) и их передачу (pushing, (xfer). Значение both разрешает оба действия; no полностью запрещает доступ. Третье поле предоставляет пользователю право регистрировать статьи, то есть, передавать статьи с незавершенной информацией заголовка, который будет завершен программным обеспечением новостей. Если второе поле содержит no, третье поле будет игнорироваться.

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

Пример файла nntp_access:
#
# 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

Назад | Глобальное оглавление | Вперед
Установка сервера NNTP | Локальное оглавление | Авторизация NNTP


IP Accounting

Назад Вперед

Глава 10. IP Accounting

Локальное оглавление
Настройка ядра для IP Accounting
Настройка IP Accounting
Использование результатов IP Accounting
Перезапуск счетчиков
Очистка правил
Пассивные коллекции данных доступа

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

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

Ядро Linux обеспечивает средство, которое позволяет Вам собирать все типы полезной информации относительно сетевого трафика. Это средство названо IP accounting.

Настройка ядра для IP Accounting

Свойство Linux IP accounting очень близко связано с программным обеспечением Linux firewall. Места, в которых Вы хотите собирать данные, те же самые, в которых Вы заинтересованы выполнением firewall-фильтрации: вход и выход сетевой машины и программное обеспечение, которое делает маршрутизацию датаграмм. Если Вы не читали раздел по firewalls, сейчас подходящее время, чтобы это сделать, поскольку мы будем использовать некоторые из понятий, описанных в главе 9.

Чтобы активизировать Linux IP accounting, Вы должны сначала проверить сконфигурировано ли Ваше ядро Linux для этого. Проверьте, существует ли файл /proc/net/ip_acct. Если да, Ваше ядро уже поддерживает IP accounting. Если нет, придется построить новое ядро, гарантируя, что Вы отвечаете “Y” для следующих опций (в версиях 2.0 и 2.2 ядра):
Networking options  --->
    [*] Network firewalls
    [*] TCP/IP networking
    [*] IP: accounting
или в версии 2.4 ядра:
Networking options  --->
    [*] Network packet filtering (replaces ipchains)

Назад | Оглавление | Вперед
A Sample Firewall Configuration |  | Configuring IP Accounting


The active File

Назад Глава 21. C News Вперед

Файл active

Файл active расположен в /etc, перечисляет все группы, известные Вашему серверу, и статьи, доступные в настоящее время. Вы редко будете изменять его, но я объясню это ради законченности. Записи в файле имеют следующую форму:

newsgroup high low perm

newsgroup, конечно, имя группы. low и high задают предельное число статей, доступных в настоящее время. Если ни одна не является доступной в настоящее время, low =high+1.

По крайней мере предполагается, что поле low это хранит. Но, из соображений эффективности, C-News не модифицирует это поле. Это не было бы большой потерей, если бы не имелось программ чтения новостей, которые зависят от этого поля. Например, trn проверяет это поле, чтобы видеть, может ли он очистить свою базу данных статей. Для обновления поля low надо регулярно выполнять команду updatemin (или в более ранних версиях C-News скрипт upact).

perm представляет собой параметр, детализирующий доступ пользователей в зависимости от группы. Он принимает одно из следующих значений:

y

Пользователям разрешают отправлять статьи в эту группу.

n

Пользователям не разрешают отправлять статьи в эту группу. Однако группа может читаться.

x

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

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

m

Это обозначает модерируемую группу. Когда пользователь пробует отправлять статью в эту группу, интеллектуальный newsreader сообщит, какая она, и пошлет статью модератору. Адрес модератора берется из файла moderators в /var/lib/news .

=real-group

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

В C-News, Вы вообще не должны обращаться к этому файлу непосредственно. Группы могут быть добавлены или удалены, используя addgroup и delgroup (см. ниже ). Когда группы добавляются или удаляются для всего Usenet, это обычно делается, посылая сообщение управления newgroup или rmgroup соответственно. Никогда не посылайте такое сообщение самостоятельно! О том, как создавать newsgroup, читайте ежемесячник в news.announce.newusers.

Файл, близко связанный с active, active.times. Всякий раз, когда группа создается, C-News пишет в этот файл сообщение, содержащее имя созданной группы, дату ее создания, было ли это выполнено в соответствии c сообщением управления newgroup или локально, и кто сделал это. Это сделано для удобства программ чтения новостей, которые могут сообщать пользователю о любой недавно созданной группе. Это также используется командой NEWGROUPS протокола NNTP.

Назад | Оглавление | Вперед
Файл sys | Локальное оглавление | Пакетирование статей


Email Addresses

Назад Глава 17. E-Mail Вперед

Адреса Email

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

Способ интерпретации машинного имени зависит от сети, к которой Вы подключены.

RFC-822

Абоненты Internet твердо придерживаются стандарта RFC-822, который требует записи user@host.domain, где host.domain задает полное доменное имя машины назначения. В середине знак @. Поскольку эта запись не включает маршрут до машины адресата, но дает взамен уникальное hostname (имя машины), она называется абсолютным адресом.

Вы увидете, что в Internet использование RFC-822 распространяется не только на почту, а также проникает в другие услуги, например новости. Мы обсудим как RFC-822 используется для новостей в главе 20.

Форматы почтовых адресов

В оригинале среды UUCP распространенная форма была path!host!user (путь!машина назначения! пользователь), где path описывал последовательность машин для достижения машины адресата (host). Эта конструкция называется записью bang path, потому что метка восклицания называется "bang". Сегодня много uucp-подобных сетей приняли стандарт RFC-822 и понимают этот тип адреса.

Другие сети имеют различные способы адресации. Decnet-сети, например, используют два двоеточия как разделитель адресов, производя адрес так: host::user. Стандарт X.400 использует совсем другую схему, описывая получателя (без связи с машиной!) набором пар свойств, например, страна и организация.

В сети FidoNet каждый пользователь идентифицирован кодом, подобным 2:320/204.9, состоящим из четырех чисел, обозначающих: зону (2 для Европы), сеть (320 для Парижа), узел и указатель (машину индивидуального пользователя). Fidonet-адреса могут быть отображены на RFC-822; вышеупомянутое написали бы как Thomas.Quinot@p9.f204.n320.z2.fidonet.org.

Два формата почтовых адресов

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

Основная проблема: смшивание UUCP стиля bang-path и формата RFC-822. Эти два типа адресации соединить не так-то просто. Допустим, есть адрес domainA!user@domainB. Неизвестно, что важнее: знак @ или путь. Другими словами: мы должны послать сообщение на domainB, который отправляет его на domainA!user, или письмо надо послать domainA, который отошлет его user@domainB?

Адреса, в которых операторы адресации смешаны, называются гибридными (hybrid addresses). В только что приведенном примере считается, что знак @ важнее пути. Запись domainA!user@domainB означает послать сообщение сначала на domainB.

Имеется способ определить маршруты RFC822-совместимыми способами: <@domainA,@domainB:user@domainC > обозначает адрес пользователя user в домене domainC, где domainC должен быть достигнут через domainA и domainB (именно в этом порядке!). Этот тип адресов часто называется адресом, направленным источником (source routed). Положиться на это поведение не очень хорошая идея, поскольку изменения в RFC, описывающие маршрутизацию почты, рекомендуют, чтобы маршрутизация источника в адресе почты игнорировалась, а взамен должна быть сделана попытка доставить письмо непосредственно удаленному адресату.

Когда имеется оператор адреса % (например, user%domainB@domainA), письмо будет сначала послано domainA, который превратит знак процента в знак @. Теперь адрес user@domainB, и почтовая программа передаст Ваше сообщение на domainB, который перешлет его пользователю user. Этот тип адреса иногда упоминается как "Ye Olde ARPAnet Kludge" и его использование не приветствуется. Однако, много средств транспортировки почты генерируют этот тип адреса.

Но лучше всего использовать адрес именно в виде абсолютного адреса RFC-822 user@host.domain, если это позволяет Ваша система.

Назад | Глобальное оглавление | Вперед
How Is Mail Delivered? | Локальное оглавление | How Does Mail Routing Work?


Assigning IP Addresses

Назад Глава 5. Настройка TCP/IP Вперед

Установка IP-адресов

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

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

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

При выборе сетевого IP-адреса многое зависит от того, предполагаете ли Вы выходить в Internet в ближайшем будущем. Если да, получите официальный IP-адрес сейчас, чтобы потом не перенастраивать систему. Попросите, чтобы Ваш провайдер помог Вам. Если Вы хотите получить сетевой адрес на всякий случай, запросите Сетевое Заявление: анкету адреса с hostmaster@internic.net или Network Information Center Вашей страны, если он имеется.

Если Ваша сеть не связана с Internet и не будет связана в ближайшем будущем, Вы свободны выбрать любой допустимый сетевой адрес. Только убедитесь, что никакие пакеты не могут из Вашей сети попасть в Internet! Чтобы быть уверенным в том, что даже в случае их попадания в Internet, они не создадут проблем, используйте один из сетевых адресов, зарезервированных для частного использования. Internet Assigned Numbers Authority (IANA) отложил несколько сетевых адресов из классов A, B и C, которые Вы можете использовать без регистрации. Эти адреса имеют силу только внутри частной сети и непригодны для сетевого взаимодействия в Internet. Они определены в RFC 1597 и перечислены в таблице 2-1 в главе 2. Обратите внимание, что вторые и третьи блоки содержат 16 и 256 подсетей соответственно.

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

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

Назад | Глобальное оглавление | Вперед
Установка Hostname | Локальное оглавление | Создание подсетей


Example Network:The Virtual Brewery

Назад Вперед

Приложение A. Пример сети: The Virtual Brewery

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

The Virtual Brewery представляет собой маленькую компанию. Чтобы управлять их бизнесом более эффективно, они хотят подключить к сети их компьютеры. Рисунок A-1 показывает сетевую конфигурацию.

На том же этаже есть другая фирма Virtual Winery, которая является дружественной к The Virtual Brewery. Там уже есть сеть Ethernet. Обе компании хотят связать свои сети в одно целое. Как первый шаг, они хотят установить шлюз, который будет обеспечивать обмен пакетами между этими подсетями. Позже они хотят сделать UUCP-связь с внешним миром, через которую будет ходить почта и новости. В конечном счете, они также хотят установить PPP-подключения, чтобы соединяться с удаленными офисами и иметь доступ к Internet.

The Virtual Brewery и Virtual Winery имеют по подсети класса C в сети класса B, и шлюз на компьютере vlager, который также поддерживает UUCP-подключение. Рисунок A-2 показывает конфигурацию.

Рисунок A-1. Подсети The Virtual Brewery и Virtual Winery

Рисунок A-2. Сеть The Virtual Brewery

Соединение с Virtual Subsidiary Network

Теперь The Virtual Brewery подросла и открыла представительство в другом городе. Подразделение имеет сеть Ethernet с собственным сетевым IP-адресом 172.16.3.0, которая является третьей подсетью из сети Brewery (класса B). Главный компьютер vlager действует как шлюз для сети Brewery и будет поддерживать связь PPP; соответствующая ему машина в другом городе называется vbourbon и имеет IP-адрес 172.16.3.1. Сеть показана на рисунке A-2.

Назад | Глобальное оглавление | Вперед
Настройка nn |  | Конфигурации кабелей


ImportantNetwork Features

Назад Вперед

Глава 12. Важные сетевые возможности

Локальное оглавление
Суперсервер inetd
Контроль доступа с помощью tcpd
Файлы services и protocols
Процедура удаленного вызова (Remote Procedure Call)
Настройка удаленного выполнения

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

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

Суперсервер inetd

Часто услуги предоставляются так называемыми демонами (daemons). Daemon является программой, которая открывает некоторый порт и ждет входящих соединений. Если происходит соединение, программа создает дочерний процесс, который обрабатывает соединение в то время, как основной процесс продолжает ждать дальнейших запросов. Этот подход имеет тот недостаток, что для каждого предлагаемого сервиса daemon должен быть свой. А они занимают ресурсы системы пока ждут соединения.

Таким образом, почти все версии Un*x запускают "суперсервер", который создает сокеты для ряда услуг и слушает их одновременно при использовании системного вызова select(2). Когда отдаленный хост запрашивает одну из услуг, суперсервер замечает это и порождает другой сервер, установленный для этого порта, а сам продолжает слушать соединения.

Обычно используется суперсервер inetd, Internet Daemon. Он запускается при начальной загрузке системы и берет список услуг, к которым он обращается из файла запуска /etc/inetd.conf . В дополнение к вызываемым серверам там есть ряд тривиальных услуг, которые являются внутренними сервисами inetd. Они включают chargen, который просто генерирует ряд знаков и daytime, который возвращает время.

Каждая запись в файле /etc/inetd.conf состоит из единственной строки, состоящей из следующих полей:

service type protocol wait user server cmdline

Значения полей:

service
Задает имя сервиса. Service name должно быть переведено в номер порта с помощью файла /etc/services . Этот файл будет описан в соответствующем разделе.
type
Определяет тип сокета: stream (для протоколов, ориентированных на соединение) или dgram (для датаграмных протоколов). TCP-сервисы должны всегда использовать stream, в то время как UDP-услуги должны всегда использовать dgram.
protocol
Задает транспортный протокол для этого сервиса. Это поле должно быть подходящим названием протокола, найденным в файле protocols.
wait
Эта опция применяется только на dgram. Это может быть wait или nowait. Если определен wait, то inetd выполняет одновременно только один сервер для порта. Иначе после запуска сервера он немедленно продолжит слушать порт. Это полезно для серверов, которые читают все входящие датаграммы и завершают работу. Большинство RPC-серверов имеет этот тип и должны определять wait . Противоположный тип, "многопоточные" серверы, могут быть запущены в нескольких копиях, но это редко используется. Эти серверы должны определять nowait. Сокеты stream должны всегда использовать nowait.
user
Это поле является идентификатором пользователя, от имени которого работает сервис. Часто это будет root, но некоторые сервисы могут применять различных пользователей. Это очень хорошая идея применения принципа наименьшего количества привилегий, который заявляет, что Вы не должны запускать команду от имени привилегированного пользователя, если программа не требует этого для функционирования. Для примера, NNTP (сервер новостей) будет запущен от имени news, а сервисы, вызывающие возможное нарушение защиты (tftp или finger), будут работать как nobody.
server
Задает полный путь к программе сервера, который будет выполнен. Внутренние сервисы помечаются ключевым словом internal.
cmdline
Командная строка, которую нужно выполнить на сервере. Она включает аргумент 0, который является именем команды. Обычно это не будет именем программы сервера, если программа ведет себя по-разному, когда вызывается с различными именами. Это поле пусто для внутренних сервисов.

Пример файла inetd.conf показан в примере 12-1. Сервис finger закомментирован, чтобы он не был доступен. Это часто делается из соображений безопасности, потому что может использоваться нападающими для того, чтобы получить имя пользователя на Вашей системе.

Пример 12-1. Типовой файл /etc/inetd.conf

#
# 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

tftp также закомментирован. tftp осуществляет примитивный протокол передачи файлов ( Trivial File Transfer Protocol), который позволяет передавать любые общедоступные файлы из Вашей системы без пароля. Это особенно вредно для файла /etc/passwd, даже более того, когда Вы не используете теневой пароль.

TFTP обычно используется бездисковыми клиентами и X-терминалами при загрузке их кода с сервера при начальной загрузке. Если Вы должны запустить tftpd, удостоверьтесь, что область доступа к директориям клиентов будет строго ограничена. Это показано во второй строке для tftp, в примере.

Назад | Глобальное оглавление | Вперед
Еще о сетевой трансляции адресов (Network Address Translation) |  | Контроль доступа с помощью tcpd


Address Resolution

Назад Глава 2. Настройка сети TCP/IP Вперед

Преобразование адресов

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

Необходим механизм, чтобы отобразить адреса IP на адреса основной сети. Используемый механизм Address Resolution Protocol (ARP, протокол преобразования адресов). Фактически, ARP не ограничен сетями Ethernet или Token Ring, он используется и на других типах сетей, типа любительского радио протокола AX.25. Идея, лежащая в основе ARP, точно такая, какую большинство людей использует, когда они должны найти человека X в толпе из 150 людей: человек, который хочет его видеть, зовет достаточно громко, чтобы каждый в толпе мог его услышать, а тот, кого зовут, отвечает. Когда он отвечает, мы узнаем, который человек нам нужен.

Когда ARP хочет найти адрес Ethernet, соответствующий данному IP-адресу, он использует свойство Ethernet под названием broadcasting, в котором пакеты адресуются всем машинам в сети одновременно. Пакет, который посылает ARP, содержит запрос IP-адреса. Каждый компьютер, получивший запрос, сравнивает его содержимое с собственным IP-адресом и, если он совпадает с указанным в запросе, возвращает ответ. Запрашивающий компьютер может теперь извлекать адрес Ethernet из ответа.

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

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

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

Назад | Глобальное оглавление | Вперед
IP-адреса | Локальное оглавление | IP-маршрутизация


NNTP Authorization

Назад Глава 22. NNTP и nntpd Daemon Вперед

Авторизация NNTP

Демон nntpd предоставляет простую схему авторизации. Если Вы печатаете прописными буквами любую из лексем доступа в файле nntp_access file, nntpd требует авторизации пользователя для соответствующей операции. Например, при определении разрешения Xfer или XFER, (в противоположность xfer), nntpd не будет позволять статьям попадать на Ваш сайт без авторизации.

Процедура авторизации выполнена посредством новой команды NNTP AUTHINFO. При использовании этой команды, пользователь передает username (имя пользователя) и его пароль на NNTP-сервер. nntpd проверяет их по файлу /etc/passwd. Проверяется также принадлежность пользователя к группе nntp.

Текущая реализация NNTP-авторизации только экспериментальная и не была выполнена очень универсальной. Результат этого в том, что авторизация работает только с базами данных паролей с простым стилем; теневые пароли не распознаются. Если Вы компилируете пакет из исходных текстов и имеете установленный пакет PAM, проверка пароля довольно проста, чтобы изменить ее.

Назад | Глобальное оглавление | Вперед
Ограничение доступа к NNTP | Локальное оглавление | Взаимодействие nntpd с C-News


Article Batching

Назад Глава 21. C-News Вперед

Упаковка статей

Упаковщик новостей использует специфический формат, который является одним и тем же для B-news, C-News и INN. Каждой статье предшествует строка:
#! rnews count

count Где count задает число байтов в статье. Когда используется пакетное сжатие, возникающий в результате файл сжат в целом и содержать другую строку в соответствии c сообщением, которое нужно использовать для распаковки. Стандартное средство сжатия compress, которое отмечен как
#! cunbatch

Иногда при необходимости посылать пакеты через программное обеспечение почты, которое удаляет восьмой бит всех данных, сжатый пакет может быть защищен, используя c7-encoding;; эти пакеты будут отмечены как c7unbatch.

Когда пакет приходит на удаленную машину, rnews проверяет эти маркеры и обрабатывает пакет соответственно. Некоторые абоненты также используют другие инструментальные средства сжатия, подобные gzip. Такие файлы будут помечены как zunbatch. C-News не распознает подобные ненормативные заголовки; Вы должны изменить исходный код, чтобы поддерживать их.

В C-News пакетирование статьи выполняется командой /usr/lib/news/batch/sendbatches, которая берет список статей из файла site/togo и помещает их в отдельный newsbatches. Это должно быть выполнено раз в час или даже более часто, в зависимости от объема трафика. Операция управляется файлом batchparms в /var/lib/news . Этот файл описывает максимальный размер пакета для каждого сервера, программу пакетирования, необязательную программу сжатия и транспорт для доставки к этому удаленному серверу. Вы можете определять параметры пакетирования, также как набор заданных по умолчанию параметров для абонента.

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

site size max batcher muncher transport

site

site имя сервера, для которого применяется запись. Файл togo для этого сервера должен постоянно находится в out.going/togo. Имя /default/ обозначает заданный по умолчанию сервер.

size

size максимальный размер созданных пакетов статей (перед сжатием). Для одиночных статей больших, чем этот размер, C-News делает исключение и помещает их в одиночный пакет.

max

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

C-News определяет число поставленных в очередь пакетов, используя скрипт queuelen в /usr/lib/news . Если вы установили C-News в формате prepackaged, скрипт не должен нуждаться в редактировании, но если Вы должны использовать другую разновидность spool-каталогов, например, Taylor UUCP, Вам может быть необходимо написать Ваш собственный. Если Вы не заботитесь относительно числа spool-файлов (например, Вы единственный пользователь данного компьютера, и Вы не пишете статьи по мегабайту каждая), Вы можете заменить содержимое скрипта просто на команду exit 0.

batcher

Поле batcher содержит команду, используемую для создания пакета из списка статей в файле togo. Обычно это batcher. Для других целей можно использовать альтернативные команды. Например, протокол ihave/sendme требует, чтобы список статей был превращен в сообщения управления ihave или sendme, которые зарегистрированы в группе новостей to.site . Это выполняется batchih и batchsm.

muncher

Поле muncher определяет команду, используемую для сжатия. Обычно это compcun, команда, которая создает сжатый пакет. В качестве альтернативы, Вы могли бы использовать muncher, который использует gzip, скажем gzipcun. Вы должны удостовериться, что распаковщик на удаленном сервере исправлен так, чтобы распознать файлы, сжатые gzip .

Если удаленный сайт не имеет команды распаковки uncompress, Вы можете определить nocomp, который не выполняет сжатие.

transport

Последнее поле, transport, описывает транспорт, который нужно использовать. Доступно несколько стандартных команд для различных транспортов, чьи имена начинаются с via. sendbatches передает им имя машины адресата в командной строке. Если запись batchparms не /default/, sendbatches получает имя машины из поля site, удаляя все последующее, включая первую точку или наклонную черту вправо. Если запись batchparms была /default/, используются имена каталогов в out.going.

Чтобы выполнять пакетирование для специфического сервера, Вы вызываете это как:
# su news -c "/usr/lib/news/batch/sendbatches site"

Когда вызов происходит без аргументов, sendbatches обрабатывает все пакетные очереди. Интерпретация понятия “все” зависит от присутствия заданной по умолчанию записи в batchparms. Если она найдена, проверяются все каталоги в /var/spool/news/out.going, иначе циклически просматриваются все записи в batchparms. Обратите внимание, что sendbatches при просмотре каталога out.going берет только те каталоги, которые не содержат точку или знак @ как имя сервера.

Имеются две команды, которые используют uux, чтобы выполнить rnews на удаленной системе; viauux и viauuxz. Последняя устанавливает флаг –z для того, чтобы отменить сообщения об успехе для каждой переданной статьи. Другая команда, viamail, посылает пакеты статей пользователю rnews в удаленной системе по почте. Полный список транспорта есть на man-странице newsbatch.

Все команды из последних трех полей нужно расположть или в out.going/site, или в /usr/lib/news/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

Назад | Глобальное оглавление | Вперед
Файл active | Локальное оглавление | Выдыхающиеся новости


Installing the Binaries

Назад Глава 5. Настройка сети TCP/IP Вперед

Установка исполняемых модулей

Если Вы используете один из готовых дистрибутивов Linux, которые сейчас расплодились в огромном количестве, он просто обязан включать в себя набор простых сетевых приложений и примеры файлов настройки. Единственный случай, в котором Вам, может быть, придется получать и устанавливать новые утилиты, это когда Вы устанавливаете новую версию ядра. Поскольку они иногда включают изменения работы с сетями на ядерном уровне, Вы будете должны модифицировать базисные инструментальные средства конфигурации. Эта модификация включает по крайней мере перекомпиляцию, но иногда может также потребоваться получить последний набор всех утилит. Эти наборы доступны на их официальном сайте ftp.inka.de/pub/comp/Linux/networking/NetTools/, в архивах с именами вида: net-tools-XXX.tar.gz, где XXX задает номер версии. Для Linux 2.0 подходит net-tools-1.45.

Если Вы хотите компилировать и устанавливать сетевые прикладные программы стандарта TCP/IP самостоятельно, Вы можете получать их исходные тексты с большинства Linux FTP серверов. Все современные дистрибутивы Linux включают богатый набор сетевых прикладных программ TCP/IP, например, браузеры World Wide Web, программы telnet и ftp и второстепенные сетевые утилиты, вроде talk. Все это компилируется довольно просто, при условии пунктуального следования инструкциям в пакете исходного кода.

Назад | Глобальное оглавление | Вперед
Настройка сети TCP/IP | Локальное оглавление | Установка Hostname


A Serial NULL Modem Cable

Назад Приложение B. Конфигурация кабелей Вперед

Нуль-модемный кабель

Последовательный нуль-модемный кабель будет работать для SLIP и PPP. Снова Вам понадобятся два соединителя DB-25. На сей раз Ваш кабель требует только восьми проводников.

Вы, возможно, видели другие схемы таких кабелей, но этот позволяет Вам использовать аппаратное управление потоком данных, что гораздо лучше XON/XOFF управления данными. Конфигурация кабеля показана на рисунке B-2:

Снова, если Вы имеете экранировку, Вы должны подключить ее к первому штырьку только на одном конце.

Рисунок B-1. Кабель PLIP

Рисунок B-2. Нуль-модемный кабель

Назад | Глобальное оглавление | Вперед
Конфигурация кабелей | Локальное оглавление | Информация об авторских правах


Useful Cable Configurations

Назад Вперед

Приложение B. Конфигурация кабелей

Локальное оглавление
Кабель PLIP
Нуль-модемный кабель

Если нужно соединить два компьютера, а сети Ethernet рядом нет, сойдет обычный нуль-модемный кабель или кабель PLIP.

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

Кабель PLIP

Чтобы сделать кабель PLIP, нужно два 25-контактных соединителя (называются DB-25) и кабель с по крайней мере одиннадцатью проводниками. Кабель не должен быть длиннее 15 метров (50 футов). Кабель может иметь экранировку, что в общем случае необязательно, но если Вы формируете длинный кабель, это, вероятно, хорошая идея.

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

Все остающиеся штырьки остаются свободными. Если кабель имеет экранировку, экран должен быть связан с металлической оболочкой соединителя DB-25 только на одном конце!

Назад | Глобальное оглавление | Вперед
Пример сети: The Virtual Brewery |  | Нуль-модемный кабель


Testing a Firewall Configuration

Назад Глава 9. TCP/IP Firewall Вперед

Проверка конфигурации Firewall

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

Более быстрый и простой метод доступен в реализации Linux firewall. Он позволяет Вам вручную генерировать тесты и выполнять их через firewall точно так, как если бы Вы проверяли их с фактическими пакетами. Все варианты поддержки firewall ядром Linux (ipfwadm, ipchains и iptables) обеспечивают поддержку для этого стиля тестирования. Реализация включает использование соответствующей команды check.

Общая процедура теста следующая:

  1. Выберите тип firewall для использования: ipfwadm, ipchains или iptables.

  2. Разработайте ряд тестов, которые определят, работает ли ваш firewall так, как нужно. Для этих тестов Вы можете использовать любой источник или адрес отправителя, так что выберите комбинации адресов, которые должны быть приняты и другие, которые должны быть отвергнуты. Если Вы принимаете или отвергаете только некоторые диапазоны адресов, хорошей идеей будет проверить адреса с обеих сторон границы диапазона: по одному внутри границы и снаружи. Это будет гарантировать, что Вы имеете правильные границы, потому что иногда просто определить неправильную маску подсети в конфигурации. Если Вы фильтруете в соответствии с протоколом и номером порта, тесты должны также проверить все важные комбинации этих параметров. Например, если Вы предполагаете принимать только TCP-пакеты, проверьте, что UDP-пакеты отклоняются.

  3. Разработайте правила для ipfwadm, ipchains или iptables, чтобы выполнить каждый тест. Вероятно, стоит записать все правила в скрипт, так что Вы можете проверять и перепроверять все без проблем по мере исправления ошибок или изменений проекта. Тесты используют почти тот же самый синтаксис, поскольку определяют правила, но в качестве параметров берут немного другие значения. Например, исходный параметр адреса в спецификации правила определяет исходный адрес, с которого должен придти пакет, который будет соответствовать этому правилу. Исходный параметр адреса в синтаксисе теста, напротив определяет исходный адрес тестового пакета, который будет сгенерирован. Для ipfwadm Вы должны использовать опцию -c, чтобы определить, что эта команда является тестом, в то время как для ipchains и iptables Вы должны использовать опцию -C. Во всех случаях Вы должны всегда определять исходный адрес, адрес получателя, протокол и интерфейс, которые нужно использовать для теста. Другие параметры, типа номера порта или битов TOS, являются факультативными.

  4. Выполните каждую команду теста и обратите внимание на вывод. Вывод каждого теста будет одним словом, указывающим конечного адресата пакета после его прохождения через firewall. Для ipchains и iptables определенные пользователем цепочки будут проверены в дополнение к встроенным.

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

А теперь практика! Напишем тест правил для ipchains. Наша локальная сеть в примере имеет адрес 172.16.1.0 с маской сети 255.255.255.0. Мы разрешаем внешние TCP-соединения с нашими web-серверами. Ничего больше не должно работать напрямую. Начнем с передачи, которая точно должна работать (из нашей локальной сети):
# ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted

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

Теперь попробуйте другой тест, на сей раз с исходным адресом, который не принадлежит нашей сети. Этот должен быть отклонен:
# ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied

Попробуйте несколько больше тестов, на сей раз с теми же самыми деталями, что и в первом тесте, но с различными протоколами. Они должны быть отклонены:
# ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied
# ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied

Попробуйте другой порт адресата, снова ожидая, что этот пакет должен быть отклонен:
# ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied

Конечно, полная проверка дело трудное и долгое, порой столь же трудное, как и разработка правильной конфигурации firewall, но зато защита будет действительно надежной!

Назад | Глобальное оглавление | Вперед
Управление битами TOS | Локальное оглавление | Пример конфигурации firewall


C-News

Назад Вперед

Глава 21. C-News

Локальное оглавление
Доставка новостей
Установка
Файл sys
Файл active
Упаковка статей
Устаревшие новости
Прочие файлы
Сообщения Control
C-News и NFS
Задачи управления и поддержки

Одним из наиболее популярных пакетов программ для Netnews является C-News. Он было разработан для сайтов, которые работают с новостями через UUCP.

C-News хранит файлы настроек в /etc/news, большинство исполняемых модулей лежит в иерархии /usr/lib/news. Статьи хранятся в иерархии /var/spool/news. Все файлы в этих каталогах должны принадлежать пользователю news или группе news. Большинство проблем возникает из-за того, что C-News не имеет прав доступа к своим файлам. Прежде чем что-то править в них, используйте команду su, чтобы стать пользователем news. Исключением является программа setnewsids, которая используется для установки реального user ID для программ работы с новостями. Она должна принадлежать пользователю root и иметь бит setuid.

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

Доставка новостей

Статьи могут быть поданы C-News разными способами. Когда локальный пользователь отправляет по почте статью, newsreader (программа для работы с новостями) обычно вручает ее команде inews, которая заполняет информацию заголовка. Новости от отдаленного абонента, будь это одиночная статья или целый пакет, передаются команде rnews , которая сохраняет их в каталоге /var/spool/news/in.coming, откуда они будут подняты в более позднее время программой newsrun. Любым из этих двух методов статья будет в конечном счете вручена команде relaynews .

Для каждой статьи команда relaynews проверяет, была ли статья уже замечена на локальной машине, для чего ищет id сообщения в файле хронологии (history). Копии статьи будут пропущены. Затем relaynews рассматривает строку заголовка Newsgroups:, чтобы выяснить, запрашивает ли локальная машина статьи из любой из этих групп. Если она это делает, и группа новостей перечислена в файле active, relaynews пробует сохранить статью в соответствующем каталоге в области хранения новостей. Если этот каталог не существует, он будет создан. Id сообщения статьи будет зарегистрирован в файле history. В противном случае relaynews пропускает статью.

Если relaynews будет не в состоянии сохранить входящую статью, потому что группа, в которой она была зарегистрирована, не перечислена в вашем файле active, статья будет перемещаться в группу junk. relaynews также проверит старые или статьи без дат и уничтожит их. Входящие пакеты, которые терпят неудачу по любой другой причине, перемещаются в /var/spool/news/in.coming/bad , и регистрируется сообщение об ошибках.

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

C-News обычно используется, чтобы передавать новости между UUCP-машинами, хотя можно использовать его и в NNTP-среде. Чтобы доставить новости на удаленную UUCP-машину делается следующее: используется uux для вызова на удаленной машине команды rnews с последующей перекачкой статьи или набора статей на эту машину. Подробно UUCP рассматривается в главе 16.

Когда удаленный сайт поддерживает пакетирование, C-News не рассылает статьи поштучно, а добавляет имена их файлов в некий файл, обычно out.going/site/togo. Периодически из crontab вызывается программа пакетирования, которая записывает статьи в файл, сжимает их, если это задано, и отправляет rnews на удаленной машине.

Назад | Глобальное оглавление | Вперед
Как Usenet обрабатывает новости? |  | Установка


C News in an NFS Environment

Назад Глава 21. C-News Вперед

C-News и NFS

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

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

C-News обрабатывает эту конфигурацию прозрачно для пользователя. Когда Вы регистрируете статью, Ваш пакет работы с новостями обычно вызывает inews, чтобы ввести статью в систему новостей. Эта команда выполняет ряд проверок статьи, заполняет ее заголовок и проверяет файл server в /etc/news. Если этот файл существует и содержит имя, отличное от имени локального компьютера, inews вызывается на удаленном компьютере через rsh. Так как скрипт inews использует ряд исполняемых модулей и файлов поддержки из C-News, Вы должны иметь C-News на локальной машине или монтировать программное обеспечение новостей по сети.

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

Удостоверьтесь, что имя сервера в server буквально соответствует выводу команды hostname на сервере. Иначе C-News зациклится навсегда при попытке доставить статью. NFS подробно обсуждется в главе 14.

Назад | Глобальное оглавление | Вперед
Сообщения Control | Локальное оглавление | Задачи управления и поддержки


Using the Configuration Utilities

Назад Глава 4. Настройка последовательного оборудования Вперед

Использование программ настройки

Рассмотрим две наиболее полезных утилиты конфигурации последовательных устройств: setserial и stty.

Команда setserial

Ядро при запуске само пытается определить настройки устройств, но из-за их большого разнообразия это не всегда возможно. Хороший пример того, где это является проблемой, внутренние модемы, о которых мы говорили ранее. UART, который они используют, имеет 16-байтовый буфер FIFO, но он похож на UART 16450. Если мы определенно не сообщаем драйверу, что этот порт является устройством UART 16550, ядро не будет использовать расширенный буфер. Еще одним примером являются четырехпотровые карты, которые позволяют поделить один IRQ между несколькими устройствами. Нам, вероятно, придется сообщать ядру, который IRQ-порт предполагается использовать, и что IRQ может быть разделен несколькими устройствами.

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

Общий синтаксис для команды setserial:
setserial device [parameters]
Здесь device является одним из последовательных устройств, типа ttyS0.

Команда setserial имеет большое количество параметров. Наиболее важные из них описаны в таблице 4-1. Остальные можно найти на man-странице по setserial.

Таблица 4-1. Параметры командной строки для setserial

Параметр | Описание
port port_number | Определяет адрес порта ввода-вывода последовательного устройства. Должен быть определен в шестнадцатеричной записи, например, 0x2f8.
irq num | Определяет прерывание, используемое последовательным устройством.
uart uart_type | Определяет тип UART последовательного устройства. Общие значения 16450, 16550 и т.д. Установка этого значение в none не отключит это последовательное устройство.
fourport | Задание этого параметра инструктирует последовательный драйвер ядра, что этот порт является одним из портов платы AST Fourport.
spd_hi | Предписывает UART использовать быстродействие 57.6 kbps, когда процесс запрашивает 38.4 kbps.
spd_vhi | Предписывает UART использовать быстродействие 115 kbps, когда процесс запрашивает 38.4 kbps.
spd_normal | Предписывает UART использовать заданное по умолчанию быстродействие 38.4 kbps, когда запрашивается. Этот параметр используется, чтобы отменить эффект spd_hi или spd_vhi на определенном последовательном устройстве.
auto_irq | Этот параметр заставит ядро сделать попытку автоматически определить IRQ определенного устройства. Эта попытка не может быть полностью надежной, так что, вероятно, лучше думать об этом как о просьбе к ядру предположить IRQ. Если Вы знаете IRQ этого устройства, Вы должны определить его, используя параметр irq.
autoconfig | Это параметр должен быть определен вместе с параметром port. Когда этот параметр задан, setserial инструктирует ядро сделать попытку автоматически определить тип UART на порте с заданным адресом. Если параметр auto_irq также задан, ядро попытается автоматически определить IRQ.
skip_test | Отменяет автоопределение типа UART. Полезен, если ядро определяет его неправильно.

Типичный и простой файл rc для настройки Ваших последовательных портов при начальной загрузке показан в примере 4-1. Большинство дистрибутивов Linux включают более сложные файлы.

Пример 4-1. Образец файла rc.serial

# /etc/rc.serial - serial line configuration script.
#
# Configure serial devices
/sbin/setserial /dev/ttyS0 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS1 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS2 auto_irq skip_test autoconfig
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
#
# Display serial device configuration
/sbin/setserial -bg /dev/ttyS*

Команда /sbin/setserial -bg /dev/ttyS* в последней строке будет печатать аккуратно форматируемое резюме аппаратной конфигурации всех активных последовательных устройств. Образец такого вывода показан в примере 4-2 .

Пример 4-2. Вывод команды setserial -bg /dev/ttyS Command

/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A

Команда stty

Имя stty, возможно, произошло от сокращения "set tty", но команда stty может также использоваться, чтобы отобразить конфигурацию терминала. Возможно, даже больше, чем setserial, команда stty обеспечивает изумительное число характеристик, которые Вы можете легко настроить. stty обычно используется, чтобы конфигурировать параметры терминала, типа того, будут ли символы отображены на экране, или какая клавиша должна генерировать сигнал прерывания. Мы объяснили ранее, что последовательные устройства являются tty-устройствами, а значит, команда stty применима к ним.

Одно из важнейших применений stty заключается в управлении аппаратным подтверждением связи на устройстве. Мы кратко говорили ранее относительно аппаратного подтверждения связи. Значение по умолчанию конфигурация для последовательных устройств: аппаратное подтверждение заблокировано. Эта установка позволяет работать последовательным кабелям “three wire”. Они не поддерживают необходимые сигналы для аппаратного подтверждения связи, и если оно включено по умолчанию, они будут не способны передать сигнал, чтобы изменить это.

Удивительно, но некоторые программы не допускают аппаратное подтверждение связи, так что если Ваш модем эту функцию поддерживает, Вы должны конфигу- рировать его так, чтобы ее использовать (проверьте руководство по модему, чтобы узнать, какую команду применить) и сконфигурировать последовательное устройство, чтобы учитывать это подтверждение. Команда stty имеет параметр crtscts, который включает аппаратное подтверждение связи на устройстве. Вам придется использовать его. Команда лучше всего должна быть выдана из rc.serial файла (или его эквивалента) при начальной загрузке. Образец показан в примере 4-3.

Пример 4-3. Файл rc.serial с командами stty

#
stty crtscts < /dev/ttyS0
stty crtscts < /dev/ttyS1
stty crtscts < /dev/ttyS2
stty crtscts < /dev/ttyS3
#

Команда stty работает на текущем терминале, но используя переадресацию ввода ("<"), мы можем с помощью stty управлять любым tty-устройством. Про символы "<" или ">" регулярно забывают. Новые версии stty имеют более удачный синтаксис для таких задач. Чтобы использовать новый синтаксис, я переписал мой пример настройки. Новую его версию можно посмотреть в примере 4-4.

Пример 4-4. Файл rc.serial с командами stty (новый синтаксис)

#
stty crtscts -F /dev/ttyS0
stty crtscts -F /dev/ttyS1
stty crtscts -F /dev/ttyS2
stty crtscts -F /dev/ttyS3
#

Я упомянул, что команда stty может использоваться, чтобы отобразить параметры конфигурации терминала tty-устройства. Чтобы отобразить все активные параметры настройки на tty-устройстве, скомандуйте:

$ stty -a -F /dev/ttyS1

Вывод этой команды показан в примере 4-5, Он дает Вам состояние всех параметров для этого устройства. Параметр, показанный с предшествующим минусом, как в -crtscts, означает, что данное свойство выключено.

Пример 4-5. Вывод команды stty -a

speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
        eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
        werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
        -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
         bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
         -echoprt echoctl echoke

Описание наиболее важных из этих параметров дано в таблице 4-2. Каждый параметр может быть включен командой stty или выключен командой stty с символом - перед этим параметром. Таким образом, чтобы отключить аппаратное подтверждение связи на ttyS0, используется:
$ stty -crtscts -F /dev/ttyS0

Таблица 4-2. Параметры stty для настройки последовательных устройств

Параметр | Назначение
N | Устанавливает быстродействие линии в N бит в секунду.
crtsdts | Включить/выключить аппаратное подтверждение связи.
ixon | Включить/выключить XON/XOFF управление потоком.
clocal | Включить/выключить сигналы управления модема типа DTR/DTS и DCD. Это необходимо, если Вы используете последовательный кабель "three wire", поскольку он не обеспечивает эти сигналы.
cs5 cs6 cs7 cs8 | Установить число бит данных соответственно в 5, 6, 7 или 8.
parodd | Включить проверку на нечетность. Отключение этого параметра включает проверку на четность.
parenb | Включить проверку четности. Когда этот параметр выключен, контроль четности или нечетности не используется.
cstopb | Включить использование двух стоп-бит на символ. Когда этот параметр выключен, используется один стоп-бит на символ.
echo | Включить/выключить повторение полученных символов обратно отправителю.

Следующий пример объединяет некоторые из этих параметров и устанавливает устройство ttyS0 на 19,200 bps, 8 бит данных, без контроля четности, но с аппаратным подтверждением связи с заблокированным ECHO-отбражением:
$ stty 19200 cs8 -parenb crtscts -echo -F /dev/ttyS0

Назад | Глобальное оглавление | Вперед
Последовательное оборудование | Локальное оглавление | Последовательное оборудование и запрос login:


UUCP Configuration Files

Назад Глава 16. Управление Taylor UUCP Вперед

Файлы настройки UUCP

В отличие от более простых программ передачи файлов, UUCP был разработан, чтобы обрабатывать все передачи автоматически. Если только все установлено правильно, ежедневное вмешательство администратора не требуется. Вся необходимая информация сохраняется в паре файлов конфигурации, которые постоянно находятся в каталоге /usr/lib/uucp. Большинство этих файлов используется только при внешнем запросе снаружи.

Введение в Taylor UUCP

Сказать, что конфигурация UUCP является тяжелой, было бы замалчиванием фактов. Это, действительно, запутанная тема, и иногда краткий формат файлов конфигурации не делает вещи проще (хотя формат Talyor читается очень просто по сравнению с более старыми форматами в HDB или Version 2).

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

Все файлы, описанные в этом разделе хранятся в /etc/uucp или в его подкаталогах. Некоторые дистрибутивы Linux содержат код UUCP, который поддерживает HDB и Taylor конфигурации, и используют различные подкаталоги для каждого набора файлов конфигурации. Обычно есть файл README в каталоге /usr/lib/uucp.

Чтобы UUCP работал правильно, эти файлы должны принадлежать пользователю uucp. Некоторые из них содержат пароли и номера телефона, и следовательно, должны иметь права доступа 600. Обратите внимание, что хотя большинство команд UUCP должно иметь бит setuid на имя uucp, Вы должны удостовериться, что программа uuchk такого бита не имеет. Иначе, пользователи будут способны отобразить пароли системы даже при том, что файлы имеют режим доступа 600.

Центральный файл конфигурации UUCP называется /etc/uucp/config. Он используется, чтобы установить общие параметры. Наиболее важный из них (и теперь единственный), является именем UUCP Вашей системы. Для нашей модельной сети Virtual Brewery использован vstout в качестве шлюза UUCP:

# /etc/uucp/config - UUCP main configuration file
nodename         vstout

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

# /usr/lib/uucp/sys - name UUCP neighbors
# system: pablo
system          pablo
time            Any
phone           555-22112
port            serial1
speed           38400
chat            ogin: vstout ssword: lorca

Ключевое слово port задает порт, который нужно использовать, time определяет время, в которое система может вызываться. chat описывает сценарии входа в систему: последовательность строк, которыми нужно обменяться, чтобы uucico зарегистрировали на pablo. Мы опишем сценарий входа позже. Команда port не называет конкретный файл устройства, например, /dev/cua1, она указывает на файл с соответсвующими записями. Вы можете назначить любое походящее имя.

Файл port содержит информацию о связи непосредственно. Для модемной связи он описывает специальный файл устройства, который нужно использовать, скорость и тип оборудования, соединенного с портом. Пример ниже описывает /dev/ttyS1 (он же COM2), с которым соединен модем NakWell способный к передаче на скорости до 38400bps. Имя порта должно соответствовать имени, заданному в файле sys.

# /etc/uucp/port - UUCP ports
# /dev/ttyS1 (COM2)
port            serial1
type            modem
device          /dev/ttyS1
speed           38400
dialer          nakwell

Информация, имеющая отношение к программам набора номера, cохраняется в другом файле, называемом dial. Для каждого типа программы набора номера он содержит последовательность команд, которые требуются, чтобы вызвать удаленную машину по номеру телефона. Все это называется chat script (сценарий дружеской системы). Пример для вышеупомянутого NakWell мог бы выглядеть следующим образом:

# /etc/uucp/dial - per-dialer information
# NakWell modems
dialer          nakwell
chat            "" AT&F OK ATDT\T CONNECT

Строка, начинающаяся с chat, определяет скрипт модема, который является последовательностью команд, посланных и полученных от модема, чтобы инициализировать его и набрать желательный номер. Последовательность \T будет заменена на номер телефона uucico.

Чтобы в общем показать Вам, как uucico работает с этими файлами конфигурации, предположим, что Вы дали команду:
$ uucico -s pablo

Первым делом uucico ищет pablo в файле sys. Из строки в файле sys для pablo она видит, что должна использовать порт serial1 для установки соединения. Файл port сообщает uucico, что serial1 является портом модема, и что есть подключенный модем NakWell.

uucico теперь ищет запись dial , описывающую модем NakWell, и найдя первую такую запись, открывает последовательный порт /dev/cua1 и выполняет "дружескую беседу" программы набора номера. То есть, посылает AT&F, ждет в ответ OK и т.д. При столкновении со строкой \T, она заменяет эту строку на номер телефона (555-22112), извлеченный из файла sys.

После того, как соединение будет установлено (модем вернет CONNECT), uucico возвращается к файлу sys и выполняет дружескую беседу входа в систему (login chat). В нашем примере она ждет приглашения login: затем посылает имя пользователя (vstout), ждет приглашения password: и посылает пароль (lorca).

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

Что нужно знать UUCP

Работа программ Linux слегка напоминает работу разведки: никто не должен знать лишнего.

Прежде, чем Вы начинаете писать файлы конфигурации UUCP, Вы должны выяснить некоторую необходимую информацию. Сначала Вы должны выяснить, к какому последовательному порту присоединен модем. Обычно порты DOS COM1-COM4 отображаются на специальные файлы устройств с /dev/ttyS0 по /dev/ttyS3. Большинство дистрибутивов, например, Slackware, создают файл /dev/modem как ссылку на соответствующий файл устройства ttyS* и конфигурируют коммуникационные программы kermit, seyon, чтобы они использовали этот обобщенный файл. В этом случае Вы должны также использовать /dev/modem в Вашей конфигурации UUCP.

Причина этого в том, что все программы используют так называемые файлы блокировки (lock files), чтобы сообщить, когда последовательный порт используется. Имена этих файлов блокировки являются конкатенацией строки LCK.. и имени файла устройства, например, LCK..ttyS1. Если программы используют различные имена для одного устройства, они будут не в состоянии распознавать чужие файлы блокировки. Как следствие, они прервут чужие сеансы связи. Это не такое уж маловероятное событие, если Вы планируете, чтобы UUCP использовал crontab. Подробности настройки последовательных портов описаны в главе 4.

Затем Вы должны выяснить, с какой скоростью модем и Linux могут связываться, и установить максимальную эффективную скорость передачи. Эффективная скорость передачи может быть намного выше, чем физическая скорость модема. Например, много модемов посылают и получают данные на скорости 56 kbps. Использование протоколов сжатия (например, V.42bis) позволяет установить фактическую скорость передачи более, чем в 100 kbps.

Конечно, если Вы хотите, чтобы UUCP cделал что-нибудь, Вам нужен номер телефона системы для вызова. Также Вам нужен идентификатор для входа в систему и, возможно, пароль для удаленной машины.

Также надо знать порядок входа в систему. Следует ли нажать клавишу Enter перед появлением приглашения для входа? Что будет отображено: login: или user:? Это необходимо для создания сценария дружеской беседы (chat script), который описывает uucico как регистрироваться. Если у Вас возникают затруднения, попробуйте вызывать систему программой терминала kermit или minicom и записать точно, что Вы делаете.

Имена сайтов

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

Однако, если Вы используете UUCP для почты или новостей, Вы должны подумать о наличии имени, зарегистрированного в UUCP Mapping project. UUCP Mapping project описан в главе 17. Даже если Вы делите домен с кем-то, Вы можете получить официальное имя UUCP для своего участка сети.

Часто люди выбирают свое UUCP имя так, чтобы соответствовать первому компоненту имени домена. Предположим, что адрес Вашего домена swim.twobirds.com, тогда имя главной машины UUCP было бы swim. Обычно именно так и бывает. Конечно, Вы можете также использовать любое UUCP имя.

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

По умолчанию, набор программ UUCP использует hostname как имя UUCP. Это имя обычно устанавливается в скрипте rc и хранится в /etc/hostname. Если ваше имя UUCP отлично от того, что Вы устанавливаете в качестве имени своей машины, Вы должны использовать опцию hostname в файле config, чтобы сообщить uucico о Вашем имени UUCP. Это будет рассмотрено чуть позже.

Файлы настройки Taylor

Теперь мы вернемся к файлам конфигурации. Taylor UUCP получает информацию из следующих файлов:

config

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

sys

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

port

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

dial

Описывает программы номера, используемые, чтобы установить телефонное соединение.

dialcode

Содержит расширения для символьных номеров (dialcodes).

call

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

passwd

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

Файлы конфигурации Taylor состоят из строк, содержащих пары "ключевое слово=значение". Знак hash (#) представляет собой комментарий, действующий до конца строки. Чтобы использовать знак # просто так, Вы можете ввести его с наклонной чертой влево \#.

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

Если Вы думаете, что сконфигурировали вашу систему UUCP полностью, можете проверить конфигурацию, используя uuchk (находится в /usr/lib/uucp). uuchk читает ваши файлы конфигурации и печатает детализированный отчет о значениях, используемых для каждой системы.

Общие опции настройки: файл config

Скорее всего Вы вообще не будете использовать этот файл, чтобы описать UUCP hostname. По умолчанию, UUCP использует имя, которое Вы устанавливаете командой hostname, но вообще хорошая идея установить имя UUCP явно. Типовой файл config показан ниже:
# /usr/lib/uucp/config - UUCP main configuration file
hostname        vstout

Здесь можно задать еще ряд параметров, например, имя каталога для буфера. Эти параметры будут рассмотрены позже в разделе “Анонимный UUCP.”

Как сказать UUCP о других системах: файл sys

Файл sys описывает системы, о которых Ваша машина знает. Запись представляется ключевым словом system; затем до следующей директивы system следуют детальные параметры, специфические для этой системы. Обычно, сведения системы определяют номер телефона, login chat и другие подобные параметры входа в систему.

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

Наиболее важные элементы записи подробней описаны ниже.

Имя системы

Команда system задает имя удаленной системы. Вы должны определить правильное имя удаленной системы, не псевдоним, потому что uucico сравнит это значение с ответом системы.

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

Номер телефона

Если связь с удаленной системой достигается по телефонной линии, поле phone определяет номер, который модем должен набрать для связи. Он может содержать отдельные лексемы, интерпретируемые процедурой набора uucico. Знак равенства (=) означает ждать вторичный тон набора кода, тире (-) генерирует паузу в одну секунду. Например, некоторые телефонные станции сбрасывают номер, если Вы не делаете паузу между набором префиксного кода и номера телефона. Я не знаю соответствующий термин для этого, но Вы знаете, что иногда на внутренней телефонной станции Вы должны набрать 0 или 9, чтобы получить выход наружу.

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

# /usr/lib/uucp/dialcode - dialcode translation
Bogoham         024881
Coxton          035119

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

port и speed

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

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

login chat

Выше мы уже сталкивались со скриптом входа в систему (login chat script), который сообщает uucico, как регистрироваться в удаленной системе. Он состоит из списка лексем, определяя строки, ожидаемые и посланные локальным процессом uucico. Проблема состоит в том, чтобы заставить uucico ждать, пока удаленная машина не пошлет приглашение входа в систему, затем послать имя входа в систему, ждать, пока удаленная система пошлет приглашение на ввод пароля, и посылать пароль. Ожидание и посылка строки чередуются. uucico автоматически добавляет символ возврата каретки (\r) к любой посылаемой строке. Таким образом, простой скрипт похож на:
ogin: vstout ssword: catch22

Обратите внимание, что поля записи не содержат текста приглашений. Удостоерьтесь, что вы войдете в систему , даже если система посылает Login: вместо login:.

uucico также учитывает некоторые виды условного выполнения, например, в случае, если getty удаленной машины должен быть сброшен перед посылкой приглашения. Для этого Вы можете присоединить под-дружескую (sub-chat) беседу к ожидающейся строке. Sub-chat выполняется только, если основное соединение не удалось, то есть произошла блокировка по времени. Один из способов использовать эту возможность состоит в том, чтобы послать BREAK, если удаленная система не отображает приглашение входа в систему. Следующий пример дает всесторонний скрипт дружеской беседы, который должен работать и в случае, если Вы должны нажать Enter прежде, чем войти в систему. Пустая строка ("") говорит UUCP ничего не ждать и продолжать посылать следующую строку немедленно.
"" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22

Имеется несколько специальных строк и ESC-символов, которые могут включаться в скрипт:

""

Пустая строка сообщает, чтобы uucico не ждал ничего, а продолжил посылать следующую.

\t

Табуляция.

\r

Перевод каретки.

\s

Пробел. Вы нуждаетесь в нем, чтобы включить пробел в строку регистрации в скрипте.

\n

Перевод строки. В unix-системах понятия перевода (возврата) каретки и перевода строки разделены в отличие от DOS/Windows-систем.

\\

Обратный слэш (\).

В посылаемой строке в дополнение к вышеупомянутым допустимы следующие ESC-символы и последовательности:

EOT

Конец передачи (^D).

BREAK

Прерывание (Break).

\c

Возврат каретки в конце строки.

\d

Пауза в 1 секунду.

\E

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

\e

Выключить эхо-контроль.

\K

Аналогично BREAK.

\p

Пауза на половину секунды.

Альтернативы (Alternates)

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

Альтернативная строка сохраняет все установки из основной и определяет только те значения, которые должны быть отменены в заданной по умолчанию или добавлены к ней. Альтернатива смещена, относительно записи для системы, строкой, содержащей ключевое слово altgrnave alternate.

Чтобы использовать два номера телефона для pablo , Вы должны изменить файл sys следующим образом:
system       pablo
phone        123-456
.. entries as above ...
alternate
phone        123-455

При вызове pablo, uucico теперь сначала наберет 123-456 и, если ничего не получается, попробует альтернативу. Альтернативный вход сохраняет все установки из основного входа системы и изменяет только номер телефона.

Ограничение времени вызова

Taylor UUCP реализует ряд способов, обеспечивающих ограничение времени обращения к удаленной системе. Вам потребуется сделать это или из-за ограничений, которые удаленная система накладывает на услуги в течение рабочих часов или просто, чтобы избегать времени с высокими ценами за услуги. Обратите внимание, что всегда возможно отменить ограничения времени обращения, запустив uucico с опцией –S или –f.

По умолчанию, Taylor UUCP отвергнет соединения в любое время, так что Вы должны использовать некоторый вид спецификации времени в файле sys. Если Вы не очень заботитесь об ограничении времени обращения, Вы можете определить опцию time со значением Any (любой) в файле sys.

Самый простой способ ограничить время обращения, поле time, которое сопровождается строкой, состоящей из дня и подполя времени. День может быть комбинацией Mo, Tu, We, Th, Fr, Sa, Su, Any (любой), Never (никогда) или Wk для выходных дней. Время состоит из двух значений часов (в 24-часовом формате), отделяемых тире. Они определяют диапазон, в течение которого обращения допустимы. Комбинация этих лексем пишется без интервалов. Можно задать несколько интервалов, разделяя их запятыми. Например, MoWe0300-0730, Fr1805-2000 допускает обращение в понедельник и среду с 3 до 7.30 утра и в пятницу с 18.05 до 20.00. Когда поле time охватывает полночь, и написано Mo1830-0600, это фактически означает понедельник, между полуночью и 6.00 утра и между 18.30 пополудни и полуночью понедельника.

Taylor UUCP также имеет специальные лексемы, которые можно использовать в строке времени: NonPeak и Night. Они эквивалентны Any2300-0800,SaSu0800-1700 и Any1800-0700,SaSu соответственно.

Команда time задает параметр, который описывает время повтора в минутах. Когда попытка установить соединение не удалась, uucico не допустит другой попытки вызвать удаленный компьютер в течение некоторого интервала. По умолчанию, используется схема backoff, где интервал повтора увеличивается с каждым последующим отказом. Например, когда Вы определяете время повторения в 5 минут, uucico откажется вызывать удаленную систему в течение 5-ти минут после последнего отказа.

Команда timegrade позволяет Вaм настраивать приоритет буферизации. Допустим, что Вы имеете следующие команды timegrade в записи системы:
timegrade           N Wk1900-0700,SaSu
timegrade           C Any

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

Точно так же, как команда time, команда timegrade берет интервал повторения в минутах как дополнительный третий параметр.

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

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

Описание устройств: файл port

Файл port сообщает uucico о доступных портах. Это могут быть порты модема, другие типы последовательных соединений и сокеты TCP.

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

Команда port должна обязательно сопровождаться именем, которое задает, какой порт описан. Допустимые типы: modem, direct для прямых соединений и tcp для сокетов TCP. Если команда port отсутствует, по умолчанию тип порта принимает значение modem.

В этом разделе я опишу лишь порты модема. Сокеты TCP и прямые соединения будут обсуждаться позже.

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

В случае использования модема, port также определяет, какой модем соединен с портом. Различные типы модемов должны быть настроены по-разному. Следовательно, Вы должны сообщить uucico, как инициализировать Ваш модем и как соединяться с требуемым номером. Taylor UUCP хранит описания всех программ набора номера в файле dial . Чтобы использовать любую из них, Вы должны определить имя программы набора номера, используя команду dialer.

Иногда Вам потребуется использовать модем различными способами в зависимости от системы, которую Вы вызываете. Например, некоторые старые модемы не понимают, когда быстрый модем пытается соединяться на скорости 56 kbps; они просто пропускают строку вместо того, чтобы вести переговоры на скорости в 9600 bps. Если Вы знаете, что некоторые машины используют такой "немой" модем, для вызова их Вы должны настраивать свой модем иначе. Для этого Вам нужно добавить строку port в файл port, которая определит другую программу набора номера. Теперь Вы можете задать новому порту другое имя, типа serial1-slow, и использовать директиву port в описании системы в файле sys.

Лучший способ отличать порты состоит в том, чтобы отличать порты по скоростям, которые они поддерживают. Например, два описания порта для вышеупомянутого случая могут выглядеть следующим образом:
# NakWell modem; connect at high speed
port            serial1         # port name
type            modem           # modem port
device          /dev/ttyS1      # this is COM2
speed           115200          # supported speed
dialer          nakwell         # normal dialer
# NakWell modem; connect at low speed
port            serial1         # port name
type            modem           # modem port
device          /dev/ttyS1      # this is COM2
speed           9600            # supported speed
dialer          nakwell-slow    # don't attempt fast connect

Системная запись для машины drop получает для использования порт serial1, но в случае запроса на использование скорости 9,600 bps uucico автоматически использует вторую запись порта. Все остальные сайты, которые работают со скоростью 115,200 будут вызываться с использованием первой записи port. По умолчанию используется первая запись с подходящей скоростью.

Как набирать номер: файл dial

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

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

Наиболее важная часть, скрипт модема (modem chat), определяется командой chat. Подобно скрипту входа в систему (login chat), он состоит из последовательности строк uucico, посылаемых программе набора номера и ответов, которые требуется получить. Они обычно используются, чтобы сбросить модем к известному состоянию, и набирать номер. Вот пример для Hayes-совместимого модема:

# NakWell modem; connect at high speed
dialer          nakwell         # dialer name
chat            "" AT&F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
chat-fail       BUSY
chat-fail       ERROR
chat-fail       NO\sCARRIER
dtr-toggle      true

Скрипт модема начинается с "", пустой ожидаемой строки. Cледовательно, uucico пошлет команду (AT&F) сразу же. Команда Hayes AT&F нужна для сброса модема. Затем uucico ждет, пока модем не пошлет OK, и посылает следующую команду, которая выключает локальное эхо, и т.п. После того, как модем снова возвращает OK, uucico посылает команду набора ATDT (для России ATDP). Escape-последовательность \T в этой строке заменяется на номер телефона, получаемый из файла sys. Затем uucico ждет, пока модем не возвратит CONNECT, который говорит о том, что соединение с удаленным модемом было установлено успешно.

Часто модем будет не в состоянии соединиться с удаленной системой, например, если другая система общается с кем-то еще, и линия занята. В этом случае модем вернет сообщение об ошибке, указывающее на причину отказа. Скрипт модема не способен обнаружить такие сообщения; uucico будет ждать требуемую строку, пока не выйдет время ожидания. В файле регистрации UUCP (log file) будет записано "timed out in chat script" вместо истинной причины.

Однако, Taylor UUCP позволяет Вам поставить в известность uucico об этих сообщениях, используя команду chat-fail, как показано выше. Когда uucico обнаруживает строку chat-file при выполнении скрипта модема, то прерывает обращение и регистрирует сообщение об ошибках в файле регистрации UUCP (log файле).

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

UUCP поверх TCP

В первый момент это может показаться абсурдом, но на самом деле UUCP поверх TCP не такая уж плохая идея, особенно при пересылке большого количества данных, типа новостей Usenet. На TCP-узлах новостями в основном обмениваются, используя NNTP протокол, в котором статьи запрашиваются и посылаются индивидуально, без сжатия и прочей оптимизации. Хотя и подходящая для больших узлов с большим объемом новостей, эта методика не подходит для небольших участков сети, которые получают новости медленным соединением типа ISDN. Им удобней объединить качества TCP с преимуществами посылки новостей в больших пакетах, которые могут быть сжаты и таким образом перемещаться с очень низкими затратами. Стандартный способ передать эти пакеты состоит в том, чтобы использовать UUCP поверх TCP.

В файле sys Вы определяете систему, которую нужно вызвать через TCP.
system          gmu
address         news.groucho.edu
time            Any
port            tcp-conn
chat            ogin: vstout word: clouseau

Команда address задает IP-адрес машины или ее полное доменное имя. Соответствующий участок файла port выглядел бы так:
port            tcp-conn
type            tcp
service         540

Этот пример говорит, что TCP-соединение должно использоваться, когда файл sys ссылается на tcp-conn , и что uucico должен пытаться соединяться с TCP-портом 540 на удаленной машине. Это заданный по умолчанию номер порта для обслуживания UUCP. Вместо номера порта, Вы можете также давать символическое имя порта командой service. Номер порта, соответствующий этому имени будет найден в файле /etc/services. Общее имя для UUCP-сервиса uucpd .

Использование прямого соединения

Допустим, что Вы используете прямое соединение своей системы vstout с системой tiny. Как и в случае с модемом, Вы должны описать вход в систему в файле sys. Команда port идентифицирует последовательный порт tiny.
system          tiny
time            Any
port            direct1
speed           38400
chat            ogin: cathcart word: catch22

В файле port Вы должны описать последовательный порт для прямого соединения. Описание программы набора номера (dialer) не нужно, так как нет никакой потребности в наборе.
port            direct1
type            direct
speed           38400
device          /dev/ttyS1

Назад | Глобальное оглавление | Вперед
Управление Taylor UUCP | Локальное оглавление | Контроль доступа к возможностям UUCP


Control Messages

Назад Глава 21. C-News Вперед

Сообщения Control

Протокол новостей Usenet знает специальный класс статей, которые вызывают некоторые ответы или действия системы новостей. Они называются сообщениями control. Они распознаются присутствием поля Control: в заголовке статьи, которое содержит имя операции управления, которую нужно выполнить. Имеются отдельные типы этих операций, которые обрабатываются командами оболочки, расположенными в /usr/lib/news/ctl.

Большинство из них выполнит свое действие автоматически во время обработки статьи C-News, без уведомления newsmaster. По умолчанию только сообщения checkgroups будут вручены newsmaster, но Вы можете изменить это, редактируя скрипты.

Сообщение cancel

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

newgroup и rmgroup

Два сообщения имеют дело с созданием или удалением newsgroups: это newgroup и rmgroup . Newsgroups ниже "обычной" иерархии могут быть созданы только после того, как среди читателей Usenet было проведено обсуждение и утверждение. Правила для иерархии alt представляют собой что-то близкое к анархии. Для подробной информации см. регулярные регистрации в news.announce.newusers и news.announce.newgroups. Никогда не посылайте сообщение newgroup или rmgroup самостоятельно, если Вы определенно не знаете, что Вам позволено.

Сообщение checkgroups

Сообщения checkgroups посылаются администраторами новостей, чтобы для всех абонентов внутри сети синхронизировать их файлы active с фактическим положением дел в Usenet. Например, коммерческие поставщики услуг Internet могли бы выпускать такое сообщение к своим абонентам. Один раз в месяц "официальное" сообщение checkgroups для главных иерархий отсылается в comp.announce.newgroups их модератором. Однако оно зарегистрировано как обычная статья, а не как управляющее сообщение. Чтобы выполнить операцию checkgroups, сохраните эту статью в файле, скажем, /tmp/check, удалите все до начала сообщения управления и передайте его скрипту checkgroups , используя следующую команду:
# su news -c "/usr/lib/news/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
The following newsgroups are not valid and should be removed.
        alt.ascii-art
        bionet.molbio.gene-org
        comp.windows.x.intrisics
        de.answers
You can do this by executing the commands:
         /usr/lib/news/maint/delgroup alt.ascii-art
         /usr/lib/news/maint/delgroup bionet.molbio.gene-org
         /usr/lib/news/maint/delgroup comp.windows.x.intrisics
         /usr/lib/news/maint/delgroup de.answers
The following newsgroups were missing.
        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
#
WHOIAM=`whoami`
if [ "$WHOIAM" != "news" ] then
   echo "You must run $0 as user 'news'" >&2
   exit 1
fi
#
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/maint/addgroup $group $mod
done

sendsys, version и senduuname

В заключение, имеются три сообщения, которые могут использоваться, чтобы выяснить топологию сети. Это sendsys, version и senduuname . Они заставляют C-News возвращать отправителю файл sys, версию программного обеспечения и вывод uuname, соответственно. C-News очень лаконичен относительно сообщения version; он возвращает просто C.

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

Назад | Глобальное оглавление | Вперед
Прочие файлы | Локальное оглавление | C-News и NFS


The NFS Daemons

Назад Глава 14. Сетевая файловая система (Network File System) Вперед

NFS Daemons

Если нужно предоставить сервис NFS, надо запустить демоны rpc.nfsd и rpc.mountd на Вашей машине. Как и все RPC-программы, они не управляются inetd , а запускаются в процессе загрузки и регистрируются через portmapper. Кстати, из этого следует, что запускать их можно только после запуска rpc.portmap. Обычно в один из сетевых скриптов загрузки надо вписать:
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"
fi

Информация о владельце файла передается демоном NFS клиентам только, как числа user и group ID. Если на клиенте и сервере имена пользователя и группы совпадают, получается разделение пространства uid/gid. Например, такая ситуация возникает при использовании NIS для распространения информации из passwd по сети.

Часто такого совпадения нет. Вместо модификации uid и gid для приведения их в соответствие можно использовать демон отображения rpc.ugidd, чтобы обойти несовпадение. Ниже будет объяснено использование опции map_daemon. Можно указать, чтобы rpc.nfsd отобразил пространство uid/gid сервера на пространство uid/gid клиента при помощи rpc.ugidd на клиенте. К сожалению, rpc.ugidd есть далеко не во всех дистрибутивах, так что если он нужен, придется найти исходные тексты и откомпилировать их.

rpc.ugidd является RPC-сервером, который запускается из сетевого скрипта загрузки аналогично rpc.nfsd и rpc.mountd:

if [ -x /usr/sbin/rpc.ugidd ]; then
   /usr/sbin/rpc.ugidd; echo -n " ugidd"
fi

Назад | Глобальное оглавление | Вперед
Монтирование томов NFS | Локальное оглавление | Файл exports


Message Routing and Delivery

Назад Глава 19. Получение и запуск Exim Вперед

Маршрутизация и доставка почты

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

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

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

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

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

Маршрутизация почты

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

Доставка писем на локальные адреса

Обычно локальный адрес задает только имя входа пользователя в систему, тогда сообщение будет доставлено в почтовый ящик пользователя, /var/spool/mail/ user-name. Другие случаи включают псевдонимы, имена списков рассылки и пересылку почты. В этих случаях локальный адрес расширяется до нового списка адресов, которые могут быть локальными или удаленными.

Кроме этих "нормальных" адресов Exim может обрабатывать другие типы локальных адресатов сообщения, подобные командам канала и именам файла. При доставке в файл Exim добавит в него сообщение, создавая файл в случае необходимости. Файл и адресаты канала не являются адресами в обычном смысле, так что Вы не можете посылать почту, скажем, на /etc/passwd@vbrew.com и перезаписывать файл пароля; доставка в специфический файл имеет силу только, если она исходит из файлов псевдонима или из команды пересылки. Обратите внимание, что адрес /etc/passwd@vbrew.com синтаксически имеет силу, но если Exim получил такой адрес, он обычно будет искать пользователя, чье имя входа в систему /etc/passwd, что приведет к сбою и сообщению об ошибке.

В списке псевдонима или файле пересылки имя файла начинается со слэша (/ ), если оно не является полным адресом почты. Например, /tmp/junk в файле пересылки или псевдонимов интерпретируется как имя файла, но /tmp/junk@vbrew.com будет воспринят как адрес email, хотя это вряд ли будет очень полезным. Однако имеющий силу адрес этого типа замечен при посылке почты через шлюзы X.400, потому что в X.400 адреса начинаются с наклонной черты вправо. В общем, маршрутизация почты всегда была сложной.

Командой канала (pipe command) может быть любая команда Unix, которой предшествует символ канала (|), если строка не является полным адресом email с указанием домена. Если Вы не изменили конфигурацию, Exim не использует оболочку, чтобы выполнить команду; вместо этого он разделяет ее на команду и параметры, сам и выполняет непосредственно. Сообщение будет подано команде на стандартном вводе.

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

Локальные пользователи

Локальный адрес обычно обозначает почтовый ящик пользователя. Ящик обычно размещается в /var/spool/mail и имеет имя пользователя, которому принадлежит файл. Если файл не существует, Exim его создаст сам.

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

Обратите внимание, что хотя в настоящее время стандартное место для размещения файлов почтовых ящиков /var/spool/mail, некоторое программное обеспечение почты может компилироваться, чтобы использовать другие места, например, /usr/spool/mail . Если доставка пользователям на Вашей машине терпит неудачу, попробуйте создать ссылку на /var/spool/mail.

Адреса MAILER-DAEMON и postmaster должны обычно появляться в Вашем файле псевдонимов, расширяясь в email-адрес администратора системы. MAILER-DAEMON используется Exim как адрес отправителя в сообщениях об ошибках. Также рекомендуется, чтобы root был установлен как псевдоним для администратора, особенно, когда доставки выполняются согласно правам пользователей-получателей, чтобы избежать доставок с правами root.

Пересылка (forwarding)

Даже в русскоязычной среде больше прижился термин forwarding, чем пересылка, так что я использую оба термина. Вообще следует отметить огромное количество английских терминов в данной области. Поэтому я стараюсь приводить как русский, так и английский варианты. Пользователи могут переназначать свою почту альтернативным адресам, создавая в своем домашнем каталоге файл .forward. Он содержит список получателей, отделяемых запятыми и/или символами перевода строки. Особое внимание надо уделить тому, что обрабатываются все строки файла, а не только первая. Почему-то очень распространено мнение, что переслать можно только на один адрес. На самом деле пересылать можно на много адресов, причем допустимы все типы адресов. Пример файла .forward:
janet, "|vacation"

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

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

Первый адрес в файле forward доставляет сообщение в почтовый ящик janet, а команда vacation вернет краткий ответ отправителю.

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

Файлы псевдонимов

Exim способен обработать файлы псевдонимов, совместимые с файлами псевдонимов Berkeley's sendmail. Записи в файле псевдонима могут иметь следующую форму:
alias: recipients

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

Специальное свойство позволяет Exim обрабатывать списки адресатов, которые хранятся в отдельном файле псевдонимов: если Вы определяете :include: filename как получателя, Exim читает этот файл и рассматривает его содержимое как список получателей. Обработка списков рассылки будет показана в этой главе ниже, в разделе списки рассылки .

Главный файл псевдонимов /etc/aliases. Если Вы сделаете этот файл доступным на запись для группы или прочих пользователей, Exim откажется использовать его и задержит локальные доставки. Вы можете управлять проверкой прав доступа, задавая modemask в редиректоре system_aliases.

Пример файла aliases:
# vbrew.com /etc/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: /etc/Exim/staff,
        /var/mail/log/announce
owner-announce: root
# gate the ppp mailing list to a local newsgroup
ppp-list: "|/usr/local/bin/gateit local.lists.ppp"

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

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

Списки рассылки

Вместо файла псевдонимов списки адресатов могут также управляться средствами редиректора forwardfile. Списки хранятся в одном каталоге, например, /etc/exim/lists, и список рассылки nag-bugs будет описан файлом lists/nag-bugs. Он должен содержать разделенный запятыми или переводами строки список адресатов. Строки, начинающиеся с символа #, являются комментариями. Простой редиректор для такой обработки:
lists:
  driver = forwardfile
  file = /etc/exim/lists/${local_part}
  no_check_local_user
  errors_to = ${local_part}-request
При выполнении этого редиректора вместо опций file и errors_to будут подставлены соответствующие значения. Это называется расширением опций. Простейший вариант расширения заключается в подстановке соответствующих значений, что здесь и происходит. Подстрока ${local_part} будет заменена значением $local_part, которое является локальной частью адреса, который сейчас обрабатывается.

Для каждого списка рассылки должен быть пользователь (или псевдоним, или список рассылки) с именем listname-request . На него присылаются все сообщения об ошибках обработки списка или доставки почты.

Назад | Глобальное оглавление | Вперед
Опции настройки | Локальное оглавление | Противоспамовая оборона


Setting Up Your System for Dialing In

Назад Глава 16. Управление Taylor UUCP Вперед

Настройка системы для приема входящих звонков (Dial In)

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

Предоставление UUCP-доступа

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

Для систем, которые подключаются через последовательный порт, Вы должны добавить эти имена в файл паролей системы, /etc/passwd . Хорошим вкусом считается поместить все имена UUCP в специальную группу типа uuguest. Домашний каталог такого пользователя должен находиться в общем каталоге /var/spool/uucppublic, оболочка входа в систему uucico.

Для обслуживания систем UUCP, которые связываются с Вашим сайтом через TCP, нужно настроить на их обработку inetd. Он должен быть нацелен на порт uucp добавлением следующей строки к файлу /etc/inetd.conf:
uucp   stream   tcp   nowait  root  /usr/sbin/tcpd  /usr/lib/uucp/uucico -l

С опцией Опция –l uucico выполняет собственную проверку на вход в систему. Она запросит имя и пароль также, как и стандартная программа login, но положится на собственный файл паролей вместо /etc/passwd . Этот файл паролей называется /etc/uucp/passwd и содержит пары имен входа в систему и паролей:
Upablo  IslaNegra
Ulorca  co'rdoba

Конечно, этот файл должен принадлежать пользователю uucp и иметь права доступа 600.

Если эта база данных так хороша, почему бы не использовать ее на нормальных последовательных входах в систему? Хорошо, в некоторых случаях Вы можете это устроить. Сначала Вам понадобится getty, которой Вы можете сообщить вызвать uucico вместо обычного /bin/login для Ваших UUCP-пользователей. Вызов uucico выглядит так:
/usr/lib/uucp/uucico -l -u user
Опция -u предписывает использовать переданное имя пользователя, а не запрашивать его.

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

Защита от перехватчиков почты

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

Вы должны принять меры против самозванцев! Для этого необходимо потребовать, чтобы каждая система использовала имя входа в Вашу систему, заданное called-login в sys. Например:
system          pablo
... usual options ...
called-login    Upablo

В результате этого всякий раз, когда система говорит, что она pablo, uucico проверит, регистрировалась ли она как Upablo. Если нет, вызов будет отвергнут, а соединение разорвано. Вы должны сделать привычкой добавлять команду called-login к каждой записи системы, которую Вы добавляете к Вашему файлу sys . Важно, что Вы делаете это для всех систем, независимо от того, будут ли они когда-либо вызывать Вас или нет. Для тех машин, которые никогда не вызывают Вас, Вы, возможно, должны установить called-login на некоторое полностью поддельное имя пользователя, типа neverlogsin , дабы никто точно не мог зайти.

.

Будьте бдительны: проверки последовательности обращения

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

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

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

Если Вы включили проверки последовательности обращения, Вы должны регулярно проверять Ваши регистрационные файлы на сообщения об ошибках, которые намекают на возможные причины. Если Ваша система отклоняет порядковый номер обращения, который вызывающая система предлагает, uucico поместит в регистрационный файл сообщение, говорящее что-нибудь вроде "Out of sequence call rejected". Если Ваша система не допущена, потому что порядковые номера находятся вне синхронизации, в регистрационном файле будет примерно следующее "Handshake failed (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

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

Анонимный UUCP

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

Кроме того, Вы должны установить несколько опций защиты для неизвестных систем. Например, Вы можете запретить им выполнение любых команд на Вашей системе. Однако, Вы не можете задать эти параметры в файле sys, потому что команда требует имени system, которое Вы не знаете. Taylor UUCP решает эту проблему через команду unknown. Команда unknown может использоваться в файле config, чтобы определить любую команду, которая может обычно появляться в записи системы:
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 и закачиванием файлов в каталог incoming ниже /var/spool/uucppublic. Следующая строка говорит uucico игнорировать любые запросы из удаленной системы, чтобы включить отладку локально. Последние две строки разрешают неизвестным системам выполнять rmail, но путь команды разрешает uucico искать команду rmail в частном каталоге, с именем anon-bin. Это позволяет Вам обеспечить некоторый специальный rmail, который, например, может передавать всю почту суперпользователю для исследования. Это разрешает анонимным пользователям писать администратору системы, но в то же время предотвращает отправление любой почты в другие места.

Чтобы включить анонимный UUCP, Вы должны определить по крайней мере один параметр unknown в файле config. Иначе uucico отклонит неизвестные системы.

Назад | Глобальное оглавление | Вперед
Контроль доступа к возможностям UUCP | Локальное оглавление | Протоколы низкого уровня UUCP


Using dip

Назад Глава 7. Serial Line IP Вперед

Использование dip

Хотелось бы иметь простую команду, которая выполняет все необходимые для установки связи действия: открывает последовательное устройство, дозванивается по модему до провайдера, регистрируется, запускает протокол SLIP и настраивает сетевой интерфейс. Такая команда есть и называется dip.

dip это сокращение от Dialup IP. Она написана Fred van Kempen, и исправлена большим количеством людей. На сегодняшний день с большинством дистрибутивов Linux поставляется версия dip337p-uri, которая также доступна на FTP-архиве metalab.unc.edu.

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

Чтобы сконфигурировать SLIP-интерфейс, dip требует привелегий root. Соблазнительно сделать dip setuid к root, чтобы Все пользователи могли соединиться с некоторым сервером SLIP без необходимости предоставления им root-доступа. Это очень опасно, потому что при установке фиктивных интерфейсов и заданных по умолчанию маршрутов dip может разрушить маршрутизацию в Вашей сети. Даже еще хуже, это даст пользователям приоритет на подсоединение к любым SLIP-серверам и начать атаку на Вашу сеть. Так, если Вы хотите позволить Вашим пользователям запустить SLIP-связь, напишите маленькие программки для каждого предполагаемого SLIP-сервера и вызовите dip с соответствующим скриптом, который установит связь. Эти программы могут быть безопасно сделаны setuid root. В качестве альтерантивы предлагается команда sudo.

Простой скрипт

Допустим, Вы написали скрипт для связи через dip с машиной cowslip и назвали его cowslip.dip. Теперь запустите dip и передайте ему имя скрипта как аргумент командной строки:
# 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 192.168.5.74
#

Сам скрипт показан в примере 7-1 .

Пример 7-1. Простой скрипт для dip

# Sample dip script for dialing up cowslip
# Set local and remote name and address
        get $local vlager-slip
        get $remote cowslip
        port ttyS3               # 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 knockknock\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.

После установления связи с cowslip и запуска протокола SLIP dip отсоединится от терминала и перейдет в фоновый режим. Вы сможете использовать обычные сетевые услуги на SLIP-связи. Чтобы завершить связь, просто вызовите dip c опцией -k. Это пошлет сигнал hangup процессу dip, используя запись id dip в /etc/dip.pid:
# dip -k

В языке скриптов dip, ключевые слова с префиксом $ обозначают различные имена. dip имеет предопределенное множество переменных, которые будут перечислены ниже. Например, $remote и $local содержат имена удаленной и локальной машин.

Первые два оператора в типовом скрипте команды get, которые являются способом установки переменных в dip. Здесь имена локальной и удаленной машин установлены соответственно в vlager и cowslip .

Следующие пять операторов устанавливают линию терминала и модем. Команда reset посылает reset-строку модему (для Hayes-совместимых модемов, это ATZ). Следующий оператор игнорирует реакцию модема так, чтобы login chat на последовательных линиях работал правильно. Сhat довольно прост: он набирает номер 41988, номер телефона cowslip, и подсоединяется под именем Svlager через пароль knockknock. Команда wait заставит dip ждать строку, заданную как его первый аргумент. Число, заданное в секундах, как второй аргумент, определяет, сколько времени надо ждать, если строка не была получена. Команды if разбросаны в процедуре входа в систему и проверяют то, что никакие ошибки не появились при выполнении этой команды.

Итоговые (final) команды выполняются после регистрации. Они заданы в default, и заставят SLIP связать заданный по умолчанию маршрут со всеми хостами и режимом (mode ), который включает SLIP на линии и конфигурирует интерфейс и таблицу маршрутов (routing tables).

Команды dip

В этом разделе мы рассмотрим команды языка скриптов dip . Вы можете получить краткий обзор всех команд, вызывая dip в тестовом режиме и вводя команду help. Для того, чтобы выяснить синтаксис конкрентой команды, Вы можете набрать команду без каких-либо аргументов; увы, это не сработает с командами, которым не нужны аргументы. Ниже показано действие команды help:

# dip -t
DIP: Dialup IP Protocol Driver version 3.3.7p-uri (25 Dec 96)
Written by Fred N. van Kempen, MicroWalt Corporation.
Debian version 3.3.7p-2 (debian).

DIP> help
DIP knows about the following commands:

        beep         bootp        break        chatkey      config
        databits     dec          default      dial         echo
        flush        get          goto         help         if
        inc          init         mode         modem        netmask
        onexit       parity       password     proxyarp     print
        psend        port         quit         reset        securidfixed
        securid      send         shell        skey         sleep
        speed        stopbits     term         timeout      wait

DIP> echo
Usage: echo on|off
DIP>

Во всех примерах, в которых есть приглашение DIP>, имеется в виду ввод команды в тестовом режиме. Примеры, в которых такого приглашения нет, показывают скрипты.

Команды модема

dip имеет ряд команд для настройки последовательной линии и модема. Некоторые из них очевидны, например, port выбирает последовательный порт, speed, databits , stopbits и parity, которые задают соответствующие параметры линии. Команда modem задает тип модема. Пока поддерживается только HAYES (именно БОЛЬШИМИ буквами!). Вы должны сообщить dip тип модема, иначе он не будет выполнять команды dial и reset. Команда reset посылает в модем строку рестарта. Для Hayes-совместимых модемов это ATZ.

Код flush может использоваться для того, чтобы убрать все реакции, которые модем посылает в ответ на команды. Иначе скрипт после reset может запутаться потому, что он читает OK реакции на более ранние команды модема.

Команда init посылает в модем строку инициализации перед дозвоном. Для Hayes-модемов это обычно "ATE0Q0V1X1".

Команда dial звонит на удаленную машину. Для Hayes-модемов это обычно ATD.

Команда echo

Команда echo служит как помощь в отладке. Использование echo on просит dip пересылать копию диалога с последовательным устройством на консоль. Эхо можно выключить командой echo off.

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

Команда get

Команда get представляет собой способ установки переменных в dip. Самая простая форма: установить переменную как константу, как это делалось в вышеупомянутом примере. Вы можете также спросить значение у пользователя, определяя ключевое слово ask вместо значения:
DIP> get $local ask
Enter the value for $local:

Третий метод состоит в том, чтобы попробовать получить значение с удаленного хоста. Причудливо на первый взгляд, но это очень полезно в некоторых случаях: некоторые серверы-SLIP не позволяют Вам использовать Ваш собственный IP-адрес на SLIP-связи, а будут приписывать Вам один из своих адресов всякий раз, когда Вы набираете номер, печатая сообщение, которое информирует Вас относительно адреса, который был назначен. Если есть сообщение вроде "Your address: 192.168.5.74", то следующий фрагмент кода dip его примет в Вашей системе:
# finish login
wait address: 10
get $locip remote

Команда print

Отображает текст на консоли из dip. Любые переменные dip могут быть использованы в таких командах. Например:
DIP> print Using port $port at speed $speed

Using port ttyS3 at speed 38400

Имена переменных

dip понимает только предопределенное множество переменных. Имя переменной всегда начинается с символа доллара и должно быть написано в нижнем регистре.

Переменные $local и $locip хранят имя и IP-адрес локальной машины. При сохранении в $local канонического имени, dip автоматически преобразует его в IP-адрес и запишет результат в переменную $locip. То же самое, но в обратном порядке произойдет при записи в $locip : dip получит имя для этого адреса и запишет его в переменную $local.

Переменные $remote и $rmtip делают то же самое для удаленной машины. $mtu хранит значение MTU для связи.

Эти пять переменных единственые, которые могут быть заданы непосредственно, используя команду get. Другие переменные могут быть установлены только через соответствующие команды, но можно использовать и операторы print ; это $modem, $port и $speed .

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

Команды if и goto

Команда if полноценная команда if, без которой нет ни одного языка программирования. Ее синтаксис:
if var op number goto label

где выражение должно быть простым сравнением с одной из переменных $errlvl, $locip и$rmtip. var должен быть целым числом; оператор op может быть одним из ==, !=, <, >, <= и >=.

Команда goto передает управление на строку с меткой label. Метка должна быть первым словом в строке и оканчиваться двоеточием.

send, wait и sleep

Эти команды выполняют простые встроенные скрипты в dip . send выводит свои аргументы в последовательную линию. Он не поддерживает переменные, но понимает все C-подобные символы со слэшем, типа \n для новой строки и \b для стирания предыдущего символа. Знак тильды (~) используется как сокращение для возврата каретки с переводом строки.

Команда wait принимает слово в качестве аргумента и читает весь вход с последовательной линии до его появления. Слово не может содержать пробелов. Вы можете дать wait ограничение по времени как второй аргумент. Если ожидаемое слово не будет получено в течении заданного времени, команда завершится со значением $errlvl равным 1.

Команда sleep ожидает заданное время. Интервал задается в секундах.

mode и default

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

Команда mode является последней выполняемой dip перед переходом в режим демона. Она ничего не возвращает до появления ошибки.

mode принимает как аргумент имя протокола. dip сейчас распознает SLIP , CSLIP, SLIP6, CSLIP6, PPP и TERM как имена протоколов. Текущая версия dip не понимает adaptive SLIP.

После запуска на последовательной линии режима SLIP dip выполняет ifconfig для настройки интерфейса и вызывает route для установки маршрутизации на удаленную машину.

Если скрипт выполняет команду default перед командой mode, dip создает маршрут по умолчанию для SLIP-связи.

Назад | Глобальное оглавление | Вперед
Работа с внутренними IP-сетями | Локальное оглавление | Запуск в режиме сервера


Configuring elm

Назад Глава 17. E-Mail Вперед

Настройка elm

elm является сокращением от "electronic mail" и является одним из наиболее приемлемых инструментальных средств Unix. Программа обеспечивает полноэкранный интерфейс с возможностью справки. Мы не будем обсуждать, здесь как использовать elm, а остановимся только на опциях конфигурации.

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

При запуске elm читает набор переменных конфигурации из файла elm.rc в /etc/elm. Затем, она будет пытаться читать файл .elm/elmrc в Вашем домашнем каталоге. Вы обычно не должны менять этот файл самостоятельно. Он создается, когда Вы выбираете "Save new options" в меню опций elm.

Набор опций для частного файла elmrc также доступен в глобальном файле elm.rc. Большинство установок в Вашем частном файле elmrc меняют соответствующие параметры из глобального файла.

Глобальные опции elm

В глобальном файле elm.rc, Вы должны установить опции, которые относятся к имени Вашей машины. Например, в Virtual Brewery у пользователя vlager файл содержал бы следующее:
#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name
hostfullname = vlager.vbrew.com

Этот набор опций ориентирует elm относительно имени локальной машины. Хотя эта информация редко используется, Вы должны установить эти опции. Заметьте, что эти опции не будут работать в частном файле elmrc.

Национальный набор символов

Имелись предложения исправить стандарт RFC-822, чтобы поддерживать различные типы сообщений: простые текстовые, двоичные данные, файлы Postscript и т.д. Набор стандартов и RFC, покрывающий эти аспекты, обычно упоминается как MIME, или многоцелевые расширения почты Internet. Между прочим, это также позволяет получателю узнать, использовался ли набор символов, отличный от стандартного ASCII, при написании сообщения. Это до некоторой степени обеспечивается elm.

Набор символов, используемый Linux, чтобы представить символы, обычно упоминается как ISO-8859-1, что является именем стандарта, которому он соответствует. Это также известно как Latin-1. В России принят кириллический стандарт KOI-8R. Любые символы в сообщении из этого набора символов должны иметь следующую строку в заголовке:
Content-Type: text/plain; charset=iso-8859-1
Для кириллицы это будет:
Content-Type: text/plain; charset=KOI-8R

Система получателя должна распознать это поле и принять соответствующие меры при отображении сообщения. Значение по умолчанию для текстовых (text/plain) сообщений us-ascii.

.

Чтобы отображать сообщения с набором символов, отличным от ASCII, elm должен знать, как печатать эти символы. По умолчанию, когда elm получает сообщение с полем charset, отличным от us-ascii, она пробует отображать сообщение, используя команду metamail. Сообщения, которые требуют использования metamail, отображаются с меткой M в самом первом столбце в экране краткого обзора.

Так как набор символов Linux ISO-8859-1, вызов metamail не требуется для отображения сообщения, использующего этот набор символов. Если elm знает, что дисплей понимает ISO-8859-1, она не будет использовать metamail, а отобразит сообщение непосредственно. Это может быть выполнено установкой следующей опции в глобальном файле elm.rc:
displaycharset = iso-8859-1

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

displaycharset = KOI-8R

Однако, установки этой опции в elm.rc недостаточно. Проблема состоит в том, что при отображении сообщения, elm вызывает библиотечную функцию для каждого символа, чтобы определить, является ли он печатаемым или нет. По умолчанию, эта функция распознает только символы ASCII, и отображает все другие символы как ^?. Вы можете преодолеть это, устанавливая переменную среды LC_CTYPE как ISO-8859-1. Это сообщает, что библиотека приняла символы Latin-1 как печатаемые. Для России надо задать LC_CTYPE как KOI-8R. Поддержка этой и ряда других возможностей появилась в стандартной библиотеке Linux, начиная с библиотек версии 4.5.8.

При посылке сообщений, которые содержат специальные символы из ISO-8859-1, Вы должны удостовериться, что установлены еще две переменные в файле elm.rc:
charset = iso-8859-1
textencoding = 8bit

Это заставит elm сообщить набор символов как ISO-8859-1 в заголовке почты и посылать это письмо как 8 битовое (по умолчанию все символы имеют 7 бит). Для России это очень важно, поскольку по умолчанию elm срезает верхний (восьмой) бит каждого символа, а для кириллицы этого допустить нельзя!

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

Назад | Глобальное оглавление | Вперед
Как работает маршрутизация почты? | Локальное оглавление | Sendmail


Ethernet Installation

Назад Глава 3. Настройка сетевого оборудования Вперед

Установка 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). Список поддерживаемых карт постоянно растет, так что Ваша карта почти наверняка поддерживается.

Когда-то раньше в руководствах по Linux пытались перечислить все допустимые карты. Сейчас такой список займет слишком много места. К счастью, Paul Gortmaker поддерживает Ethernet HOWTO, в котором есть список всех карт и информация о том, как заставить их работать в Linux. Документ рассылается в группу новостей comp.os.linux.answers и доступен на зеркалах Linux Documentation Project.

Даже если Вы уверены, что знаете, как установить специфический тип платы Ethernet на своей машине, все равно стоит ознакомиться с Ethernet HOWTO на предмет возможных хитростей. Это поможет сэкономить немало сил для DMA-карт Ethernet, которые используют тот же канал DMA, что и контроллер Adaptec 1542 SCSI. Если их не разделить, Вы получите карту Ethernet, записывающую данные пакетов в произвольное место на Вашем жестком диске.

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

Автоопределение Ethernet

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

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

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

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

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

ether=irq, base_addr, [param1,][param2,] name

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

Первый параметр задает IRQ. По умолчанию, ядро попробует его найти само. Например, драйвер 3c503 имеет специальное свойство, которое выбирает свободный IRQ из 5, 9, 3, 4 и настраивает плату, чтобы использовать эту линию. Параметр base_addr задает адрес ввода-вывода карты, значение 0 сообщает, чтобы ядро исследовало возможные адреса карты.

Различные драйверы используют следующие два параметра по разному. Для карт с разделением памяти (shared-memory cards), подобных WD80x3, они определяют первый и последний адреса разделяемой памяти. Другие платы обычно используют param1, чтобы установить уровень выдачи отладочной информации. Значения от 1 до 7 задают повышенные уровни отладки, 8 выключает ее, 0 выдает нормальное число сообщений. Драйвер 3c503 использует param2, чтобы выбрать между своим трансивером (по умолчанию) и внешним (значение 1). Аргументы param не должны быть включены вообще, если нет ничего особо нуждающегося в настройке.

Первый нечисловой параметр интерпретируется ядром как имя устройства. Вы должны определить имя устройства для каждой платы Ethernet.

Если у Вас две платы Ethernet cards, можно поручить определение первой ядру, а самому настроить вторую через lilo. Можно и вручную конфигурировать обе платы. Если Вы решите поручить ядру поиск первой платы, надо выяснить, какую плату считаете первой Вы, а какую ядро. Ваши мнения совпадут не всегда. Решить проблему позволяет опция lilo reserve, которая однозначно запретит ядру поиск в адресном пространстве первой карты. Например, чтобы Linux нашла вторую карту Ethernet на адресе 0x300 с именем eth1 задайте параметры ядра:

reserve=0x300,32 ether=0,0x300,eth1

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

reserve=0x340,32 ether=0,0x340,eth0

Автопоиск можно и вовсе запретить (допустим, Вы временно сняли одну из плат Ethernet). Чтобы запретить автопоиск задайте аргумент base_addr как –1:

ether=0,-1,eth0

Для передачи этих параметров ядру при загрузке Вы их вводите в ответ на приглашение lilo "boot:". Чтобы lilo выдал запрос "boot:", надо при загрузке держать нажатой одну из клавиш Control, Alt или Shift. Если в ответ на приглашение нажать Tab, будет выведен список ядер, которые можно загрузить. Для загрузки ядра с параметрами введите его имя, пробел и все нужные параметры. Затем нажмите клавишу Enter, и lilo загрузит заданное ядро с заданными параметрами.

Чтобы параметры воспринимались при каждой перезагрузке автоматически, внесите их в /etc/lilo.conf, используя ключевое слово append=. Например:
boot=/dev/hda
root=/dev/hda2
install=/boot/boot.b
map=/boot/map
vga=normal
delay=20
append="ether=10,300,eth0"

image=/boot/vmlinuz-2.2.14
label=2.2.14
read-only

После правки lilo.conf, выполните команду lilo для активизации изменений.

Назад | Глобальное оглавление | Вперед
Обзор сетевых устройств в Linux | Локальное оглавление | Драйвер PLIP


A Sample Firewall Configuration

Назад Глава 9. TCP/IP Firewall Вперед

Пример конфигурации Firewall

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

Конфигурация в этом примере была разработана, чтобы быть легко расширенной и настроенной. Мы обеспечили три версии. Первая версия выполнена, используя команду ipfwadm (или скрипт ipfwadm-wrapper), вторая использует ipchains и третья использует iptables. Пример не пытается использовать определяемые пользователем цепочки, но покажет Вам сходства и различия между старыми и новыми инструментами конфигурации firewall:

#!/bin/bash
##########################################################################
# IPFWADM VERSION
# This sample configuration is for a single host firewall configuration
# with no services supported by the firewall machine itself.
##########################################################################

# USER CONFIGURABLE SECTION

# The name and location of the ipfwadm utility. Use ipfwadm-wrapper for
# 2.2.* kernels.
IPFWADM=ipfwadm

# The path to the ipfwadm executable.
PATH="/sbin"

# Our internal network address space and its supporting network device.
OURNET="172.29.16.0/24"
OURBCAST="172.29.16.255"
OURDEV="eth0"

# The outside address and the network device that supports it.
ANYADDR="0/0"
ANYDEV="eth1"

# The TCP services we wish to allow to pass - "" empty means all ports
# note: space separated
TCPIN="smtp www"
TCPOUT="smtp www ftp ftp-data irc"

# The UDP services we wish to allow to pass - "" empty means all ports
# note: space separated
UDPIN="domain"
UDPOUT="domain"

# The ICMP services we wish to allow to pass - "" empty means all types
# ref: /usr/include/netinet/ip_icmp.h for type numbers
# note: space separated
ICMPIN="0 3 11"
ICMPOUT="8 3 11"

# Logging; uncomment the following line to enable logging of datagrams
# that are blocked by the firewall.
# LOGGING=1

# END USER CONFIGURABLE SECTION
###########################################################################
# Flush the Incoming table rules
$IPFWADM -I -f

# We want to deny incoming access by default.
$IPFWADM -I -p deny

# SPOOFING
# We should not accept any datagrams with a source address matching ours
# from the outside, so we deny them.
$IPFWADM -I -a deny -S $OURNET -W $ANYDEV

# SMURF
# Disallow ICMP to our broadcast address to prevent "Smurf" style attack.
$IPFWADM -I -a deny -P icmp -W $ANYDEV -D $OURBCAST

# TCP
# We will accept all TCP datagrams belonging to an existing connection
# (i.e. having the ACK bit set) for the TCP ports we're allowing through.
# This should catch more than 95 % of all valid TCP packets.
$IPFWADM -I -a accept -P tcp -D $OURNET $TCPIN -k -b

# TCP - INCOMING CONNECTIONS
# We will accept connection requests from the outside only on the
# allowed TCP ports.
$IPFWADM -I -a accept -P tcp -W $ANYDEV -D $OURNET $TCPIN -y

# TCP - OUTGOING CONNECTIONS
# We accept all outgoing tcp connection requests on allowed TCP ports.
$IPFWADM -I -a accept -P tcp -W $OURDEV -D $ANYADDR $TCPOUT -y

# UDP - INCOMING
# We will allow UDP datagrams in on the allowed ports.
$IPFWADM -I -a accept -P udp -W $ANYDEV -D $OURNET $UDPIN

# UDP - OUTGOING
# We will allow UDP datagrams out on the allowed ports.
$IPFWADM -I -a accept -P udp -W $OURDEV -D $ANYADDR $UDPOUT

# ICMP - INCOMING
# We will allow ICMP datagrams in of the allowed types.
$IPFWADM -I -a accept -P icmp -W $ANYDEV -D $OURNET $UDPIN

# ICMP - OUTGOING
# We will allow ICMP datagrams out of the allowed types.
$IPFWADM -I -a accept -P icmp -W $OURDEV -D $ANYADDR $UDPOUT

# DEFAULT and LOGGING
# All remaining datagrams fall through to the default
# rule and are dropped. They will be logged if you've
# configured the LOGGING variable above.
#
if [ "$LOGGING" ]
then
        # Log barred TCP
        $IPFWADM -I -a reject -P tcp -o

        # Log barred UDP
        $IPFWADM -I -a reject -P udp -o

        # Log barred ICMP
        $IPFWADM -I -a reject -P icmp -o
fi
#
# end.

Теперь мы повторно выполним это, используя команду ipchains:

#!/bin/bash
##########################################################################
# IPCHAINS VERSION
# This sample configuration is for a single host firewall configuration
# with no services supported by the firewall machine itself.
##########################################################################

# USER CONFIGURABLE SECTION

# The name and location of the ipchains utility.
IPCHAINS=ipchains

# The path to the ipchains executable.
PATH="/sbin"

# Our internal network address space and its supporting network device.
OURNET="172.29.16.0/24"
OURBCAST="172.29.16.255"
OURDEV="eth0"

# The outside address and the network device that supports it.
ANYADDR="0/0"
ANYDEV="eth1"

# The TCP services we wish to allow to pass - "" empty means all ports
# note: space separated
TCPIN="smtp www"
TCPOUT="smtp www ftp ftp-data irc"

# The UDP services we wish to allow to pass - "" empty means all ports
# note: space separated
UDPIN="domain"
UDPOUT="domain"

# The ICMP services we wish to allow to pass - "" empty means all types
# ref: /usr/include/netinet/ip_icmp.h for type numbers
# note: space separated
ICMPIN="0 3 11"
ICMPOUT="8 3 11"

# Logging; uncomment the following line to enable logging of datagrams
# that are blocked by the firewall.
# LOGGING=1

# END USER CONFIGURABLE SECTION
##########################################################################
# Flush the Input table rules
$IPCHAINS -F input

# We want to deny incoming access by default.
$IPCHAINS -P input deny

# SPOOFING
# We should not accept any datagrams with a source address matching ours
# from the outside, so we deny them.
$IPCHAINS -A input -s $OURNET -i $ANYDEV -j deny

# SMURF
# Disallow ICMP to our broadcast address to prevent "Smurf" style attack.
$IPCHAINS -A input -p icmp -w $ANYDEV -d $OURBCAST -j deny

# We should accept fragments, in ipchains we must do this explicitly.
$IPCHAINS -A input -f -j accept

# TCP
# We will accept all TCP datagrams belonging to an existing connection
# (i.e. having the ACK bit set) for the TCP ports we're allowing through.
# This should catch more than 95 % of all valid TCP packets.
$IPCHAINS -A input -p tcp -d $OURNET $TCPIN ! -y -b -j accept

# TCP - INCOMING CONNECTIONS
# We will accept connection requests from the outside only on the
# allowed TCP ports.
$IPCHAINS -A input -p tcp -i $ANYDEV -d $OURNET $TCPIN -y -j accept

# TCP - OUTGOING CONNECTIONS
# We accept all outgoing TCP connection requests on allowed TCP ports.
$IPCHAINS -A input -p tcp -i $OURDEV -d $ANYADDR $TCPOUT -y -j accept

# UDP - INCOMING
# We will allow UDP datagrams in on the allowed ports.
$IPCHAINS -A input -p udp -i $ANYDEV -d $OURNET $UDPIN -j accept

# UDP - OUTGOING
# We will allow UDP datagrams out on the allowed ports.
$IPCHAINS -A input -p udp -i $OURDEV -d $ANYADDR $UDPOUT -j accept

# ICMP - INCOMING
# We will allow ICMP datagrams in of the allowed types.
$IPCHAINS -A input -p icmp -w $ANYDEV -d $OURNET $UDPIN -j accept

# ICMP - OUTGOING
# We will allow ICMP datagrams out of the allowed types.
$IPCHAINS -A input -p icmp -i $OURDEV -d $ANYADDR $UDPOUT -j accept

# DEFAULT and LOGGING
# All remaining datagrams fall through to the default
# rule and are dropped. They will be logged if you've
# configured the LOGGING variable above.
#
if [ "$LOGGING" ]
then
        # Log barred TCP
        $IPCHAINS -A input -p tcp -l -j reject

        # Log barred UDP
        $IPCHAINS -A input -p udp -l -j reject

        # Log barred ICMP
        $IPCHAINS -A input -p icmp -l -j reject
fi
#
# end.

В нашем примере для iptables мы включили использование набор правил FORWARD из-за различий в реализации набора правил INPUT в netfilter. Это имеет значение: такое отличие означает, что ни одно из правил не защищает firewall главный компьютер непосредственно. Точно подражая примеру с ipchains, мы скопировали каждое из наших правил в INPUT. Для ясности, мы пропустили все входящие пакеты (datagrams), полученные из нашего внешнего интерфейса.

#!/bin/bash
##########################################################################
# IPTABLES VERSION
# This sample configuration is for a single host firewall configuration
# with no services supported by the firewall machine itself.
##########################################################################
# USER CONFIGURABLE SECTION

# The name and location of the ipchains utility.
IPTABLES=iptables

# The path to the ipchains executable.
PATH="/sbin"

# Our internal network address space and its supporting network device.
OURNET="172.29.16.0/24"
OURBCAST="172.29.16.255"
OURDEV="eth0"

# The outside address and the network device that supports it.
ANYADDR="0/0"
ANYDEV="eth1"

# The TCP services we wish to allow to pass - "" empty means all ports
# note: comma separated
TCPIN="smtp,www"
TCPOUT="smtp,www,ftp,ftp-data,irc"

# The UDP services we wish to allow to pass - "" empty means all ports
# note: comma separated
UDPIN="domain"
UDPOUT="domain"

# The ICMP services we wish to allow to pass - "" empty means all types
# ref: /usr/include/netinet/ip_icmp.h for type numbers
# note: comma separated
ICMPIN="0,3,11"
ICMPOUT="8,3,11"

# Logging; uncomment the following line to enable logging of datagrams
# that are blocked by the firewall.
# LOGGING=1

# END USER CONFIGURABLE SECTION
###########################################################################
# Flush the Input table rules
$IPTABLES -F FORWARD

# We want to deny incoming access by default.
$IPTABLES -P FORWARD deny

# Drop all datagrams destined for this host received from outside.
$IPTABLES -A INPUT -i $ANYDEV -j DROP

# SPOOFING
# We should not accept any datagrams with a source address matching ours
# from the outside, so we deny them.
$IPTABLES -A FORWARD -s $OURNET -i $ANYDEV -j DROP

# SMURF
# Disallow ICMP to our broadcast address to prevent "Smurf" style attack.
$IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DENY

# We should accept fragments, in iptables we must do this explicitly.
$IPTABLES -A FORWARD -f -j ACCEPT

# TCP
# We will accept all TCP datagrams belonging to an existing connection
# (i.e. having the ACK bit set) for the TCP ports we're allowing through.
# This should catch more than 95 % of all valid TCP packets.
$IPTABLES -A FORWARD -m multiport -p tcp -d $OURNET --dports $TCPIN /
    ! --tcp-flags SYN,ACK ACK -j ACCEPT
$IPTABLES -A FORWARD -m multiport -p tcp -s $OURNET --sports $TCPIN /
    ! --tcp-flags SYN,ACK ACK -j ACCEPT

# TCP - INCOMING CONNECTIONS
# We will accept connection requests from the outside only on the
# allowed TCP ports.
$IPTABLES -A FORWARD -m multiport -p tcp -i $ANYDEV -d $OURNET $TCPIN /
    --syn -j ACCEPT

# TCP - OUTGOING CONNECTIONS
# We will accept all outgoing tcp connection requests on the allowed /
    TCP ports.
$IPTABLES -A FORWARD -m multiport -p tcp -i $OURDEV -d $ANYADDR /
    --dports $TCPOUT --syn -j ACCEPT
# UDP - INCOMING
# We will allow UDP datagrams in on the allowed ports and back.
$IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -d $OURNET /
    --dports $UDPIN -j ACCEPT
$IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -s $OURNET /
    --sports $UDPIN -j ACCEPT
# UDP - OUTGOING
# We will allow UDP datagrams out to the allowed ports and back.
$IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -d $ANYADDR /
    --dports $UDPOUT -j ACCEPT
$IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -s $ANYADDR /
    --sports $UDPOUT -j ACCEPT
# ICMP - INCOMING
# We will allow ICMP datagrams in of the allowed types.
$IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET /
    --dports $ICMPIN -j ACCEPT
# ICMP - OUTGOING
# We will allow ICMP datagrams out of the allowed types.
$IPTABLES -A FORWARD -m multiport -p icmp -i $OURDEV -d $ANYADDR /
    --dports $ICMPOUT -j ACCEPT
# DEFAULT and LOGGING
# All remaining datagrams fall through to the default
# rule and are dropped. They will be logged if you've
# configured the LOGGING variable above.
#
if [ "$LOGGING" ] then
        # Log barred TCP
        $IPTABLES -A FORWARD -m tcp -p tcp -j LOG
        # Log barred UDP
        $IPTABLES -A FORWARD -m udp -p udp -j LOG
        # Log barred ICMP
        $IPTABLES -A FORWARD -m udp -p icmp -j LOG
fi
#
# end.

Во многих простых случаях все, что надо сделать для конкретного применения этого примера, это поправить в начале файла блок, помеченный “USER CONFIGURABLE section” для указания, какие протоколы и пакеты надо пропускать. Для более сложных конфигураций надо поправить этот раздел целиком. Помните, что это простой пример, так что очень тщательно исследуйте его, чтобы гарантировать, что он делает именно то, что Вы хотите.

Назад | Глобальное оглавление | Вперед
Проверка конфигурации Firewall | Локальное оглавление | IP Accounting


Getting EximUp and Running

Назад Получение и запуск Exim Вперед

Глава 19. Получение и запуск Exim

Локальное оглавление
Запуск Exim
Если почта не работает
Компиляция Exim
Режимы доставки почты
Опции настройки
Маршрутизация и доставка почты
Противоспамовая оборона
Настройка UUCP

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

Основной файл конфигурации обычно назван /etc/exim.conf или /etc/exim/config в большинстве дистрибутивов Linux, или /usr/lib/exim/config в старых версиях. Вы можете выяснить, где искать файл конфигурации командой:
$ exim -bP configure_file

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

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

Когда почта ходит внутри TCP/IP-сети, Exim часто выполняется в режиме daemon: при загрузке системы он вызывается из /etc/init.d/exim и помещает себя в фоновый режим, где ждет входящие TCP-подключения на порте SMTP (обычно порт 25). Это полезно, когда Вы ожидаете большой трафик, потому что Exim не должен запускаться для каждого входящего подключения. Альтернативно, inetd мог бы контролировать порт SMTP и порождать Exim всякий раз, когда имеется подключение на этом порте. Эта конфигурация могла бы быть полезна, когда Вы ограничены в памяти и имеете небольшой трафик почты.

Exim имеет сложный набор параметров командной строки, многие из которых соответствуют таким же параметрам sendmail. Вместо поиска нужных параметров можно выполнять многие общие действия, вызывая соответствующие команды, например, rmail или rsmtp. Они являются символическими связями с Exim. Когда Вы выполняете одну из команд, Exim проверяет имя, которое Вы используете, чтобы вызвать его, и устанавливает соответствующие параметры самостоятельно.

Имеются две связи с Exim, которые Вы должны иметь при любых обстоятельствах: /usr/bin/rmail и /usr/sbin/sendmail. Когда Вы составляете и посылаете сообщение почты пользовательским агентом, подобным elm, оно направляется по каналу к sendmail или rmail для доставки. Именно поэтому /usr/sbin/sendmail и /usr/bin/rmail должны указывать на Exim. Список получателей сообщения будет передан Exim в командной строке. То же самое случается с почтой, приходящей через UUCP. Вы можете устанавливать требуемые имена пути, чтобы указать на Exim, печатая следующее в ответ на приглашение оболочки:
$ ln -s /usr/sbin/exim /usr/bin/rmail
$ ln -s /usr/sbin/exim /usr/sbin/sendmail

Если Вы хотите детально изучить настройку Exim, Вы должны ознакомиться с полной спецификацией Exim. Если она не входит в Ваш дистрибутив Linux, ее можно получить на сайте Exim по адресу http://www.exim.org.

Запуск Exim

Для запуска Exim, сначала надо решить, хотите ли Вы, чтобы он обрабатывал входящие SMTP-сообщения, работая как отдельный daemon, или поставить inetd управлять SMTP-портом и вызывать Exim только когда SMTP-подключение будет запрошено пользователем. Обычно Вы предпочтете вариант daemon на почтовом сервере, поскольку это загружает машину гораздо меньше, чем порождение через inetd. А при небольшом трафике лучше именно запуск через inetd.

Любой режим работы Вы выбираете для каждого компьютера индивидуально. Вы должны удостовериться, что имеете следующую запись в файле /etc/services:
smtp            25/tcp          # Simple Mail Transfer Protocol

Это определяет номер порта TCP для протокола SMTP. Он определен как 25 в "Assigned Numbers" RFC (RFC-1700).

При запуске в режиме демона Exim переходит в фоновый режим и ждет соединений через SMTP-порт. Когда подключение происходит, он разветвляется, и порожденный процесс проводит сеанс связи SMTP с таким же процессом на удаленной машине. Exim daemon обычно вызывается из rc скрипта при загрузке командой:
/usr/sbin/exim -bd -q15m

Параметр –bd включает режим daemon, а –q15m заставляет обрабатывать любые сообщения, накопленные в очереди сообщений, каждые 15 минут.

Если нужно использовать inetd, впишите в файл /etc/inetd.conf такую строку:
smtp    stream  tcp nowait  root  /usr/sbin/exim  in.exim -bs

Помните, что после изменений этого файла нужно сообщить inetd, чтобы он перечитал inetd.conf. Для этого после внесения изменений пошлите ему сигнал HUP.

Режимы daemon и inetd взаимоисключающие. Если Вы запускаете Exim в режиме daemon, удостоверьтесь, что в inetd.conf закомментированы все строки для протокола smtp. Аналогично, при запуске Exim через inetd проверьте, чтобы в скриптах rc не было команды на загрузку Exim как daemon.

Вы можете проверять, что Exim правильно установлен для получения входящих SMTP-сообщений, соединяясь программой telnet с SMTP-портом на Вашей машине. При нормальной работе системы Вы увидите примерно следующее:
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 richard.vbrew.com ESMTP Exim 3.13 #1 Sun, 30 Jan 2000 16:23:55 +0600
quit
221 richard.brew.com closing connection
Connection closed by foreign host.

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

Назад | Глобальное оглавление | Вперед
Советы и секреты |  | Если почта не работает


Miscellaneous config Options

Назад Глава 19. Получение и запуск Exim Вперед

Опции настройки

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

message_size_limit

Ограничивает размер сообщений, принимаемых Exim.

return_size_limit

Установка этой опции ограничивает размер входящих сообщений, которые Exim возвращает как часть сообщений об ошибках.

deliver_load_max

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

smtp_accept_max

Это максимальное число одновременных входящих вызовов SMTP, которые принимает Exim.

log_level

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

Назад | Глобальное оглавление | Вперед
Режимы доставки почты | Локальное оглавление | Маршрутизация и доставка почты


Expiring News

Назад Глава 21. C News Вперед

Устаревшие новости

В Bnews, устаревание cтатей выполняется программой expire, которая принимает список групп новостей как аргументы вместе с указанием времени, после которого статьи должны устареть. В C-News есть специальный файл explist, в котором можно указывать время старения для каждой группы новостей. Ежедневно вызывается команда doexpire (из демона cron), которая обрабатывает все группы в соответствии со списком.

Иногда Вы хотите сохранять статьи из некоторых групп даже после того, как они устарели; например, программы, зарегистрированные в comp.sources.unix. Это называется архивированием. Файл explist разрешает Вам отмечать группы для архивирования.

Записи в explist имеют следующий формат:
grouplist perm times archive

grouplist представляет собой разделенный запятыми список newsgroups (групп новостей), к которым применяется эта запись. Иерархии могут быть определены префиксом имени группы, необязательно добавляется ключ all. Например, для записи, обращающейся ко всем группам ниже иерархии comp.os, Вы могли бы ввести comp.os или comp.os.all.

При устаревании новости из группы, имя будет проверено для всех записей в explist в данном порядке. Применяется первая соответствующая запись. Например, чтобы отбросить большую часть comp через четыре дня, кроме comp.os.linux.announce, которую Вы хотите хранить в течение недели, Вы просто должны иметь запись для 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/ содержит значения по умолчанию для трех значений поля times, описанного выше.

Поле /expired/ определяет, как долго C-News будет хранить строки в файле хронологии. Это необходимо, потому что C-News не будет удалять строку из файла хронологии, если соответствующая статья устарела, но будет хранить ее в случае, если дубликат должен прибыть после этой даты. Если Вы подпитываетесь новостями с одного сайта, можете задать небольшое значение. Иначе установите порядка двух недель, в зависимости от времени хранения статей (особенно в UUCP-сетях).

Простой файл explist воспроизведен ниже:
# keep history lines for two weeks. No article 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 не модифицирует это поле. Если Вы хотите, чтобы это поле представляло реальную ситуацию, Вы должны выполнить программу, называемую updatemin, после каждого выполнения doexpire. В старых версиях C-News аналогичные задачи возложены на скрипт upact.

Кроме того, C-News не сканирует каталоги новостей в поисках устаревших. Вместо этого он анализирует файл хронологии (файл history). А ведь совсем не факт, что этот файл соответствует реальному положению дел! Например, если он оказался неправильным, на диске появятся "вечные" статьи, которые не удалятся никогда, а вот место занимать будут. Для борьбы с ними есть скрпт addmissing в каталоге /usr/lib/news/maint, который добавляет потерянные статьи в файл, или mkhistory, который просто заново создает файл history. Эти команды должны выполняться от имени пользователя news, иначе Вы получите еще худшую ситуацию, когда C-News вообще не может прочитать или обновить файл history.

Назад | Глобальное оглавление | Вперед
Пакетирование статей | Локальное оглавление | Прочие файлы


The exports File

Назад Глава 14. Сетевая файловая система (Network File System) Вперед

Файл exports

Рассмотрим, как настроить сервер NFS. Здесь можно задать, какие каталоги доступны клиентам, в каких режимах предоставляется доступ, а также можно дополнительно задать много параметров для управления доступом клиентов к файловой системе сервера. Файл /etc/exports перечисляет системы, которые сервер предоставляет для общего доступа.

По умолчанию, rpc.mountd не позволяет кому угодно монтировать файловые системы по сети, что является довольно разумной позицией. Для того, чтобы разрешить одному или большему количеству хостов монтировать nfs-каталог, он должен быть экспортирован, то есть определен в файле exports. Типовой файл может выглядеть следующим образом:
# exports file for vlager
/home             vale(rw) vstout(rw) vlight(rw)
/usr/X11R6        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 также, как и laboratory.foo.com. Если имя хоста не задано, как с каталогом /home/ftp в примере выше, то любому хосту позволено монтировать этот каталог. Хост может быть также задан его IP-адресом в форме address/ netmask.

При проверке клиентского хоста по файлу exports, rpc.mountd будет искать имя клиента, используя вызов gethostbyaddr. С DNS этот вызов возвращает каноническое имя машины клиента, так что Вы должны удостовериться в том, не используются ли псевдонимы в exports. Без использования DNS, возвращенное имя будет первым подходящим именем, найденным в файле hosts, которое соответствует адресу клиента.

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

secure

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

insecure

Задает действие, обратное действию параметра secure.

ro

Монтировать каталог NFS только для чтения. Задан по умолчанию.

rw

Монтировать каталог NFS для чтения и записи.

root_squash

Все обращения по NFS выполнять от имени пользователя nobody (uid 65534) на сервере независимо от того, пользователь с каким uid послал запрос с клиента.

no_root_squash

Не отображать uid 0 на uid 65534. Задан по умолчанию.

link_relative

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

link_absolute

Оставляет все символьные связи такими, какими они и были (нормальное поведение для Sun NFS серверов).

map_identity

Клиентские uids и gids соответствуют серверным. Задан по умолчанию.

map_daemon

Клиент и сервер не разделяют пространство uid/gid. rpc.nfsd построит карту отображений ID клиента и сервера, запрашивая на клиенте демон rpc.ugidd.

map_static

Этот параметр позволяет Вам определять имя файла, который содержит статическую карту uids и gids. Например, map_static=/etc/nfs/vlight.map определит файл /etc/nfs/vlight.map как карту uid/gid. Синтаксис файла карты описан на man-странице exports(5).

map_nis

Предписывает NIS-серверу выполнять работу по отображению uid и gid.

anonuid и anongid

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

Все ошибки при обработке файла exports будут переданы syslogd daemon на уровне notice при запуске rpc.nfsd или rpc.mountd.

Заметьте, что имена хостов будут получены из IP-адресов клиентов обратным поиском, так что Вы должны иметь правильно сконфигурированный сервер имен. Если Вы используете BIND, то Вы должны включить контроль спуфинга в Вашем файле host.conf. Подробно это рассмотрено в главе 6.

Назад | Глобальное оглавление | Вперед
NFS Daemons | Локальное оглавление | Поддержка серверов NFS v2


Preface

Назад Вперед

Введение

Локальное оглавление
Цель и аудитория этой книги
Источники информации
Стандарты файловой системы
Стандартная база Linux
Про эту книгу
Официальные печатные версии
Обзор
Соглашения, принятые в книге
Подписка на обновления
Acknowledgments

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

Конечно, работа с сетями была доступна давно. Соединение компьютеров, чтобы формировать локальные сети, было общей практикой даже в маленьких организациях. Но действительно широкое распространение сети получили с появлением Internet. Создание хоста Internet с поддержкой почты и новостей, предоставляющего dialup-доступ, стало относительно простым, а появление ISDN только ускорило процесс. Сейчас развиваются еще две технологии скоростного доступа DSL (Digital Subscriber Line) и Cable Modem.

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

Что делает Unix особенно интересной частным пользователям, так это активность по созданию свободных систем на ее основе для PC, например 386BSD, FreeBSD и Linux.

Linux свободно распространяемый аналог Unix для персональных компьютеров. Она в настоящее время выполняется на ряде машин, включая Intel, системы на базе Motorola 680x0 (например, Commodore Amiga и Apple Macintosh), Sun SPARC, Ultra-SPARC, Compaq Alpha, MIPS, PowerPC (новое поколение Apple Macintosh) и даже на системах StrongARM (rebel.com Netwinder и 3Com Palm). Linux была перенесена и на ряд не слишком распространенных платформ, например, Fujitsu AP-1000 и IBM System 390. Но этот процесс не закончен. Идут работы по переносу данной системы на другие архитектуры.

Linux была разработана большой группой добровольцев через Internet. Проект был начат в 1990 году студентом колледжа в Финляндии Линусом Торвальдсом (Linus Torvalds). На сегодняшний день Linux представляет собой полнофункциональный клон Unix. Много аппаратных средств поддерживаются, и Linux содержит полную реализацию TCP/IP-стека для работы с сетями, включая SLIP, PPP, firewall, полную поддержку IPX.

ОС Linux распространяется по лицензии GNU General Public License. Эта лицензия позволяет любому желающему распространять или переделывать программное обеспечение (бесплатно или для прибыли) пока все модификации и дистрибутивы также свободно распространяются. Термин "free software" (свободное программное обеспечение) относится к свободной модификации программ, а не к их бесплатности. Как раз наоборот, на таком программном обеспечении немало фирм зарабатывают хорошие деньги.

Цель и аудитория этой книги

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

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

Назад | Глобальное оглавление | Вперед
Linux Network Administrators Guide |  | Источники информации


What Is IP Filtering?

Назад Глава 9. TCP/IP Firewall Вперед

Что такое IP Filtering?

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

  • Типы протоколов: TCP, UDP, ICMP и т.д.

  • Номера портов (для TCP/UPD)

  • Типы пакетов: SYN/ACK, data, ICMP Echo Request и т.д.

  • Откуда пришел пакет

  • Куда идет пакет

Важно понять, что IP-фильтрация является средством сетевого уровня. Это означает, что она не понимает ничего относительно прикладной программы, использующей сетевые подключения, а понимает только что-то непосредственно относительно подключений. Например, Вы можете отвергать доступ пользователей к Вашей внутренней сети через telnet-порт, но если Вы полагаетесь ТОЛЬКО на IP-фильтрацию, Вы не сможете запретить использование программы telnet с портом, с которого Вы позволяете передавать пакеты через Ваш firewall. Вы можете предотвращать эти проблемы, используя прокси-сервер для каждого сервиса, проходящего через firewall. Прокси-серверы понимают прикладную программу, под которую они были разработаны, и предотвращают злоупотребления типа использования программы telnet, чтобы обойти firewall через порт для World Wide Web. Если Ваш firewall поддерживает прокси для World Wide Web, telnet будет всегда соединяться только с ним, и проходить будут только HTTP-запросы. Есть много прокси-серверов, как коммерческих, так и свободных. Они хорошо рассмотрены в Firewall-HOWTO.

Набор правил IP-фильтрации задает много правил. Например, допустим, что Вы позволяете пользователям World Wide Web в сети Virtual Brewery network обращаться только к другим web-серверам в Internet. Настройте Ваш firewall на пропуск пакетов:

  • С исходными адресами сети Virtual Brewery network, любым сайтом назначения и портом назначения 80 (WWW)

  • С адресом назначения в сети Virtual Brewery network и портом назначения 80 (WWW) с любого исходного адреса.

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

Назад | Глобальное оглавление | Вперед
Что такое Firewall? | Локальное оглавление | Настройка Firewall в Linux


Three Ways We Can Do Filtering

Назад Глава 9. TCP/IP Firewall Вперед

Три способа фильтрации

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

  • (1) IP-пакет откуда-то пришел.

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

  • (2) Если он для этой машины, то обработан в местном масштабе.

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

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

  • Исходящий IP-пакет будет исследован, чтобы определить, есть ли имеющий силу маршрут для него, если нет, он будет пропущен.

  • (5) IP-пакет куда-то отправится.

В этой схеме поток 1-3-5 представляет нашу машину, направляющую данные между компьютером в нашей сети Ethernet на другой доступный компьютер через какую-то связь (в дальнейших примерах это будет PPP). Потоки 1-2 и 4-5 представляют ввод данных и выходные потоки сетевой программы, работающей на нашем локальном компьютере. Поток 4-3-2 представляет передачу данных по кольцевому внутреннему интерфейсу (loopback connection).

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

В ipfwadm и ipchains правило Input применяется к потоку 1, правило Forwarding к потоку 3 и правило Output к потоку 5. Позже, при обсуждении netfilter, мы увидим, какие точки перехвата изменились так, чтобы правило Input применилось в потоке 2 и правило Output в потоке 4. Это имеет важное значение для того, как Вы структурируете свой набор правил, но общий принцип остается верным для всех версий Linux firewall.

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

Назад | Глобальное оглавление | Вперед
Установка Firewall в Linux | Локальное оглавление | IP Firewall (ядра 2.0)


TCP/IP Firewall

Назад Вперед

Глава 9. TCP/IP Firewall

Локальное оглавление
Методы атаки
Что такое Firewall?
Что такое IP Filtering?
Установка Firewall в Linux
Три способа фильтрации
IP Firewall (ядра 2.0)
IP Firewall Chains (ядра 2.2)
Netfilter и таблицы IP (ядра 2.4)
Управление битами TOS
Проверка конфигурации Firewall
Пример конфигурации Firewall

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

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

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

Предупреждение

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

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

Building Internet Firewalls

Авторы: D. Chapman и E. Zwicky (издательство O'Reilly). Это полная энциклопедия по созданию и использованию firewall для Unix, Linux и даже Windows NT. Рассмотрены также вопросы о том, как настроить службы Internet для работы через firewall.

Firewalls and Internet Security

Авторы: W. Cheswick и S. Bellovin (издательство Addison Wesley). Книга скорее о философии построения firewall, чем о конкретных программах, но в ней есть немало ценного по реализации этой философии.

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

Методы атаки

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

Несанкционированный доступ

Это значит, что к Вашим системам подключается тот, кому делать этого не следует. Например, кто-то пытается смонтировать Ваши каталоги NFS.

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

Эксплуатация известных слабостей в программах

Некоторые программы и сетевые услуги первоначально не были разработаны с сильной защитой. Пример этого: BSD remote services (rlogin, rexec и другие r-сервисы). Термин "эксплойт" появился как раз из этого вида атак.

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

Denial of service

Так называемые Denial of service attacks (атаки отрицания обслуживания) заставляют сервис или программу перестать работать или не дают другим их использовать. Они могут выполняться в сетевом уровне, посылкой тщательно подготовленных пакетов, которые сервис обработать не сможет. Они могут также выполняться в уровне прикладной программы, где тщательно подготовленные команды должны перегрузить избранный сервис.

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

Spoofing

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

Защита против этого типа атак проста: надо тщательно отслеживать, откуда на самом деле пришел пакет, и соответствует ли его внутренняя информация тому окружению, которое ему сопутствует.

Eavesdropping

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

Здесь помогает шифрование трафика.

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

Назад | Глобальное оглавление | Вперед
Продвинутая настройка PPP |  | Что такое Firewall?


Flushing the Ruleset

Назад Глава 10. IP Accounting Вперед

Удаление набора правил

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

Параметр -f в команде ipfwadm удалит все правила заданного типа. ipchains использует параметр -F, который делает то же самое:
# ipfwadm -A -f
или:
# ipchains -F
или:
# iptables -F
Это удаляет все Ваши правила, избавляя от необходимости убирать каждое в отдельности. Обратите внимание, что в ipchains эта операция не уничтожает заданных пользовательских цепочек, а только вычищает из них правила.

Назад | Глобальное оглавление | Вперед
Перезапуск счетчиков | Локальное оглавление | Пассивные коллекции данных доступа


Netfilter and IP Tables (2.4 Kernels)

Назад Глава 9. TCP/IP Firewall Вперед

Netfilter и таблицы IP (ядра 2.4)

При разработке IP Firewall Chains, Paul Russell решил, что IP firewall должен быть проще. Он стал совершенствовать код фильтра и создал пакет, который оказался много проще и мощнее. Это netfilter.

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

Так, что было неправильно с IP chains? Они значительно улучшили эффективность и управление правилами firewall. Но они все равно обрабатывали пакеты очень длинным путем, особенно в связке с другими возможностями firewall, например, IP masquerade (описан в главе 11) и другими формами трансляции адреса. Часть этой проблемы существовала потому, что IP masquerade (маскировка IP) и Network Address Translation (сетевая трансляция адресов) были разработаны независимо от IP firewall и интегрированы в него позже.

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

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

Ключевыми различиями стало удаление из ядра кода для маскировки IP и изменение в логике работы наборов правил input и output. Появился новый расширяемый инструмент конфигурации iptables.

В IP chains набор правил input применяется ко всем пакетам, полученным компьютером, независимо от того, предназначены ли они для локального компьютера или направлены на другой компьютер. В netfilter набор правил input применяется только к пакетам, предназначенным для локального компьютера. Цепочка forward теперь применяется исключительно к пакетам, предназначенным для передачи другому компьютеру. В IP Сhains набор правил output применяется ко всем пакетам, исходящим с компьютера, независимо от того, сгенерированы ли они на локальном компьютере. В netfilter этот набор применяется только к пакетам, сгенерированным на этом компьютере, и не применяется к пакетам, проходящим транзитом. Это изменение резко упростило настройку.

Еще одной новостью стало вынесение компонентов работы с маскировкой IP в отдельные модули ядра. Они были переписаны как модули netfilter.

Рассмотрим случай конфигурации, в которой по умолчанию для input, forward и output задана стратегия deny. В IP chains для пропуска всех пакетов потребовалось бы шесть правил.

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

Документ PACKET-FILTERING-HOWTO предлагает очень подробный список изменений, которые были сделаны. Поэтому давайте сосредоточимся на более практических аспектах.

Обратная совместимость с ipfwadm и ipchains

Замечательная гибкость Linux netfilter иллюстрируется способностью подражать интерфейсам ipfwadm и ipchains. Эмуляция делает переход к новому поколению программного обеспечения firewall немного проще.

Два модуля ядра из netfilter с именами ipfwadm.o и ipchains.o обеспечивают обратную совместимость с ipfwadm и ipchains. Можно загрузить одновременно только один из этих модулей и использовать его только при условии, что модуль ip_tables.o не загружен. Когда соответствующий модуль загружен, netfilter работает аналогично заданной реализации firewall.

Чтобы netfilter копировал интерфейс ipchains скомандуйте:
# rmmod ip_tables
# modprobe ipchains
# ipchains
...

Использование iptables

Утилита iptables используется для настройки правил netfilter. Синтаксис заимствован у ipchains, но имеет важное отличие: он расширяемый. Это означает, что функциональные возможности могут быть расширены без перекомпиляции пакета. Для этого используются разделяемые библиотеки. Имеются стандартные расширения, ряд которых мы сейчас изучим.

Перед использованием команды iptables Вы должны загрузить модуль ядра netfilter, который позволяет ей работать. Проще всего сделать это командой modprobe:
# modprobe ip_tables

Команда iptables используется для настройки IP filter и Network Address Translation. Для этого используются две таблицы: filter и nat. Если не задана опция -t, используется таблица filter. Доступны пять встроенных цепочек (наборов правил): INPUT и FORWARD для таблицы filter, PREROUTING и POSTROUTING для таблицы nat и OUTPUT для всех таблиц. В этой главе я расскажу только о таблице filter, таблица nat описана в главе 11.

Синтаксис команд iptables в общем виде таков:

iptables command rule-specification extensions
Теперь мы будем рассмотрим некоторые параметры подробно, после чего перейдем к примерам.

Команды

Команды позволяют управлять правилами и наборами правил iptables. К IP firewall относятся:

-A chain

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

-I chain rulenum

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

-D chain

Удаляет одно или несколько правил из определенной цепочки, которая соответствует заданной спецификации правил.

-D chain rulenum

Удаляет правило в позиции rulenum указанной цепочки. Нумерация начинается с 1.

-R chain rulenum

Заменяет правило в позиции rulenum указанной цепочки заданным правилом.

-C chain

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

-L [chain]

Выведет список правил в наборе, или всех правил, если конкретный набор не задан.

-F [chain]

Стирает правила в наборе или во всех наборах, если конкретный набор не задан.

-Z [chain]

Обнуляет счетчикик пакетов и байтов для всех правил в наборе или для всех наборов, если конкретный набор не задан.

-N chain

Создает новую цепочку с заданным именем. Таким способом создаются задаваемые пользователем цепочки.

-X [chain]

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

-P chain policy

Задает стратегию по умолчанию для указанной цепочки. Допустимые стратегии: ACCEPT, DROP, QUEUE и RETURN. ACCEPT пропускает пакет. DROP отбрасывает пакет. QUEUE передает пакет пользовательской цепочке для дальнейшей обработки. RETURN заставляет IP firewall вернуться к цепочке, правило которой вызвало эту ситуацию, и предписывает продолжить ее обработку со следующего правила.

Параметры определения правил

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

-p [!]protocol

Указывает протокол, соответствующий правилу. Допустимы имена протоколов tcp, udp, icmp. Можно задать номер протокола для протоколов, которые здесь не определены. Например, 4 для протокола ipip. Если задан префикс !, правило превращается в отрицательное, и принимаются все пакеты, не соответствующие этому протоколу. Значение по умолчанию: все протоколы.

-s [!]address[/mask]

Указывает исходный адрес и порт, с которого пришел пакет. Адрес может задавать имя машины, имя сети или IP-адрес. Опция mask задает сетевую маску. Она может быть задана в обычной форме (например, /255.255.255.0) или в новой (например, /24). Опция port задает порт TCP или UDP, или тип пакетов ICMP. Вы можете задать спецификацию порта только, если Вы задали параметр -p с одним из протоколов tcp, udp или icmp. Порты могут быть определены как диапазон, определяя верхние и нижние границы диапазона с двоеточием в качестве разделителя. Например, 20:25 определяет порты с 20 по 25 включительно. Символ ! превращает правило в его противоположность.

-d [!]address[/mask]

Задает адрес и порт назначения. Во всем остальном аналогичен параметру -s.

-j target

Указывает, что делать при срабатывании правила. Допустимые действия: ACCEPT, DROP, QUEUE и RETURN. Ранее я уже описал значение каждого действия. Однако, Вы можете также задать имя определяемой пользователем цепочки, в которой продолжится обработка. Если этот параметр опущен, будут только изменены данные пакетов и счетчиков, но ничего с этим пакетом сделано не будет.

-i [!]interface-name

Задает интерфейс, с которого пришел пакет, или через который пакет будет передан. Символ ! переворачивает результат сравнения. Если имя интерфейса кончается на +, ему будут соответствовать все интерфейсы, имена которых начинаются на заданную строку. Например, -i ppp+ совпадает со всеми PPP-интерфейсами, а -i ! eth+ соответствует всем интерфейсам, кроме Ethernet.

-o [!]interface-name

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

[!] -f

Указывает, что это правило применяется ко второму и последующим, но не к первому, фрагментам пакета.

Опции

Опции iptables имеют более широкое значение. Они предоставляют доступ к тайным свойствам этой программы.

-v

Предписывает iptables выдавать подробную информацию.

-n

Предписывает iptables использовать IP-адреса и порты, не пытаясь преобразовать их в имена.

-x

Любые числа в выводе iptables будут точными (округление не используется).

- -line-numbers

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

Расширения (Extensions)

Ранее мы рассматривали, что iptables расширяется с помощью модулей. Имеется стандарт расширений, который обеспечивает некоторые из свойств ipchains. Чтобы использовать расширение, Вы должны определить имя через параметр -m name в iptables. Следующий список показывает опции -m и -p, которые устанавливают расширения контекста.

TCP-расширения: использование с опциями -m tcp -p tcp

- -sport [!] [port[:port]]

Определяет порт, который должен использовать источник пакетов, чтобы соответствовать этому правилу. Можно задать диапазон, указав верхние и нижние границы, например: 20:25 задает все порты с 20 по 25 включительно. Символ ! переворачивает значение.

- -dport [!] [port[:port]]

Задает порт, который должны использовать исходящие пакеты. В остальном аналогичен - -sport.

- -tcp-flags [!] mask comp

Определяет, что это правило должно работать, когда флажки в TCP-пакете соответствуют определениям mask и comp. mask задает (через запятую) перечень флажков, а comp указывает их состояние. Допустимы флажки: SYN, ACK, FIN, RST, URG, PSH, ALL или NONE. Это сложный параметр: ознакомьтесь со значением флажков в каком-нибудь хорошем описании протокола TCP, например, в RFC-793. Действие символа ! обычное для всех правил: он переворачивает значение.

[!] - -syn

Устанавливает, что у пакета должны быть выставлены в 1 флажок SYN и в 0 флажки ACK и FIN. Пакет с этими параметрами используется для создания TCP-соединения, и эту опцию можно использовать для отлова запросов подключения. Эта опция эквивалент для:
- -tcp-flags SYN,RST,ACK SYN
Когда Вы используете оператор отрицания, правило будет соответствовать всем пакетам, флажки SYN и ACK которых вместе не установлены в 1.

UDP-расширения: использование с опциями -m udp -p udp

- -sport [!] [port[:port]]

Определяет порт, который должен использовать источник пакетов, чтобы соответствовать этому правилу. Можно задать диапазон, указав верхние и нижние границы, например: 20:25 задает все порты с 20 по 25 включительно. Символ ! переворачивает значение.

- -dport [!] [port[:port]]

Задает порт, который должны использовать исходящие пакеты. В остальном аналогичен - -sport.

ICMP-расширения: использование с опциями -m icmp -p icmp

- -icmp-type [!] typename

Указывает подходящие этому правилу сообщения ICMP. Типы сообщений можно задать номерами или именами. Допустимые имена: echo-request, echo-reply, source-quench, time-exceeded, destination-unreachable, network-unreachable, host-unreachable, protocol-unreachable и port-unreachable.

MAC-расширения: использование с опциями -m mac

- -mac-source [!] address

Задает, с какого адреса в сети Ethernet должен придти пакет для этого правила. Это имеет смысл только в правилах input или forward, поскольку любой передаваемый нами пакет должен соответствовать правилам output.

Вернемся к нашим примерам

Теперь используя netfilter, Вы могли бы просто загружать модуль ipchains.o и работать с ним, как с ipchains. Вместо этого, мы повторно напишем наши правила, используя iptables.

Как и раньше, мы предполагаем, что есть сеть некоей организации, на Linux-машине запущен firewall. Все внутренние пользователи имеют доступ к WWW-серверам в Internet, но и только.

Если сеть использует сетевую маску в 24 бита (класс C) и имеет адрес сети 172.16.1.0, нужно использовать правила iptables:
# modprobe ip_tables
# iptables -F FORWARD
# iptables -P FORWARD DROP
# iptables -A FORWARD -m tcp -p tcp -s 0/0 --sport 80 -d 172.16.1.0/24 / --syn -j DROP
# iptables -A FORWARD -m tcp -p tcp -s 172.16.1.0/24 --sport / 80 -d 0/0 -j ACCEPT
# iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 --dport 80 -s 0/0 -j / ACCEPT

В этом примере iptables работает точно как команда ipchains. Вся разница в том, что надо предварительно загрузить модуль ip_tables.o. Обратите внимание, что iptables не поддерживает опцию -b, так что мы должны отдельно задать правило для каждого направления.

Назад | Глобальное оглавление | Вперед
IP Firewall Chains (ядра 2.2) | Локальное оглавление | Управление битами TOS


IP Firewall Chains (2.2 Kernels)

Назад Глава 9. TCP/IP Firewall Вперед

IP Firewall Chains (ядра 2.2)

Большинство аспектов Linux развиваются, чтобы удовлетворить увеличивающиеся запросы пользователей. IP firewall не исключение. Традиционная версия IP firewall прекрасна для большинства прикладных программ, но может быть неэффективен, чтобы конфигурировать сложные среды. Чтобы решить эту проблему, был разработан новый метод конфигурирования IP firewall и связанных свойств. Этот новый метод был назван "IP Firewall Chains" и впервые был выпущен для общего использования в ядре Linux 2.2.0.

IP Firewall Chains разработан Paul Russell и Michael Neuling. Paul описал IP Firewall Chains в IPCHAINS-HOWTO.

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

IP Firewall Chains поддерживается серией ядер 2.2 и доступен как патч для серии 2.0.* ядер. HOWTO описывает, где получить патч и дает большое количество полезных советов относительно того, как использовать утилиту конфигурации ipchains.

Использование ipchains

Имеются два пути, которыми Вы можете использовать ipchains. Первый путь состоит в том, чтобы использовать скрипт ipfwadm-wrapper, который является заменой ipfwadm, управляющий программой ipchains в фоновом режиме. Если Вы хотите сделать именно это, то не читайте дальнейшее описание, а вернитесь к описанию ipfwadm, и подставьте везде ipfwadm-wrapper. Это будет работать, но нет никакой гарантии, что скрипт будет поддерживаться, и Вы не будете пользоваться каким-либо из продвинутых свойств, которые может предложить IP Firewall Chains.

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

ipfwadm управлял тремя наборами (цепочками) правил с целью конфигурирования firewall. В IP Firewall Chains Вы можете создавать произвольные наборы (цепочки), связанные друг с другом, но имеется три предопределенных набора. Это прямые эквиваленты тех, которые использовались в ipfwadm, за исключением того, что они имеют имена: input, forward и output.

Давайте сначала рассматривать общий синтаксис команды ipchains, затем рассмотрим, как использовать ipchains вместо ipfwadm без проблем с каким-либо из продвинутых свойств формирования цепочки. Будем делать это, повторно рассматривая предыдущие примеры.

Синтаксис команды ipchains

Синтаксис команды ipchains прост. В общем виде он выглядит так:
ipchains command rule-specification options

Команды

С помощью команд можно управлять правилами и наборами правил для ipchains. Рассмотрим их подробно:

-A chain

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

-I chain rulenum

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

-D chain

Удаляет одно или несколько правил из определенной цепочки, которая соответствует заданной спецификации правил.

-D chain rulenum

Удаляет правило, находящееся в позиции rulenum определенной цепочки. Первое правило в цепочке занимает первую позицию (не нулевую!).

-R chain rulenum

Заменяет правило, находящееся в позиции rulenum определенной цепочки.

-C chain

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

-L [chain]

Перечисляет правила определенной цепочки или всех цепочек, если никакая конкретная цепочка не задана.

-F [chain]

Удаляет правила определенной цепочки или всех цепочек, если никакая конкретная цепочка не задана.

-Z [chain]

Обнуляет пакеты и счетчики для определенной цепочки или всех цепочек, если никакая конкретная цепочка не задана.

-N chain

Создает новую цепочку с заданным именем. Таким способом создаются задаваемые пользователем цепочки.

-X [chain]

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

-P chain policy

Задает стратегию по умолчанию для указанной цепочки. Допустимые стратегии: ACCEPT, DENY, REJECT, REDIR или RETURN. ACCEPT, DENY и REJECT имеют те же самые значения, как для традиционной реализации IP firewall. REDIR определяет, что пакет должен быть переназначен к порту на машине с firewall. RETURN заставляет IP firewall вернуться к цепочке, правило которой вызвало эту ситуацию, и предписывает продолжить ее обработку со следующего правила.

Параметры определения правил

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

-p [!]protocol

Указывает протокол, соответствующий правилу. Допустимы имена протоколов tcp, udp, icmp или all. Можно задать номер протокола для протоколов, которые здесь не определены. Например, 4 для протокола ipip. Если задан префикс !, правило превращается в отрицательное, и принимаются все пакеты, не соответствующие этому протоколу. Значение по умолчанию: all.

-s [!]address[/mask] [!] [port]

Указывает исходный адрес и порт, с которого пришел пакет. Адрес может задавать имя машины, имя сети или IP-адрес. Опция mask задает сетевую маску. Она может быть задана в обычной форме (например, /255.255.255.0) или в новой (например, /24). Опция port задает порт TCP или UDP, или тип пакетов ICMP. Вы можете задать спецификацию порта только, если задали параметр -p с одним из протоколов tcp, udp или icmp. Порты могут быть определены как диапазон, определяя верхние и нижние границы с двоеточием в качестве разделителя. Например, 20:25 определяет порты с 20 по 25 включительно. Символ ! превращает правило в полную его противоположность.

-d [!]address[/mask] [!] [port]

Задает адрес и порт назначения. Во всем остальном аналогичен параметру -s.

-j target

Указывает, что делать при срабатывании правила. Допустимые действия: ACCEPT, DENY, REJECT, REDIR и RETURN. Ранее я уже описал значение каждого действия. Вы можете также задать имя определяемой пользователем цепочки, в которой продолжится обработка. Если этот параметр опущен, будут только изменены данные пакетов и счетчиков, но ничего с этим пакетом сделано не будет.

-i [!]interface-name

Задает интерфейс, с которого пришел пакет, или через который пакет будет передан. Символ ! переворачивает результат сравнения. Если имя интерфейса кончается на +, ему будут соответствовать все интерфейсы, имена которых начинаются на заданную строку. Например, -i ppp+ совпадает со всеми PPP-интерфейсами, а -i ! eth+ соответствует всем интерфейсам, кроме Ethernet.

[!] -f

Указывает, что это правило применяется к первому фрагменту фрагментированного пакета.

Опции

Опции ipchains имеют более широкое значение. Они предоставляют доступ к тайным свойствам этой программы.

-b

Генерирует сразу два правила. Первое точно соответствует заданным параметрам, второе делает то же самое, но прямо противоположными параметрами.

-v

Предписывает ipchains выдавать подробную информацию.

-n

Предписывает ipchains использовать IP-адреса и порты, не пытаясь преобразовать их в имена.

-l

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

-o[maxsize]

Заставляет IP chains копировать все подходящие правилам пакеты в устройство “netlink”. Параметр maxsize ограничивает число байтов из каждого пакета, которые будут переданы на устройство netlink. Эта опция имеет большое значение для разработчиков, но может эксплуатироваться пакетами пользовательских программ в будущем.

-m markvalue

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

-t andmask xormask

Разрешает управление битами TOS (“type of service”) в заголовке IP любого пакета, удовлетворяющего правилам. Биты типа сервиса используются интеллектуальными маршрутизаторами для расположения пакетов перед отправкой в соответствии с их приоритетом. andmask и xormask задают разрядные маски, которые будут использованы в логических операциях AND и OR с битами типа сервиса. Это продвинутое свойство, которое более подробно описано в IPCHAINS-HOWTO.

-x

Любые числа в выводе ipchains будут точными (округление не используется).

-y

Задает правило, которое будет соответствовать любому пакету TCP с установленным битом SYN и неустановленными битами ACK и FIN. Это используется, чтобы фильтровать TCP-запросы.

Вернемся к нашему примеру

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

Если наша сеть имеет 24-битную маску подсети (класс C) и имеет сетевой адрес 172.16.1.0, следует использовать такое правило ipchains:
# ipchains -F forward
# ipchains -P forward DENY
# ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT

Первая команда удаляет все правила из набора forward , вторая устнавливает действие по умолчанию для forward в DENY. Третья и четвертая команды делают специфическую фильтрацию, которую мы хотим. Четвертая команда разрешает доступ к web-серверам, а третья запрещает входящие TCP-подключения с порта 80.

Если мы теперь хотим добавить правила, которые предоставят только пассивный режим доступа к FTP-серверу снаружи сети, мы добавим правила:
# ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT
# ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT

Просмотр наших правил в ipchains

Чтобы перечислить наши правила в команде ipchains, используется параметр -L argument. Точно как с ipfwadm, там могут быть заданы аргументы, которые позволят детализировать вывод. В простейшем случае ipchains выведет нечто вроде:
# ipchains -L -n
Chain input (policy ACCEPT):
Chain forward (policy DENY):
target   prot opt     source          destination     ports
DENY     tcp  -y----  0.0.0.0/0       172.16.1.0/24   80 ->   *
ACCEPT   tcp  ------  172.16.1.0/24   0.0.0.0/0       * ->   80
ACCEPT   tcp  ------  0.0.0.0/0       172.16.1.0/24   80 ->   *
ACCEPT   tcp  ------  172.16.1.0/24   0.0.0.0/0       * ->   20
ACCEPT   tcp  ------  0.0.0.0/0       172.16.1.0/24   20 ->   *
ACCEPT   tcp  ------  172.16.1.0/24   0.0.0.0/0       * ->   21
ACCEPT   tcp  ------  0.0.0.0/0       172.16.1.0/24   21 ->   *

Chain output (policy ACCEPT):

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

Подробная форма, вызываемая опцией -u, обеспечивает намного больше деталей. Вывод добавляет поля для пакетов и счетчиков байтов, Type of Service AND и XOR масок, имени интерфейса и значения меток.

Все правила, созданные ipchains имеют пакеты и счетчики байтов, связанные с ними. Это важно для IP Accounting и будет подробно рассмотрено в главе 10. По умолчанию эти счетчики используются в округленной форме, использующей суффиксы K и M для представления тысячи и миллиона соответственно. Если задан аргумент -x , счетчики работают без округления.

Правильное использование цепочек

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

Определяемые пользователем цепочки

Три набора правил традиционного IP firewall обеспечивают механизм формирования конфигураций firewall, которые были довольно просты в понимании и пригодны для маленьких сетей с простыми требованиями к firewall. Однако, в больших сетях неизбежно возникают большие проблемы и требовавния. Наборы правил растут как снежный ком, управлять ими становится очень сложно. Хуже всего то, что с ростом числа правил падает эффективность IP firewall: ведь программе приходится сравнивать каждый пакет со все большим числом правил. Кроме того, нельзя безопасно отключать наборы правил целиком. Вместо этого, Вы вынуждены выключить некий набор, а пока Вы его перестраиваете, доступ в сеть оказывается открыт всем желающим!

Создание своих цепочек IP Firewall позволит решить почти все эти проблемы. Каждая такая цепочка может использоваться наравне со встроенными. Вы можете использовать параметр -N команды ipchains, чтобы создать новую цепочку с именем не более 8 символов. Ограничение имени символами только нижнего регистра, может быть, неплохая мысль. Опция -j позволяет задать реакцию на соответствие пакета данному правилу. Она может определять, что если пакет подходит под правило, дальше он должен тестироваться по заданному пользователем набору правил. Рассмотрим команды ipchains :
ipchains -P input DENY
ipchains -N tcpin
ipchains -A tcpin -s ! 172.16.0.0/16
ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT
ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT
ipchains -A input -p tcp -j tcpin
ipchains -A input -p all

Мы задали реакцию по умолчанию deny для набора правил input. Вторая команда создает определенную пользователем цепочку tcpin, которая соответствует любому пакету, пришедшему снаружи нашей локальной сети. Третья команда добавляет в нее правило, которое пока не выполняет никаких действий. Это правило нужно для учета и подробно рассмотрено в главе 10. Следующие два правила соответствуют любому пакету, который предназначен для нашей локальной сети и любого из портов ssh или www , такие пакеты будут приняты. Следующее правило как раз то, когда реально начинается волшебство ipchains. Оно вызывает firewall для проверки всех пакетов протокола TCP по набору правил, заданному пользователем. Наконец, мы добавляем правило к нашему набору input, которое соответствует любому пакету. Это еще одно правило учета.

Наши наборы правил input и tcpin заполняются нашими правилами. Процесс обработки пакета всегда начинается в одной из встроенных цепочек. Наша собственная цепочка вступает в дело по команде из одной из встроенных цепочек. Сначала, давайте рассмотрим, что происходит, когда для одного из наших компьютеров получен пакет UDP.

Пакет на приеме попадает в цепочку input. Первые два правила его игнорируют, поскольку они соответствуют ICMP и TCP. Пакет соответствует третьему правилу в input, но оно не определяет адресата, так как просто модифицирует счетчики байтов и пакетов, и не выполняет никакого действия непосредственно с пакетом. Он достигает конца input, встречается с заданной по умолчанию стратегией для input и отклоняется.

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

На это раз второе правило в цепочке input подходит и определяет адресата tcpin, нашу определяемую пользователем цепочку. Задание определяемой пользователем цепочки как адресата приведет к тому, что пакет будет проверен по правилам в ней, так что следующее проверяемое правило, это первое правило в tcpin. Первое правило соответствует любому пакету, который имеет исходный адрес вне нашей локальной сети и не определяет никакого адресата, так что это тоже ччетное правило, и тестирование переходит к следующему правилу. Второе правило в нашей цепочке tcpin соответствует этому пакету и определяет адресата ACCEPT. Итак, пакет принят.

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

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

Этот пример очень прост, но иллюстрирует основную логику работы. Немного более сложный пример:

# Set default forwarding policy to REJECT
ipchains -P forward REJECT
#
# create our user-defined chains
ipchains -N sshin
ipchains -N sshout
ipchains -N wwwin
ipchains -N wwwout
#
# Ensure we reject connections coming the wrong way
ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT
ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT
ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT
ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT
#
# Ensure that anything reaching the end of a user-defined chain is rejected.
ipchains -A sshin -j REJECT
ipchains -A sshout -j REJECT
ipchains -A wwwin -j REJECT
ipchains -A wwwout -j REJECT
#
# divert www and ssh services to the relevant user-defined chain
ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin
ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout
ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin
ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout
#
# Insert our rules to match hosts at position two in our user-defined chains.
ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT
ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT
ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT
ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT
ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT

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

Наш пример создает определяемые пользователем цепочки для сервисов ssh и www в каждом направлении подключения. Есть цепочка wwwout, в ней мы помещаем правила для компьютеров, имеющих право создавать исходящие подключения World Wide Web, и цепочка sshin, хранящая правила для машин, которым можно приинимать входящие подключения ssh. Допустим, нам надо гибко задавать эти разрешения для каждого компьютера в нашей сети. Упрощение происходит, потому что определяемые пользователем цепочки позволяют нам аккуратно группировать правила для прав доступа входящих и исходящих пакетов с компьютеров. Рост эффективности происходит потому, что для любого пакета мы уменьшили среднее число тестов, требуемых для поиска адресата. Если бы мы не использовали определяемые пользователем цепочки, нам бы пришлось искать целый список правил, чтобы узнать какое действие выполнить с каждым пакетом. Даже при условии равномерности поступления пакетов в среднем мы просматривали бы половину списка. Определяемые пользователем цепочки позволяют нам избегать проверки большого числа правил, если проверяемый пакет не соответствует простому правилу во встроенной цепочке, которая вызывает наши цепочки.

Скрипты поддержки ipchains

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

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

Скрипты ipchains-save и ipchains-restore делают формирование и изменение конфигурации firewall много проще. Команда ipchains-save читает текущую конфигурацию firewall и пишет упрощенную форму в стандартный вывод. Команда ipchains-restore читает данные в выходном формате команды ipchains-save и задает конфигурацию IP firewall в соответствии с этими правилами. Преимущество использования этих скриптов в том, что можно динамически менять конфигурацию, а потом ее сохранить в файле.

Чтобы использовать скрипты, введите:

ipchains-save >/var/state/ipchains/firewall.state
для сохранения текущих настроек firewall. Во время загрузки можно их восстановить командой:

ipchains-restore </var/state/ipchains/firewall.state

Скрипт ipchains-restore проверяет существование всех определяемых пользователем цепочек. Если задан параметр -f, он автоматически удалит все правила из пользовательских наборов перед настройкой. По умолчанию, Вам будет задан вопрос, очищать ли эту цепочку.

Назад | Глобальное оглавление | Вперед
IP Firewall (ядра 2.0) | Локальное оглавление | Netfilter и таблицы IP (ядра 2.4)


Serial Devices and the login: Prompt

Назад Глава 4. Настройка последовательного оборудования Вперед

Последовательное оборудование и запрос login:

Когда-то очень распространенным вариантом Unix-систем был такой: одна мощная машина, а вокруг нее много тупых ("dumb") символьных терминалов или модемов. Сейчас такая схема очень редкая, что очень радует. А вот модемы сейчас очень распространены, хотя они используются обычно для сервисов SLIP и PPP (описаны в главе 7 и главе 8). Однако, каждая из этих конфигураций может использовать простую программу, названную getty.

Термин getty сокращение от "get tty" Программа getty открывает последовательное устройство, конфигурирует его, факультативно конфигурирует модем и ждет подключение, которое будет сделано. Активное подключение на последовательном устройстве обычно указывается Data Carrier Detect (DCD) штырьком в последовательном шнуре. Когда происходит соединение, getty выдает приглашение login: и затем вызывает программу login, чтобы обработать вход в систему. Каждый из виртуальных терминалов (устройств /dev/tty1) в Linux имеет свою копию программы getty, запущенную именно для него.

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

Настройка mgetty Daemon

mgetty daemon доступен в исходных кодах с ftp://alpha.greenie.net/pub/mgetty/source и почти во всех дистрибутивах Linux. Демон mgetty отличается от большинства других версий getty, которые были разработаны для Hayes-совместимых модемов. Он поддерживает прямые подключения терминала, но лучше всего подходит для dialup прикладных программ. Вместо DCD-линии для определения входного подключения, эта версия слушает сообщение RING, генерируемое современными модемами, когда они обнаруживают входящее обращение и не сконфигурированы для автоответа.

Главный исполняемый модуль назван /usr/sbin/mgetty , а основной файл настройки /etc/mgetty/mgetty.config. Имеется ряд других программ и файлов конфигурации, которые покрывают другие свойства mgetty .

Для большинства инсталляций настройка сводится к правке /etc/mgetty/mgetty.config и добавлении соответствующих записей в файл /etc/inittab, чтобы выполнять mgetty автоматически.

Пример 4-6 показывает очень простой файл настройки mgetty. Этот пример определяет два последовательных устройства. Первое, /dev/ttyS0, поддерживает Hayes-модем со скоростью 38,400 bps. Второе, /dev/ttyS0, поддерживает терминал прямого доступа VT100 со скоростью 19,200 bps.

Пример 4-6. Простой файл /etc/mgetty/mgetty.config

# mgetty configuration file
#
# this is a sample configuration file, see mgetty.info for details
# comment lines start with a "#", empty lines are ignored
#
# ----- global section -----
# In this section, you put the global defaults, per-port stuff is below
#
# access the modem(s) with 38400 bps
speed 38400
#
# set the global debug level to "4" (default from policy.h)
debug 4
#
# ----- port specific section -----
#
# Here you can put things that are valid only for one line, not the others
#
#
# Hayes modem connected to ttyS0: don't do fax, less logging
#
port ttyS0
  debug 3
  data-only y
#
# direct connection of a VT100 terminal which doesn't like DTR drops
#
port ttyS1
  direct y
  speed 19200
  toggle-dtr n

Файл конфигурации поддерживает глобальные и специфические для порта параметры. В нашем примере мы использовали глобальную опцию, чтобы установить быстродействие в 38,400 bps. Это значение унаследовано портом ttyS0. mgetty применяет именно это значение, если в секции специфической информации для порта не задано другое, как это сделано для ttyS1.

Ключевое слово debug управляет уровнем детализации отчетов mgetty. Ключевое слово data-only в конфигурации ttyS0 предписывает mgetty игнорировать любые свойства факс-модема, чтобы функционировать только как модем данных. Ключеове слово direct в конфигурации ttyS1 предписывает mgetty не делать попытку инициализации модема на этом порте. Наконец, toggle-dtr предписывает mgetty не делать попытку повесить трубку при получении на линии сигнала DTR (Data Terminal Ready).

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

Мы должны добавить две записи в файл /etc/inittab , чтобы активизировать эту конфигурацию. Файл inittab файл конфигурации команды init. Команда init является ответственной за инициализацию системы. Она автоматически выполняет программы при начальной загрузке и перезапускает их, когда они завершаются. Это идеально для целей работы программы getty.

T0:23:respawn:/sbin/mgetty ttyS0
T1:23:respawn:/sbin/mgetty ttyS1

Каждая строка файла /etc/inittab содержит 4 поля, разделяемые двоеточиями. Первое поле является идентификатором. Оно уникально маркирует запись в файле. Традиционно это два символа, но современные версии позволяют четыре. Второе поле содержит список уровней выполнения, на которых эта запись должна быть активна. Уровни выполнения являются средством обеспечения альтернативных конфигураций системы. Они связаны с наборами скриптов в каталогах /etc/rc1.d, /etc/rc2.d и т.д. Третье поле описывает, когда принять меры. Для работы программы getty оно должно быть определено как respawn. Это означает, что при завершении программы, она будет запущена вновь. Имеется еще несколько параметров, но они не важны для наших целей в данный момент. Четвертое поле задает команду, которая будет выполнена. Именно здесь надо определить команду mgetty и все необходимые ее параметры. В нашем простом примере мы запускаем и перезапускаем mgetty, когда система действует на уровнях выполнения 2 или 3 и передаем в качестве аргумента только имя устройства для работы. Команда mgetty подразумевает каталог /dev, так что задавать его явно в имени устройства не нужно.

Эта глава дает только общее представлдение о mgetty. Подробные сведения можно найти в Serial-HOWTO.

После правки файла конфигурации, надо перезапустить процесс init, чтобы изменения вступили в силу. Пошлите сигнал hangup процессу init. Он всегда имеет ID процесса равный единице, так что можно использовать команду:

# kill -HUP 1
Только не забудьте параметр -HUP! Иначе получите останов системы со страшным скрежетом.
Назад | Глобальное оглавление | Вперед
Использование программ настройки | Локальное оглавление | Настройка сети TCP/IP


Linux Network Administrator's Guide, Second Edition Copyright Information

оБЪБД чРЕТЕД

рТЙМПЦЕОЙЕ C. Linux Network Administrator's Guide, Second Edition Copyright Information

ъБНЕЮБОЙЕ БЧФПТБ ТХУУЛПК ЧЕТУЙЙ: рПУЛПМШЛХ РТЙЧПДЙНБС ОЙЦЕ ЙОЖПТНБГЙС ПВ БЧФПТУЛЙИ РТБЧБИ СЧМСЕФУС АТЙДЙЮЕУЛЙН ДПЛХНЕОФПН, Б С ОЕ УЙМЕО Ч АТЙУРТХДЕОГЙЙ, РТЙЧПЦХ ЕЕ ВЕЪ РЕТЕЧПДБ, ДБВЩ ОЕ ОБРХФБФШ ЮФП-МЙВП АТЙДЙЮЕУЛПЕ РП ОЕЪОБОЙА. дБООЩК ДПЛХНЕОФ РЕТЕЧЕДЕО ОБ ТХУУЛЙК СЪЩЛ бМЕЛУЕЕН рБХФПЧЩН Ч 2000 ЗПДХ. оПЧЩЕ ЧЕТУЙЙ (ЕУМЙ ФБЛПЧЩЕ ВХДХФ) ЙЭЙФЕ ОБ УФТБОЙЮЛЕ Russian LDP http://www.botik.ru/~rldp.

мПЛБМШОПЕ ПЗМБЧМЕОЙЕ
0. Preamble
1. Applicability and Definitions
2. Verbatim Copying
3. Copying in Quantity
4. Modifications
5. Combining Documents
6. Collections of Documents
7. Aggregation with Independent Works
8. Translation
9. Termination
10. Future Revisions of this License

Copyright К 1993 Olaf Kirch Copyright К 2000 Terry Dawson Copyright on O'Reilly printed version К 2000 O'Reilly & Associates

The online version of this book, which at this time of printing contains exactly the same text as the O'Reilly printed version, is available under the GNU FDL. Rights to reprint the document under the FDL include the right to print and distribute printed copies of the online version. Rights to copy the O'Reilly printed version are reserved. You can find the online copy of the license at http://www.oreilly.com/catalog/linag/licenseinfo.html. The book is available at http://www.linuxdoc.org/LDP/nag/nag.html and http://www.oreilly.com/catalog/linag/, and may be reposted by others at other locations.

Permission is granted to copy, print, distribute, and modify the online document under the terms of the GNU Free Documentation License, Version 1.1, or any later version published by the Free Software Foundation; with the Invariant Sections being the Acknowledgments (in the Preface and Appendix C. Further acknowledgments can be added outside the Invariant Section. The Front-Cover Text must read:

Linux Network Administrator's Guide
by Olaf Kirch and Terry Dawson
Copyright К 1993 Olaf Kirch
Copyright К 2000 Terry Dawson
Copyright on O'Reilly printed version К 2000 O'Reilly & Associates

The following is a copy of the GNU Free Documentation License, which is also at http://www.gnu.org/copyleft/fdl.html .

Version 1.1, March 2000
Copyright К 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

0. Preamble

The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft," which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. Applicability and Definitions

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document," below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you."

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque."

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats that do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

2. Verbatim Copying

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. Copying in Quantity

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. Modifications

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section entitled "History," and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. In any section entitled "Acknowledgements" or "Dedications," preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section entitled "Endorsements." Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements," provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. Combining Documents

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements," and any sections entitled "Dedications." You must delete all sections entitled "Endorsements."

6. Collections of Documents

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. Aggregation with Independent Works

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate," and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

8. Translation

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

9. Termination

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. Future Revisions of this License

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

оБЪБД | зМПВБМШОПЕ ПЗМБЧМЕОЙЕ | чРЕТЕД
оХМШ-НПДЕНОЩК ЛБВЕМШ |  | SAGE: The System Administrators Guild


The PPP and SLIP Drivers

Назад Глава 3. Настройка сетевого оборудования Вперед

Драйверы PPP и SLIP

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

Для запуска PPP или SLIP не нужно никаких изменений оборудования: Вы можете использовать любой последовательный порт. Так как конфигурация последовательного порта не специфическая для работы с сетями TCP/IP, она рассмотрена в отдельной главе. Подробности есть в главе 4. PPP детально рассмотрен в главе 8, а SLIP в главе 7.

Назад | Глобальное оглавление | Вперед
Драйвер PLIP | Локальное оглавление | Другие типы сетей


Configuring the Networking Hardware

Назад Вперед

Глава 3. Настройка сетевого оборудования

Локальное оглавление
Настройка ядра
Обзор сетевых устройств в Linux
Установка Ethernet
Драйвер PLIP
Драйверы PPP и SLIP
Другие типы сетей

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

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

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

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

В PC-компьютерах эта связь устанавливается через область памяти ввода-вывода, которая является отображением регистров платы и т.п. Все команды и данные, которые ядро посылает плате, проходят через эти регистры. Память ввода-вывода описывается указанием начального адреса (base address). Типичные основные адреса для Ethernet-плат 0x280 или 0x300. Сетевые карты на интерфейсе PCI обычно получают адрес ввода-вывода автоматически.

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

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

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

Интерфейсы идентифицируются посредством имен. Эти имена определены внутри ядра, это файлы устройств в каталоге /dev. Если ввести команду ls -las /dev/, Вы увидите много файлов. В колонке прав доступа Вы увидите, что первым символом прав доступа здесь является не такой символ, как для обычных имен файлов. Он показывает тип интерфейса. Символ b задает блочное (block) устройство. Символ c задает символьное (character) устройство, которое обрабатывает данные посимвольно, а не блоками. В поле длины файла Вы увидите два числа, которые называются старшим и младшим номерами устройства.

Каждый драйвер имеет уникальный старший номер в ядре. Каждая копия драйвера (по одной на устройство) имеет свой младший номер. Интерфейсы tty с именами /dev/tty* являются символьными, и имеют первый символ в правах доступа c”, все они имеют общий старший номер 4, но младшие номера у каждого свои: /dev/tty1 имеет младший номер 1 и /dev/tty2 имеет 2.

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

При загрузке ядро показывает, какие интерфейсы установлены и устройства найдены. Вот образец типичного сообщения при загрузке:
 .
 .  This processor honors the WP bit even when in supervisor mode./
    Good.
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: IGMP,ICMP, UDP, TCP
Swansea University Computer Society IPX 0.34 for NET3.035
IPX Portions Copyright (c) 1995 Caldera, Inc.
Serial driver version 4.13 with no serial options enabled
tty00 at 0x03f8 (irq = 4) is a 16550A
tty01 at 0x02f8 (irq = 3) is a 16550A
CSLIP: code copyright 1989 Regents of the University of California
PPP: Version 2.2.0 (dynamic channel allocation)
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 0e e4 e0,/
    IRQ 10.
3c509.c:1.12 6/4/97 becker@cesdis.gsfc.nasa.gov
Linux Version 2.0.32 (root@perf) (gcc Version 2.7.2.1)
#1 Tue Oct 21 15:30:44 EST 1997
 .
 .

Этот пример показывает, что ядро построено с поддержкой сетевого протокола TCP/IP и включает драйверы для SLIP, CSLIP и PPP. Третья строка снизу говорит об обнаружении платы 3C509 Ethernet и установке ее интерфейса eth0. Если у Вас другой тип сетевой карты, будет выведена соответствующая строка, обычно с ее названием. Например, для адаптера D-Link используется имя dl0. А вот если сетевая карта есть, а сообщения о ней нет, тогда плохо дело. Ядро не нашло карту при загрузке. Эта ситуация будет рассмотрена позже.

Настройка ядра

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

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

Очень важна версия ядра. Ядра Linux нумеруются по следущей схеме: 2.2.14. Первая цифра показывает старший номер версии. Эта цифра изменяется, когда вносятся значительные изменения. Старший номер версии сменился с 1 на 2, когда ядро было перенесено на другие платформы (не Intel). Второе число определяет младший номер версии. Разработчики Linux договорились о том, что четный младший номер версии показывает production (готовую) или stable (стабильную) версию ядра, а нечетный показывает development (разрабатываемую) или unstable (нестабильную) версию. Вы должны использовать на машине, которая является важной, стабильные ядра потому, что они надежны настолько, насколько вообще может быть надежна программа. Можно использовать нестабильные ядра, если нужны некоторые экспериментальные возможности Linux, но они не отлажены до конца. Они надежней, чем Windows, но все же ниже того минимума, который позволителен в Linux. Третье число показывает номер редакции версии ядра. Система развивается, в ней устраняются небольшие ошибки, появляются новые возможности, что и отражается этим номером.

При запуске программы make menuconfig Вы получите текстовое меню с опциями настройки ядра. На вопрос о поддержке сетей TCP/IP надо ответить "y" для ее включения.

Опции ядра в Linux 2.0 и выше

Здесь в главном меню задаются параметры для основных возможностей системы, например, поддержки SCSI или звуковых карт. Вы можете нажать ? для получения подробного описания опции. Чтобы включить поддержку некой возможности в ядро постоянно, надо ответить y. Можно ответить m, тогда соответствующий драйвер будет включен в ядро как модуль и загружаться по мере необходимости. При всем своем удобстве модули не могут загружаться при начальной инициализации ядра, так что все необходимое для его загрузки должно быть встроено прямо в ядро без модулей. Наконец, если некая возможность не нужна, от нее можно отказаться ответом n.

Меню настройки имеет иерархический вид. Например, чтобы настроить сеть, Вам сначала нужно подвердить, что Вы вообще включаете ее поддержку, и только потом будут заданы вопросы о том, в чем именно эта поддержка должна выражаться. В ядрах серий 2.0 и 2.1 первый вопрос о сети такой:
*
* Network device support
*
Network device support (CONFIG_NETDEVICES) [Y/n/?]

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

PLIP (parallel port) support (CONFIG_PLIP) [N/y/m/?] y
PPP (point-to-point) support (CONFIG_PPP) [N/y/m/?] y
*
* CCP compressors for PPP are only built as modules.
*
SLIP (serial line) support (CONFIG_SLIP) [N/y/m/?] m
  CSLIP compressed headers (CONFIG_SLIP_COMPRESSED) [N/y/?] (NEW) y
  Keepalive and linefill (CONFIG_SLIP_SMART) [N/y/?] (NEW) y
  Six bit SLIP encapsulation (CONFIG_SLIP_MODE_SLIP6) [N/y/?] (NEW) y

Эти вопросы касаются различных протоколов уровня связи, которые Linux поддерживает. PPP и SLIP позволяют Вам передавать пакеты IP по последовательной линии связи. PPP не ограничен передачей пакетов TCP/IP, он может передавать пакеты IPX.

Если Вы отвечаете y или m на вопрос о поддержке SLIP, Вам придется ответить на три вопроса, которые появляются после этого. Опция "CSLIP compressed headers" позволяет сжимать заголовки пакетов TCP/IP. Заметьте, что эта опция лишь обеспечивает возможность работы с такими заголовками, но не заставляет работать с ними в обязательном порядке! Опция Keepalive and linefill заставляет поддержку SLIP периодически генерировать действия на линии SLIP, чтобы таймер неактивности не разрывал соединение. Опция Six bit SLIP encapsulation позволяет Вам выполнять SLIP на линиях, которые не способны к передаче 8-битных данных в чистом виде.

PLIP обеспечивает способ послать IP-пакеты через параллельный порт. Это обычно используется, чтобы связаться с машинами, работающими в DOS. На типичных аппаратных средствах PLIP может быть быстрее, чем PPP или SLIP, но он требует намного большей нагрузки на CPU.

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

 .
 .
Ethernet (10 or 100Mbit) (CONFIG_NET_ETHERNET) [Y/n/?]
3COM cards (CONFIG_NET_VENDOR_3COM) [Y/n/?]
3c501 support (CONFIG_EL1) [N/y/m/?]
3c503 support (CONFIG_EL2) [N/y/m/?]
3c509/3c579 support (CONFIG_EL3) [Y/m/n/?]
3c590/3c900 series (592/595/597/900/905) "Vortex/Boomerang" support/
    (CONFIG_VORTEX) [N/y/m/?]
AMD LANCE and PCnet (AT1500 and NE2100) support (CONFIG_LANCE) [N/y/?]
AMD PCInet32 (VLB and PCI) support (CONFIG_LANCE32) [N/y/?] (NEW)
Western Digital/SMC cards (CONFIG_NET_VENDOR_SMC) [N/y/?]
WD80*3 support (CONFIG_WD80x3) [N/y/m/?] (NEW)
SMC Ultra support (CONFIG_ULTRA) [N/y/m/?] (NEW)
SMC Ultra32 support (CONFIG_ULTRA32) [N/y/m/?] (NEW)
SMC 9194 support (CONFIG_SMC9194) [N/y/m/?] (NEW)
Other ISA cards (CONFIG_NET_ISA) [N/y/?]
Cabletron E21xx support (CONFIG_E2100) [N/y/m/?] (NEW)
DEPCA, DE10x, DE200, DE201, DE202, DE422 support (CONFIG_DEPCA) [N/y/m/?]/
    (NEW)
EtherWORKS 3 (DE203, DE204, DE205) support (CONFIG_EWRK3) [N/y/m/?] (NEW)
EtherExpress 16 support (CONFIG_EEXPRESS) [N/y/m/?] (NEW)
HP PCLAN+ (27247B and 27252A) support (CONFIG_HPLAN_PLUS) [N/y/m/?] (NEW)
HP PCLAN (27245 and other 27xxx series) support (CONFIG_HPLAN) [N/y/m/?]/
    (NEW)
HP 10/100VG PCLAN (ISA, EISA, PCI) support (CONFIG_HP100) [N/y/m/?] (NEW)
NE2000/NE1000 support (CONFIG_NE2000) [N/y/m/?] (NEW)
SK_G16 support (CONFIG_SK_G16) [N/y/?] (NEW)
EISA, VLB, PCI and on card controllers (CONFIG_NET_EISA) [N/y/?]
Apricot Xen-II on card ethernet (CONFIG_APRICOT) [N/y/m/?] (NEW)
Intel EtherExpress/Pro 100B support (CONFIG_EEXPRESS_PRO100B) [N/y/m/?]/
    (NEW)
DE425, DE434, DE435, DE450, DE500 support (CONFIG_DE4X5) [N/y/m/?] (NEW)
DECchip Tulip (dc21x4x) PCI support (CONFIG_DEC_ELCP) [N/y/m/?] (NEW)
Digi Intl. RightSwitch SE-X support (CONFIG_DGRS) [N/y/m/?] (NEW)
Pocket and portable adaptors (CONFIG_NET_POCKET) [N/y/?]
AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [N/y/?] (NEW)
D-Link DE600 pocket adaptor support (CONFIG_DE600) [N/y/m/?] (NEW)
D-Link DE620 pocket adaptor support (CONFIG_DE620) [N/y/m/?] (NEW)
Token Ring driver support (CONFIG_TR) [N/y/?]
IBM Tropic chipset based adaptor support (CONFIG_IBMTR) [N/y/m/?] (NEW)
FDDI driver support (CONFIG_FDDI) [N/y/?]
Digital DEFEA and DEFPA adapter support (CONFIG_DEFXX) [N/y/?] (NEW)
ARCnet support (CONFIG_ARCNET) [N/y/m/?]
  Enable arc0e (ARCnet "Ether-Encap" packet format) (CONFIG_ARCNET_ETH)/
      [N/y/?] (NEW)
  Enable arc0s (ARCnet RFC1051 packet format) (CONFIG_ARCNET_1051)/
      [N/y/?] (NEW)
 .
 .

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

NFS file system support (CONFIG_NFS_FS) [y]
NFS детально описана в главе 14.

Сетевые опции в ядре Linux 2.2.0 и выше

Linux 2.2.0 отмечена серьезными изменениями в сетевой части ядра. Появилось много новых опций, а также поддержка протокола IPX. Большая часть этих опций нужна только в особых конфигурациях, так что я их не описываю. Подробно с ними можно ознакомиться в Networking HOWTO. Я перечислю наиболее часто используемые опции:

Basics

Нужна для работы с протколом TCP/IP, если ответите n, лишитесь этого протокола, но протокол IPX останется доступен:

Networking options  --->
    [*] TCP/IP networking

Gateways

Если машина используется как шлюз между сетями или между LAN и SLIP-связью (или в других подобных ситуациях), включите эту опцию. А вот если Вы используете свою машину как firewall, выключите ее! Firewall называется машина, которая связана с двумя сетями, но передает информацию между ними по сложному алгоритму. Эта система используется, чтобы внутренние машины могли выйти в Internet, но внешние машины не могли попасть во внутреннюю сеть (подробно firewall рассматриваются в главе 9):

     [*] IP: forwarding/gatewaying

Virtual hosting

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

    [*] Network aliasing
        <*> IP: aliasing support

Accounting

Эта опция позволяет собирать информацию о IP-трафике этой машины (вопрос детально обсуждается в главе 10):

    [*] IP: accounting

PC hug

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

    --- (it is safe to leave these untouched)
    [*] IP: PC/TCP compatibility mode

Diskless booting

Включает Reverse Address Resolution Protocol (RARP). RARP используется бездисковыми терминалами и X-ьерминалами для запроса своего IP-адреса при загрузке. Если у Вас есть такие клиенты, RARP Вам понадобится. Маленькая программа rarp, которая входит в стандартный сетевой пакет, используется для управления записями в таблице RARP ядра:

    <*> IP: Reverse ARP

MTU

При передаче данных по TCP, ядро разделяет поток данных на блоки для передачи по IP. Размер блока называется Maximum Transmission Unit или MTU. Для машин в сети Ethernet MTU обычно большой и составляет максимальную длину пакетов Ethernet (1500 байт). Но при работе с модемом стоит подобрать нужное значение. Ядро может само определить минимальный размер пакетов и соответственно настроить TCP. Это можно отменить ответом y на этот вопрос.

Если нужно маленькие пакеты для отдельных систем, например, при работе с протоколом SLIP, используйте опцию mss команды route, которая обсуждается в следующей главе:

    [ ] IP: Disable Path MTU Discovery (normally enabled)

Security feature

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

     [*] IP: Drop source routed frames

Novell support

Включает поддержку IPX, транспортного протокола Novell Networking. Linux будет функционировать как IPX маршрутизатор. Эта поддержка полезна в средах, где Вы имеете файловый сервер Novell. Файловая система NCP также требует поддержки IPX. Она понадобится, если нужно монтировать по сети файловые системы фирмы Novell (я подробно рассмотрю IPX и файловую систему NCP в главе 15):

    <*> The IPX protocol

Amateur radio

Эта опция включает поддержку Linux протоколов Amateur Radio: AX.25, NetRom и Rose (они подробно описаны в AX25 HOWTO):
    <*> Amateur Radio AX.25 Level 2
    <*> Amateur Radio NET/ROM
    <*> Amateur Radio X.25 PLP (Rose)

Linux поддерживает еще один тип драйверов: тупой драйвер. Следующий вопрос появляется в начале раздела драйверов устройств:
    <*> Dummy net driver support

Такой драйвер маскирует кольцевой интерфейс и очень полезен на отдельной или PPP/SLIP машине. На машинах только с интерфейсом PPP/SLIP он будет обеспечивать передачу трафика IP. Подробно он рассмотрен в разделе Dummy Interface в главе 5. Обратите внимание, что сегодня Вы можете достичь того же самого результата, используя IP псевдоним и конфигурируя свой адрес IP как псевдоним на кольцевом интерфейсе.

Назад | Глобальное оглавление | Вперед
Преобразование имен машин |  | Обзор сетевых устройств в Linux


Setting the Hostname

Назад Глава 5. Настройка сети TCP/IP Вперед

Установка Hostname

Большинство сетевых приложений предполагает, что Вы установите имя компьютера в какое-то приемлемое значение. Эта установка обычно бывает сделана в течение процедуры начальной загрузки, выполняя команду hostname. Для установки имени компьютера в name введите:
# hostname name

Обычной практикой является использование локального имени (без имени домена). Например, машины Virtual Brewery (описаны в приложении A) могут иметь имена vale.vbrew.com и vlager.vbrew.com. Эти имена полные, то есть с именем домена (fully qualified domain names, FQDNs. Их локальные имена будут первыми компонентами полных, например, vale. Однако, поскольку локальные имена часто используется, чтобы искать IP-адрес компьютера, Вы должны удостовериться, что сервер имен способен найти адрес по имени. Это обычно означает, что Вы должны внести имя в файл /etc/hosts.

Некоторые люди предлагают использовать команду domainname, чтобы сообщить ядру оставшуюся часть FQDN. Этим путем Вы могли бы объединять вывод из hostname и domainname для получения FQDN. Однако, это в самом лучшем случае только наполовину верно. domainname вообще используется, чтобы установить домен NIS, который может полностью отличаться от домена DNS, к которому компьютер принадлежит. Вместо этого, чтобы гарантировать, что короткая форма пригодна к использованию в поиске, все новые версии hostname добавляют соответствующую запись в сервер имен или пишут полное доменное имя в файл /etc/hosts. Затем можно использовать параметр --fqdn в команде hostname для получения полного имени.

Назад | Глобальное оглавление | Вперед
Установка исполняемых модулей | Локальное оглавление | Установка IP-адресов


How DNS Works

Назад Глава 6. Name Service and Resolver Configuration Вперед

Как работает DNS

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

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

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

Домне | Описание
edu | Образовательные учреждения, подобные университетам (главным образом США, хотя регистрироваться в этом домене могут ВУЗы любой страны).
com | Коммерческие организации, компании. В Москве много таких доменов.
org | Некоммерческие организации. Часто частные UUCP-сети находятся в этом домене. К конкретной стране не привязан.
net | Шлюзы и другие административные хосты в сети. Часто сетевые сервисы, справочники и т.п. Например, автор данной работы в свое время хотел зарегистрировать домен RussianLDP.net и отказался от этого лишь из-за оплаты домена. Но в последнее время в нем стало можно регистрировать имена за рекламу, так что, может, еще и соберусь...
mil | Американские военные учреждения.
gov | Американские правительственные учреждения (хотя в последнее время наметились сдвиги в плане того, чтобы сделать этот домен международным правительственным).
uucp | Официально, все имена сайтов, прежде используемые как UUCP-имена без доменов, были перемещены в этот домен.
ru | Российский национальный домен. Все машины с этим доменом находятся в России.

Технически первые четыре из них принадлежат американской части Internet, но там встречаются и не американские сайты. Это особенно верно для доменов .net и .org. Однако, .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-адреса в пределах подсети без всякого вмешательства сверху.

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

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

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

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

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

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

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

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

Типы серверов имен

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

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

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

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

База данных DNS

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

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

Конечно, хост может иметь больше, чем одно имя. Например, сервер предоставляющий сервисы FTP и World Wide Web может иметь имена ftp.machine.org и www.machine.org. Однако, одно из этих имен должно быть определено как официальное или каноническое (canonical) имя хоста в то время, как остальные просто псевдонимы. Различие между ними в том, что каноническое имя хоста связано с А-записью в то время, как другие только с записью типа CNAME, которая указывает на каноническое имя хоста.

Я не буду приводить здесь все типы записей, а сделаю это позже, в другой главе, здесь же ограничусь кратким примером. Пример 6-4 показывает часть базы данных домена, которая загружена на сервере имен для зоны physics.groucho.edu.

Пример 6-4. Выдержка из файла named.hosts для отдела физики

; Authoritative Information on physics.groucho.edu.
@  IN  SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
                  1999090200       ; 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
name server    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
...

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

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

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

Пример 6-5. Выдержка из файла named.hosts для GMU

; Zone data for the groucho.edu zone.
 @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
                      1999070100       ; 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
 ...

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

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

Создание зоны полномочий обычно означает, что ее администраторам дают полный контроль над тем, как назначать адреса и имена хостов. Так как они обычно управляют одной или более 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 показана в примере 6-6. Соответствующие склеенные записи в базе данных зоны родителя показаны в примере 6-7.

Пример 6-6. Выдержка из файла named.rev для подсети 12

 ; the 12.76.149.in-addr.arpa domain.
 @  IN  SOA  niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
                      1999090200 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.

Пример 6-7. Выдержка из файла named.rev для сети 149.76

 ; the 76.149.in-addr.arpa domain.
 @  IN  SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
                      1999070100 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
 ...

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

Назад | Глобальное оглавление | Вперед
Name Service and Resolver Configuration | Локальное оглавление | Running named


Setting Up Linux for Firewalling

Назад Глава 9. TCP/IP Firewall Вперед

Установка Firewall в Linux

Чтобы запустить Linux IP firewall, нужно построить ядро с поддержкой IP firewall и соответствующие конфигурационные утилиты. В ядрах до серии 2.2, нужно использовать утилиту ipfwadm. Ядра 2.2.x имеют третье поколение IP firewall для Linux, называемое IP Chains. IP chains использует программу ipchains. Ядра Linux 2.3.15 и старше поддерживают четвертое поколение Linux IP firewall: netfilter. Код пакета netfilter результат больших изменений потока обработки пакетов в Linux. netfilter обеспечивает обратную совместимость с ipfwadm и ipchains. Настраивается эта версия командой iptables. В следующих разделах я подробно рассмотрю отличия этих трех реализаций.

Настройка ядра для IP Firewall

Ядро Linux надо настроить на поддержку IP firewall. Для этого нужно просто указать параметры при настройке ядра, например, командой make menuconfig. Подробно настройка ядра описана в главе 3. В ядрах 2.2 надо выбрать следующие опции:
Networking options  --->
        [*] Network firewalls
        [*] TCP/IP networking
        [*] IP: firewalling
        [*] IP: firewall packet logging

В ядрах серий 2.4.0 и старше надо выбрать гораздо больше опций:
   Networking options  --->
     [*] Network packet filtering (replaces ipchains)
         IP: Netfilter Configuration  --->
              .
             <M> Userspace queueing via NETLINK (EXPERIMENTAL)
             <M> IP tables support (required for filtering/masq/NAT)
             <M>   limit match support
             <M>   MAC address match support
             <M>   netfilter MARK match support
             <M>   Multiple port match support
             <M>   TOS match support
             <M>   Connection state match support
             <M>   Unclean match support (EXPERIMENTAL)
             <M>   Owner match support (EXPERIMENTAL)
             <M>   Packet filtering
             <M>     REJECT target support
             <M>     MIRROR target support (EXPERIMENTAL)
             <M>   Packet mangling
             <M>     TOS target support
             <M>     MARK target support
             <M>   LOG target support
             <M> ipchains (2.2-style) support
             <M> ipfwadm (2.0-style) support

Утилита ipfwadm

Утилита ipfwadm (IP Firewall Administration) нужна для управления правилами в ядрах до версии 2.2.0. Ее синтаксис очень сложен, но я приведу несколько наиболее простых примеров.

Утилита ipfwadm есть во всех современных дистрибутивах Linux, но, возможно, не ставится по умолчанию. Может иметься специальный сетевой пакет, который надо поставить отдельно. Найти исходный код можно на ftp.xos.nl в каталоге /pub/linux/ipfwadm.

Утилита ipchains

Аналогично ipfwadm, утилита ipchains может несколько сбивать с толку, пока к ней не привыкнешь. Она обеспечивает всю гибкость ipfwadm с упрощенным синтаксисом и дополнительно обеспечивает механизм наборов или цепочек (“chaining”), который позволяет Вам управлять множеством правил и связывать их друг с другом. Я рассмотрю формирование цепочки правил в отдельном разделе чуть позже.

Команда ipchains появилась в дистрибутивах Linux на ядрах серии 2.2. Исходники можно взять на http://www.rustcorp.com/linux/ipchains. В этот пакет исходников входит скрипт ipfwadm-wrapper, который имитирует работу ipfwadm, используя возможности ipchains. Это существенно упрощает к новой версии firewall.

Утилита iptables

Синтаксис iptables очень похож на синтаксис ipchains. Разница в поддержке модулей расширения и ряде новшеств в фильтрации пакетов. Разумеется, я приведу пример и для iptables, так что Вы сможете сравнить эти две утилиты.

Утилита iptables входит в пакет netfilter, исходники которого можно скачать с http://www.samba.org/netfilter. Она также входит в дистрибутивы Linux на ядре 2.4. Правда, поскольку это ядро еще находится на стадии тестирования, я пока не встречал дистрибутивов на нем.

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

Назад | Глобальное оглавление | Вперед
Что такое IP Filtering? | Локальное оглавление | Три способа фильтрации


A Tour of Linux Network Devices

Назад Глава 3. Настройка сетевого оборудования Вперед

Обзор сетевых устройств в Linux

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

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

lo

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

eth0, eth1, ethn

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

tr0, tr1, trn

Карты сети Token Ring. Имена используются большинством карт Token Ring, включая не-IBM карты.

sl0, sl1, sln

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

ppp0, ppp1, pppn

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

plip0, plip1, plipn

n-ый PLIP-интерфейс. PLIP-транспортирует IP-пакеты по параллельным линиям. Они устанавливаются PLIP-драйвером при загрузке системы и отображают параллельные порты. В ядрах 2.0.x имеется прямая связь между именем устройства и адресом ввода-вывода параллельного порта, но в более поздних ядрах имена устройства распределены последовательно точно, как для SLIP и PPP.

ax0, ax1, axn

n-ый интерфейс AX.25. AX.25 является главным протоколом операторов amateur radio. Интерфейсы AX.25 распределяются аналогично интерфейсам SLIP.

Есть еще немало разных интерфейсов для сетевых драйверов. Я перечислил лишь самые распространенные.

В следующих разделах мы будем обсуждать детали использования драйверов, описанных выше. Много полезного по настройке сетевых устройств можно узнать в Networking HOWTO, а AX25 HOWTO подробно описывает настройку сетевых устройств Amateur Radio.

Назад | Глобальное оглавление | Вперед
Настройка сетевого оборудования | Локальное оглавление | Установка Ethernet


The Internet Control Message Protocol

Назад Глава 2. Настройка сети TCP/IP Вперед

Internet Control Message Protocol

IP имеет вспомогательный протокол, о котором мы еще не говорили. Это Internet Control Message Protocol (ICMP), используемый кодом работы с сетями ядра Linux, чтобы передавать сообщения об ошибках на другие компьютеры. Например, допустим, что вы с системы erdos пытаетесь связаться по telnet с портом 12345 на quark, но на той машине нет никаких процессов на этом порте. Когда первый пакет TCP попадет на этот порт quark, уровень работы с сетями распознает это поступление и немедленно возвратит ICMP-сообщение на erdos с диагностикой "Port Unreachable".

ICMP-протокол обеспечивает несколько различных сообщений, многие из которых имеют дело с условиями ошибки. Однако, имеется очень интересное сообщение, названное Redirect. Оно генерируется модулем маршрутизации, когда он обнаруживает, что другой компьютер использует его как шлюз, несмотря на наличие намного более короткого маршрута. Например, после загрузки таблица маршрутизации sophus не была завершена. Она могла бы содержать маршруты к сети Mathematics network, к каналу FDDI и заданному по умолчанию маршруту, указывающему на Groucho Computing Center (gcc1). Таким образом, пакеты для quark были бы посланы gcc1, а не niels, шлюзу кафедры физики. При получении такого пакета gcc1 обратит внимание, что это неправильная маршрутизация и передаст пакет на niels , одновременно возвращая сообщение ICMP Redirect на sophus.

Это, кажется, очень умный способ избежать настройки маршрутов, кроме базисных, вручную. Однако помните, что доверять сообщениям Redirect протоколов RIP и ICMP можно не всегда! ICMP Redirect и RIP не дают возможности проверить подлинность информации. Эта ситуация позволяет злонамеренному человеку сделать очень многое. Код работы с сетями Linux обрабатывает сообщения Network Redirect, как будто они были сообщениями Host Redirects. Это минимизирует повреждение при нападении, ограничивая их одной машиной, а не целой сетью.

Назад | Глобальное оглавление | Вперед
IP-маршрутизация | Локальное оглавление | Преобразование имен машин


Configuring TCP/IP Networking

Назад Вперед

Глава 5. Настройка сети TCP/IP

Локальное оглавление
Монтирование файловой системы /proc
Установка исполняемых модулей
Установка Hostname
Установка IP-адресов
Создание подсетей
Написание файлов hosts и networks
Настройка интерфейса для IP
Все про ifconfig
Команда netstat
Проверка ARP-таблиц

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

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

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

Монтирование файловой системы /proc

Некоторые из инструментов конфигурации в Net-2 и NET-3 для связи с ядром используют файловую систему /proc. Это виртуальная файловая система, которая является интерфейсом, разрешающим доступ к информации ядра времени выполнения через механизм похожий на файловую систему. Когда она установлена, Вы можете просматривать список файлов и их содержимое также, как в любой другой файловой системе. Типичными представителями являются файлы loadavg, который содержит среднее число загруженности системы и meminfo , который показывает текущее состояния памяти ядра и использование свопа. К этому сетевой код добавляет директорию net . Она содержит ряд файлов, которые отображают состояние параметров сети, типа ARP-таблицы, TCP-соединений и таблиц маршрутизации. Большинство инструментов администрирования сети получают информацию из этих файлов.

Файловая система proc (или procfs) обычно монтируется во время загрузки в /proc. Самый лучший метод состoит в том, чтобы добавить следующую строку в файл /etc/fstab:
# procfs mount point:
none            /proc           proc    defaults
Затем надо выполнить mount /proc в скрипте /etc/rc.

Сейчас procfs имеется в большинство ядер по умолчанию. Если procfs в Вашем ядре нет, Вы получите сообщение вида: mount: fs type procfs not supported by kernel. Придется перестроить с ответом “yes” на вопрос о поддержке procfs.

Назад | Глобальное оглавление | Вперед
Последовательное оборудование и запрос login: |  | Установка исполняемых модулей


All About ifconfig

Назад Глава 5. Настройка сети TCP/IP Вперед

Все про ifconfig

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

interface имя интерфейса и address IP-адрес, который требуется назначить интерфейсу. Это может быть IP-адрес или имя, которое ifconfig будет искать в файле /etc/hosts.

Если ifconfig используется только с именем интерфейса, он показывает конфигурацию этого интерфейса. Когда он вызывается без параметров, он показывает все интерфейсы, которые Вы отконфигурировали; опция –a вынуждает его показать и бездействующие. Вывод для Ethernet-интерфейса eth0 может напоминать это:
# ifconfig eth0
eth0      Link encap 10Mbps Ethernet  HWaddr 00:00:C0:90:B3:42
          inet addr 172.16.1.2 Bcast 172.16.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-адрес. Также используется для перезапуска интерфейса, который временно выключен опцией down.

Соответствует флагам UP и RUNNING.

down

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

netmask mask

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

pointopoint address

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

broadcast address

Широковещательный адрес обычно создается из сетевого адреса установкой всех бит части машины. Некоторые реализации IP используют другую схему, эта опция помогает приспособиться к этим странным средам. Если широковещательный (broadcast) адрес был установлен, ifconfig показывает флаг BROADCAST .

irq

Задает номер IRQ для устройства. Обычно используется для PLIP, но может пригодиться и для некоторых карт Ethernet.

metric number

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

mtu bytes

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

arp

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

-arp

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

promisc

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

–promisc

Запрещает режим promiscuous.

allmulti

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

-allmulti

Запрещает multicast-адреса.

Назад | Глобальное оглавление | Вперед
Настройка интерфейсов для IP | Локальное оглавление | Команда netstat


Internet News

Назад Вперед

Глава 23. Internet News

Локальное оглавление
Введение в INN
Программы чтения новостей и INN
Установка INN
Настройка INN
Файлы настройки INN
Запуск INN
Управление INN: команда ctlinnd

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

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

Как работает INN

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

Другое важное свойство INN: всегда имеется только один экземпляр innd. Это также сильно повышает эффективность потому, что daemon может обрабатывать все статьи без необходимости синхронизации внутренних переменных с другими копиями. Поскольку важно, чтобы входящие новости были обработаны настолько быстро, насколько возможно, недопустимо, чтобы сервер занимался всякими побочными задачами, например, предоставлением доступа клиентам по NNTP или распаковкой пакетов новостей с каналов UUCP. Следовательно, эти задачи вынесены в отдельные программы поддержки.

Сегодня NNTP наиболее общее средство транспортировки статей, и innd непосредственно не поддерживает другие протоколы. Это означает, что innd ждет соединений по TCP (порт 119) и принимает статьи, использующие протокол ihave.

Статьи, прибывающие транспортом, отличным от NNTP, поддержаны косвенно при наличии другого процесса, принимающего статьи и передающего их innd по NNTP. Новости, поступающие по UUCP, например, традиционно обрабатываются программой rnews. Версия rnews из INN распаковывает пакет в случае необходимости, делит его на индивидуальные статьи, а затем передает innd.

Программы работы с новостями (newsreaders) могут доставлять новости, когда пользователь посылает статью. Так как обработка newsreaders заслуживает особого внимания, мы возвратимся к этому немного позже.

При получении статьи innd сначала ищет идентификатор сообщения (message ID) в файле history . Дубликаты статей игнорируются. То же произойдет со старыми статьями или статьями с неправильным заголовком. Если innd находит, что статья приемлема, он рассматривает строку заголовка Newsgroups:, чтобы выяснить, в какой группе эта статья должна быть сохранена. Если группа или группы найдены в файле active, статья записывается на диск. Иначе, она попадает в спецгруппу junk.

Индивидуальные статьи сохраняются ниже каталога /var/spool/news, также называемого news spool. Каждая группа новостей имеет отдельный каталог, в котором каждая статья будет сохранена в отдельном файле. Имена файлов представляют собой последовательные числа. Например, статья в группе comp.risks может иметь имя файла comp/risks/217. Если каталог, в котором требуется сохранить статью не существует, он будет создан автоматически innd.

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

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

Для исходящего трафика NNTP innd может порождать несколько процессов innxmit. Каждой копии этой программы передается имя файла статьи, ее размер и message ID через стандартный ввод. Для исходящего трафика UUCP данные о статье вносятся в файл протокола, обрабатываемый затем программой, которая собирает статьи в пакеты, сжимает их и отсылает по назначению.

Помимо этих двух примеров, имеются другие типы каналов. Они используются, например, при архивировании групп новостей или при подготовке краткого обзора. Информация краткого обзора предназначена, чтобы помочь программам работы с новостями обрабатывать потоки новостей. Раньше такая программа должна была просмотреть все статьи, чтобы получить информацию заголовка, требуемую для создания потоков. Это перегружало сервер новостей, особенно при использовании NNTP. Кроме того, этот подход был очень медленным. Механизм краткого обзора облегчает эту задачу, сохраняя все подходящие заголовки в отдельном файле (.overview) для каждой группы. Эта информация может быть поднята программой чтения новостей из каталога spool или командой XOVER протокола NNTP.

Назад | Глобальное оглавление | Вперед
Взаимодействие nntpd и C-News |  | Программы чтения новостей и INN


nntpd Interaction with C News

Назад Глава 22. NNTP и nntpd Daemon Вперед

Взаимодействие nntpd и C-News

При получении статьи, nntpd должен приписать ее к подсистеме новостей. В зависимости от того, было ли это получено в результате команды IHAVE или POST, статья будет вручена rnews или inews, соответственно. Вместо того, чтобы вызывать rnews, Вы можете также конфигурировать rnews (во время компиляции), чтобы пакетировать входящие статьи и перемещать возникающие в результате пакеты в /var/spool/news/in.coming, где они остаются для relaynews, которая при очередной обработке буфера подберет их.

Чтобы правильно выполнить протокол ihave/sendme, nntpd должен обратиться к файлу history. Во время компиляции, Вы должны удостовериться, что путь установлен правильно. Вы должны также удостовериться, что C-news и nntpd договорятся о формате вашего файла history. 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 localhost
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, поиск в файле history потерпел неудачу. Завершите диалог нажатием Ctrl-D. Вы можете проверять, что пошло неправильно, проверяя файл регистрации системы: nntpd регистрирует все виды сообщений в syslog. Несовместимая библиотека dbm обычно проявляется в сообщении о том, что dbminit потерпел неудачу.

Назад | Глобальное оглавление | Вперед
Авторизация NNTP | Локальное оглавление | Internet News


Interface Configuration for IP

Назад Глава 5. Настройка сети TCP/IP Вперед

Настройка интерфейса для IP

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

ifconfig используется, чтобы сделать интерфейс доступным для ядра, что включает в себя назначение IP-адреса и других параметров и активизацию интерфейса. Активизация означает, что ядро будет посылать и получать IP-пакеты через интерфейс. Самый простой путь установки:
ifconfig interface ip-address

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

route позволяет Вам добавлять или удалять маршруты из таблицы маршрутизации. Это может быть использовано так:
route [add|del] [-net|-host] target [if]

Аргументы add и del определяют добавлять или удалять маршрут target. Аргументы -net и -host определяют тип маршрута: к сети или к компьютеру (второй вариант принимается по умолчанию). Аргумент if определяет, к какому сетевому интерфейсу относится команда.

Кольцевой интерфейс (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  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Collisions:0

Как Вы можете видеть, интерфейс loopback получил сетевую маску 255.0.0.0, так как адрес 127.0.0.1 принадлежит к классу A.

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

Здесь тоже можно использовать localhost вместо IP-адреса, если он задан в файле /etc/hosts.

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

# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms

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

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

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

Описанных выше шагов достаточно, чтобы использовать сетевые приложения на автономном компьютере. После добавления вышеупомянутых строк к скрипту запуска, вы можете перезагрузить вашу машину и попытаться использовать различные приложения. Например, telnet localhost должен установить telnet-соединение с вашей машиной и вывести приглашение login:.

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

Интерфейсы Ethernet

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

В Virtual Brewery мы с вами разбивали на подсети IP-сеть, которая была первоначально класса B на сети калсса С. При установке интерфейса для нее требовалось написать:
# ifconfig eth0 vstout netmask 255.255.255.0

Эта запись назначает интерфейсу eth0 IP-адрес vstout (172.16.1.2 ). Если бы мы опустили netmask, ifconfig вывел бы netmask из класса сети, что привело бы к неправильной маске подсети 255.255.0.0. Теперь быстренько проверим:
# ifconfig eth0
eth0      Link encap 10Mps Ethernet HWaddr  00:00:C0:90:B3:42
          inet addr 172.16.1.2 Bcast 172.16.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. Для Virtual Brewery, это:
# route add -net 172.16.1.0

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

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

Конечно, вышеупомянутая команда немного утомительна для набора и дает много ошибок. Более удобный подход: использование сетевых имен, которые определены в /etc/networks.. Это делает команду более удобочитаемой. Даже опция -net может быть опущена, потому что route теперь знает, что 172.16.1.0 обозначает сеть:
# route add brew-net

Теперь, когда вы закончили основные шаги конфигурации, надо удостовериться, что Ваш Ethernet-интерфейс, действительно, работает правильно. Выберите машину в вашей Ethernet-сети, например, vlager, и наберите:
# ping vlager
PING vlager: 64 byte packets
64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms
64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms
64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms
64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms
^C
----vstout.vbrew.com PING Statistics----
4 packets transmitted, 4 packets received, 0
round-trip (ms)  min/avg/max = 3/8/12

Если вы не видите подобный вывод, значит что-то не так. Если вы сталкиваетесь с необычным количеством потерянных пакетов, это означает проблему аппаратных средств, типа плохого или отсутствующего терминатора и т.д.. Если вы не получаете пакеты вообще, вы должны проверить конфигурацию интерфейса с помощью 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
172.16.1.0   *        255.255.255.0   U     1      0       10 eth0

Детальное значение этих полей объясняется ниже. Колонка Flags содержит список флагов, устанавливаемых для каждого интерфейса. U всегда установлен для активных интерфейсов, а H сообщает, что адрес места назначения обозначает машину (хост). Если флаг H установлен для маршрута, который вы считаете сетевым маршрутом, тогда вы должны использовать опцию -net с командой route. Чтобы проверить, используется ли маршрут, который вы ввели, посмотрите на поле Use, которое находится между двумя сообщениями ping.

Маршрутизация через шлюз (Gateway)

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

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

# route add wine-net gw vlager

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

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

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

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

Настройка шлюза

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

Весьма полезно добавлять информацию относительно двух интерфейсов к файлу hosts путем показанным ниже так, чтобы иметь удобные имена для них:
172.16.1.1      vlager.vbrew.com    vlager vlager-if1
172.16.2.1      vlager-if2

Последовательность команд для создания двух интерфейсов:
# ifconfig eth0 vlager-if1
# route add brew-net
# ifconfig eth1 vlager-if2
# route add wine-net

Если эта последовательность не работает, проверьте, включена ли в ядре поддержка IP forwarding. Для этого посмотрите первое число во второй строке файла /proc/net/snmp, оно должна быть 1.

Интерфейс PLIP

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

PLIP предоставляет мобильную связь между машинами. Как пример рассмотрим laptop-компьютер служащего Virtual Brewery, который связан с vlager через PLIP. Laptop назван vlite и имеет только один параллельный порт. Во время загрузки, этот порт будет регистрироваться как plip1. Чтобы сформировать связь, Вы должны отконфигурировать интерфейс plip1, используя следующие команды:
# ifconfig plip1 vlite pointopoint vlager
# route add default gw vlager

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

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

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

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

Текущие версии net-tools имеют утилиту plipconfig, которая позволяет настроить параметры PLIP timing. IRQ для порта принтера можно задать командой ifconfig.

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

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

Тупой (Dummy) интерфейс

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

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

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

IP-псевдонимы (IP-Alias)

Новые ядра поддерживают свойство, которое может полностью заменить dummy-интерфейс, и имеет другие полезные функции. IP Alias позволяет конфигурировать много IP-адресов на одно физическое устройство. В самом простом случае Вы могли бы копировать функцию dummy-интерфейса, конфигурируя адрес как псевдоним для loopback, и полностью избежать применения интерфейса dummy. В более сложных случаях Вы могли бы конфигурировать ваш компьютер, чтобы он выглядел как несколько машин с разными IP-адресами. Эта конфигурация иногда называется "Virtual Hosting".

Чтобы конфигурировать псевдоним для интерфейса, вы должны сначала гарантировать что ядро компилировалось с поддержкой для IP Alias (проверьте файл /proc/net/ip_alias, если его нет, ядро придется перестроить). Конфигурация IP-псевдонима фактически идентична конфигурированию реального сетевого устройства. Вы используете специальное имя, чтобы указать, что это псевдоним. Например:
# ifconfig lo:0 172.16.1.1
Эта команда создаст псевдоним для кольцевого интерфейса с адресом 172.16.1.1. IP aliases используют переменную n для каждого устройства, где "n" является целым числом. В нашем примере сетевое устройство, на котором мы создаем псевдоним, lo и создается псевдоним номер ноль для него. Этим путем одно физическое устройство может поддерживать ряд псевдонимов.

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

Назад | Глобальное оглавление | Вперед
Написание файлов hosts и networks | Локальное оглавление | Все про ifconfig


Introduction to Networking

Назад Вперед

Глава 1. Введение в сети

Локальное оглавление
Немного истории
Сети TCP/IP
Сети UUCP
Сети и Linux
Управление Вашей системой

Немного истории

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

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

Я опишу три типа сетей в этом руководстве. Мы с вами сосредоточимся на сетях TCP/IP, потому что это наиболее популярный набор протоколов в локальных (Local Area Networks, LAN) и глобальных сетях (Wide Area Networks, WAN), типа Internet. Мы будем также изучать сети UUCP и IPX. Протокол UUCP раньше обычно использовался для транспортировки новостей и сообщений почты по dialup телефонным подключениям. Это менее распространено сегодня, но все еще полезно в ряде ситуаций. Протокол используется обычно IPX в Novell NetWare, и я опишу как использовать его, чтобы подключить вашу Linux-машину к Novell-сети. Все это протоколы работы с сетями, которые используются, чтобы передавать данные между компьютерами. Мы обсудим, как они используются и их основные принципы.

Мы определяем сеть как совокупность компьютеров (хостов, от hosts), которые могут связаться друг с другом, часто полагаясь на услуги ряда выделенных компьютеров, передающих данные между участниками. Хостом может являться не обязательно полноценный компьютер, им вполне может быть X-терминал или интеллектуальный принтер. Маленькие скопления компьютеров также называют сайтами (sites).

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

Назад | Глобальное оглавление | Вперед
Acknowledgments |  | Сети TCP/IP


What Is a Firewall?

Назад Глава 9. TCP/IP Firewall Вперед

Что такое firewall?

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

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

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

Ядро Linux предоставляет встроенные функции IP firewall. Сетевой код ядра реализует IP filtering несколькими способами и предоставляет интерфейс для управлния правилами фильтрации. Кроме того, Linux firewall имеет еще две полезные функции, не связанные напрямую с фильтрацией пакетов. Они будут рассмотрены позже, пока я просто назову их. Это IP Accounting (глава 10) и IP masquerade (глава 11).

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

Назад | Глобальное оглавление | Вперед
TCP/IP Firewall | Локальное оглавление | Что такое IP Filtering?


IP Addresses

Назад Глава 2. Настройка сети TCP/IP Вперед

IP-адреса

Как сказано в главе 1, IP-адреса, это 32-битовые числа. Каждая машине в данной сети должна иметь уникальный адрес. В локальной сети, которая не использует TCP/IP для связи с другими сетями, вы можете назначить эти адреса согласно вашим персональным предпочтениям. Однако, для участков Internet, они назначаются NIC (Network Information Center). Есть несколько диапазонов IP-адресов, зарезервированных для частных сетей. Они перечислены в таблице 2-1.

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

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

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

Класс A

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

Класс B

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

Класс C

Класс C включает диапазон сетей от 192.0.0.0 до 223.255.255.0. Адрес сети содержится в первых трех octets. Это предполагает почти 2 миллиона подсетей по 254 хоста каждая.

Классы D, E и F

Адреса в диапазоне от 224.0.0.0 до 254.0.0.0 являются экспериментальными или сохранены для будущего использования и не определяют какую-либо сеть. IP Multicast, сервис, который позволяет транслировать в internet данные из одной точки на несколько, может быть связан с этим диапазоном.

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

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

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

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

Некоторые диапазоны адресов каждого из сетевых классов были отложены и обозначены “reserved” или “private”. Эти адреса зарезервированы для использования частными сетями и не направлены на Internet. Они обычно используются организациями, формирующими их собственный intranet (локальные сети с архитектурой и логикой Internet), но даже маленькие сети часто находят их полезными. Зарезервированные сетевые адреса показаны в таблице 2-1 .

Таблица 2-1. Диапазоны IP-адресов, зарезервированных для частных сетей

Класс | Сети
A | от 10.0.0.0 до 10.255.255.255
B | от 172.16.0.0 до 172.31.0.0
C | от 192.168.0.0 до 192.168.255.0
Назад | Глобальное оглавление | Вперед
Настройка сети TCP/IP | Локальное оглавление | Преобразование адресов


IP Configuration Options

Назад Глава 8. Протокол Point-to-Point Вперед

Опции настройки IP (IPCP)

IРCP используется для того, чтобы обговорить пару IP-параметров в конфигурационной связи. Обычно каждый может посылать IPCP-запрос конфигурации, указывая которая переменная хочет измениться из значений по умолчанию и к какому значению. После получения удаленный абонент осматривает каждую опцию, подтверждает или отклоняет ее.

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

Выбор IP-адресов

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

Некоторые PPP-серверы, которые обрабатывают множество клиентов, приписывают адреса динамически: адреса назначены системам только, когда существует обращение и освобождаются после того, как сеанс связи закончен. Это позволяет ограничить число требуемых адресов числом линий dialup. В то время, как ограничение удобно для администраторов PPP dialup-сервера, оно часто куда менее удобно для пользователей. Мы обсуждали путь, которым имена преобразуются в адреса, в главе 6. Когда происходит соединение с таким сервером, вы должны удостовериться, что pppd не запрашивает какой-либо IP-адрес с него, но когда адрес будет выдан, сервер попросит вас, чтобы вы использовали именно его. Это означает, что если кто-то пытается связаться с вашим компьютером, он должен будет знать его текущий адрес, а обеспечить это не так-то просто.

В примере выше, у нас был pppd, связывающейся с c3po и устанавливающий IP-связь. Никакие условия не принимались для того, чтобы выбрать частный адрес IP на любом конце связи. Взамен мы выбрали адрес vlager как локальный адрес IP и позволили c3po обеспечить себя собственным. Иногда полезно иметь контроль над тем, какой адрес используется на одном или другом конце связи.

Чтобы просить о частных адресах, вы вызываете pppd со следующеми опциями:
local_addr:remote_addr

local_addr и remote_addr могут быть определены в dotted quad notation или как имена машин. Это заставит pppd попытаться использовать первый адрес как собственный адрес IP, а второй как адрес удаленной машины. Если удаленная машина отклоняет любой из них в течение IPCP-переговоров, связь IP не будет установлена.

Если вы звоните на сервер и ожидаете, что он назначит вам IP-адрес, надо гарантировать отсутствие неожиданных инициатив со стороны pppd. Чтобы сделать это, используйте опцию noipdefault и оставьте поле local_addr пустым. Опция noipdefault избавит от попытки pppd использовать адрес IP, связанный с именем машины как локальный адрес.

Если Вы хотите устанавливать только локальный адрес, но удаленный адрес примете любой, просто не указывайте remote_addr . Чтобы vlager использовал IP-адрес 130.83.4.27 вместо своего, укажите 130.83.4.27: в командной строке. Точно так же, чтобы установить только удаленный адрес, оставьте пустым поле local_addr. По умолчанию pppd использует адрес, связанный с вашим именем машины (hostname).

Маршрутизация через PPP-линию

После установки сетевого интерфейса, pppd установит маршрут только к своему серверу. Если удаленный хост находится в локальной сети (LAN), вы обязательно захотите соединяться с хостами в ней, то есть должен быть установлен сетевой маршрут.

Мы уже видели, что pppd можно попросить уствновить заданный по умолчанию маршрут, используя опцию defaultroute. Эта опция очень полезна, если PPP-сервер, с которым вы связались, будет действовать как Internet-шлюз.

Обратный случай является относительно простым: ваша система действует как шлюз для единственного хоста. Например, возьмите некоторых служащих в Virtual Brewery, чья локальная машина называется oneshot. При соединении с vlager через PPP, она использует адрес в подсети Brewery. В vlager мы можем теперь дать pppd опцию proxyarp, которая установит ARP-запись для oneshot. Это автоматически сделает oneshot доступным для всех в Brewery и в Winery.

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

Как пример, предположим, что Virtual Brewery открывает ветвь в каком-нибудь другом городе. Подразделение запускает собственную сеть Ethernet, используя сетевой адрес 172.16.3.0, который является подсетью 3 сети Brewery класса B. Они хотят соединиться с Brewery Ethernet по PPP для того, чтобы модифицировать базы данных заказчиков и т.п. Снова vlager действует как шлюз, другая машина называется vbourbon и имеет IP-адрес 172.16.3.1. Такая сеть показана в приложении A.

Когда vbourbon соединится с vlager, она примет заданный по умолчанию маршрут к vlager как обычно. На vlager мы должны установить сетевой маршрут для подсети 3, который проходит к vbourbon. Для этого мы используем особенность pppd, которая еще не обсуждалась: команду ip-up. Это программа, размещенная в /etc/ppp, которая будет выполнена после того, как PPP интерфейс будет сконфигурирован. Когда он существует, эта программа вызывается со следующими параметрами
ip-up iface device speed local_addr remote_addr

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

Аргумент | Имя | Описание
$1 | iface | Используемый сетевой интерфейс, например ppp0
$2 | device | Имя используемого последовательного устройства (если используется stdin/stdout, это будет /dev/tty)
$3 | speed | Скорость устройства бит в секунду
$4 | local_addr | Локальный адрес IP
$5 | remote_addr | Удаленный адрес IP

В нашем случае, скрипт ip-up может содержать следующий фрагмент кода:
#!/bin/sh
case $5 in
172.16.3.1)            # this is vbourbon
        route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0

В подобном режиме /etc/ppp/ip-down используется для того, чтобы отменить все действия ip-up после того, как связь PPP была завершена. В нашем скрипте /etc/ppp/ip-down следует иметь команду route, которая отменит маршрут, созданный /etc/ppp/ip-up.

Однако схема матшрутов еще не полна. Мы установили записи таблицы маршрутов на оба PPP-хоста, но пока все другие хосты в обеих сетях не знают ничего относительно связи PPP. Это небольшая проблема, если все хосты в подразделении имеют свои, заданные по умолчанию маршруты в vbourbon, и все хосты в Brewery направляются по умолчанию на vlager. Если это не так, то ваш единственный выход в использованни демона динамической маршрутизации, например,gated. После создания сетевого маршрута на vlager он передаст новый маршрут всем хостам присоединенной подсети.

Назад | Глобальное оглавление | Вперед
Использование скрипта для автодозвона | Локальное оглавление | Опции контроля связи


Configuring IP Accounting

Назад Глава 10. IP Accounting Вперед

Настройка IP Accounting

Поскольку IP accounting очень тесно связан с IP firewall, для их настройки используется одна программа. В зависимости от реализации это ipfwadm, ipchains или iptables. Синтаксис команды очень похож на используемый при задании правил firewall.

Общий синтаксис для IP accounting с ipfwadm:
# ipfwadm -A [direction] [command] [parameters]

Появился новый параметр direction. Он принимает значения in, out или both. Все значения считаются с точки зрения linux-машины, так что in задает входящий трафик, out задает исходящий трафик, а both оба типа сразу.

Общий синтаксис для ipchains и iptables:
# ipchains -A chain rule-specification
# iptables -A chain rule-specification

Команды ipchains и iptables позволяют Вам определять направление в стиле, больше похожем на определения правил. IP Firewall Chains не позволяет настроить правила для обоих направлений сразу, но позволяет настроить правила в наборе forward, чего старая реализация не умела.

Команды очень похожи на свои аналоги для правил firewall за исключением того, что стратегии здесь не применяются. Мы можем добавлять, вставлять, удалять и просматривать список правил учета. В случае ipchains и iptables, все имеющие силу правила считаются правилами для учета, и любая команда, которая не определяет опцию -j, выполняет только учет.

Параметры спецификации правила для учета IP такие же, как и для IP firewall.

Учет по адресам

Давайте на примере покажем, как мы использовали бы учет IP.

Допустим, у нас есть Linux-роутер, который обслуживает два департамента Virtual Brewery. Он имеет два устройства Ethernet, eth0 и eth1, по одному на департамент, и одно устройство PPP, ppp0, для связи через быстродействующую последовательную связь с университетским городком Groucho Marx University.

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

Следующая таблица показывает используемые нами адреса и интерфейсы:

Интерфейс | Адрес | Сетевая маска
eth0 | 172.16.3.0 | 255.255.255.0
eth1 | 172.16.4.0 | 255.255.255.0

Для ответа на вопрос, сколько данных каждый отдел передает по PPP, мы могли бы использовать правило, которое напоминает:
# ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b
# ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b
или:
# ipchains -A input -i ppp0 -d 172.16.3.0/24
# ipchains -A output -i ppp0 -s 172.16.3.0/24
# ipchains -A input -i ppp0 -d 172.16.4.0/24
# ipchains -A output -i ppp0 -s 172.16.4.0/24
или с iptables:
# iptables -A FORWARD -i ppp0 -d 172.16.3.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.3.0/24
# iptables -A FORWARD -i ppp0 -d 172.16.4.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.4.0/24

Первая половина каждого набора правил задает подсчет всех данных, передаваемых по интерфейсу ppp0 с исходным адресом или адресом назначения 172.16.3.0/24. Здесь полезна опция -b в ipfwadm и iptables. Вторая половина каждого набора правил задает то же самое, но для второй сети Ethernet.

Для ответа на вопрос, сколько трафика проходит между департаментами, нужно правило, которое выглядит следующим образом:
# ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b
или:
# ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b
или:
# iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24
# iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24
Эти правила будут считать все пакеты с исходящими адресами сети одного департамента и адресом назначения в сети другого.

Учет по портам сервисов

Предположим, мы хотим также знать, какой именно трафик преобладает на связи через PPP. Например, надо выяснить, сколько данных проходит по протоколам FTP, smtp и World Wide Web.

Для сбора этой информации пригоден такой скрипт с правилами:
#!/bin/sh
# Collect FTP, smtp and www volume statistics for data carried on our
# PPP link using ipfwadm
#
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 smtp
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www
или:
#!/bin/sh
# Collect ftp, smtp and www volume statistics for data carried on our
# PPP link using ipchains
#
ipchains -A input -i ppp0 -p tcp -s 0/0 ftp-data:ftp
ipchains -A output -i ppp0 -p tcp -d 0/0 ftp-data:ftp
ipchains -A input -i ppp0 -p tcp -s 0/0 smtp
ipchains -A output -i ppp0 -p tcp -d 0/0 smtp
ipchains -A input -i ppp0 -p tcp -s 0/0 www
ipchains -A output -i ppp0 -p tcp -d 0/0 www
или:
#!/bin/sh
# Collect ftp, smtp and www volume statistics for data carried on our
# PPP link using iptables.
#
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport ftp-data:ftp
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport smtp
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport www

Здесь есть пара интересных свойств. Во-первых, мы определили протокол. Когда мы определяем порты в наших правилах, мы должны также определить протокол потому, что TCP и UDP имеют отдельные наборы портов. Так как все эти услуги основаны на TCP, мы определяем именно этот протокол. Во-вторых, мы определили два сервиса, ftp и ftp-data в одной команде. ipfwadm позволяет определять одиночные порты, диапазоны портов или произвольные списки портов. Команда ipchains позволяет определять любой одиночный порт или диапазон портов. Запись "ftp-data:ftp" означает "порты с ftp-data (20) по ftp (21)", так можно кодировать порты в ipchains и iptables. Когда вы имеете список портов в правиле учета, это означает, что любые данные для любого из портов в списке будут добавлены к общему количеству для этой записи. Поскольку FTP использует два порта, команды и данные, мы добавили их вместе к общему трафику FTP. Наконец, мы определили исходный адрес как 0/0, что соответствует всем адресам и требуется ipfwadm и ipchains для определения портов.

Теперь нас интересует соотношение полезного трафика по FTP, SMTP и World Wide Web к трафику по другим протоколам. Для этого зададим такие правила:
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767

Если вы уже исследовали ваш файл /etc/services, вы увидите, что второе правило покрывает все порты за исключением (ftp, ftp-data, smtp и www).

Как сделать это с командами ipchains или iptables, ведь они позволяют только один параметр в спецификации порта? Мы можем эксплуатировать определяемые пользователем цепочки в учете так же легко, как в правилах firewall. Рассмотрим следующий подход:

# ipchains -N a-essent
# ipchains -N a-noness
# ipchains -A a-essent -j ACCEPT
# ipchains -A a-noness -j ACCEPT
# ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent
# ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent
# ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j a-essent
# ipchains -A forward -j a-noness
Здесь мы создаем две определяемых пользователем цепочки: a-essent, где мы фиксируем данные для полезного трафика и a-noness, где мы собираем данные для всего остального. Затем добавим правила к цепочке forward, которые соответствуют полезным сервисам и задают переход в цепочку a-essent , которая только считает трафик. Последнее правило в нашей цепочке forward задает переход к цепочке a-noness, где тоже есть только одно правило, считающее трафик. Правило, которое переходит к цепочке a-noness, не будет достигнуто любым пакетом из полезных сервисов, поскольку они будут приняты в их собственной цепочке. Наши счетчики для полезных и остальных услуг будут доступны только в правилах внутри тех цепочек. Это только один подход, который вы могли бы избрать. Реализация того же самого подхода для iptables:
# iptables -N a-essent
# iptables -N a-noness
# iptables -A a-essent -j ACCEPT
# iptables -A a-noness -j ACCEPT
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp -j a-essent
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp -j a-essent
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www -j a-essent
# iptables -A FORWARD -j a-noness

Это выглядит достаточно простым. К сожалению, имеется маленькая, но неизбежная проблема при попытке делать учет сервисным типом. Мы обсуждали в одной из предыдущих глав роль MTU в работе с сетями TCP/IP. MTU определяет самый большой пакет, который будет передан на сетевое устройство. Когда пакет получен маршрутизатором, и этот пакет больше, чем MTU интерфейса, который должен его передать, маршрутизатор выполняет фрагментацию (fragmentation). Маршрутизатор разбивает большой пакет на маленькие части не больше, чем MTU интерфейса, и затем передает эти части. Маршрутизатор формирует новые заголовки для получившихся пакетов, по которым получатель сможет восстановить исходный пакет. К сожалению, в течение фрагментации значение порта будет потеряно для всего, кроме первого фрагмента. Это означает, что учет IP не может правильно считать фрагментированные пакеты, а только первые фрагменты или нефрагментированные пакеты. Имеется маленькая хитрость ipfwadm, которая позволяет считать пакеты, даже не зная порт второго и последующих фрагментов. Первая версия программного обеспечения Linux accounting назначала фрагментам поддельный номер порта 0xFFFF, который мы могли перехватывать для учета. Мы фиксируем вторые и последующие фрагменты, используя правило:
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF

Реализация IP chains имеет немного более сложное решение, но результат тот же самый. При использовании команды ipchains надо использовать правило:
# ipchains -A forward -i ppp0 -p tcp -f
Для iptables подойдет правило:
# iptables -A FORWARD -i ppp0 -m tcp -p tcp -f

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

В ядрах 2.2 вы можете выбирать при настройке ядра опцию, которая решает эту проблему, если ваша Linux-машина действует как одиночная точка доступа к сети. Если вы включили при построении ядра опцию IP: always defragment, все пакеты будут повторно собраны маршрутизатором Linux перед маршрутизацией и передачей. Эта операция выполняется перед firewall, и учетный блок видит пакеты. Таким образом, фрагментов просто не будет. В ядрах 2.4 откомпилируйте и загрузите netfilter с модулем forward-fragment.

Учет по пакетам ICMP

Протокол ICMP не использует сервисные номера портов, так что сбор статистики по нему труднее. ICMP использует ряд различных типов пакетов. Многие из их безобидны и нормальны, в то время, как другие появляются только при специальных обстоятельствах. Иногда пытаются обвалить систему, посылая огромное число пакетов ICMP. Эта атака называется ping flooding. Против такой атаки хорош IP firewall, а IP accounting позволит узнать, кто это сделал.

ICMP не использует порты в отличие от TCP и UDP. Вместо них используются типы сообщений ICMP. Мы можем создать правила, чтобы учитывать каждый тип сообщений ICMP. Для этого нужно определить тип сообщения ICMP вместо номера порта в команде ipfwadm. Типы сообщений перечислены в разделе "Типы пакетов ICMP" главы 9.

Для сбора данных о передаче пакетов ICMP по всем типам сообщений используйте правило:
# ipfwadm -A both -a -P icmp -S 0/0 8
# ipfwadm -A both -a -P icmp -S 0/0 0
# ipfwadm -A both -a -P icmp -S 0/0 0xff
или в ipchains:
# ipchains -A forward -p icmp -s 0/0 8
# ipchains -A forward -p icmp -s 0/0 0
# ipchains -A forward -p icmp -s 0/0 -f
или в iptables:
# iptables -A FORWARD -m icmp -p icmp --sports echo-request
# iptables -A FORWARD -m icmp -p icmp --sports echo-reply
# iptables -A FORWARD -m icmp -p icmp -f
Первое правило собирает информацию относительно пакетов ICMP Echo Request (ping requests), второе правило собирает информацию относительно пакетов ICMP Echo Reply (ping replies). Третье правило собирает информацию относительно фрагментированных пакетов ICMP. Этот прием подобен описанному для фрагментированных пакетов TCP и UDP.

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

Учет по протоколам

Допустим, нам интересно, какие протоколы используются нашим трафиком: TCP, UDP или ICMP. Тут нам поможет правило:
# ipfwadm -A both -a -W ppp0 -P tcp -D 0/0
# ipfwadm -A both -a -W ppp0 -P udp -D 0/0
# ipfwadm -A both -a -W ppp0 -P icmp -D 0/0
или:
# ipchains -A forward -i ppp0 -p tcp -d 0/0
# ipchains -A forward -i ppp0 -p udp -d 0/0
# ipchains -A forward -i ppp0 -p icmp -d 0/0
или:
# iptables -A FORWARD -i ppp0 -m tcp -p tcp
# iptables -A FORWARD -o ppp0 -m tcp -p tcp
# iptables -A FORWARD -i ppp0 -m udp -p udp
# iptables -A FORWARD -o ppp0 -m udp -p udp
# iptables -A FORWARD -i ppp0 -m icmp -p icmp
# iptables -A FORWARD -o ppp0 -m icmp -p icmp
С этими правилами трафик через интерфейс ppp0 будет проанализирован, чтобы определить тип протокола: TCP, UDP или IMCP, и соответствующие счетчики будут модифицированы для каждого пакета.

Назад | Глобальное оглавление | Вперед
IP Accounting | Локальное оглавление | Using IP Accounting Results


IP Masquerade and Network Address Translation

Назад Вперед

Глава 11. IP Masquerade и Network Address Translation

Локальное оглавление
Краевые эффекты
Настройка ядра для IP Masquerade
Настройка IP Masquerade
Перехват обращений к серверу имен
Еще о сетевой трансляции адресов (Network Address Translation)

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

Одной из частей этого сервиса является сетевая трансляция адресов (Network Address Translation, NAT). NAT описывает процесс изменения сетевых адресов, содержащихся в заголовках пакетов. Этот подход является идеальным для решения проблемы. Таким образом, ВСЯ сеть может реально работать с Internet через ОДИН IP-адрес!

IP masquerading позволяет использовать частный IP-адрес в локальной сети и поручить маршрутизатору преобразование адресов с учетов сервисов и портов. Когда такой маршрутизатор получает пакет из внутренней сети, он меняет его так, будто пакет пришел на самом деле от маршрутизатора. Затем пакет отсылается в сеть. С пакетами ответов из сети выполняется то же самое, но в обратном порядке.

Мы имеем маленькую сеть Ethernet на частных адресах, которые не могут использоваться в Internet. Сеть имеет Linux-маршрутизатор, обеспечивающий доступ к Internet. Одно из автоматизированных рабочих мест в сети (192.168.1.3) пожелало установить подключение к удаленному компьютеру 209.1.106.178 через порт 8888. Автоматизированное рабочее место направляет пакет маршрутизатору, который идентифицирует этот запрос подключения как требование услуг masquerade. Он принимает пакет, выделяет для него порт 1035, заменяет адрес и номер порта в пакете и передает пакет в сеть. Компьютер адресата полагает, что получил подключения из Linux-компьютера, который обеспечивает masquerade, и посылает ответ. Маршрутизатор после получения этого ответа находит связь в таблице masquerade и производит обратную замену адреса и порта. Локальный компьютер полагает, что он работает непосредственно с удаленным компьютером. Удаленный главный компьютер не знает ничего относительно локального компьютера вообще и полагает, что получил подключение с Linux-компьютера, обеспечивающего masquerade.

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

Краевые эффекты

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

Ни один из компьютеров в сети позади маршрутизатора masquerade никогда не проявится в сети непосредственно. Следовательно, вы нуждаетесь только в одном реальном адресе IP, чтобы позволить всем компьютерам делать сетевые подключения в Internet. Это имеет и плохую сторону: ни один из этих компьютеров не видим из Internet, и вы не можете непосредственно соединяться с ними из Internet. Единственный компьютер, видимый в masquerade-сети, это машина, которая обеспечивает masquerade. Это важно, когда используются услуги типа почты или FTP. Этот факт помогает определять то, что услуги нужно обеспечить masquerade-компьютером.

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

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

Наконец, некоторые сетевые сервисы либо вообще не работают через masquerade, либо требуют немало работы по их настройке. Обычно это сервисы, которым нужны входящие соединения: Direct Communications Channels (DCC), IRC, разные видео и аудио трансляций. Некоторые из этих услуг имеют модули для своей работы в такой ситуации, другие вообще не могут быть использованы.

Назад | Глобальное оглавление | Вперед
Пассивные коллекции данных доступа |  | Настройка ядра для IP Masquerade


IPX and the NCP Filesystem

Назад Вперед

Глава 15. IPX и файловая система NCP

Локальное оглавление
Xerox, Novell и немного истории
IPX и Linux
Настройка ядра для IPX и NCPFS
Настройка интерфейса IPX
Настройка маршрутизатора IPX
Монтирование удаленных томов NetWare
Утилиты IPX
Выполнение заданий NetWare на печать
Эмуляция сервера NetWare

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

Linux поддерживает не только протоколы TCP/IP, но также и набор протоколов, используемых операционной системой Novell Corporation's NetWare. Эти протоколы дальние родственники TCP/IP, и хотя они делают то же самое, но работают совсем иначе, что делает их несовместимыми с TCP/IP.

Linux имеет свободное и коммерческое программное обеспечение, чтобы обеспечить поддержку интеграции с Novell.

Xerox, Novell и немного истории

В 1970 годах Xerox Corporation разработала и опубликовала открытый стандарт Xerox Network Specification (XNS). Xerox Network Specification описывал набор протоколов, разработанных для универсальной работы с сетями с сильным акцентированием на использовании локальных сетей. Имелись два первичных протокола работы с сетями: Internet Datagram Protocol (IDP), который обеспечил соединение и не очень надежный обмен данными, и Sequenced Packet Protocol (SPP), который был другой формой IDP, ориентированной на подключение и надежной. Пакеты XNS-сети были индивидуально адресованы. Схема адресации использовала комбинацию сетевого адреса IDP с 4 байтами (который был уникально назначен каждому сегменту Ethernet LAN) и адреса узла с 6 байтами (адрес NIC-платы). IDP не имеет никакого понятия подсетей: любая новая совокупность компьютеров требовала, чтобы был назначен другой сетевой адрес. Сетевые адреса были выбраны так, что они являются уникальными на совокупности рассматриваемой сети.

Novell Corporation создала свой набор протоколов на основе протоколов XNS. Novell слегка расширила IDP и SPP и переименовала их соответственно в IPX (Internet Packet eXchange) и SPX (Sequenced Packet eXchange). Novell добавила новые протоколы, типа NetWare Core Protocol (NCP), который обеспечил свойства разделения файлов и принтеров по сети IPX, и Service Advertisement Protocol (SAP), который давал возможность компьютерам в Novell-сети знать, который компьютер какие услуги обеспечивает.

Таблица 15-1 показывает связь между наборами XNS, Novell и TCP/IP в терминах функций. Связи только приблизительные, но они должны помочь вам понять, что там происходит, когда мы займемся этими протоколами позже.

Таблица 15-1. Связи протоколов XNS, Novell и TCP/IP

XNS | Novell | TCP/IP | Функция
IDP | IPX | UDP/IP | Связь, ненадежная передача
SPP | SPX | TCP | Надежная передача
Нет | NCP | NFS | Файловый сервис
Нет | RIP | RIP | Обмен информацией маршрутизации
Нет | SAP | Нет, а жаль | Сервисный обмен информации доступности
Назад | Глобальное оглавление | Вперед
Поддержка серверов NFS v3 |  | IPX и Linux


Configuring IPX Interfaces

Назад Глава 15. IPX и файловая система NCP Назад

Настройка интерфейса IPX

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

Сетевые устройства с поддержкой IPX

Протокол IPX считает, что любая совокупность компьютеров, которые могут передать пакеты друг другу без маршрутизации, принадлежит одной и той же IPX-сети. Все компьютеры, принадлежащие к одиночному сегменту сети Ethernet будут принадлежать к одной IPX-сети. Аналогично, оба компьютера, обеспечивающие PPP-связь, должны принадлежать IPX-сети, которая непосредственно является последовательной связью. В среде Ethernet имеется ряд различных типов пакетов, которые могут использоваться, чтобы нести пакеты IPX. Типы пакетов представляют различные протоколы сети Ethernet и описывают отличающиеся пути переноса протоколов. Наиболее общие типы пакетов, с которыми вы столкнетесь: 802.2 и ethernet_II.

Сетевые устройства Linux, которые в настоящее время поддерживают протокол IPX: Ethernet и PPP. Ethernet или PPP интерфейс должен быть активен до настройки для использования IPX. Обычно, Вы конфигурируете устройство Ethernet для IP и IPX, так что устройство уже существует, но если ваша сеть только для IPX, вы должны использовать ifconfig, чтобы изменить состояние устройства на следующее:
# ifconfig eth0 up

Утилиты настройки интерфейса IPX

Greg Page разработал набор утилит настройки IPX, который является обычным пакетом в современных дистрибутивах и может быть также получен в исходной форме по anonymous FTP с http://metalab.unc.edu/ (файл /pub/Linux/system/filesystems/ncpfs/ipx.tgz).

Скрипт rc обычно выполняет инструментальные средства IPX при загрузке.

Команда ipx_configure

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

Без параметров ipx_configure отображает текущие настройки флажков автоконфигурации:
# ipx_configure
Auto Primary Select is OFF
Auto Interface Create is OFF

Флажки Auto Primary и Auto Interface по умолчанию выключены. Для их включения и запуска автоконфигурации, задайте параметры:
# ipx_configure --auto_interface=on --auto_primary=on

Когда параметр --auto_primary установлен в on, ядро автоматически гарантирует, что как минимум один активный интерфейс функционирует как первичный интерфейс для компьютера.

Когда параметр --auto_interface установлен в on, IPX-драйвер ядра будет слушать все пакеты, полученные на активных сетевых интерфейсах, и пытаться определить сетевой адрес IPX и используемый тип пакета.

Механизм автоматического определения работает хорошо на правильно управляемых сетях. Есть примеры настройки сети IPX так, чтобы по Ethernet шли пакеты разных типов, что технически недопустимо. Настроенный как 802.2 компьютер не может непосредственно связываться с сетью Ethernet-II и, следовательно, не может быть в той же самой IPX-сети. Linux IPX-поддержка слушает на сегменте IPX-пакеты. Из них она пытается вычислить адрес и тип пакета, если типы пакетов разные, или они идут на несколько интерфейсов сразу, это будет понято как сетевая проверка на пересечение адреса. Определить правильный тип пакета в такой ситуации едва ли получится. В файле протокола в такой ситуации появится нечто вроде:
IPX: Network number collision 0x3901ab00
eth0 etherII and eth0 802.3
Если Вы видите эту проблему, отключите автоматическое определение и настройте интерфейсы вручную, используя команду ipx_interface, как сказано ниже.

Команда ipx_interface

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

Синтаксис команды, чтобы добавить IPX на существующее устройство Ethernet:
# ipx_interface add -p eth0 etherII 0x32a10103
Параметры означают:

-p

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

eth0

Имя сетевого устройства, на которое мы добавляем поддержку IPX.

etherII

Тип пакета, в даноом случае Ethernet-II. Это значение также может быть кодировано как 802.2, 802.3 или SNAP.

0x32a10103

Сетевой адрес IPX, которому этот интерфейс принадлежит.

Следующая команда удаляет IPX из интерфейса:
# ipx_interface del eth0 etherII

Наконец, чтобы отобразить текущую конфигурацию IPX для сетевого устройства используйте:
# ipx_interface check eth0 etherII

Команда ipx_interface подробно описана на ее man-странице.

Назад | Глобальное оглавление | Вперед
Настройка ядра для IPX и NCPFS | Локальное оглавление | Настройка маршрутизатора IPX


Exploring Some of the Other IPX Tools

Назад Глава 15. IPX и файловая система NCP Вперед

Утилиты IPX

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

Список серверов

Команда slist перечисляет все серверы файлов доступные для этого компьютера. Информация будет получена из самого близкого IPX-маршрутизатора. Эта команда была, вероятно, первоначально предназначена, чтобы позволить пользователям видеть, что серверы файлов доступны для монтирования. Но это стало полезным как сетевой инструмент диагностики, позволяя сетевым администраторам видеть, где информация SAP размножается:

$ slist
NPPWR-31-CD01         23A91330  000000000001
V242X-14-F02          A3062DB0  000000000001
QITG_284ELI05_F4      78A20430  000000000001
QRWMA-04-F16          B2030D6A  000000000001
VWPDE-02-F08          35540430  000000000001
NMCS_33PARK08_F2      248B0530  000000000001
NCCRD-00-CD01         21790430  000000000001
NWGNG-F07             53171D02  000000000001
QCON_7TOMLI04_F7      72760630  000000000001
W639W-F04             D1014D0E  000000000001
QCON_481GYM0G_F1      77690130  000000000001
VITG_SOE-MAIL_F4R     33200C30  000000000001

slist не принимает параметры. В выводе будут: имя сервера файлов, IPX-адрес сети и адрес машины.

Рассылка сообщений пользователям NetWare

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

# nsend -S vbrew_f1 -U gary -P j0yj0y supervisor
      “Join me for a lager before we do the print queues!”

Здесь пользователь gary посылает оповещение человеку, использующему логин supervisor на сервере ALES_F1. По умолчанию используются ваши параметры входа в систему и имя сервера.

Просмотр и управление данными bindery

Каждый файловый сервер NetWare поддерживает базу данных пользователей и конфигурации. Эта база данных называется bindery. Linux поддерживает набор инструментальных средств, которые позволяют читать эти записи, и если вы имеете разрешения супервизора на сервере, то менять и удалять эти данные. Резюме этих инструментальных средств перечислено в таблице 15-3.

Таблица 15-3. Утилиты Linux для работы с Bindery

Имя команды | Описание
nwfstime | Отображает или меняет дату и время на сервере NetWare
nwuserlist | Список пользователей, в данный момент работающих с сервером NetWare
nwvolinfo | Данные о томах NetWare
nwbocreate | Создать объект NetWare bindery
nwbols | Перечислить объекты NetWare bindery
nwboprops | Перечислить свойства объекта NetWare bindery
nwborm | Удалить объект NetWare bindery
nwbpcreate | Создать свойство NetWare bindery
nwbpvalues | Вывести содержимое свойства NetWare bindery
nwbpadd | Задать содержимое свойства NetWare bindery
nwbprm | Удалить свойство NetWare bindery
Назад | Глобальное оглавление | Вперед
Монтирование удаленных томов NetWare | Локальное оглавление | Выполнение заданий NetWare на печать


Resolving Host Names

Назад Глава 2. Настройка сети TCP/IP Вперед

Преобразование имен машин

Как описано выше, адресация в сети TCP/IP крутится вокруг 32-разрядных адресов. Однако, вам будет трудно запомнить даже некоторые из них. Поэтому хосты чаще известны под "обычными" именами типа gauss или strange. Поэтому требуются программы для получения IP-адреса по имени машины. Этот процесс назван получением имени (hostname resolution).

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

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

Одно из решений этой проблемы: сетевая информационная система (Network Information System, NIS), разработанная Sun Microsystems, также известная как YP или желтые страницы. NIS хранит файл hosts и другую информацию в базе данных на главном хосте, с которого клиенты могут восстановить свои файлы, если это необходимо. Этот способ подходит только для сетей среднего размера, потому что он требует поддерживать полную базу данных как на центральной машине, так и на всех остальных. Установка и настройка NIS подробно рассмотрены в главе 13.

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

Вот почему в 1984 г. была введена новая схема Domain Name System (DNS), разработанная Paul Mockapetris и решившая обе проблемы одновременно. Domain Name System подробно обсуждается в главе 6.

Назад | Глобальное оглвление | Вперед
Internet Control Message Protocol | Локальное оглавление | Настройка сетевого оборудования


IP Routing

Назад Глава 2. Настройка сети TCP/IP Вперед

IP-маршрутизация

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

IP-сети

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

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

Подсети

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

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

Подсеть принимает ответственность за доставку пакетов для определенного диапазона IP-адресов. Как с классами A, B или C она идентифицируется сетевой частью IP-адресов. Однако, сетевая часть теперь расширена, чтобы включить некоторые биты части хоста. Число битов, которые интерпретируются как номер в подсети, задается так называемой маской подсети (subnet mask) или 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.

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

Gateways

Subnetting не только организационное деление, но часто и естественное следствие границ аппаратных средств. Знания хостов о строении данной физической сети, типа Ethernet, являются очень ограниченными: единственные хосты, с которыми они способны говорить непосредственно, те, что находятся в той же сети. Ко всем другим хостам они могут обращаться только через так называемый gateway (шлюз). 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.1.1, а при работе с хостом на магистрали она должна использовать 149.76.1.0 . Таким образом, gateway получает по одному IP-адресу на каждую сеть, к которой подключен. Эти адреса (вместе с netmask) привязаны к интерфейсу, через который обращаются подсети. Значит, интерфейсы и адреса sophus связаны так:

Интерфейс | Адрес | Маска подсети
eth0 | 149.76.4.1 | 255.255.255.0
fddi0 | 149.76.1.1 | 255.255.255.0
lo | 127.0.0.1 | 255.0.0.0

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

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

Таблица маршрутов (Routing Table)

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

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

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

Сеть | Netmask | Gateway | Интерфейс
149.76.1.0 | 255.255.255.0 | - | fddi0
149.76.2.0 | 255.255.255.0 | 149.76.1.2 | fddi0
149.76.3.0 | 255.255.255.0 | 149.76.1.3 | fddi0
149.76.4.0 | 255.255.255.0 | - | eth0
149.76.5.0 | 255.255.255.0 | 149.76.1.5 | fddi0
… | … | … | …
0.0.0.0 | 0.0.0.0 | 149.76.1.2 | fddi0

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

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

Процесс определения правильного маршрута прост, но требует знания логики и двоичной арифметики: маршрут совпадает с пунктом назначения, если (адрес сети AND netmask)=(адрес назначения AND netmask).

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

Когда реализация IP ищет самый лучший маршрут к адресату, может найтись ряд записей маршрутизации, которые соответствуют целевому адресу. Например, мы знаем, что заданный по умолчанию маршрут соответствует каждому адресату, но пакеты, предназначенные для местных сетей, будут соответствовать и их локальному маршруту. Как узнать, какой маршрут использовать? Здесь netmask играет важную роль. В то время как оба маршрута соответствуют адресату, один из маршрутов имеет большую netmask, чем другой. Я уже упомянул, что netmask используется, чтобы разбить наше адресное пространство на меньшие сети. Больший netmask более определенно задает целевой адрес, значит, при маршрутизации мы должны всегда выбирать маршрут, который имеет самую большую netmask. Заданный по умолчанию маршрут имеет netmask из нулевых битов, и в конфигурации, приведенной выше, местные сети имеют 24-разрядный netmask. Если пакет соответствует местной сети, он будет направлено на соответствующее устройство, а не на заданный по умолчанию маршрут, потому что локальный сетевой маршрут соответствует netmask с большим числом битов. Единственный пакет, который будет направлен через заданный по умолчанию маршрут это тот, который не соответствует вообще никакому другому маршруту.

В зависимости от размера сети используются различные протоколы маршрутизации. Для маршрутизации в автономной системе (типа университетского городка) лучше подходит внутренний протокол маршрутизации (internal routing protocols), например, RIP (Routing Information Protocol, протокол маршрутной информации), который предложен в демоне BSD routed. Для маршрутизации между автономными системами используются внешние протоколы маршрутизации (external routing protocols) типа EGP (External Gateway Protocol) или BGP (Border Gateway Protocol). Они были предложены в демоне gated (разработка University of Cornell's).

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

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

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

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

Назад | Глобальное оглавление | Вперед
Преобразование адресов | Локальное оглавление | Internet Control Message Protocol


Issues of TCP/IP Networking

Назад Вперед

Глава 2. Настройка сети TCP/IP

Локальное оглавление
Сетевые интерфейсы
IP-адреса
Преобразование адресов
IP-маршрутизация
Internet Control Message Protocol
Преобразование имен машин

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

На английском языке есть прекрасная книга (трехтомник) о TCP/IP Internetworking with TCP/IP, автор Douglas R. Comer (издательство Prentice Hall). Более подробно сети a TCP/IP рассмотрены в книге TCP/IP Network Administration, автор Craig Hunt (издательство O'Reilly).

Сетевые интерфейсы

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

Для каждого переферийного устройства, которое вы хотите использовать, в ядре должен быть представлен соответствующий интерфейс. Например, Ethernet-интерфейсы в Linux названы eth0 и eth1, интерфейсы PPP (обсуждаются в главе 8) ppp0 и ppp1, а FDDI-интерфейсы fddi0 и fddi1. Эти названия интерфейса используются при конфигурировании, когда вы хотите определить ядру специфическое физическое устройство. Они не имеют никакого назначения кроме этого.

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

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

Назад | Глобальное оглавление | Вперед
Поддержка вашей системы |  | IP-адреса


Configuring the Kernel for IPX and NCPFS

Назад Глава 15. IPX и файловая система NCP Вперед

Настройка ядра для IPX и NCPFS

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

Следующие параметры должны быть выбраны, если вы хотите иметь в Linux поддержку протокола IPX:
General setup  --->
    [*] Networking support

Networking options  --->
    <*> The IPX protocol

Network device support  --->
    [*] Ethernet (10 or 100Mbit)
        ... and appropriate Ethernet device drivers
Если вы хотите, чтобы Linux поддерживала файловую систему NCP, чтобы монтировать удаленные тома NetWare, вы должны дополнительно выбрать параметры:
Filesystems  --->
   [*] /proc filesystem support
   <*> NCP filesystem support (to mount NetWare volumes)
Когда вы откомпилируете и установите ваше новое ядро, поддержка протокола IPX и файловой системы NCP будет доступна.

Назад | Глобальное оглавление | Вперед
IPX и Linux | Локальное оглавление | Настройка интерфейса IPX


Configuring the Kernel for IP Masquerade

Назад Глава 11. IP Masquerade and Network Address Translation Вперед

Настройка ядра для IP Masquerade

Чтобы использовать IP masquerade, ваше ядро должно компилироваться с поддержкой masquerade. Вы должны выбрать следующие параметры при конфигурировании ядра ряда 2.2:
Networking options  --->
        [*] Network firewalls
        [*] TCP/IP networking
        [*] IP: firewalling
        [*] IP: masquerading
        --- Protocol-specific masquerading support will be built as modules.
        [*] IP: ipautofw masq support
        [*] IP: ICMP masquerading
Обратите внимание, что часть поддержки masquerade доступна только как модуль ядра. Это означает, что Вы должны гарантировать выполнение команды make modules в дополнение к обычной make zImage при сборке ядра.

Ядра ряда 2.4 больше не предлагают поддержку IP masquerade как опцию при сборке ядра. Вместо этого, Вы должны выбрать фильтрацию сетевых пакетов:
Networking options  --->
    [M] Network packet filtering (replaces ipchains)

В ядрах серии 2.2 будет создан ряд специфических для протоколов модулей в течение сборки ядра. Некоторые протоколы начинаются с исходящего запроса на одном порте, а затем ожидают входящее подключение на другом. Обычно они не могут быть masqueraded, так как нет способа логически связать оба соединения без работы напрямую с пакетами и понимания логики протокола. Модули делают именно это: они фактически смотрят внутрь пакетов и позволяют masquerading работать для поддержанных протоколов. Такие модули называют также модулями-помощниками. Поддерживаемые протоколы:

Модуль | Протокол
ip_masq_ftp | FTP
ip_masq_irc | IRC
ip_masq_raudio | RealAudio
ip_masq_cuseeme | CU-See-Me
ip_masq_vdolive | For VDO Live
ip_masq_quake | IdSoftware's Quake
Вы должны загрузить эти модули вручную, используя команду insmod, чтобы выполнить их. Обратите внимание, что эти модули не могут быть загружены демоном kerneld. Каждый из модулей принимает параметр определяющий, на каких портах он будет слушать. Для модуля RealAudio Вы могли бы использовать:
# insmod ip_masq_raudio.o ports=7070,7071,7072
Порты, которые Вы должны определить, зависят от протокола. IP masquerade mini-HOWTO (автор: Ambrose Au) объясняет подробности о модулях IP masquerade и как конфигурировать их.

Пакет netfilter включает модули, которые выполняют подобные функции. Например, чтобы обеспечить работу сеансов FTP, используйте модули ip_conntrack_ftp и ip_nat_ftp.o.

Назад | Глобальное оглавление | Вперед
IP Masquerade and Network Address Translation | Локальное оглавление | Configuring IP Masquerade


Kernel-Based NFSv2 Server Support

Назад Глава 14. The NetworkFile System Вперед

Поддержка серверов NFS v2

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

Ядро 2.2.0 поддерживает экспериментальный сервер NFS уровня ядра, разработанный Olaf Kirch, H.J. Lu, G. Allan Morris и Trond Myklebust. Поддержка NFS ядром обеспечивает значительное увеличение эффективности.

В текущих дистрибутивах инструментальные средства сервера доступны в откомпилированном виде. Если их не оказалось в вашем дистрибутиве, они доступны для скачивания на http://csua.berkeley.edu/gam3/knfsd. Вы должны формировать ядро 2.2.0 с поддержкой NFS демона уровня ядра, чтобы использовать инструментальные средства. Вы можете узнать имеет ли ваше ядро NFS daemon, проверив существование файла /proc/sys/sunrpc/nfsd_debug. Если файла нет, вам, вероятно, придется загружать модуль rpc.nfsd, используя утилиту modprobe.

Ядерный демон NFS использует стандартный файл конфигурации /etc/exports. Пакет обеспечивает новые версии демонов rpc.mountd и rpc.nfsd, так что в плане администрирования мало что изменилось , а производительность сервера существенно выросла.

Назад | Глобальное оглавление | Вперед
Файл exports | Локальное оглавление | Поддержка серверов NFS v3


Kernel-Based NFSv3 Server Support

Назад Глава 14. Сетевая файловая система (NFS) Вперед

Поддержка серверов NFS v3

Наиболее используемая версия NFS: NFS Version 2. Однако, в ней выявлены слабости, которые может преодолеть только изменение протокола. Третья версия NFS поддерживает большие файлы и файловые системы, добавляет значительно расширенную защиту и предлагает ряд усовершенствований, которые большинство пользователей найдут полезными.

Olaf Kirch и Trond Myklebust разрабатывают экспериментальный сервер NFSv3. Он появился в ядре версии 2.3 и доступен как патч для ядра 2.2. Он создан на базе демона ядерного уровня NFS v2.

Патч доступен на страничке Linux Kernel based NFS по адресу http://csua.berkeley.edu/gam3/knfsd.

█═╖═╓ | ┐╚╝║═╚Л╜╝╔ ╝ё╚═╒╚╔╜╗╔ | ┌╞╔Ю╔╓
▐╝╓╓╔Ю╕╙═ А╔Ю╒╔Ю╝╒ NFS v2 | ▀╝╙═╚Л╜╝╔ ╝ё╚═╒╚╔╜╗╔ | IPX ╗ Д═╘╚╝╒═О А╗АБ╔╛═ NCP


Linux Network Administrators Guide Russian

Глобальное оглавление
Введение
Цель и аудитория этой книги
Источники информации
Документы, доступные по FTP
Документы, доступные по WWW
Документы, доступные на коммерческой основе
Linux Journal n Linux Magazine
Linux Usenet Newsgroups
Списки рассылки по Linux
Поддержка Linux
Linux User Groups
Получение Linux
Стандарты файловой системы
Стандартная база Linux
Про эту книгу
Официальные печатные версии
Обзор
Соглашения, принятые в книге
Подписка на обновления
Благодарности
Зал славы
1. Введение в сети
Немного истории
Сети TCP/IP
Введение в сети TCP/IP
Ethernet
Другие типы оборудования
Internet Protocol
IP на последовательных линиях
Transmission Control Protocol
User Datagram Protocol
Еще о портах
Библиотека сокетов
Сети UUCP
Сети и Linux
Различные полосы разработки
Где взять код
Управление Вашей системой
Защита системы
2. Настройка сети TCP/IP
Сетевые интерфейсы
IP-адреса
Преобразование адресов
IP-маршрутизация
IP-сети
Подсети
Gateways
Таблица маршрутов (Routing Table)
Метрические значения
Internet Control Message Protocol
Преобразование имен машин
3. Настройка сетевого оборудования
Настройка ядра
Опции ядра в Linux 2.0 и выше
Сетевые опции в ядре Linux 2.2.0 и выше
Обзор сетевых устройств в Linux
Установка Ethernet
Автоопределение Ethernet
Драйвер PLIP
Драйверы PPP и SLIP
Другие типы сетей
4. Настройка последовательного оборудования
Программы для модемной связи
Обзор последовательных устройств
Доступ к последовательным устройствам
Файлы последовательных устройств
Последовательное оборудование
Использование программ настройки
Команда setserial
Команда stty
Последовательное оборудование и запрос login:
Настройка mgetty Daemon
5. Настройка сети TCP/IP
Монтирование файловой системы /proc
Установка исполняемых модулей
Установка Hostname
Установка IP-адресов
Создание подсетей
Написание файлов hosts и networks
Настройка интерфейса для IP
Кольцевой интерфейс (Loopback)
Интерфейсы Ethernet
Маршрутизация через шлюз (Gateway)
Настройка шлюза
Интерфейс PLIP
Интерфейсы SLIP и PPP
Тупой (Dummy) интерфейс
IP-псевдонимы (IP-Alias)
Все про ifconfig
Команда netstat
Отображение таблицы маршрутизации
Отображение статистики интерфейса
Отображение соединений
Проверка ARP-таблиц
6. Настройка сервера имен
Библиотека Resolver
Файл host.conf
Файл nsswitch.conf
Настройка сервера имен: файл resolv.conf
Ошибкоустойчивость Resolver
Как работает DNS
Поиск имени с помощью DNS
Типы серверов имен
База данных DNS
Обратный поиск
Запуск named
Файл named.boot
Файл host.conf в BIND 8
Файлы базы данных DNS
Настройка сервера только для кэширования
Написание главных (Master) файлов
Проверка настроек сервера имен
Другие полезные инструменты
7. Serial Line IP (IP на последовательнхы линиях)
Основные требования
Действия со SLIP
Работа с внутренними IP-сетями
Использование dip
Простой скрипт
Команды dip
Запуск в режиме сервера
8. Протокол Point-to-Point
PPP и Linux
Запуск pppd
Использование файлов Options
Использование скрипта для автоматического дозвона
Опции настройки IP (IPCP)
Choosing IP Addresses
Routing Through a PPP Link
Опции управления связью
Основы безопасности
Авторизация и PPP
PAP против CHAP
Файл для CHAP
Файл для PAP
Отладка Ваших настроек PPP
Тонкая настройка PPP
PPP-сервер
Дозвон по требованию
Постоянный дозвон
9. TCP/IP Firewall
Методы атаки
Что такое firewall?
Что такое IP Filtering?
Установка Firewall в Linux
Настройка ядра для IP Firewall
Утилита ipfwadm
Утилита ipchains
Утилита iptables
Три способа фильтрации
Original IP Firewall (ядра 2.0)
Использование ipfwadm
Более сложный пример
Обзор параметров ipfwadm
IP Firewall Chains (ядра 2.2)
Использование ipchains
Синтаксис команды ipchains
Вернемся к нашему примеру
Просмотр наших правил в ipchains
Правильное использование цепочек
Netfilter и таблицы IP (ядра 2.4)
Обратная совместимость с ipfwadm и ipchains
Использование iptables
Вернемся к нашим примерам
Управление битами TOS
Задание TOS-битов с помощью ipfwadm или ipchains
Установка TOS-битов с помощью iptables
Проверка конфигурации Firewall
Пример конфигурации Firewall
10. IP Accounting
Настройка ядра для IP Accounting
Настройка IP Accounting
Учет по адресам
Учет по портам сервисов
Учет по пакетам ICMP
Учет по протоколам
Использование результатов IP Accounting
Просмотр данных с помощью ipfwadm
Просмотр данных с помощью ipchains
Просмотр данных с помощью iptables
Перезапуск счетчиков
Удаление набора правил
Пассивные коллекции данных доступа
11. IP Masquerade и Network Address Translation
Краевые эффекты
Настройка ядра для IP Masquerade
Настройка IP Masquerade
Установка параметров синхронизации для IP Masquerade
Перехват обращений к серверу имен
Еще о сетевой трансляции адресов (Network Address Translation)
12. Важные сетевые возможности
Суперсервер inetd
Контроль доступа с помощью tcpd
Файлы services и protocols
Процедура удаленного вызова (Remote Procedure Call)
Настройка удаленного выполнения
Выключение r-команд
Установка и конфигурирование ssh
13. Сетевая информационная система (NIS)
Знакомство с NIS
NIS против NIS+
Клиентская сторона NIS
Запуск NIS-сервера
Безопасность NIS-сервера
Установка клиента NIS с GNU libc
Выбор правильных карт
Использование карт passwd и group
NIS и затенение паролей
14. Сетевая файловая система (NFS)
Запуск NFS
Монтирование тома NFS
NFS Daemons
Файл exports
Поддержка серверов NFS v2
Поддержка серверов NFS v3
15. IPX и файловая система NCP
Xerox, Novell и немного истории
IPX и Linux
Поддержка Caldera
О поддержке NDS
Настройка ядра для IPX и NCPFS
Настройка интерфейса IPX
Сетевые устройства с поддержкой IPX
Утилиты настройки интерфейса IPX
Команда ipx_configure
Команда ipx_interface
Настройка маршрутизатора IPX
Статическая IPX-маршрутизация. Использование ipx_route
Внутренние сети IPX и маршрутизация
Монтирование удаленных томов NetWare
Простой пример ncpmount
Подробно о команде ncpmount
Как скрыть пароль для логина NetWare
Более сложный пример ncpmount
Утилиты IPX
Список серверов
Рассылка сообщений пользователям NetWare
Просмотр и управление данными bindery
Выполнение заданий NetWare на печать
Использование nprint с Line Printer Daemon
Управление очередями печати
Эмуляция сервера NetWare
16. Управление Taylor UUCP
Обзор передачи UUCP и удаленного выполнения
Внутренние действия uucico
Опции командной строки uucico
Файлы настройки UUCP
Введение в Taylor UUCP
Что нужно знать UUCP
Имена сайтов
Файлы настройки Taylor
Общие опции настройки: файл config
Как сказать UUCP о других системах: файл sys
Описание устройств: файл port
Как набирать номер: файл dial
UUCP поверх TCP
Использование прямого соединения
Контроль доступа к возможностям UUCP
Выполнение команд
Передача файлов
Пересылка (Forwarding)
Настройка системы для приема входящих звонков (Dial In)
Предоставление UUCP-доступа
Защита от перехватчиков почты
Будьте бдительны: проверки последовательности обращения
Анонимный UUCP
Протоколы низкого уровня UUCP
Краткий обзор протоколов
Настройка протокола передачи
Выбор специфических протоколов
Поиск неисправностей
Сообщение uucico "Wrong Time to Call"
Uucico сообщает, что сайт уже заблокирован
Вы можете соединиться с удаленной системой, но происходит сбой скрипта регистрации
Модем не соединяется
Модем пробует соединятся, но не может
Я регистрируюсь, но происходит сбой авторизации
Log-файлы и отладка
17. E-Mail
Что такое почтовое сообщение?
Как доставляется почта?
Адреса Email
RFC-822
Форматы почтовых адресов
Два формата почтовых адресов
Как работает маршрутизация почты?
Маршрутизация почты в Internet
Маршрутизация почты в UUCP
UUCP и RFC-822
Настройка elm
Глобальные опции elm
Национальный набор символов
18. Sendmail
Введение в Sendmail
Установка sendmail
Обзор файлов настроек
Файлы sendmail.cf и sendmail.mc
Два примера файла sendmail.mc
Обычно используемые параметры sendmail.mc
Построение файла sendmail.cf
Интерпретация и написание правил переписки
sendmail.cf: команды R и S
Полезные макросы
Левая сторона
Правая сторона
Пример простого правила
Семантика наборов правил
Опции sendmail
Наиболее распространенные конфигурации
Заполнение поля From: пользователями
Управление почтовыми псевдонимами
Использование интеллектуальных хостов (Smart Host)
Противоспамовая оборона
Настройка виртуальных хостов
Тестирование настроек
Запуск sendmail
Советы и секреты
Управление почтовой очередью
Как заставить удаленный хост обрабатывать почтовую очередь
Анализ почтовой статистики
19. Получение и запуск Exim
Запуск Exim
Если почта не работает
Компиляция Exim
Режимы доставки почты
Опции настройки
Маршрутизация и доставка почты
Маршрутизация почты
Доставка писем на локальные адреса
Файлы псевдонимов
Списки рассылки
Противоспамовая оборона
Настройка UUCP
20. Netnews
История Usenet
Что такое Usenet?
Как в Usenet обрабатывают новости?
21. C-News
Доставка новостей
Установка
Файл sys
Файл active
Упаковка статей
Устаревшие новости
Прочие файлы
Сообщения Control
Сообщение cancel
newgroup и rmgroup
Сообщение checkgroups
sendsys, version и senduuname
C-News и NFS
Задачи управления и поддержки
22. NNTP и nntpd Daemon
Протокол NNTP
Соединение с сервером новостей
Выталкивание (Pushing) статьи на сервер
Изменение режима работы с NNTP
Получение списка групп
Перечень активных групп
Посылка статьи
Перечень новых статей
Выбор группы для дальнейшей работы
Перечень статей в группе
Получение только заголовка статьи
Получение только тела статьи
Чтение статьи из группы
Установка сервера NNTP
Ограничение доступа к NNTP
Авторизация NNTP
Взаимодействие nntpd и C-News
23. Internet News
Как работает INN
Программы чтения новостей и INN
Установка INN
Настройка INN
Файлы настройки INN
Глобальные параметры
Настройка групп новостей
Настройка подачи новостей
Контроль доступа программ работы с новостями
Старение статей
Обработка сообщений Control
Запуск INN
Управление INN: команда ctlinnd
Добавление группы новостей
Изменение группы
Удаление группы
Перенумерация группы
Доступ для Newsreaders
Блокировка входящих новостей
Разблокирование входящих новостей
Выключение сервера новостей
Перезапуск сервера новостей
Отображение статуса поступления новостей
Прекращение подачи новостей
Начало подачи новостей
Отмена статьи
24. Настройка программ работы с новостями
Настройка tin
Настройка trn
Настройка nn
A. Приложение A. Пример сети: The Virtual Brewery
Соединение с Virtual Subsidiary Network
B. Приложение B. Конфигурация кабелей
Кабель PLIP
Нуль-модемный кабель
C. Приложение C. Linux Network Administrator's Guide, Second Edition Copyright Information
0. Preamble
1. Applicability and Definitions
2. Verbatim Copying
3. Copying in Quantity
4. Modifications
5. Combining Documents
6. Collections of Documents
7. Aggregation with Independent Works
8. Translation
9. Termination
10. Future Revisions of this License
D. Приложение D. SAGE: The System Administrators Guild
Вперед
Введение


Electronic Mail

Назад Вперед

Глава 17. E-Mail

Локальное оглавление
Что такое почтовое сообщение?
Как доставляется почта?
Адреса Email
Как работает маршрутизация почты?
Настройка elm

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

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

Огромное количество программ транспортировки почты было написано для систем Un*x. Одна из наиболее известных, sendmail университета Berkeley. Первоначальный автор, Eric Allman, теперь снова активно работает над sendmail. Подробно о Linux-версии пакета sendmail мы поговорим в главе 18.

Linux также использует сервер Exim (автор Philip Hazel, место создания University of Cambridge). О нем мы поговорим в главе 19.

Пакеты Exim и sendmail поддерживают набор файлов конфигурации, которые должны быть настроены для Вашей системы. Кроме информации, которая требуется, чтобы почта вообще работала (например, имя машины), имеется много параметров, которые могут быть настроены. Основной файл конфигурации sendmail сначала очень трудно понять. Выглядит, как будто Ваша кошка ходила по клавиатуре с нажатой клавишей SHIFT. Файлы конфигурации Exim более структурированы и проще в понимании, чем у sendmail. Но Exim не обеспечивает прямую поддержку для UUCP и обрабатывает только доменные адреса. Сегодня это не такое уж страшное ограничение. Однако, для малого сайта работа, требуемая для установки любого из них, приблизительно одна.

В этой главе я опишу, что такое email, и с какими проблемами Вы, как администратор будете иметь дело. Глава 18 и глава 19 описывают установку и настройку sendmail и Exim. Приводимой здесь информации хватит, чтобы создать небольшой почтовый сервер, но помните, что можно провести много часов за настройкой поистине фантастического количества параметров.

К концу текущей главы я кратко опишу настройку elm, клиента почты очень распространенного на многих Unix-подобных системах, включая Linux.

Для получения более подробной информации относительно электронной почты в Linux, пожалуйста, обратитесь к Electronic Mail HOWTO (автор Vince Skahan), который регулярно отсылается в comp.os.linux.answers . Дистрибутивы elm, Exim и sendmail также поставляются с хорошей документацией. Можно также почитать RFC-документы для знакомства с теорией вопроса.

Что такое почтовое сообщение?

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

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

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

Большая часть программного обеспечения для транспортировки почты в мире Unix использует формат заголовка, определенный в RFC-822. Его первоначальная цель: определить стандарт для использования в ARPANET. Позже он был адаптирован к разным сетям, включая UUCP-сети.

RFC-822 задает только самые общие данные. Более современные стандарты были задуманы, чтобы справиться с возрастанием потребностей как, например, шифрование данных, поддержка наборов национальных символов и мультимедиа расширений почты (MIME), которые подробно описаны в RFC-1341 и других RFC.

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

Типичный заголовок выглядит примерно так:
Return-Path: <ph10@cus.cam.ac.uk>
Received: ursa.cus.cam.ac.uk (cusexim@ursa.cus.cam.ac.uk [131.111.8.6])
    by al.animats.net (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA04654
    for <terry@animats.net>; Sun, 30 Jan 2000 22:30:01 +1100
Received: from ph10 (helo=localhost) by ursa.cus.cam.ac.uk with local-smtp
    (Exim 3.13 #1) id 12EsYC-0001eF-00; Sun, 30 Jan 2000 11:29:52 +0000
Date: Sun, 30 Jan 2000 11:29:52 +0000 (GMT)
From: Philip Hazel <ph10@cus.cam.ac.uk>
Reply-To: Philip Hazel <ph10@cus.cam.ac.uk>
To: Terry Dawson <terry@animats.net>, Andy Oram <andyo@oreilly.com>
Subject: Electronic mail chapter
In-Reply-To: <38921283.A58948F2@animats.net>
Message-ID: <Pine.SOL.3.96.1000130111515.5800A-200000@ursa.cus.cam.ac.uk>

Обычно, все необходимые поля заголовка генерируются Вашим mailer`ом (программой для работы с электронной почтой), например elm , pine, mush или mailx. Некоторые поля необязательны и могут быть добавлены пользователем. Например, elm позволяет редактировать часть заголовка сообщения. Ниже приведен список наиболее часто используемых полей с пояснением их значения:

From:

Содержит email-адрес отправителя и, возможно, его "реальное имя".

To:

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

Cc:

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

Bcc:

Кому послать невидимые копии. Может быть несколько адресов, они разделяются запятыми. Разница между "Cc:" и "Bcc:" в том, что "Bcc:"-получатели не увидят имен и адресов других получателей, а "Cc:"-получатели их увидят.

Subject:

Тема сообщения в нескольких словах.

Date:

Дата посылки почты.

Reply-To:

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

Organization:

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

Message-ID:

Строка, сгенерированная транспортировщиком почты. Она уникальна для этого сообщения.

Received:

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

X-anything:

Почтовые программы не должны жаловаться на заголовки, которые начинаются с X-. Они используются, чтобы воплотить дополнительные возможности, которые еще не реализованы в RFC. Например, один из крупных серверов списков рассылки по Linux указывает имя списка в поле X-Mn-Key:.

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

Назад | Глобальное оглавление | Вперед
Файлы протоколов и отладка |  | Как доставляется почта?


How Is Mail Delivered?

Назад Глава 17. E-Mail Вперед

Как доставляется почта?

Вообще, Вы создаете почту, используя интерфейс, подобный mail или mailx, или более сложный, например, mutt, tkrat или pine. Эти программы называются пользовательскими средствами почты (mail user agents, MUA). Если Вы посылаете сообщение почты, программа интерфейса будет в большинстве случаев вручать его другой программе, которая называется средством транспорта почты (mail transport agent, MTA). На некоторых системах имеются различные средства транспорта почты для локальной и удаленной почты, на других имеется только одно. Обычно это команда /usr/sbin/sendmail, а на не-FSSTND системах /usr/lib/sendmail. В UUCP-системах команда для удаленной почты обычно rmail, для локальной lmail (если она существует).

Локальное получение почты, конечно, больше чем присоединение входящего сообщения к mailbox получателя. Обычно локальный MTA поймет совмещение имен (установка локальных адресов получателя, указывающих на другие адреса), и пересылку (переназначение почты пользователя другому адресату). Также сообщения, которые не могут быть переданы, должны обычно быть bounced, то есть возвращены отправителю с сообщением об ошибке.

Для удаленного получения используемое программное обеспечение зависит от характера связи. Если почта должна быть передана по сети, используя TCP/IP, обычно используется SMTP. SMTP (Simple Mail Transfer Protocol) определен в RFC 821. SMTP обычно соединяется с машиной получателя непосредственно.

В UUCP-сетях почта обычно не будет передана непосредственно, а будет послана на машину адресата рядом промежуточных систем. Чтобы послать сообщение по UUCP, MTA будет обычно выполнять rmail на системе пересылки, используя uux с подачей письма на стандартный ввод программы.

Так как команда uux выполняется для каждого сообщения отдельно, этот подход может вызвать значительную загрузку главного узлового хаба почты, также как сотни малых файлов, занимающих непропорциональное количество дискового пространства. Некоторые MTA позволяют Вам собирать отдельные сообщения для удаленной системы в одном файле. Командный файл содержит команды SMTP, которые локальная машина выдала бы, если бы использовалось прямое SMTP-соединение. Это называется BSMTP или пакетирование (batched) SMTP. Пакет передается программе rsmtp или bsmtp на удаленной системе, которая будет работать, как будто бы произошло нормальное SMTP-соединение.

Назад | Глобальное оглавление | Вперед
E-Mail | Локальное оглавление | E-mail адреса


How Does Mail Routing Work?

Назад Глава 17. Electronic Mail Вперед

Как работает маршрутизация почты?

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

Имеется большое различие между способом маршрутизации дескрипторов пункта UUCP и способом маршрутизации в Internet. В Internet, основная работа направления данных на машину получателя (если только известен адрес IP) выполнен IP уровнем работы с сетями, в то время как в зоне UUCP, маршрут должен быть задан пользователем или сгенерирован средством передачи почты.

Маршрутизация почты в Internet

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

Большинство машин будет обычно направлять всю почту доступному серверу почты, который способен обработать все это движение. Чтобы объявить это обслуживание, сервер создает так называемую запись MX для их локальной области в базе данных DNS. MX замещает обменник почты ( Mail Exchanger) и заявляет, что серверная машина желает действовать как механизм продвижения данных почты для всех машин в этой области. MX-записи могут также использоваться, чтобы обработать трафик для машин, которые не соединены с Internet напрямую, подобно UUCP сетям или сетям компаний с машинами, хранящими конфиденциальную информацию.

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

Предположим, что организация Foobar Inc хочет всю свою почту обрабатывать своей машиной mailhub. Они будут иметь примерно такую MX-запись в базе данных DNS:
green.foobar.com.        IN   MX      5    mailhub.foobar.com.

Это объявляет mailhub.foobar.com как обработчик почты для домена green.foobar.com со значением приоритета 5. Машина, которая хочет передать сообщение joe@green.foobar.com, проверит DNS и найдет MX-запись, указывающую на mailhub. Если нет никакого MX с приоритетом меньше, чем 5, сообщение будет передано на mailhub.

Дальнейшую информацию по маршрутизации почты (например, для случаев, когда не работают MX-записи) рекомендую посмотреть в RFC-974.

Маршрутизация почты в UUCP

Маршрутизация почты в UUCP-сетях намного более сложна, чем в Internet, потому что транспортное программное обеспечение не выполняет никакой маршрутизации. В более ранние времена вся почта должна была быть адресована, используя пути bang. Они определяли список машин для передачи сообщения, отделяемые метками восклицания, и с последующим именем пользователя. Чтобы адресовать письмо пользователю Janet на машине moria, Вы использовали бы путь eek!swim!moria!janet. Это послало бы почту с Вашей системы на eek, оттуда на swim и в заключение на moria.

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

Первым шагом в идентификации имен машин было основание The UUCP Mapping Project. Он размещен в Rutgers University и регистрирует все официальные UUCP-имена, наряду с информацией относительно их соседей UUCP и их географическего расположения, создавая уверенность, что никакой hostname не используется дважды. Информация, собранная Mapping Project, издана как Usenet Maps, которые распространяются регулярно через Usenet. Типичная запись в карте (при удалении комментариев) походит на это:
moria
        bert(DAILY/2),
        swim(WEEKLY)

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

Используя информацию связности, обеспеченной картами, Вы можете автоматически генерировать полные пути от Вашей машины до любого пункта адресата. Эта информация обычно сохраняется в файле paths, также называемом базой данных pathalias. Если карты устанавливают, что Вы можете достигать bert через ernie, то запись pathalias для moria, сгенерированная из отрывка карты выше, выглядит следующим образом:
moria           ernie!bert!moria!%s

Если Вы теперь дадите адрес janet@moria.uucp Вашему MTA, он выберет маршрут, показанный выше, и пошлет сообщение на ernie с адресом bert!moria!janet.

Формирование файла paths из полных карт Usenet не очень хорошая идея. Информация в них обычно искажается и иногда устаревает. Следовательно, только ряд систем использует полные всемирные карты-UUCP, чтобы формировать свой файл paths. Многие сайты хранят только данные о своем окружении и посылают данные системам с более полными картами сети для дальнейшей передачи. Такая схема называется smart-host routing.

UUCP и RFC-822

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

Это очень хорошо работает со схемой smart-host routing маршрутизации, описанной выше. Глобальная информация маршрутизации поддерживается шлюзом, а машины внутри области получают только маленький файл paths, который перечисляет маршруты внутри их области и маршрут к хабу почты. Даже шлюз почты не должен иметь информации маршрутизации для каждой 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, которые действуют как их smart-host routing. Посылка сообщений через 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-стиля из адреса, который определяет имя домена. Некоторые почтовые программы имеют для этого специальные файлы: sendmail, например, использует uucpxtable.

Обратное преобразование (domainizing)) иногда требуется при посылке почты из UUCP-сети в Internet. Как только отправитель почты использует имя домена в адресе назначения, этой проблемы можно избежать. не удаляя имя области из адреса конверта при пересылке сообщения на smart-host. Однако, все еще есть абоненты UUCP, которые не являются частью домена. Они обычно определяются добавлением псевдодомена uucp.

База данных pathalias обеспечивает направляющую информацию в uucp-сетях. Типичная запись походит на эту (имя сервера и путь отделяются метками табуляции):
moria.orcnet.org  ernie!bert!moria!%s
moria             ernie!bert!moria!%s

Это направляет любое сообщение к moria через ernie и bert . Полное доменное имя moria и его имя в UUCP должны быть заданы, если почтовая программа не имеет отдельного способа связи имен.

Если Вы хотите направлять все сообщения на машины внутри некоторой области на сервер почты, Вы можете также определять путь в базе данных pathalias, давая имя области как целевой с предшествующей точкой. Например, если все машины в sub.org могут быть достигнуты через swim!smurf, запись pathalias могла бы выглядеть следующим образом:
.sub.org        swim!smurf!%s

Запись в файл pathalias является допустимой только, когда Вы имеете сервер, который не должен делать много маршрутизации. Если Вы должны делать маршрутизацию для большого количества машин, лучший способ использовать команду pathalias, чтобы создать файл из файлов карты. Карты могут поддерживаться намного проще, потому что Вы можете просто добавлять или удалять систему, редактируя запись карты системы, и вновь создавать файл карты. Хотя карты, изданные Usenet Mapping Project, не очень хороши для маршрутизации, UUCP-сети могут обеспечивать информацию маршрутизации в их собственном наборе карт.

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

Например, рассмотрим moria, который опрашивает swim.twobirds.com два раза в день, и bert.sesame.com только раз в неделю. Кроме того, связь с bert использует медленный модем на 2400bps. Машина moria издаст следующую запись карты:
moria.orcnet.org
        bert.sesame.com(DAILY/2),
        swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria

Последняя строка делает moria известной под именем UUCP. Обратите внимание, что для этой связи должно быть DAILY/2, при вызове два раза в день.

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

Команда pathalias обеспечивает пару других возможностей, подобно скрывающемуся пункту (то есть абонент, доступный только через шлюз) и т.д. См. man-страницу 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 наиболее забавно: оно задает Вашу географическую позицию в latitude/longitude и используется, чтобы рисовать карты postscript, которые показывают всех абонентов для каждой страны.

Назад | Глобальное оглавление | Вперед
Email Addresses | Локальное оглавление | Configuring elm


Maintenance Tools and Tasks

Назад Глава 21. C-News Вперед

Средства и задачи администрирования

Несмотря на сложность C-News, жизнь администратора новостей может быть довольно проста, потому что C-News обеспечивает Вас богатым набором инструментальных средств сопровождения. Некоторые из них предназначены для регулярного запуска из cron, подобно newsdaily. Использование этих скриптов значительно уменьшает ежедневную работу.

Если не установлено иное, эти команды расположены в /usr/lib/news/maint. Обратите внимание, что Вы должны стать пользователем news перед вызовом этих команд. При выполнении их от имени супер-пользователя файлы могут стать недоступными C-News.

newsdaily

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

newswatch

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

addgroup

Добавляет группу к Вашему серверу локально. Соответствующий вызов:
addgroup groupname y|n|m|=realgroup

Второй аргумент имеет то же самое значение, что и флаг в файле active: любой может посылать статью в группу (y), никто не может посылать статью (n), группа модерируемая (m), или что она является псевдонимом (alias) для другой группы (= realgroup). Вы можете также использовать addgroup, когда первые статьи в недавно созданной группе прибывают раньше, чем сообщение управления newgroup, которое предназначено, чтобы создать ее.

delgroup

Позволяет Вам удалять группу локально. Вызовите ее как:
delgroup groupname

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

addmissing

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

newsboot

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

newsrunning

Постоянно находится в /usr/lib/news/input и может использоваться, чтобы отключить распакетирование входящих новостей, например, в течение рабочего времени, дабы не перегружать систему. Вы можете выключить распакетирование вызовом:
/usr/lib/news/input/newsrunning off

Или включить, подставив on вместо off.

Назад | Глобальное оглавление | Вперед
C-News и NFS | Локальное оглавление | NNTP и nntpd Daemon


Configuring IP Masquerade

Назад Глава 11. IP Masquerade и Network Address Translation Вперед

Настройка IP Masquerade

Если Вы уже прочитали главы о firewall и accounting, у Вас уже не вызовет удивления, что для настройки правил IP masquerade используются знакомые команды ipfwadm, ipchains и iptables.

Правила masquerade представляют собой специальный класс правил фильтрации. Вы можете обеспечить masquerade только пакетов, которые получены на одном интерфейсе и будут направлены другому интерфейсу. Чтобы настроить masquerade надо создать правило, очень похожее на правило пересылки firewall, но со специальными параметрами, которые сообщают ядру, что надо использовать masquerade пакетов. Команда ipfwadm использует опцию -m, ipchains использует -j MASQ, а в iptables есть опция -j MASQUERADE, чтобы указать, что пакеты, соответствующие спецификации правила, должны быть masqueraded.

Давайте рассмотрим пример. Допустим, у студента университета Groucho Marx дома есть несколько машин, объединенных в маленькую сеточку Ethernet. Она использует один из зарезервированных частных сетевых адресов. Сеть доступна и другим студентам, которые имеют интерес в использовании Internet. Для доступа в Internet используется простое соединение dial-up PPP.

Студенты настраивают Linux-машину для поддержки связи dial-up и работы в качестве маршрутизатора сети. Ее IP-адрес при модемном соединении не важен. Linux-маршрутизатор конфигурируется с поддержкой IP masquerade и использует один из частных сетевых адресов для локальной сети: 192.168.1.0. При этом гарантируется, что каждый из компьютеров в этой сети имеет заданный по умолчанию маршрут, указывающий на Linux-маршрутизатор.

Чтобы запустить эту конфигурацию с помощью ipfwadm, надо только скомандовать:
# ipfwadm -F -p deny
# ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0/0
или с ipchains:
# ipchains -P forward -j deny
# ipchains -A forward -s 192.168.1.0/24 -d 0/0 -j MASQ
или с iptables:
# iptables -t nat -P POSTROUTING DROP
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Теперь всякий раз, когда любой из компьютеров сети пробует соединяться с сервисом на удаленном компьютере, их пакеты будет автоматически masqueraded Linux-маршрутизатором. Первое правило в каждом примере запрещает маршрутизацию любого другого пакета и добавляет некоторую защиту.

Чтобы посмотреть созданные правила masquerade, используйте параметр -l команды ipfwadm.

Чтобы отобразить только что созданные правила, введите:
# ipfwadm -F -l -e
вывод будет напоминать следующее:
# ipfwadm -F -l -e
IP firewall forward rules, default policy: accept
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress
    0     0 acc/m all  ---- 0xFF 0x00 any     any
Здесь /m указывает, что это правило masquerade.

Посмотреть правила командой ipchains можно с опцией -L. Аналогично предыдущему примеру с ipchains:
# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target   prot opt     source           destination   ports
MASQ     all  ------  192.168.1.0/24   anywhere      n/a

Chain output (policy ACCEPT):

Все правила с адресатом MASQ являются правилами masquerade.

Наконец, то же самое можно сделать командой iptables :
# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source       destination

Chain POSTROUTING (policy DROP)
target     prot opt source       destination
MASQUERADE  all  --  anywhere     anywhere     MASQUERADE

Chain OUTPUT (policy ACCEPT)
target     prot opt source       destination
Правила masquerade появляются с адресатом MASQUERADE .

Установка параметров синхронизации для IP Masquerade

Когда новое подключение установлено, программное обеспечение IP masquerade создает ассоциацию в памяти между компьютерами, связанными с подключением. Вы можете рассматривать эти ассоциации в любое время в файле /proc/net/ip_masquerade Эти ассоциации имеют время ожидания бездеятельности. После окончания этого времени связь удаляется.

Вы можете устанавливать время ожидания, используя ipfwadm. Синтаксис в общем виде такой:
ipfwadm -M -s <tcp> <tcpfin> <udp>

Для ipchains:
ipchains -M -S <tcp> <tcpfin> <udp>

Реализация iptables использует намного более длинные значения по умолчанию для таймеров и не позволяет Вам устанавливать их. Каждое из этих значений представляет таймер, используемый программным обеспечением IP masquerade. Следующая таблица описывает таймеры и их назначение:

Имя | Описание
tcp | Время ожидания сеанса TCP. Задает как долго TCP-подключение может оставаться неактивным до того, как ассоциация для него удалится.
tcpfin | Время ожидания TCP после FIN. Как долго ассоциация останется после того, как TCP-подключение было разъединено.
udp | Время ожидания сеанса UDP. Как долго UDP-подключение может оставаться неактивным перед тем, как ассоциация для него удалится.
Назад | Глобальное оглавление | Вперед
Configuring the Kernel for IP Masquerade | Локальное оглавление | Handling Name Server Lookups


Miscellaneous Files

Назад Глава 21. C-News Вперед

Прочие файлы

Имеется ряд файлов, которые управляют поведением C-News, но не существенны для функционирования. Все они постоянно находятся в /etc/news. Я опишу их кратко.

newsgroups

Это файл, дополняющий active, который содержит список имен newsgroup, наряду с кратким описанием темы. Этот файл автоматически модифицируется, когда C-News получает сообщение управления checknews.

localgroups

Если Вы имеете ряд локальных групп таких, что Вы не хотите, чтобы C-News сообщал о них каждый раз, когда Вы получаете сообщение checkgroups, поместите их имена и описания в этом файле точно так же, как они появились бы в newsgroups .

mailpaths

Этот файл содержит адрес модератора для каждой модерируемой группы. Каждая строка содержит имя группы, сопровождаемое адресом email модератора (через табуляцию).

Две специальных записи используются как значения по умолчанию. Это backbone и internet . Обе в форме bang-path являются путем к самому близкому базовому серверу и серверу, который понимает адреса RFC 822 ( user@host). По умолчанию это:
internet          backbone

Вы не должны изменять запись internet, если Вы имеете exim или sendmail потому, что они понимают адресацию RFC 822.

Запись backbone используется всякий раз, когда пользователь отправляет по почте статью в модерируемую группу, чей модератор не перечислен явно. Если имя newsgroup alt.sewer, и запись backbone содержит path!%s, C-News отправит по почте статью на path!alt-sewer, надеясь, что базовая машина способна передать статью кому надо. Чтобы выяснить, какой путь использовать, спросите администратора новостей сервера, который передает Вам. Вы можете также использовать uunet.uu.net!%s.

distributions

Этот файл не является файлом C-News, но он используется некоторыми newsreaders и nntpd. Он содержит список областей распространения, распознаваемых Вашим сервером, и описание встроенных возможностей. Например, Virtual Brewery имеет следующий файл:
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.

Назад | Глобальное оглавление | Вперед
Устаревшие новости | Локальное оглавление | Сообщения Control


Troubleshooting

Назад Глава 16. Управление Taylor UUCP Вперед

Поиск неисправностей

Этот раздел описывает возможные неисправности в Вашем соединении UUCP и дает возможные пути их исправления. Однако, я просто не в состоянии охватить все возможные варианты.

В любом случае включите отладку опцией -xall и смотрите на вывод в файле Debug в каталоге spool. Это поможет быстро распознть, где происходит сбой. Также иногда полезно включить динамик модема, когда соединение не удается установить. С Hayes-совместимыми модемами это можно сделать, добавив ATL1M1 к скрипту модема в файле dial.

Первым делом стоит проверить, все ли права доступа к файлам установлены правильно. Исполняемый модуль uucico должен принадлежать uucp, а все файлы в /usr/lib/uucp, /var/spool/uucp и /var/spool/uucppublic должны принадлежать uucp. Имеются также некоторые скрытые файлы в каталоге spool, которые также должны принадлежать uucp.

Сообщение uucico "Wrong Time to Call"

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

Uucico сообщает, что сайт уже заблокирован

Это означает, что uucico обнаружил файл блокировки для удаленной системы в /var/spool/uucp. Файл блокировки может остаться от прошлого обращения к системе, если ее работа была прервана некорректно. Однако, также правдоподобно, что есть другой процесс uucico, который пробует вызвать удаленную систему, но по какой-то причине связь пока не установил. Если этот процесс не преуспел в соединение с удаленной системой, уничтожьте его и удалите все файлы блокировки, которые он оставил.

Вы можете соединиться с удаленной системой, но происходит сбой скрипта регистрации

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

Модем не соединяется

Если модем не указывает, что DTR-линия была установлена, когда uucico вызывает удаленный сайт, возможно, Вы задали неправильное устройство для uucico. Если модем распознает DTR, сверьтесь с программой терминала, которой Вы можете записывать данные в модем. Если она работает, включите отображение на экране командой \E в начале скрипта модема. Если это не отображает команды в скрипте модема, проверьте, правильно ли настроен модем. Если Вы видите копии команд, проверьте, отключили ли Вы ответы модема, или устанавливаете их к кодам числа. Проверьте правильность скрипта модема. Не забудьте, что Вы должны записать две наклонных черты влево, чтобы послать одну такую черту модему.

Модем пробует соединятся, но не может

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

Вы регистрируетесь, но происходит сбой авторизации

Может быть ряд проблем. Посмотрите, какими протоколами пользуется удаленная система (она посылает строку P protlist в течение авторизации). Обе стороны должны поддерживать по крайней мере один общий протокол, так что проверьте, что они делают.

Если удаленная система посылает RLCK, имеется просроченный lockfile (файл блокировки) для Вас на удаленной системе. Если Вы еще не соединены с удаленной системой на другой линии, попросите удалить его.

Если удаленная система посылает RBADSEQ, она проверила Ваш логин, но числа опознания не совпали. Если она посылает RLOGIN, Вам не разрешили входить в систему под этим идентификатором.

Назад | Глобальное оглавление | Вперед
Протоколы низкого уровня UUCP | Локальное оглавление | Log-файлы и отладка


Mounting an NFS Volume

Назад Глава 14. Network File System Вперед

Монтирование тома NFS

Монтирование томов NFS очень похоже на монтирование обычных файловых систем. Команда mount имеет следующий вид:
# mount -t nfs nfs_volume local_dir options

Параметр nfs_volume имеет вид remote_host:remote_dir. Он указаывает определенную файловую систему NFS, причем можно опустить параметр -t nfs.

Имеется ряд дополнительных опций, которые Вы можете определить в команде mount. Они могут быть заданы переключателем -o в командной строке или в области опций файла /etc/fstab. В обоих случаях составные опции отделяются друг от друга запятыми. Опции, определенные в командной строке, всегда отменяют те, что были заданы в файле fstab.

Типовая запись в /etc/fstab могла бы быть такой:
# volume              mount point       type  options
news:/var/spool/news  /var/spool/news   nfs   timeo=14,intr

Этот значение затем может быть использовано при монтировании:
# mount news:/var/spool/news

В отсутствии записи в fstab, NFS устанавливает большинство параметров mount по умолчанию. Например, предположим, что Вы монтируете home-каталоги Ваших пользователей с машины moonshot, которая использует заданный по умолчанию размер блока, равный 4k, для операции чтения-записи. Вы могли бы уменьшить размер блока до 2k, чтобы подойти под размер Linux-пакетов, введя следующую команду:
# mount moonshot:/home /home -o rsize=8192,wsize=8192

Список всех допустимых опций есть на man-странице по nfs(5). Ниже приведен список наиболее популярных опций:

rsize=n и wsize=n

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

timeo=n

Устанавливает время (в десятых долях секунды), которое NFS-клиент будет ждать запрос, чтобы завершить работу. Значение по умолчанию 7 (0.7 секунды). Что произойдет после окончания времени ожидания зависит от того, используете Вы опцию hard или soft.

hard

Отмечает этот том как hard-смонтированный. Задано по умолчанию. Эта опция предписывает серверу выдать сообщение на консоль при окончании времени ожидания и продолжать попытки смонтировать том.

soft

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

intr

Разрешает прервать обращение к NFS. Удобно в случае недоступности сервера.

Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер стал временно недостижим. Они работают вместе следующим способом: всякий раз, когда клиент посылает запрос к NFS-серверу, он ожидает, что операция закончится после заданного интервала времени (точно установленного в опции блокировки по времени, timeout). Если никакого подтверждения не получено в этот промежуток времени, то появится так называемая незначительная остановка по времени (minor timeout), и операция повторится, но уже с интервалом блокировки по времени вдвое большим. После достижения максимальной блокировки по времени (60 секунд), происходит глобальная блокировка по времени (major timeout). Вот тут-то и срабатывают опции hard или soft .

По умолчанию, глобальная блокировка по времени заставит клиента напечатать сообщение на консоль и начать все снова. В принципе это может продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор, пока сервер не становится доступным, называются hard-mounted. В противоположность им значения soft-mounted генерируют ошибку ввода-вывода для процесса всякий раз, когда происходит глобальная блокировка по времени. Из-за того, что write-behind вводится буферным кэшем, это условие ошибки не распространяется непосредственно на процесс прежде, чем он вызовет функцию write в следующий раз. Дело в том, что иначе программа никогда не сможет убедиться в том, что операция записи в ресурс, помеченный как soft-mounted, имела место вообще.

Поставили ли Вы hard или soft-mount значение, это не только вопрос вкуса, но также и то, что Вы должны сделать с той информацией, которую хотите получить от этого значения. Например, если Вы монтируете Ваши Х-программы NFS, Вы конечно не хотели бы, чтобы ваш X-сеанс рухнул только потому, что кто-то свалил сеть, запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet-разъем. Используя hard-mounting, Вы удостоверитесь в том, что компьютер будет ждать, пока не появится возможность заново восстановить контакт с nfs-сервером. С другой стороны, некритические данные типа новостей или FTP-архив могут быть soft-mounted, так что это не повесит сеанс в случае, если удаленная машина должна стать временно недосягаемой или просто выключенной. Если сетевая связь с сервером медленная или проходит через программу маршрутизации, то Вы можете также увеличить начальную блокировку по времени, используя опцию timeo или значение hard-mount, но разрешите прерывание вызова NFS, так чтобы Вы могли прервать любое действие с файлами.

Hard-mount представляют проблему, потому что, по умолчанию, операции с файлами не прерываются. Таким образом, если процесс пытается, например, записать файл на удаленной машине, а она недоступна, программа пользователя висит, а пользователь бегает вокруг нее, не в состоянии прервать процесс записи. Если Вы используете опцию intr при hard mount, сигналы процессу прервут NFS-вызов, так что пользователь все же сможет продолжать работу.

Обычно daemon rpc.mountd будет следить, какие каталоги какими хостами были смонтированы. Эта информация может быть отображена при использовании программы showmount, которая также включена в пакет сервера NFS:
# showmount -e moonshot
Export list for localhost:
/home <anon clnt>
# showmount -d moonshot
Directories on localhost:
/home
# showmount -a moonshot
All mount points on localhost:
localhost:/home

Назад | Глобальное оглавление | Вперед
Сетевая файловая система (NFS) | Локальное оглавление | NFS Daemons


Энциклопедия сетевого администратора Linux
версия 2.0
(LNAGR, Linux Network Administrators Guide Russian)

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

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


Running named

Назад Глава 6. Name Service and Resolver Configuration Вперед

Запуск named

Пакет named обеспечивает DNS на большинстве Unix-машин. Это серверная программа, первоначально разработанная для BSD, чтобы обеспечить сервис имен для клиентов и, возможно, для других серверов имен. BIND Version 4 довольно долго поставлялся почти во всех дистрибутивах Linux. Сейчас вместо него поставляется новая версия 8, которая имеет много отличий от предыдущей. Особо надо отметить введение поддержки динамических модификаций DNS, сообщений изменения DNS, улучшение эффективности и новый синтаксис файла конфигурации.

Этот раздел требует понимания принципов работы DNS. Если такого понимания нет, обратитесь к разделу "Как работает DNS".

Пакет named обычно запускается при начальной загрузке системы. Реализации BIND до Version 8 берут информацию из файла конфигурации /etc/named.boot и различных файлов, которые отображают имена домена к адресам. Последние называются зональными файлами (zone files). Версии BIND после Version 8 используют /etc/named.conf вместо /etc/named.boot.

Для запуска named скомандуйте:
# /usr/sbin/named

Пакет named запустится и прочитает named.boot и заданные в нем зональные файлы. Он пишет свой process ID в файл /var/run/named.pid в ASCII, загружает все зональные файлы с первичного сервера и начинает слушать порт 53 в ожидании запросов DNS.

Файл named.boot

Файл конфигурации BIND до Version 8 был очень прост. BIND Version 8 имеет совсем другую структуру файла настройки, чтобы использовать новые свойства. Имя файла настройки сменилось с /etc/named.boot на /etc/named.conf. Мы сосредоточимся на конфигурировании старой версии, потому что многие дистрибутивы ее еще используют, но рассмотрим и отличия. К тому же мы рассмотрим, как преобразовать старый файл named.conf в новый.

Файл named.boot вообще маленький и содержит мало данных, но указывает на главные файлы, содержащие зональную информацию и хранит указатели на другие серверы имен. Комментарии в файле начинаются с символов # или ; и заканчиваются в конце строки. Прежде чем мы обсудим формат named.boot более подробно, рассмотрим типовой файл для vlager в примере 6-8.

Пример 6-8. Файл named.boot для vlager

;
; /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       16.172.in-addr.arpa      named.rev

Рассмотрим каждую инструкцию индивидуально. Ключевое слово directory сообщает named , что все имена файлов, упоминаемых позже в этом файле, например, зональные файлы, размещены в каталоге /var/named.

Ключевое слово primary загружает информацию в named. Эта информация принимается из главных (master) файлов, определенных как последние параметры. Эти файлы представляют DNS-записи ресурсов, которые мы рассмотрим позже.

В этом примере мы конфигурируем named как первичный (primary) сервер имен для трех доменов, как обозначено тремя инструкциями primary. Первая из них предписывает named действовать как первичный сервер для vbrew.com, принимая зональные данные из файла named.hosts.

Ключевое слово cache должно присутствовать фактически на всех машинах, управляющих сервером имен. Оно инструктирует named использовать кэш и загружать имена (root name server hints) из определенного файла кэша (в нашем примере named.ca). Это будет рассмотрено чуть позже.

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

directory

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

primary

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

Всегда будет по крайней мере одна запись primary в каждом файле boot, используемая для обратного отображения сети 127.0.0.0, которая является кольцевым интерфейсом (loopback).

secondary

Инструкция берет имя домена, список адресов и имя файла как параметры. Это объявляет локальный сервер вторичным главным (secondary master) сервером для заданного домена.

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

Затем named пытается обновить зональные данные с регулярными интервалами. Этот процесс объясняется позже в связи с типом записи ресурса SOA.

cache

Эта опция берет имя домена и имя файла как параметры. Этот файл содержит root server hints, который является списком записей, указывающих на корневые серверы имен. Будут распознаны только записи NS и A. Параметр domain должен быть именем корневого домена.

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

forwarders

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

slave

Инструкция делает сервер имен подчиненным (slave ). Он никогда не выполняет рекурсивные запросы самостоятельно, а только пересылает их на серверы, определенные в инструкции forwarders.

Есть два параметра, которые мы не будем описывать здесь: sortlist и domain . Еще две директивы могут также использоваться внутри этих файлов базы данных: $INCLUDE и $ORIGIN. Так как они редко нужны, мы не будем рассматривать их сейчас.

Файл host.conf в BIND 8

BIND Version 8 имеет много новых свойств, а с ними пришел и новый синтаксис файла конфигурации. Старый named.boot с простыми одиночными инструкциями был заменен на named.conf с синтаксисом, аналогичным gated, похожий на C-синтаксис.

Новый синтаксис более сложен, но есть инструмент, который автоматизирует преобразование старого синтаксиса в новый. В пакете исходников BIND 8 есть perl-программа named-bootconf.pl , которая занимается этим преобразованием. Чтобы использовать этот инструмент, Вы должны иметь установленный интерпретатор perl.

Вы должны использовать скрипт так:
# cd /etc
# named-bootconf.pl <named.boot >named.conf
Скрипт изготовит named.conf, похожий на приведенный в примере 6-9.

Пример 6-9. Файл для BIND 8, эквивалентный файлу named.conf для vlager

//
// /etc/named.boot file for vlager.vbrew.com
options {
        directory "/var/named";
};

zone "." {
        type hint;
        file "named.ca";
};

zone "vbrew.com" {
        type master;
        file "named.hosts";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
};

zone "16.172.in-addr.arpa" {
        type master;
        file "named.rev";
};

Если Вы внимательно его рассмотрите, то обратите внимание на то, что каждая из инструкций named.boot превратилась в C-инструкцию, взятую в фигурные скобки "{ }".

Комментарии, которые в файле named.boot начинались с точки с запятой (;), теперь обозначены как //.

Инструкция directory превратилась в параграф options с предложением directory.

Команды cache и primary преобразованы в зональные параграфы (zone) с типами ( type) предложений hint и master, соответственно.

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

Файлы базы данных DNS

Главные (Master) файлы, поставляемые с named, подобно named.hosts, всегда имеют домен, связанный с ними, называемый origin. Это имя домена, указанное с параметрами cache и primary. Внутри главного файла Вы можете определить домен и связанные с ним имена файлов. Имя, заданное в файле конфигурации, рассматривается абсолютно (absolute), если оно заканчивается одной точкой, иначе оно рассматривается относительно origin. Можно и прямо сослаться на origin знаком (@).

Данные, содержащиеся в главном файле, разделены на записи ресурсов (resource records, RRs). RRs самые маленькие модули информации, доступные через DNS. Каждая запись ресурса имеет тип. Например, A-записи отображают имя хоста на IP-адрес, а CNAME-записи связывают псевдоним для хоста с его официальным именем. Пример 6-11 показывает главный файл named.hosts для Virtual Brewery.

Записи ресурсов в главных файлах совместно используют общий формат:
[domain] [ttl] [class] type rdata

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

domain

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

ttl

Чтобы сервер имен обновлял информацию, RR ограничен по времени работы (ttl). Это поле определяет время в секундах, которое информация имеет силу после того, как была получена с сервера. Это десятичное число из восьми цифр.

Если значение ttl не дано, ему присваивается значение поля minimum предыдущей SOA-записи.

class

Класс адреса, например, IN для адресов IP или HS для объектов в Hesiod-классе. Для TCP/IP Вы должны определить IN.

Если никакое поле класса не задано, берется класс предшествующей RR.

type

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

rdata

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

Дальше приведен частичный список RR, которые нужно использовать в файлах DNS.

SOA

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

origin

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

contact

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

serial

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

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

refresh

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

retry

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

expire

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

minimum

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

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

A

Ассоциирует IP-адрес с именем. Содержит адрес в dotted quad notation. Для каждого хоста должна быть только одна запись. Hostname, используемый в этой А-записи, считается служебным или каноническим hostname. Все другие hostname расцениваются как псевдонимы и должны быть отображены на канонический (canonical) hostname, используя запись CNAME. Если каноническое имя нашего хоста vlager, его и надо вписать в A-запись с его IP-адресом. Если мы связываем с этим адресом другое имя, например news, надо использовать запись CNAME, которая свяжет его с альтернативным именем.

NS

Указывает на главный (primary) сервер подчиненной зоны. Содержит hostname сервера.

Вы встретите записи NS в двух ситуациях:

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

Запись NS определяет имена первичного и вторичного серверов для зоны. Эти имена должны быть разрешимы к используемому адресу. Иногда серверы не принадлежат к обслуживаемому домену, что порождает проблему: нельзя обратиться к серверу, пока не получен его адрес, но получить адрес нельзя, пока не обратимся к серверу (неоткуда). Можно конфигурировать специальные записи непосредственно на сервере имен родительской зоны. Они позволяют серверу из родительской области преобразовывать IP-адрес делегированного зонального сервера. Эти записи обычно названы приклеенными записями (glue records), поскольку они "склеивают" делегированную зону с родительской.

CNAME

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

PTR

Этот тип записи используется, для того, чтобы соединить имена домена in-addr.arpa с именами хостов (hostnames). Это используется для обратного отображения IP-адресов к hostnames. Данное имя должно быть каноническим.

MX

Эта RR объявляет преобразователь почты (mail exchanger) для домена. Для чего надо иметь преобразователи почты, рассказано в главе 17 . Синтаксис MX-записи следующий:
[domain] [ttl] [class] MX preference host

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

HINFO

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

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

Запись HINFO для Intel Linux-машин может выглядеть примерно так:
tao     36500  IN  HINFO  IBM-PC  LINUX2.2
А для Linux-машины на процессоре Motorola 68000 так:
cevad 36500 IN  HINFO  ATARI-104ST LINUX2.0
jedd  36500 IN  HINFO  AMIGA-3000  LINUX2.0

Настройка сервера только для кэширования

Это особая конфигурация named. Такой сервер в действительности не обслуживает домен, а просто осуществляет переброску всех запросов DNS, произведенных на Ваш компьютер. Преимущество этой схемы в том, что она создает кэш. Так что только первый запрос для специфического компьютера фактически будет послан серверу имен в Internet. Любой повторный запрос будет обработан из кэша. Такая схема названа caching-only. Это удобно при работе с Internet по модему, как описано в главе 7 и главе 8.

Файл named.boot для caching-only сервера имен выглядит примерно так:
; named.boot file for caching-only server
directory                            /var/named
primary       0.0.127.in-addr.arpa   named.local ; localhost network
cache         .                      named.ca    ; root servers

В дополнение к этому файлу named.boot, Вы должны установить файл named.ca со списком корневых серверов имен. Вы можете копировать и использовать для этой цели пример 6-10. Другие файлы не требуются.

Написание главных (Master) файлов

Примеры 6-10, 6-11, 6-12 и 6-13 дают типовые файлы для сервера имен сети brewery, размещенного на машине vlager. Это довольно простая конфигурация для одиночной локальной сети.

Файл кэша named.ca в примере 6-10 показывает типовые записи корневого сервера имен. Типичный файл кэша обычно описывает около десятка серверов. Вы можете получать текущий список серверов для корневого домена с помощью команды nslookup. Она описана чуть ниже.

Пример 6-10. Файл named.ca

; /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.
;
;.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
;A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;.                        3600000      NS    B.ROOT-SERVERS.NET.
;B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;.                        3600000      NS    C.ROOT-SERVERS.NET.
;C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;.                        3600000      NS    D.ROOT-SERVERS.NET.
;D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;.                        3600000      NS    E.ROOT-SERVERS.NET.
;E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;.                        3600000      NS    F.ROOT-SERVERS.NET.
;F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;.                        3600000      NS    G.ROOT-SERVERS.NET.
;G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;.                        3600000      NS    H.ROOT-SERVERS.NET.
;H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;.                        3600000      NS    I.ROOT-SERVERS.NET.
;I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;.                        3600000      NS    J.ROOT-SERVERS.NET.
;J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;.                        3600000      NS    K.ROOT-SERVERS.NET.
;K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
;.                        3600000      NS    L.ROOT-SERVERS.NET.
;L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;.                        3600000      NS    M.ROOT-SERVERS.NET.
;M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33

Пример 6-11. Файл named.hosts

; /var/named/named.hosts       Local hosts at the brewery
;                               Origin is vbrew.com
;
@                IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
                           2000012601 ; serial
                           86400      ; refresh: once per day
                           3600       ; retry:   one hour
                           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
;
; Virtual Brewery Ethernet
vlager           IN  A     172.16.1.1
vlager-if1       IN  CNAME vlager
; vlager is also news server
news             IN  CNAME vlager
vstout           IN  A     172.16.1.2
vale             IN  A     172.16.1.3
;
; Virtual Winery Ethernet
vlager-if2       IN  A     172.16.2.1
vbardolino       IN  A     172.16.2.2
vchianti         IN  A     172.16.2.3
vbeaujolais      IN  A     172.16.2.4
;
; Virtual Spirits (subsidiary) Ethernet
vbourbon         IN  A     172.16.3.1
vbourbon-if1     IN  CNAME vbourbon

Пример 6-12. Файл named.local

; /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
                        360000     ; minimum: 100 hrs
                        )
              IN  NS    vlager.vbrew.com.
1             IN  PTR   localhost.

Пример 6-13. Файл named.rev

; /var/named/named.rev         Reverse mapping of our IP addresses
;                               Origin is 16.172.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-if2.vbrew.com.
2.2           IN  PTR   vbardolino.vbrew.com.
3.2           IN  PTR   vchianti.vbrew.com.
4.2           IN  PTR   vbeaujolais.vbrew.com.

Проверка настроек сервера имен

Программа nslookup отличный инструмент для проверки работы сервера имен. Она может использоваться в интерактивном режиме с приглашением или как одиночная команда с непосредственным выводом. В последнем случае Вы просто вызываете ее как:
$ nslookup hostname

Программа nslookup делает запрос сервера имен, определенного в файле resolv.conf для hostname. Если этих серверов много, nslookup выбирает один случайным образом.

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

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

Вы можете искать типы записи:

> set type=type

Здесь type является одним из описанных имен записи ресурса или ANY.

Пример сеанса работы с nslookup:
$ nslookup
Default Server:  tao.linux.org.au
Address:  203.41.101.121

> metalab.unc.edu
Server:  tao.linux.org.au
Address:  203.41.101.121

Name:    metalab.unc.edu
Address:  152.2.254.81

>

Сначала отображаются данные о сервере DNS, затем результат запроса.

Если Вы пробуете сделать запрос для имени, которое не имеет никакого адреса IP, связанного с ним, но другие записи для него были найдены в базе данных DNS, nslookup выдаст сообщение об ошибке No type A records found. Вы можете заставить программу сделать запрос для записей, отличных от A, командой set type. Для получения SOA-записей из unc.edu введите:
> unc.edu
Server:  tao.linux.org.au
Address:  203.41.101.121

*** No address (A) records available for unc.edu
> set type=SOA
> unc.edu
Server:  tao.linux.org.au
Address:  203.41.101.121

unc.edu
        origin = ns.unc.edu
        mail addr = host-reg.ns.unc.edu
        serial = 1998111011
        refresh = 14400 (4H)
        retry   = 3600 (1H)
        expire  = 1209600 (2W)
        minimum ttl = 86400 (1D)
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
unc.edu name server = ns.unc.edu
ns2.unc.edu     internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1
ns.unc.edu      internet address = 152.2.21.1

Аналогично Вы можете сделать запрос для записей MX:
> set type=MX
> unc.edu
Server:  tao.linux.org.au
Address:  203.41.101.121

unc.edu preference = 0, mail exchanger = conga.oit.unc.edu
unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu
unc.edu name server = ns.unc.edu
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
conga.oit.unc.edu       internet address = 152.2.22.21
imsety.oit.unc.edu      internet address = 152.2.21.99
ns.unc.edu      internet address = 152.2.21.1
ns2.unc.edu     internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1

Используйте тип ANY, чтобы получить все записи ресурса, связанные с данным именем.

Практически программа nslookup помимо отладки позволяет получать текущий список корневых серверов имен. Вы можете получать этот список запросом всех записей NS, связанных с корневым доменом:
> set type=NS
> .
Server:  tao.linux.org.au
Address:  203.41.101.121

Non-authoritative answer:
(root)  name server = A.ROOT-SERVERS.NET
(root)  name server = H.ROOT-SERVERS.NET
(root)  name server = B.ROOT-SERVERS.NET
(root)  name server = C.ROOT-SERVERS.NET
(root)  name server = D.ROOT-SERVERS.NET
(root)  name server = E.ROOT-SERVERS.NET
(root)  name server = I.ROOT-SERVERS.NET
(root)  name server = F.ROOT-SERVERS.NET
(root)  name server = G.ROOT-SERVERS.NET
(root)  name server = J.ROOT-SERVERS.NET
(root)  name server = K.ROOT-SERVERS.NET
(root)  name server = L.ROOT-SERVERS.NET
(root)  name server = M.ROOT-SERVERS.NET

Authoritative answers can be found from:
A.ROOT-SERVERS.NET      internet address = 198.41.0.4
H.ROOT-SERVERS.NET      internet address = 128.63.2.53
B.ROOT-SERVERS.NET      internet address = 128.9.0.107
C.ROOT-SERVERS.NET      internet address = 192.33.4.12
D.ROOT-SERVERS.NET      internet address = 128.8.10.90
E.ROOT-SERVERS.NET      internet address = 192.203.230.10
I.ROOT-SERVERS.NET      internet address = 192.36.148.17
F.ROOT-SERVERS.NET      internet address = 192.5.5.241
G.ROOT-SERVERS.NET      internet address = 192.112.36.4
J.ROOT-SERVERS.NET      internet address = 198.41.0.10
K.ROOT-SERVERS.NET      internet address = 193.0.14.129
L.ROOT-SERVERS.NET      internet address = 198.32.64.12
M.ROOT-SERVERS.NET      internet address = 202.12.27.33

Для просмотра списка всех команд введите help в nslookup.

Другие полезные инструменты

Есть несколько инструментальных средств, которые могут помочь Вам в решении задач. Здесь кратко описаны два таких средства.

Программа hostcvt помогает Вам построить конфигурацию с нуля, преобразуя файл /etc/hosts в главные файлы для named. Она генерирует прямой (A) и обратный (PTR) коды отображения и заботится о псевдонимах. Конечно, она не сделает всю работу за Вас, поскольку Вам все еще нужно настраивать значения времени ожидания в записи SOA или добавить MX-записи. Утилита hostcvt входит в пакет BIND, но доступна и отдельно с нескольких Linux FTP-серверов.

После установки сервера имен Вы должны проверить его конфигурацию. Некоторые хорошие инструментальные средства делают эту работу проще. Во-первых, это dnswalk, основанный на Perl. Во-вторых, nslint. Они оба обходят базу данных DNS, ищут общие ошибки и проверяют, что информация является непротиворечивой. Два других полезных инструментальных средства, host и dig, являются универсальными средствами для запроса базы данных DNS. Вы можете использовать эти инструментальные средства, чтобы вручную осматривать и диагностировать записи базы данных DNS.

Скорей всего, все эти средства доступны в откомпилированном виде. Утилиты dnswalk и nslint доступны в исходниках с http://www.visi.com/~barr/dnswalk и ftp://ftp.ee.lbl.gov/nslint.tar.Z. Утилиты host и dig доступны в исходниках с ftp://ftp.nikhef.nl/pub/network и ftp://ftp.is.co.za/networking/ip/dns/dig.

Назад | Глобальное оглавление | Вперед
Как работает DNS | Локальное оглавление | Serial Line IP


Handling Name Server Lookups

Назад Глава 11. IP Masquerade и трансляция сетевых адресов Вперед

Перехват обращений к серверу имен

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

Назад | Глобальное оглавление | Вперед
Настройка IP Masquerade | Локальное оглавление | О трансляции сетевых адресов


Mounting a Remote NetWare Volume

Назад Глава 15. IPX и файловая система NCP Вперед

Монтирование удаленных томов NetWare

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

В среде NFS мы использовали бы команду mount в Linux, чтобы смонтировать удаленную файловую систему. К сожалению NCP имеет уникальные требования, которые делают непрактичным встраивание в нормальный mount. Linux имеет команду ncpmount, которую мы используем вместо этого. Команда ncpmount одно из инструментальных средств в пакете ncpfs, который доступен в откомпилированном виде или в исходных кодах с ftp.gwdg.de/pub/linux/misc/ncpfs. На момент написания книги текущей была версия 2.2.0.

Прежде, чем Вы сможете монтировать тома NetWare, Вы должны гарантировать, что сетевой интерфейс IPX конфигурирован правильно (как описано ранее). Затем, Вы должны знать детали входа в систему относительно сервера NetWare: имя пользователя и пароль. Наконец, Вы должны знать, какой том и в какой локальный каталог надо смонтировать.

Простой пример ncpmount

Программа ncpmount используется так:
# ncpmount -S ALES_F1 -U rick -P d00-b-gud /mnt/brewery
Эта команда смонтирует все тома сервера ALES_F1 в иерархии /mnt/brewery под NetWare-логином rick с паролем d00-b-gud.

Команда ncpmount обычно объявлена как setuid к root и может использоваться любым пользователем Linux. По умолчанию этот пользователь владеет подключением, и только он или пользователь root могут его размонтировать.

NetWare реализует понятие тома (volume), который аналогичен файлововй системе Linux. Том NetWare является логическим представлением файловой системы NetWare. По умолчанию Linux NCPFS обрабатывает тома как подкаталоги больших логических файловых систем, представляемых файловым сервером. Команда ncpmount представляет каждый том NetWare как каталог в иерархии под каталогом монтирования. Это удобно, если Вы хотите доступ к целому серверу, но по сложным техническим причинам Вы не сможете реэкспортировать эти каталоги, используя NFS. Чуть позже мы рассмотрим, как это обойти.

Подробно о команде ncpmount

Команда ncpmount имеет большое количество параметров командной строки. Это позволяет Вам гибко управлять томами NCP. Наиболее важные из них описаны в таблице 15-2.

Таблица 15-2. Параметры команды ncpmount

Параметр | Описание
-S server | Имя сервера для монтирования.
-U user_name | Логин пользователя NetWare для регистрации на сервере.
-P password | Пароль для логина NetWare.
-n | Вход без пароля (открытый ресурс).
-C | Отключает автоматическое преобразование паролей к верхнему регистру.
-c client_name | Позволяет Вам определять, кто владеет подключением к серверу файлов. Это полезно для печати из NetWare.
-u uid | Идентификатор пользователя Linux, который должен использоваться в качестве владельца файлов в смонтированном каталоге. Если не задан, используется идентификатор пользователя, смонтировавшего каталог.
-g gid | Аналогично -u, но для групп.
-f file_mode | Указывает режим доступа к файлам (permissions), используемый для доступа к файлам в смонтированном томе. Значение должно быть восьмеричным числом, например, 0664. Реальные права доступа вычисляются из заданного значения и Ваших прав в системе NetWare. Значение по умолчанию берется из текущего значения umask.
-d dir_mode | Аналогично -f, но для каталогов.
-V volume | Позволяет Вам определять имя тома для монтирования, вместо монтирования всех томов. Эта опция необходима, если Вы желаете реэкспортировать том NetWare, используя NFS.
-t time_out | Позволяет Вам определять время, которо клиент NCPFS будет ждать ответ с сервера. Значение по умолчанию 60mS, время ожидания определяется в сотых долях секунды. Если Вы испытываете любые проблемы стабильности NCP, попробуйте увеличить это значение.
-r retry_count | Клиент NCP пытается посылать пакеты на сервер несколько раз, прежде чем придет к выводу, что подключение не работает. Эта опция позволяет задать, сколько раз будут выполняться такие повторы. Значение по умолчанию 5.

Как скрыть пароль для логина NetWare

Указывать пароль в командной строке ncpmount опасно. Например, его можно увидеть командами top или ps. Чтобы уменьшить риск, ncpmount может читать данные из файла в домашнем каталоге пользователя. Этот файл хранит имя входа пользователя в систему и пароль, связанный с каждым из файловых серверов. Файл называется /.nwclient и должен иметь права доступа 0600, чтобы гарантировать, что другие пользователи не могут его читать. Если права доступа заданы неправильно, ncpmount откажется использовать его.

Файл имеет очень простой синтаксис. Любые строки, начинающиеся символом #, обрабатываются как комментарии и игнорируются. Остальные строки имеют синтаксис:
fileserver/userid password
Здесь fileserver задает имя сервера файлов, userid имя входа в систему на этом сервере, password задает пароль и может отсутствовать. Если этого поля нет, ncpmount запросит пароль при монтировании. Если поле password определено как -, пароль не используется, это эквивалентно параметру -n командной строки.

Вы можете задать сколько угодно записей, но поле имени сервера должно быть уникальным. Первая запись задает сервер по умолчанию. Команда ncpmount использует для задания сервера, с которым надо связаться, параметр командной строки -S. Он задает то, какую запись в /.nwclient ╬┴─╧ ╔╙╨╧╠╪┌╧╫┴╘╪. х╙╠╔ ╫ -S ╬┼ ╒╦┴┌┴╬ ╙┼╥╫┼╥, ╔╙╨╧╠╪┌╒┼╘╙╤ ┌┴─┴╬╬┘╩ ╨╧ ╒═╧╠▐┴╬╔└.

т╧╠┼┼ ╙╠╧╓╬┘╩ ╨╥╔═┼╥ ncpmount

≤╬┴▐┴╠┴ ╙╧┌─┴─╔═ ╨╥╧╙╘╧╩ ╞┴╩╠ /.nwclient:
# NetWare login details for the Virtual Brewery and Winery
#
# Brewery Login
ALES_F1/MATT staoic1
#
# Winery Login
REDS01/MATT staoic1
Правильно выставим права доступа к нему:
$ chmod 600 /.nwclient

Смонтируем один том с сервера Winery с указанием прав доступа к каталогам и файлам:
$ ncpmount -S REDS01 -V RESEARCH -f 0664 -d 0775 /usr/share/winery/data
Эта команда в комбинации с файлом /.nwclient смонтирует том RESEARCH сервера REDS01 в каталог /usr/share/winery/data под логином NetWare MATT и паролем из файла /.nwclient. Права для смонтированных файлов 0664, а для каталогов 0775.

Назад | Глобальное оглавление | Вперед
Настройка маршрутизатора IPX | Локальное оглавление | Утилиты IPX


Printing to a NetWare Print Queue

Назад Глава 15. IPX и файловая система NCP Вперед

Выполнение заданий NetWare на печать

Пакет ncpfs содержит маленькую утилиту nprint, которая посылает задания по выводу на печать через подключения NCP в очередь печати NetWare. Эта команда создает подключение, если оно в настоящее время не существует и использует файл /.nwclient, чтобы скрыть имя пользователя и пароль. Параметры командной строки, используемые, чтобы управлять процессом входа в систему такие же, как и у ncpmount, так что мы не будем их изучать второй раз. Наиболее важные параметры командной строки nprint будут показаны в примерах.

Единственная требуемая опция для nprint имя файла для печати. Если имя файла не задано, nprint примет задание по выводу на печать из stdin. Наиболее важные параметры nprint определяют сервер и очередь. Таблица 15-4 перечисляет наиболее важные параметры.

Таблица 15-4. Опции команды nprint

Опция | Описание
-S server_name | Имя сервера печати. Удобно иметь соответствующую запись в файле /.nwclient. Она обязательна.
-q queue_name | Очередь печати, в которую надо послать задание по выводу на печать. Эта опция обязательна.
-d job_description | Текст, который появится в консоли печати при показе списка поставленных в очередь работ.
-l lines | Число строк на страницу. По умолчанию 66.
-r columns | Число столбцов на страницу. По умолчанию 80.
-c copies | Число копий работы, которая будет напечатана. Значение по умолчанию 1.

Простой пример использования nprint:
$ nprint -S REDS01 -q PSLASER -c 2 /home/matt/ethylene.ps
Эта команда напечатает две копии файла /home/matt/ethylene.ps на принтере PSLASER на сервере REDS01, используя имя пользователя и пароль из файла /.nwclient.

Использование nprint с Line Printer Daemon

Раньше я упомянул, что опция -c программы ncpmount полезна для печати.

Linux обычно использует программное обеспечение принтера BSD-стиля. Line printer daemon (lpd) является демоном, который проверяет локальный каталог буфера в поисках поставленных в очередь работ, которые должны быть напечатаны. Пакет lpd читает имя принтера и некоторые другие параметры из указанного файла форматирования и пишет данные на принтер, факультативно передавая данные через фильтр, чтобы трансформировать их или управлять печатью.

Демон lpd использует простую базу данных, названную /etc/printcap, чтобы сохранить конфигурацию принтера, включая то, какие фильтры должны выполняться. lpd обычно выполняется с правами специального системного пользователя lp.

Вы могли бы конфигурировать nprint как фильтр для lpd, который позволяет пользователям Вашей Linux-машины выводить данные непосредственно на удаленные принтеры, которые установлены на сервере NetWare. Чтобы сделать это, пользователь lp должен быть способен писать запросы на NCP-подключение к серверу.

Простой способ достичь этого: определить lp как владельца подключения, установленного другим пользователем. Полный пример того, как устанавливать Linux-печать, чтобы обработать задания по выводу на печать клиентов NetWare состоит из трех шагов:

  1. Написать скрипт-обертку (wrapper script).

    Файл /etc/printcap не разрешает передавать параметры фильтрам. Следовательно, Вы должны написать короткий скрипт, вызывающий команду, которую Вы хотите выполнить, с нужными параметрами:
    #!/bin/sh
# p2pslaser - simple script to redirect stdin to the
# PSLASER queue on the REDS01 server
#
/usr/bin/nprint -S REDS01 -U stuart -q PSLASER
#

    Сохраните его в файле /usr/local/bin/p2pslaser.

  2. Введите новую запись в /etc/printcap.

    Мы будем должны конфигурировать p2pslaser как выходной фильтр в /etc/printcap. Это делается так:
    pslaser|Postscript Laser Printer hosted by NetWare server:\
:lp=/dev/null:\
:sd=/var/spool/lpd/pslaser:\
:if=/usr/local/bin/p2pslaser:\
:af=/var/log/lp-acct:\
:lf=/var/log/lp-errs:\
:pl#66:\
:pw#80:\
:pc#150:\
:mx#0:\
:sh:

  3. Добавьте опцию -c к команде ncpmount.

    ncpmount -S REDS01 .... -c lp ....

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

Теперь любой пользователь Linux может указать pslaser как имя принтера при вызове lp. Задание по выводу на печать будет послано на указанный сервер NetWare и помещено в очередь для печати.

Управление очередями печати

Команда pqlist показывает все очереди печати, доступные Вам на указанном сервере. Если Вы не определяете сервер в командной строке, используя опцию -S или логин с паролем, они будут приниматься из заданной по умолчанию записи в файле /.nwclient:

# pqlist -S vbrew_f1 -U guest -n
Server: ALES_F1
Print queue name   Queue ID
---------------------------
TEST               AA02009E
Q2                 EF0200D9
NPI223761_P1       DA03007C
Q1                 F1060004
I-DATA             0D0A003B
NPI223761_P3       D80A0031

Пример показывает список очередей печати, доступных пользователю guest на сервере ALES_F1.

Чтобы посмотреть задания по выводу на печать в очереди, используйте команду pqstat. Требуется имя очереди как параметр, и выводятся все работы в очереди. Вы можете факультативно задать другой параметр, указывающий сколько работ в очереди хотели бы внести в список. Следующий типовой вывод немного сжат, чтобы поместиться на странице:
$ pqstat -S ALES_F1 NPI223761_P1

Server: ALES_F1   Queue: NPI223761_P1          Queue ID: 6A0E000C
   Seq  Name      Description                  Status   Form  Job ID
----------------------------------------------------------------------
     1  TOTRAN    LyX document - proposal.lyx  Active      0  02660001

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

Команда pqrm используется, чтобы удалить задания по выводу на печать из определенной очереди печати. Чтобы удалить работу в очереди, скомандуйте:

$ pqrm -S ALES_F1 NPI223761_P1 02660001

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

Назад | Глобальное оглавление | Вперед
Утилиты IPX | Локальное оглавление | Эмуляция сервера NetWare


Printing to a NetWare Print Queue

Назад Chapter 15. IPX и файловая система NCP Вперед

Выполнение заданий NetWare на печать

Пакет ncpfs содержит маленькую утилиту nprint, которая посылает задания по выводу на печать через подключения NCP в очередь печати NetWare. Эта команда создает подключение, если оно в настоящее время не существует и использует файл ~/.nwclient, чтобы скрыть имя пользователя и пароль. Параметры командной строки, используемые, чтобы управлять процессом входа в систему, такие же, как и у ncpmount, так что мы не будем их изучать второй раз. Наиболее важные параметры командной строки nprint будут показаны в примерах.

Единственная требуемая опция для nprint имя файла для печати. Если имя файла не задано, nprint примет задание по выводу на печать из stdin. Наиболее важные параметры nprint определяют сервер и очередь. Таблица 15-4 перечисляет наиболее важные параметры.

Таблица 15-4. Опции команды nprint

Опция | Описание
-S server_name | Имя сервера печати. Удобно иметь соответствующую запись в файле ~/.nwclient. Она обязательна.
-q queue_name | Очередь печати, в которую надо послать задание по выводу на печать. Эта опция обязательна.
-d job_description | Текст, который появится в консоли печати при показе списка поставленных в очередь работ.
-l lines | Число строк на страницу. По умолчанию 66.
-r columns | Число столбцов на страницу. По умолчанию 80.
-c copies | Число копий работы, которая будет напечатана. Значение по умолчанию 1.

Простой пример использования nprint:
$ nprint -S REDS01 -q PSLASER -c 2 /home/matt/ethylene.ps
Эта команда напечатает две копии файла файла /home/matt/ethylene.ps на принтере PSLASER на сервере REDS01, используя имя пользователя и пароль из файла ~/.nwclient.

Использование nprint с Line Printer Daemon

Раньше я упомянул, что опция -c программы ncpmount полезна для печати.

Linux обычно использует программное обеспечение принтера BSD-стиля. Line printer daemon (lpd) является демоном, который проверяет локальный каталог буфера в поисках поставленных в очередь работ, которые должны быть напечатаны. Пакет lpd читает имя принтера и некоторые другие параметры из указанного файла форматирования и пишет данные на принтер, факультативно передавая данные через фильтр, чтобы трансформировать их или управлять печатью.

Демон lpd использует простую базу данных, названную /etc/printcap, чтобы сохранить конфигурацию принтера, включая то, какие фильтры должны быть выполняться. lpd обычно выполняется с правами специального системного пользователя lp.

Вы могли бы конфигурировать nprint как фильтр для lpd, который позволяет пользователям Вашей Linux-машины выводить данные непосредственно на удаленные принтеры, которые установлены на сервере NetWare. Чтобы сделать это, пользователь lp должен быть способен писать запросы на NCP-подключение к серверу.

Простой способ достичь этого: определить lp как владельца подключения, установленного другим пользователем. Полный пример того, как устанавливать Linux-печать, чтобы обработать задания по выводу на печать клиентов NetWare состоит из трех шагов:

  1. Написать скрипт-обертку (wrapper script).

    Файл /etc/printcap не разрешает передавать параметры фильтрам. Следовательно, Вы должны написать короткий скрипт, вызывающий команду, которую Вы хотите вызвать, с нужными параметрами:
    #!/bin/sh
# p2pslaser - simple script to redirect stdin to the
# PSLASER queue on the REDS01 server
#
/usr/bin/nprint -S REDS01 -U stuart -q PSLASER
#

    Сохраните его в файле /usr/local/bin/p2pslaser.

  2. Введите новую запись в /etc/printcap.

    Мы будем должны конфигурировать p2pslaser как выходной фильтр в /etc/printcap. Это делается так:
    pslaser|Postscript Laser Printer hosted by NetWare server:\
:lp=/dev/null:\
:sd=/var/spool/lpd/pslaser:\
:if=/usr/local/bin/p2pslaser:\
:af=/var/log/lp-acct:\
:lf=/var/log/lp-errs:\
:pl#66:\
:pw#80:\
:pc#150:\
:mx#0:\
:sh:

  3. Добавьте опцию -c к команде ncpmount.

    ncpmount -S REDS01 .... -c lp ....

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

Теперь любой пользователь Linux может указать pslaser как имя принтера при вызове lp. Задание по выводу на печать будет послано на указанный сервер NetWare и помещено в очередь для печати.

Управление очередями печати

Команда pqlist показывает все очереди печати, доступные Вам на указанном сервере. Если Вы не определяете сервер в командной строке, используя опцию -S или логин с паролем, они будут приниматься из заданной по умолчанию записи в файле ~/.nwclient:

# pqlist -S vbrew_f1 -U guest -n
Server: ALES_F1
Print queue name                                    Queue ID
------------------------------------------------------------
TEST                                                AA02009E
Q2                                                  EF0200D9
NPI223761_P1                                        DA03007C
Q1                                                  F1060004
I-DATA                                              0D0A003B
NPI223761_P3                                        D80A0031

Пример показывает список очередей печати, доступных пользователю guest на сервере ALES_F1.

Чтобы посмотреть задания по выводу на печать в очереди, используйте команду pqstat. Требуется имя очереди как параметр, и выводятся все работы в очереди. Вы можете факультативно задать другой параметр, указывающий сколько работ в очереди хотели бы внести в список. Следующий типовой вывод немного сжат, чтобы поместиться на странице:
$ pqstat -S ALES_F1 NPI223761_P1

Server: ALES_F1     Queue: NPI223761_P1          Queue ID: 6A0E000C
   Seq  Name      Description                    Status   Form  Job ID
------------------------------------------------------------------------
     1  TOTRAN    LyX document - proposal.lyx    Active      0  02660001

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

Команда pqrm используется, чтобы удалить задания по выводу на печать из определенной очереди печати. Чтобы удалить работу в очереди, скомандуйте:

$ pqrm -S ALES_F1 NPI223761_P1 02660001

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

Назад | Глобальное оглавление | Вперед
Exploring Some of the Other IPX Tools | Локальное оглавление | NetWare Server Emulation


NetWare Server Emulation

Назад Глава 15. IPX и файловая система NCP Вперед

Эмуляция сервера NetWare

Есть два свободных эмулятора файлового сервера NetWare для Linux. Это lwared, разработанный Ales Dryak, и mars_nwe, разработанный Martin Stover. Оба пакета предоставляют эмуляцию файлового сервера NetWare под Linux, позволяя клиентам NetWare монтировать каталоги Linux, экспортируемые как тома NetWare. lwared проще в настройке, а mars_nwe более функционален. Их установка и настройка подробно описаны в IPX-HOWTO.

Назад | Глобальное оглавление | Вперед
Выполнение заданий NetWare на печать | Локальное оглавление | Управление Taylor UUCP


The netstat Command

Назад Глава 5. Configuring TCP/IP Networking Вперед

Команда netstat

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

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

При вызове netstat с параметром -r, он показывает таблицу маршрутизации ядра, подготовленную с помощью route. На vstout он выдаст:
# netstat -nr
Kernel IP routing table
Destination   Gateway      Genmask         Flags  MSS Window  irtt Iface
127.0.0.1     *            255.255.255.255 UH       0 0          0 lo
172.16.1.0    *            255.255.255.0   U        0 0          0 eth0
172.16.2.0    172.16.1.1   255.255.255.0   UG       0 0          0 eth0

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

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

G

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

U

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

H

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

D

устанавливается, если запись таблицы была произведена по приходу перенаправляемого сообщения ICMP (см. раздел Internet Control Message Protocol главы 2), или если запись таблицы была создана демоном динамической маршрутизации, наподобие gated.

M

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

!

путь неверен (закрыт), все пакеты будут отброшены.

Еще три колонки показывают MSS, Window и irtt, применяемые для соединений TCP через этот маршрут. MSS (Maximum Segment Size) определяет максимальный размер пакета для этого маршрута. Window задает максимальное количество данных, которое система примет в одном пакете с удаленного компьютера. irtt означает "initial round trip time". TCP протокол гарантирует, что данные будут надежно доставлены между компьютерами, повторно передавая пакеты, если они были потеряны. При этом ведется счетчик времени: сколько можно ждать, пока пакет дойдет до машины назначения, и оттуда придет подтверждение. Если время вышло, пакет будет послан еще раз. Этот процесс называется round-trip time. initial round-trip time задает значение, которое используется при установке подключения. Для большинства сетей подходит значение по умолчанию, но для некоторых медленных сетей (особенно ряд типов пакетного радио) время слишком короткое, что вызывает ненужные повторы. Параметр irtt может быть установлен, используя команду route. По умолчанию в этом поле ноль.

Последнее поле показывает, к какому сетевому интерфейсу относится маршрут.

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

Когда netstat вызывается с параметром -i, он показывает статистику для сетевых интерфейсов. Если, кроме того, дается опция -a, он будет печатать все интерфейсы, представленные в ядре, а не только те, которые были отконфигурированы в настоящее время. На vstout вывод 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 /TX-ERR), сколько было потеряно (RX-DRP/TX-DRP) и сколько было потеряно из-за переполнения (RX-OVR/ TX-OVR).

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

B

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

L

Этот интерфейс задает устройство loopback.

M

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

O

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

P

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

R

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

U

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

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

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 будут отображаться все сокеты всех семейств сразу.

Назад | Глобальное оглавление | Вперед
Все про ifconfig | Локальное оглавление | Проверка ARP-таблиц


Netnews

Назад Вперед

Глава 20. Netnews

Локальное оглавление
История Usenet
Что такое Usenet?
Как в Usenet обрабатывают новости?

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

История Usenet

Идея сетевых новостей была рождена в 1979, когда два студента Tom Truscott и Jim Ellis подумали об использовании UUCP, чтобы соединять машины с целью информационного обмена среди пользователей Unix. Они создали сеть из трех машин на севере Каролины.

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

A-News не был разработан, чтобы обработать больше, чем несколько статей на группу в день. Когда объем вырос, пакет был переписан Мark Horton и Matt Glickman и назван B-News. Впервые B-News (версия 2.1) был опубликован в 1982. Он непрерывно расширялся с добавлением отдельных новых возможностей. Текущая версия B-News 2.11. Она медленно устаревает.

Geoff Collyer и Henry Spencer переписали B-News и опубликовали свою разработку в 1987. Она называется C-News. Все выпуски до C-News прежде всего направлены на сети UUCP, хотя они могут использоваться в других средах также. Эффективная передача новостей по сетям TCP/IP и DECNet требует новой схемы. Это было причиной, по которой в 1986 появился сетевой протокол передачи новостей (Network News Transfer Protocol, NNTP). Он основан на сетевых соединениях и определяет ряд команд, чтобы в интерактивном режиме передавать статьи. Мы поговорим о C-News подробно в главе 21.

Имеется ряд NNTP-программ, доступных из Сети. Одна из них пакет nntpd (авторы Brian Barber и Phil Lapsley), который Вы можете использовать, чтобы обеспечить сервис новостей на компьютерах в локальной сети. Пакет nntpd был разработан, чтобы дополнить пакеты новостей, подобные B-News или C-News, дать им свойства NNTP. Если Вы хотите использовать NNTP с сервером C-News, Вы должны прочитать главу 22, которая объясняет, как конфигурировать nntpd daemon и использовать его с C-News.

Альтернативный пакет, обеспечивающий NNTP, INN или Internet News. Это не только внешний интерфейс, а своя система новостей. Он включает сложные новости и демон передачи, который может эффективно поддерживать несколько параллельных связей NNTP. Подробно он будет описан в главе 23.

Назад | Глобальное оглавление | Вперед
Настройка UUCP |  | Что такое Usenet?


How Does Usenet Handle News?

Назад Глава 20. Netnews Вперед

Как в Usenet обрабатывают новости?

Сегодня, Usenet вырос до огромных размеров. Конечно, это требует намного больше, чем обмен файлами. Так что давайте рассмотрим способ, которым большинство систем Unix обрабатывают новости Usenet.

Новости распространяются по сети различными транспортами. Как историческая среда используется UUCP, но сегодня основной трафик несет Internet. Используемый алгоритм маршрутизации называется лавинной (flooding) маршрутизацией. Каждый сайт поддерживает ряд связей с другими абонентами. Любая статья, сгенерированная или полученная локальной системой новостей будет послана к ним (это называется подпиткой новостями, news feeds).

Чтобы отличать статьи и распознавать дубликаты, Usenet-статьи должны нести ID сообщения (заданный в поле заголовка Message-Id:), которое объединяет имя пункта регистрации и серийный номер в виде serial @site. Для каждой обработанной статьи, система новостей регистрирует ее ID в файле history, в котором проверяются все прибывающие статьи.

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

Реальное число статей обычно требует, чтобы к вышеупомянутой схеме были сделаны уточнения. На сетях UUCP обычно статьи за некоторый период времени объединяются в один файл, который сжимается и посылается удаленному сайту. Это вызывается пакетированием (batching).

Альтернативная методика: протокол ihave/sendme, который не дает пересылась статьи дважды. Вместо того, чтобы помещать все статьи в пакетные файлы и посылать их, только ID сообщений будут объединены в сообщении "ihave" и посланы. Удаленный сайт читает это сообщение, сравнивает с файлом history и возвращает список статей, которые ему нужны в сообщении "sendme". Только запрошенные статьи будут посланы.

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

Сайты, которые находятся в Internet, полагаются на TCP/IP программное обеспечение, которое использует Network News Transfer Protocol (NNTP). NNTP описан в RFC-977. Он отвечает за передачу новостей между серверами новостей и обеспечивает Usenet-доступ одиночным пользователям.

NNTP знает три различных способа передать новости. Первый: версия ihave/sendme в реальном масштабе времени, также упоминаемого как выталкивание (pushing) новостей. Вторая методика названа pulling. Здесь пользователь запрашивает список статей в данной группе новостей (newsgroup) или иерархии, которые достигли сервера после определенной даты, и выбирает те, которых у него нет. Третья методика предназначена для интерактивных программ работы с новостями (newsreader). Она позволяет Вам или Вашему newsreader отыскивать статьи из определенных newgroups и передавать статьи с незавершенной информацией заголовка.

На кааждом сайте новости хранятся в иерархии каталога /var/spool/news, каждая статья в отдельном файле, и каждая newsgroup в отдельном каталоге. Имя каталога составлено из имени newsgroup с компонентами пути. Таким образом, статьи comp.os.linux.misc сохраняются в /var/spool/news/comp/os/linux/misc. Статьи получают номера в порядке поступления. Эти номера служат именами файлов. Диапазон номеров статей в настоящее время интерактивно сохраняется в файле active, который в то же время служит как список newsgroups, известных Вашему сайту.

Так как дисковое пространство конечный ресурс, Вы должны отбрасывать статьи после некоторого времени. Это называется expiring. Обычно статьи из некоторых групп и иерархий устаревают в течение фиксированного числа дней после того, как они прибывают. Это может быть изменено отправителем с помощью поля Expires: заголовка статьи.

Вы теперь имеете достаточно информации, чтобы выбрать, что читать дальше. Пользователи UUCP должны читать о C-News в главе 21. Если Вы используете TCP/IP сеть, читайте о NNTP в главе 22 . Если Вы должны передавать умеренные количества новостей по TCP/IP, сервера, описанного в этой главе может быть достаточно для Вас. Чтобы установить сверхпрочный сервер новостей, который может обрабатывать огромные объемы, прочитайте о InterNet News в главе 23.

Назад | Глобальное оглавление | Вперед
Что такое Usenet? | Локальное оглавление | C-News


Newsreader Configuration

Назад Вперед

Глава 24. Настройка программ работы с новостями

Локальное оглавление
Настройка tin
Настройка trn
Настройка nn

Программы работы с новостями (newsreader ) предоставляют функциональные возможности, позволяющие пользователю легко обращаться к функциям системы новостей: отсылать статьи или просматривать содержимое newsgroup удобным способом. Качество этого интерфейса является предметом бесконечных споров. Имеется много newsreaders, которые были перенесены в Linux. Ниже я буду описывать базисную установку для трех наиболее популярных, а именно: tin, trn и nn.

Один из наиболее эффективных newsreaders это:
$ find /var/spool/news -name '[0-9]*' -exec cat {} \;|more

Это способ, которым Unix читает новости.

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

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

Тема ответа обычно повторяет тему исходной статьи, начинаясь с Re:. Дополнительно в поле References: заголовка включается message ID статьи, на которую текущая статья является ответом. Сортировка статей по теме и связям создает деревья статей, именуемые потоками (threads). Одна из задач при написании newsreader, создание эффективной схемы построения потоков (threading), потому что время, требуемое для этого, является пропорциональным квадрату числа статей.

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

В следующих разделах мы будем иметь дело только с административными задачами. Большинство их касается создания баз данных и учета.

Настройка tin

Наиболее универсальный newsreader tin. Он написан Iain Lea и свободно построен на более старом newsreader tass (автор Rich Skrenta).

На 486DX50 ему нужно приблизительно 30 секунд, чтобы найти 1000 статей, при чтении непосредственно с диска. При обращении по NNTP к загруженному серверу новостей это займет более 5 минут. Вы можете уточнить это, регулярно модифицируя индексный файл с опцией -u или вызывая tin с опцией -U.

Обычно tin формирует дамп баз данных в домашнем каталоге пользователя ниже иерархии .tin/index. Это может быть дорого в терминах ресурсов, так что иногда стоит хранить одну копию. Это может быть достигнуто объявлением tin как setuid, например, к пользователю news. Тогда tin будет хранить все базы данных в /var/spool/news/.index.

Версия tin, включенная в некоторые дистрибутивы Linux, не имеет поддержки NNTP. При вызове как rtin или с опцией -r tin пробует соединяться с NNTP-сервером, заданным в файле /etc/nntpserverNNTPSERVER. Файл nntpserver просто содержит имя сервера в одной строке.

Назад | Глобальное оглавление | Вперед
Управление INN: команда ctlinnd |  | Настройка trn


The NetworkFile System

Назад Вперед

Глава 14. Сетевая файловая система (NFS)

Локальное оглавление
Запуск NFS
Монтирование тома NFS
NFS Daemons
Файл exports
Поддержка серверов NFS v2
Поддержка серверов NFS v3

Network File System (NFS), возможно, является наиболее видной сетевой услугой, использующей RPC. Она позволяет обращаться к файлам на удаленных хостах точно тем же самым способом, как к любым локальным файлам. Это стало возможным за счет взаимодействия функциональных возможностей ядра на клиентской стороне (которая использует удаленную файловую систему) и NFS-сервера на серверной стороне (который обеспечивает доступ к данным). Этот доступ к файлу полностью прозрачен для клиента и работает через все разнообразие серверов и архитектуры хостов.

NFS предлагает ряд преимуществ:

  • Данные, к которым обращаются все пользователи, могут быть сохранены на центральном хосте, клиенты будут монтировать этот каталог при начальной загрузке. Например, Вы можете сохранить все логины пользователей на одном хосте, настроить все хосты Вашей сети на монтирование каталога /home с этого хоста. Если все это установлено в паре с NIS, то пользователи смогут войти в любую систему и работать на одном множестве файлов.

  • Данные, потребляющие большие количества дискового пространства, могут быть сохранены на единственном хосте. Например, все файлы и программы, относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в одном месте. Мало того, что удобно ими управлять, так еще и место экономится.

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

Linux NFS в значительной степени работа Rick Sladkey, написавшего код NFS kernel и большие части NFS-сервера. Последний был создан из unfsd, NFS-сервер уровня пользователя, первоначально написанного Mark Shand, и hnfs Harris NFS-сервера, написанного Donald Becker.

Давайте теперь посмотрим, как NFS работает: клиент может запросить смонтировать каталог с удаленного хоста в локальный каталоге тем же способом, как он может установить физическое устройство. Однако, синтаксис, используемый для этого, несколько иной. Например, чтобы смонтировать каталог /home с хоста vlager в каталог /users на машине vale, администратор использовал бы следующую команду на vale:
# mount -t nfs vlager:/home /users

Команда mount попробует соединиться с rpc.mountd, daemon монтирования на vlager через RPC. Сервер проверит, разрешается ли vale смонтировать каталог, и если все нормально, вернет file handle. Этот handle будет использоваться во всех последовательных запросах к подкаталогам /users.

Когда кто-то обращается к файлу по NFS, kernel RPC-сайта вызовет rpc.nfsd (NFS daemon) на машине сервера. Это обращение берет handle файла, имя файла, к которому обращаются, идентификаторы группы и пользователя как параметры. Они используются в определении прав доступа к точно определенному файлу. Чтобы защититься от несанкционированного чтения или модифицирования файла, идентификаторы пользователя и группы должны быть одними и теми же на обоих хостах.

В большинстве реализаций Unix, функциональные возможности NFS клиента и сервера выполнены как демоны kernel-уровня, которые запускаются из пространства пользователя при начальной загрузке системы. Это NFS Daemon (rpc.nfsd) на хосте сервера и Block I/O Daemon (biod) на клиентском хосте. Чтобы улучшить производительность, biod выполняет асинхронный ввод-вывод, используя упреждающее чтение и отложенную запись. К тому же, несколько демонов rpc.nfsd обычно запускаются совместно.

Реализация NFS в Linux немного отличается в клиентском коде: она объединена с файловой системой VFS на уровне ядра и не требует дополнительного управления. Обычно код сервера запускается полностью в пространстве пользователя, так что управление несколькими копиями затруднено. Текущая реализация rpc.nfsd предлагает экспериментальную ограниченную поддержку нескольких серверов. Olaf Kirch разработал NFS-сервер уровня ядра, который появился в ядрах Linux 2.2 и выше. Эффективность заметно выросла. Позже мы поговорим об этом отдельно.

Запуск NFS

Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку NFS, компилируемую в него. Новые ядра имеют для этого простой интерфейс в файловой системе proc, файл /proc/filesystems, который Вы можете отобразить, используя команду cat:
$ cat /proc/filesystems
        minix
        ext2
        msdos
nodev   proc
nodev   nfs

Если nfs отсутствует в этом списке, Вы должны скомпилировать собственное ядро с включенным NFS. Конфигурирование сетевых опций ядра объяснено в разделе "Настройка ядра" главы 3.

Назад | Глобальное оглавление | Вперед
NIS с поддержкой Shadow |  | Монтирование тома NFS


The Network Information System

Назад Вперед

Глава 13. Сетевая информационная система (NIS)

Локальное оглавление
Знакомство с NIS
NIS против NIS+
Клиентская сторона NIS
Запуск NIS-сервера
Безопасность NIS-сервера
Установка клиента NIS с GNU libc
Выбор нужных карт
Использование карт passwd и group
NIS и затенение паролей

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

Поэтому фирма Sun разработала Network Information System (NIS). NIS обеспечивает универсальные средства доступа к базе данных, которая может использоваться, например, чтобы распределять информацию, содержащуюся в файлах passwd и groups на все компьютеры в Вашей сети. Точно так же Вы можете использовать NIS, чтобы распределить информацию о hostname из файла /etc/hosts на все машины в сети.

NIS основан на RPC, включает сервер, клиентскую библиотеку и несколько административных инструментальных средств. Первоначально NIS был назван желтыми страницами или YP (Yellow Pages), это название все еще используется, чтобы обратиться к нему. К сожалению, это имя является маркой компании British Telecom, которая требовала, чтобы Sun отказалась от его использования. Тем не менее, YP остался префиксом в именах команд, относящихся к NIS таких, как ypserv и ypbind.

Сегодня NIS доступен фактически для всех Unix, и имеются свободные реализации. BSD Net-2 был основан на публичной версии, выпущенной Sun. Код клиентской библиотеки из этого релиза долго присутствовал в Linux libc, а административные программы были перенесены в Linux Swen ThЭmmler. Сервер NIS в публичной версии отсутствовал.

Peter Eriksson разработал новую версию под именем NYS. Она поддерживает как NIS, так и Sun NIS+. NYS не только обеспечивает набор инструментальных средств NIS и сервер, но также добавляет целый набор новых библиотечных функций, которые должны компилироваться в libc, если Вы желаете использовать этот пакет. Это включает новую схему конфигурации преобразования имен, которая заменяет текущую схему, использующую host.conf.

GNU libc, известная как libc6, в сообществе Linux, включает модифицированную версию традиционной поддержки NIS, разработанную Thorsten Kukuk. Она поддерживает все библиотечные функции NYS и также использует расширенную схему конфигурации NYS. Вам все еще нужны инструментальные средства и сервер, но использование GNU libc избавляет от проблем с библиотеками.

Эта глава в основном рассматривает поддержку NIS в GNU libc. Для двух других пакетов приведенные здесь инструкции тоже могут пригодиться. Подробнее о вопросе можно узнать в NIS-HOWTO, кроме того на английском языке есть книга Managing NFS and NIS (автор Hal Stern, издательство O'Reilly).

Знакомство с NIS

NIS хранит информацию базы данных в файлах карт (maps), которые содержат пары ключ=значение. Примером такой пары является имя пользователя и зашифрованная форма его пароля для входа в систему. Карты хранятся на центральном главном компьютере, управляющем сервером NIS, откуда клиенты могут брать информацию через различные обращения RPC. Часто карты хранятся в DBM-файлах. DBM это простая библиотека управления базами данных, которая использует методы хеширования, чтобы ускорить операции поиска. Имеется свободная реализация DBM из проекта GNU, названная gdbm, которая является частью большинства дистрибутивов Linux.

Карты обычно генерируются из текстовых файлов типа /etc/hosts или /etc/passwd . Для некоторых файлов будет создано несколько карт, по одной для каждого типа ключа поиска. Например, Вы можете искать в файле hosts имя машины или ее IP-адрес. Соответственно, из этого файла будут получены две NIS-карты hosts.byname и hosts.byaddr . Таблица 13-1 перечисляет наиболее распространенные карты и файлы, из которых они сгенерированы.

Таблица 13-1. Стандартные карты NIS и соответствующие им файлы

Файл | Карта (карты) | Описание
/etc/hosts | hosts.byname, hosts.byaddr | Соответствие IP-адресов именам машин
/etc/networks | networks.byname, networks.byaddr | Соответствие IP-адресов именам сетей
/etc/passwd | passwd.byname, passwd.byuid | Пароли пользователей и их логины
/etc/group | group.byname, group.bygid | Идентификаторы групп (Group ID) и имена групп в системе
/etc/services | services.byname, services.bynumber | Описание сервисов и их имена
/etc/rpc | rpc.byname, rpc.bynumber | Номера сервисов Sun RPC и их имена
/etc/protocols | protocols.byname, protocols.bynumber | Номера протоколов и их имена
/usr/lib/aliases | mail.aliases | Почтовые псевдонимы с именами

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

Для некоторых карт обычно используют прозвища (nicknames), которые короче и, следовательно, их проще напечатать. Обратите внимание, что эти прозвища понятны только ypcat и ypmatch, двум инструментальным средствам для проверки Вашей конфигурации NIS. Чтобы получить полный список прозвищ, понятных этим инструментальным средствам, выполните следующую команду:
$ ypcat -x
Use "passwd" for "passwd.byname"
Use "group" for "group.byname"
Use "networks" for "networks.byaddr"
Use "hosts" for "hosts.byaddr"
Use "protocols" for "protocols.bynumber"
Use "services" for "services.byname"
Use "aliases" for "mail.aliases"
Use "ethers" for "ethers.byname"

Сервер NIS традиционно назван ypserv. Для средней сети один сервер обычно достаточен, большие сети могут выполнить несколько серверов на различных машинах и в разных сегментах сети, чтобы уменьшить загрузку на серверы и маршрутизаторы. Эти серверы должны быть синхронизированы объявлением одного из них главным (master server), а остальных подчиненными (slave servers). Карты создаются только на главном. Оттуда они распределяются на все подчиненные.

До сих пор мы очень неопределенно говорили относительно "сети". Имеется в виду особый термин в NIS: все хосты, разделяющие часть системных настроек по NIS: так называемый домен NIS (NIS domain). К сожалению, домены NIS не имеют абсолютно ничего общего с доменами, с которыми мы столкнулись в DNS. Во избежание неоднозначности мы будем всегда определять, какой тип домена имеется в виду.

NIS-домены имеют административную функцию. Они обычно невидимы для пользователей, за исключением совместного использования паролей всеми машинами в домене. Следовательно, имя, данное NIS-домену, нужно только администраторам. Обычно любое имя несет определенную смысловую нагрузку в сети. Например, администратор Virtual Brewery может создать два домена NIS: один для Brewery, второй для сети Winery, с именами brewery и winery соответственно. Можно и просто использовать имя DNS-домена и для NIS.

Чтобы устанавливать и отображать имя домена NIS Вашей машины, используйте команду domainname. Когда она вызывается без параметров, отображает текущее имя. Чтобы задать имя домена, надо задать его в качестве параметра. Введите от имени администратора:
# domainname brewery

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

Возникает вопрос: а как клиент найдет, к какому серверу обращаться? Самое простое решение сводится к файлу конфигурации с указанием в нем имени нужной машины. Такой подход пригоден в сетях с одним сервером, но если несколько, клиент не сможет динамически запрашивать разные серверы (понятно, из одного домена) в зависимости от их доступности. Следовательно, реализации NIS полагаются на специальный daemon по имени ypbind, чтобы обнаружить подходящий сервер NIS в своем домене. Перед выполнением любого NIS-запроса, прикладная программа сначала выясняет у ypbind, какой сервер использовать.

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

Динамическое связывание полезно только, когда сеть обеспечивает больше, чем один сервер NIS. Динамическое связывание также представляет проблему защиты: ypbind просто верит, кто бы не отвечал. Так что если вместо сервера NIS ответит хакер, его ответ будет воспринят без тени недоверия. Само собой разумеется, это становится особенно ненадежным, если Вы управляете базами данных паролей по NIS. Чтобы принимать меры против этого, Linux ypbind обеспечивает два способа работы: либо обычный опрос локальной сети в поисках сервера NIS, либо указание имен машин с серверами NIS в своем файле настроек.

Назад | Глобальное оглавление | Вперед
Настройка удаленного выполнения |  | NIS против NIS+


The Client Side of NIS

Назад Глава 13. Network Information System (NIS) Вперед

Клиентская сторона NIS

Если Вы знакомы с написанием или переносом сетевых прикладных программ, Вы можете обратить внимание, что большинство карт NIS соответствует библиотечным функциям в библиотеке C lib. Например, чтобы получить passwd, Вы обычно используете функции getpwnam и getpwuid, которые возвращают информацию, связанную с данным логином или цифровым идентификатором пользователя (user ID), соответственно. При нормальных обстоятельствах эти функции выполняют поисковый запрос на стандартном файле, типа /etc/passwd.

NIS-реализация этих функций изменяет это поведение и использует обращение RPC к серверу NIS, который ищет логин или user ID. Функция может обрабатывать NIS-данные, как если бы они были добавлены к оригинальному файлу passwd, так что оба набора информации доступны прикладной программе и будут использованы. Есть второй вариант: информация в локальном passwd игнорируется вообще, и используются только NIS-данные.

Для традиционных реализаций NIS имелись некоторые соглашения на предмет того, какие карты как обрабатывать. Но иногда это позволяло модифицировать файл passwd и открывало дыры в защите. Для обхода этих ловушек NYS и GNU libc используют общую схему конфигурации, которая определяет, использует ли специфический набор функций пользователя оригинальные файлы, NIS или NIS+, а также в каком порядке. Эта схема будет рассмотрена чуть ниже.

Назад | Глобальное оглавление | Вперед
NIS против NIS+ | Локальное оглавление | Запуск NIS-сервера


NIS Versus NIS+

Назад Глава 13. Network Information System (NIS) Вперед

NIS против NIS+

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

NIS+ дополнительно поддерживает безопасный и шифрованный RPC, который помогает решать проблемы защиты NIS.

Традиционный NIS использует RPC Version 2, а NIS+ нужна Version 3. На момент написания книги хорошей рабочей реализации NIS+ для Linux не было, так что этот сервис не рассмотрен здесь детально.

Назад | Глобальное оглавление | Вперед
Сетевая информационная система (NIS) | Локальное оглавление | Клиентская сторона NIS


nn Configuration

Назад Глава 24. Настройка программ работы с новостями Вперед

Настройка nn

Пакет nn написан Kim F. Storm, он утверждает, что цель программы чтения новостей не состоит в том, чтобы читать новости. Имя расшифровывается как "No News", а девиз "Отсутствие новостей хорошая новость. А nn лучше.".

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

Диспетчер базы данных nn называется nnmaster. Он обычно выполняется как daemon и запускается из скрипта rc. Он вызывается как:
/usr/local/lib/nn/nnmaster -l -r -C

Это дает возможность отсеивания для всех newsgroups, представленных в файле active.

Также Вы можете вызывать nnmaster периодически из cron, передавая ему список групп. Этот список очень похож на список в файле sys за исключением того, что он использует пробелы вместо запятых. Вместо группы all для всех должен использоваться пустой аргумент "", чтобы обозначить все группы. Типовой вызов:
# /usr/local/lib/nn/nnmaster !rec.games.go rec comp

Обратите внимание, что порядок важен: крайная левая спецификация группы, которая соответствует ситуации, всегда используется. Таким образом, если мы поместим !rec.games.go после rec, все статьи из этой группы отсеются.

nn предлагает разные методы удалять устаревшие статьи из баз данных. Первое: модифицировать базу данных, развертывая каталоги групп новостей и отбрасывая записи, чья соответствующая статья является больше не доступной. Это заданная по умолчанию операция, полученная вызовом nnmaster с опцией -E. Приемлемо быстро, если Вы не делаете это через NNTP.

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

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

Список групп, которые устарели задается опцией -F. Однако, если Вы имеете nnmaster, выполняющийся как daemon, Вы должны уничтожить его (используя -k) прежде, чем сможет произойти устаревание, и перезапустить его с первоначальными опциями. Таким образом, команда выполнения устаревания на всех группах, использующая метод 1:
# nnmaster -kF ""
# nnmaster -lrC

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

nnmaster полагается на файл GROUPS, который расположен в /var/lib/nn. Если он не существует первоначально, то будет создан. Для каждой newsgroup он содержит строку, которая начинается с имени группы, необязательно сопровождаемого временной меткой и флагами. Вы можете редактировать эти флаги, чтобы задать поведение для рассматриваемой группы, но Вы не можете изменять порядок, в котором группы появляются. Флаги и их эффекты детализированы на man-странице по nnmaster.

Назад | Глобальное оглавление | Вперед
Настройка trn | Локальное оглавление | Пример сети: The Virtual Brewery


NNTP and the nntpd Daemon

Назад Вперед

Глава 22. NNTP и nntpd Daemon

Локальное оглавление
Протокол NNTP
Установка сервера NNTP
Ограничение доступа к NNTP
Авторизация NNTP
Взаимодействие nntpd и C-News

Протокол передачи сетевых новостей (Network News Transfer Protocol, NNTP) предусматривает разные подходы к обмену новостей. Здесь поддерживается все: от пакетной технологии (аналог UUCP), до интерактивного обмена по сети. NNTP не просто пакет программ, это стандарт Internet, описанный в RFC-977. Он основан на поточных соединениях, обычно по TCP, между клиентами в сети и сервером новостей. Поточная схема позволяет клиентам и серверу гибко управлять передачей статей.

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

NNTP также обеспечивает активый и пассивный способы передачи новостей, которые называются "pushing" и "pulling". Выталкивание (pushing), в основном, представляет собой то же самое, что и C-News протокол ihave/sendme, который рассмотрен в главе 21). Клиент предлагает статью серверу через IHAVE msgid, а сервер возвращает код ответа, который указывает, имеет ли он уже эту статью, или она требуется. В последнем случае, клиент посылает статью, завершенную одиночной точкой в отдельной строке.

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

Противоположная методика: перемещать (pulling) новости. Клиент запрашивает список всех доступных статей группы, которые прибыли после заданной даты. Этот запрос выполняется командой NEWNEWS. Из возвращенного списка сообщений, клиент выбирает те статьи, которые он еще не имеет, используя команду ARTICLE для каждой из них.

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

Имеется также ряд команд для newsreaders, которые разрешают им отыскивать заголовок и тело статьи отдельно или даже находтьь коекретные строки заголовка из набора статей. Это дает возможность хранить все новости на центральной машине, используя nntp-основанные клиентские программы для чтения и регистрации. Это альтернатива экспорту каталогов новостей через NFS, который описан в главе 21.

Полная проблема NNTP состоит в том, что он позволяет хорошо осведомленному специалисту вставлять статьи в поток новостей с ложной спецификацией отправителя. Это называется news faking или spoofing. Расширение NNTP позволяет требовать установления подлинности пользователя для некоторых команд.

Имеется ряд доступных пакетов NNTP. Один из наиболее широко известных: NNTP daemon. Первоначально, он был написан Stan Barber и Phil Lapsley, чтобы проиллюстрировать подробности RFC-977. Вы можете найти его в большинстве дистрибутивов Linux, а также получить исходники и откомпилировать их.

Пакет nntpd состоит из сервера и двух клиентов для перемещения и выталкивания новостей, соответственно, и свою версию программы inews. Они живут в среде B-news, но с небольшими дополнениями, они будут работать с C-news. Однако, если Вы планируете использовать NNTP больше, чем для доступа newsreaders к серверу новостей, эта реализация недостаточна. Мы обсудим только NNTP daemon, содержащийся в пакете nntpd и не будем останавливаться на клиентских программах.

Если Вы желаете использовать большой сайт новостей, Вы должны рассмотреть пакет InterNet News (INN), который был написан Rich Salz. Этот пакет обеспечивает NNTP и UUCP-доставку новостей, что определенно лучше, чем nntpd. INN подробно рассматривается в главе 23.

Протокол NNTP

Мы упомянули две команды NNTP, которые являются ключевыми при передаче статей между серверами. Теперь мы рассмотрим их в контексте фактического NNTP-сеанса, чтобы показать Вам насколько прост этот протокол. Используем простой клиент telnet, чтобы соединиться с INN-сервером новостей Virtual Brewery с именем news.vbrew.com. Чтобы сделать примеры короткими, сервер запущен в минимальной конфигурации. Мы рассмотрим как завершить конфигурацию этого сервера в главе 23. В нашем тестировании мы будем очень осторожны: все статьи будут генерироваться только в группе новостей junk, чтобы никому не мешать.

Соединение с сервером новостей

Для связи с сервером нужно просто открыть TCP-соединение с портом для NNTP. После этого будет показано приветственное приглашение сервера. Одна из первых команд, которые Вы могли бы попробовать: help. Ответ, который Вы получите, зависит от того, чем считает Вас сервер: удаленным NNTP-сервером или программой чтения новостей (newsreader), так как имеются различные наборы команд. Вы можете изменять режим доступа, используя команду mode:

$ telnet news.vbrew.com nntp
Trying 172.16.1.1...
Connected to localhost.
Escape character is '^]'.
200 news.vbrew.com InterNetNews server INN 1.7.2 08-Dec-1997 ready
help
100 Legal commands
          authinfo
                help
                ihave
                check
                takethis
                list
                mode
                xmode
                quit
                head
                stat
                xbatch
                xpath
                xreplic
For more information, contact "usenet" at this machine.
.

Ответы NNTP всегда клнчаются точкой (.) в начале строки. Числа в выводе задают коды ответа (response codes) и означают результат запроса (норма или произошла какая-то ошибка). Они описаны в RFC-977; мы будем говорить о наиболее важных.

Выталкивание (Pushing) статьи на сервер

Я упомянул команду IHAVE когда говорил о выталкивании статей на сервер новостей. Давайте посмотрим, как она работает:

ihave <123456@gw.vk2ktj.ampr.org>
335
From: terry@gw.vk2ktj.ampr.org
Subject: test message sent with ihave
Newsgroups: junk
Distribution: world
Path: gw.vk2ktj.ampr.org
Date: 26 April 1999
Message-ID: <123456@gw.vk2ktj.ampr.org>
Body:

This is a test message sent using the NNTP IHAVE command.
.

235

Все команды NNTP нечувствительны к регистру, так что Вы можете вводить их в любом. Команда IHAVE берет один обязательный параметр, это Message ID статьи, которая помещается на сервер. Каждая статья имеет уникальный message ID. Команда IHAVE будет выдана для каждой статьи, которую сервер желает передать. Если код ответа команды находится в диапазоне "3xx", NNTP-сервер передаст полную статью с заголовком и точкой в отдельной строке в качестве маркера конца статьи. Если код ответа был в диапазоне "4xx", принимающий сервер данную статью принять не может из-за ее наличия или какой-то технической проблемы.

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

Изменение режимиа работы с NNTP

Программы работы с новостями (Newsreaders) используют собственный набор команд при работе с сервером новостей. Чтобы активизировать эти команды, сервер должен перейти в режим читателя (reader). Большинство серверов так и делают, если IP-адрес соединяющейся машины не перечислен в списке серверов новостей (news-forwarding). В любом случае NNTP обеспечивает команду для явного переключения в режим reader:

mode reader
200 news.vbrew.com InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready/
    (posting ok).
help
100 Legal commands
  authinfo user Name|pass Password|generic <prog> <args>
  article [MessageID|Number]
  body [MessageID|Number]
  date
  group newsgroup
  head [MessageID|Number]
  help
  ihave
  last
  list [active|active.times|newsgroups|distributions|distrib.pats|/
      overview.fmt|subscriptions]
  listgroup newsgroup
  mode reader
  newgroups yymmdd hhmmss ["GMT"] [<distributions>]
  newnews newsgroups yymmddhhmmss ["GMT"] [<distributions>]
  next
  post
  slave
  stat [MessageID|Number]
  xgtitle [group_pattern]
  xhdr header [range|MessageID]
  xover [range]
  xpat header range|MessageID pat [morepat...]
  xpath MessageID
Report problems to <usenet@vlager.vbrew.com>
.

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

Получение списка групп

Команда list выводит список групп с их краткими описаниями:

list newsgroups
215 Descriptions in form "group description".
control          News server internal group
junk             News server internal group
local.general    General local stuff
local.test       Local test group
.

Перечень активных групп

Команда list active показывает каждую группу и данные о ней. Два числа в каждой строке вывода задают старший и младший номера статей в каждой группе. Программы работы с новостями на основании этих чисел узнают, сколько статей сейчас в группе. Последнее поле в выводе отображает флажки контроля: разрешено ли посылать статьи в груупу, является ли она модерируемой, и хранятся ли статьи на сервере на самом деле, или только данные о них. Подробно эти флажки описаны в главе 23. Рассмотрим пример:

list active
215 Newsgroups in form "group high low flags".
control  0000000000 0000000001 y
junk     0000000003 0000000001 y
alt.test 0000000000 0000000001 y
.

Посылка статьи

Раньше уже упоминалось различие между передачей статьи и ее посылкой. Когда Вы передаете статью, имеется неявное предположение, что статья уже существует, что она имеет идентификатор сообщения, который уникален и назначен сервером, первоначально обработавшем статью. Такая статья имеет полный заголовок. При регистрации (посылке) статья имеет лишь заголовок из заданных Вами полей (тема, группа, в которую направлена и т.п.). Сервер новостей добавит все остальные поля заголовка и создаст message ID для передачи статьи дальше.

Все это означает, что посылка статьи проще, чем передача:

post
340 Ok
From: terry@richard.geek.org.au
Subject: test message number 1
Newsgroups: junk
Body:

This is a test message, please feel free to ignore it.
.

240 Article posted

Сгенерируйте еще парочку сообщений самостоятельно, они нам понадобятся.

Перечень новых статей

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

newnews junk 990101 000000
230 New news follows
<7g2o5r$aa$6@news.vbrew.com>
<7g5bhm$8f$2@news.vbrew.com>
<7g5bk5$8f$3@news.vbrew.com>
.

Выбор группы для дальнейшей работы

Когда пользователь выбирает группу для просмотра, newsreader может сообщить серверу, что некая группа была выбрана. Это упрощает взаимодействие между ними: исчезает потребность постоянно в каждой команде указывать имя группы новостей. Команда group просто берет имя выбранной группы как параметр. Многие команды используют группу, выбранную по умолчанию сервером:

group junk
211 3 1 3 junk

Команда group возвращает сообщение с числом активных сообщений, старшим и младшим номерами и именем группы. Обратите внимание, что хотя в нашем примере число активных сообщений и старший номер статьи совпадают, такое бывает нечасто: некоторые статьи, возможно, устарели и были удалены, понижая число активных сообщений, но оставляя старший номер прежним! Здесь надо проявлять внимание.

Перечень статей в группе

Чтобы адресовать статьи newsreader должен знать, какие числа представляют активные статьи. Команда listgroup предлагает список активных чисел статей в текущей или явно заданной группе, если имя группы указано дополнительным параметром:

listgroup junk
211 Article list follows
1
2
3
.

Получение только заголовка статьи

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

Статьи могут быть определены, используя любой их номер (из вывода команды listgroup) или их message id:

head 2
221 2 <7g5bhm$8f$2@news.vbrew.com> head
Path: news.vbrew.com!not-for-mail
From: terry@richard.geek.org.au
Newsgroups: junk
Subject: test message number 2
Date: 27 Apr 1999 21:51:50 GMT
Organization: The Virtual brewery
Lines: 2
Message-ID: <7g5bhm$8f$2@news.vbrew.com>
NNTP-Posting-Host: localhost
X-Server-Date: 27 Apr 1999 21:51:50 GMT
Body:
Xref: news.vbrew.com junk:2
.

Получение только тела статьи

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

body 2
222 2 <7g5bhm$8f$2@news.vbrew.com> body
This is another test message, please feel free to ignore it too.
.

Чтение статьи из группы

Иногда требуется передавать статьи целиком (заголовок и тело). Часто этим пользуются разные программы кэширования NNTP, например, leafnode.

Естественно, NNTP обеспечивает средства для выполнения этого, которые работают почти аналогично команде head. Команда article принимает номер статьи или message ID как параметр, но возвращает статью целиком с заголовком:

article 1
220 1 <7g2o5r$aa$6@news.vbrew.com> article
Path: news.vbrew.com!not-for-mail
From: terry@richard.geek.org.au
Newsgroups: junk
Subject: test message number 1
Date: 26 Apr 1999 22:08:59 GMT
Organization: The Virtual brewery
Lines: 2
Message-ID: <7g2o5r$aa$6@news.vbrew.com>
NNTP-Posting-Host: localhost
X-Server-Date: 26 Apr 1999 22:08:59 GMT
Body:
Xref: news.vbrew.com junk:1

This is a test message, please feel free to ignore it.
.

Если Вы пытаетесь получить неизвестную статью, сервер вернет сообщение об ошибке с соответствующим кодом ответа, а иногда и текстовым комментарием:

article 4
423 Bad article number

Здесь я рассмотрел, как используются наиболее важные команды NNTP. Если Вы заинтересовались разработкой программного обеспечения, которое осуществляет работу по протоколу NNTP, обратитесь к соответствующим документам RFC: они предоставят много технических подробностей

Назад | Глобальное оглавление | Вперед
Средства и задачи администрирования |  | Установка сервера NNTP


Installing the NNTP Server

Назад Глава 22. NNTP и nntpd Daemon Вперед

Установка сервера NNTP

NNTP сервер (nntpd) может компилироваться двумя способами, в зависимости от ожидаемой загрузки на системе новостей. Не имеется никаких откомпилированных версий, из-за некоторых машинно-специфических значений по умолчанию, которые являются жестко закодированными в выполнимую программу. Вся конфигурация выполнена через макросы в common/conf.h.

nntpd может быть сконфигурирован как автономный сервер, который запускается при начальной загрузке системы из rc или как daemon, управляемый inetd. В последнем случае Вы должны иметь следующую запись в /etc/inetd.conf:
nntp    stream  tcp nowait      news    /usr/etc/in.nntpd    nntpd

Формат inetd.conf описан в главе 12. Если Вы конфигурируете nntpd как автономный сервер, удостоверьтеь, что любая такая строка в inetd.conf закомментирована. В любом случае Вы должны удостовериться, что имеется следующая строка в /etc/services:
nntp    119/tcp   readnews untp    # Network News Transfer Protocol

Чтобы временно сохранять любые входящие статьи, nntpd также нуждается в каталоге .tmp в spool-каталоге новостей. Вы должны создать его используя команды:
# mkdir /var/spool/news/.tmp
# chown news.news /var/spool/news/.tmp

Назад | Глобальное оглавление | Вперед
NNTP и nntpd Daemon | Локальное оглавление | Ограничение доступа к NNTP


Choosing the Right Maps

Назад Глава 13. Network Information System (NIS) Вперед

Выбор нужных карт

После проверки достижимости сервера NIS Вы должны решить, какие файлы конфигурации заменять или расширять с помощью карт NIS. Обычно Вы будете использовать карты NIS для поиска хоста и пароля. Это особенно полезно, если Вы не имеете сервиса имен BIND. Поисковая таблица пароля позволяет всем пользователям на машине в домене NIS работать на любой машине в нем. Это обычно применяется наряду с совместным использованием центрального каталога /home через NFS. Карта паролей будет рассмотрена в следующем разделе.

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

Вообще, надо иметь выбор, когда функция поиска использует локальные файлы, когда она делает запрос к серверу NIS станции, и в каких случаях используются другие серверы, типа DNS. GNU libc позволяет Вам конфигурировать порядок, в котором функция обращается к этим услугам. Это управляется через файл /etc/nsswitch.conf (сокращение от Name Service Switch), но он, конечно, не ограничен обслуживанием имен. Для любой из функций поисковой таблицы данных, поддерживаемых GNU libc, файл содержит соответствующую строку.

Порядок опроса зависит от типа данных, которые предлагает каждый сервис. Маловероятно, что карта services.byname будет содержать записи, отличающиеся от своих аналогов в локальном файле services. Она будет содержать только дополнительные записи. Так что проще сначала сделать запрос локальных файлов и проверять NIS только, если сервисное имя не найдено. С другой стороны, информация об именах машин может изменяться очень часто, так что сервер DNS или NIS должен всегда иметь наиболее точные данные в то время, как локальный файл hosts сохраняется только как копия на случай, если DNS и NIS не сработали. Следовательно, для hostname обычно надо проверять локальный файл данных в последнюю очередь.

Следующий пример показывает, как вынудить функции gethostbyname и gethostbyaddr искать в NIS и DNS до просмотра файла hosts и как заставить функцию getservbyname просматривать локальные файлы перед запросом к NIS. Эти функции опробуют каждый из перечисленных сервисов. Если поиск прошел успешно, возвращается результат, иначе выбирается следующий сервис. Установка файла для этих приоритетов:

# small sample /etc/nsswitch.conf
#
hosts:     nis dns files
services:  files nis

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

nis

Использовать текущий сервер NIS домена. Его расположение задается в yp.conf, как показано в предыдущем разделе. Для записи hosts запрашиваются карты hosts.byname и hosts.byaddr.

nisplus или nis+

Использовать для этого домена сервер NIS+. Где его искать берется из файла /etc/nis.conf.

dns

Использовать сервер имен DNS. Этот сервисный тип полезен только с записью hosts. Сервер, который будет запрошен, задается в resolv.conf.

files

Использовать локальный файл (например, /etc/hosts для запроса hosts).

compat

Нужна совместимость со старыми форматами файлов. Эта опция может использоваться, когда NYS или glibc 2.x используются для поиска в NIS или NIS+. В то время, как эти версии обычно не могут интерпретировать старые записи NIS в файлах passwd и group, опция compat позволяет им работать с этими форматами.

db

Информация берется из файлов DBM, размещенных в каталоге /var/db. Соответствующее имя карты NIS используется для этого файла.

В настоящее время реализация NIS в GNU libc поддерживает следующие базы данных для nsswitch.conf: aliases, ethers.group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services и shadow.

Пример 13-2 показывает более полный пример, который представляет новое свойство nsswitch.conf. Ключевое слово [NOTFOUND=return] в записи hosts предписывает клиенту NIS вернуться, если нужный элемент не может быть найден в базе данных NIS или DNS.

Пример 13-2. Образец файла nsswitch.conf

# /etc/nsswitch.conf
#
hosts:      nis dns [NOTFOUND=return] files
networks:   nis [NOTFOUND=return] files
services:   files nis
protocols:  files nis
rpc:        files nis

GNU libc обеспечивает некоторые другие действия, которые описаны на man-странице nsswitch.

Назад | Глобальное оглавление | Вперед
Установка клиента NIS с GNU libc | Локальное оглавление | Использование карт passwd и group


SLIP Operation

Назад Глава 7. Serial Line IP Вперед

Действия со SLIP

Серверы Dialup IP часто предлагают сервис SLIP через специального пользователя. После регистрации под именем такого пользователя Вы не входите в общую оболочку: взамен используется SLIP-драйвер серверов последовательной линии и настраивается соответствующий сетевой интерфейс.

В некоторых операционных системах драйвер SLIP является программой уровня пользователя. Но под Linux это часть ядра, которая делает связь намного быстрее. Требуется, чтобы последовательная линия явно была преобразована в SLIP-режим. Это выполнено посредством tty line discipline SLIPDISC. Пока tty находится в обычной line discipline (DISC0), она обменивается данными только с процессами уровня пользователя, применяя вызовы read(2) и write(2), SLIP-драйвер в это время отключен для записи или чтения из tty. В SLIPDISC все наоборот: все данные, поступающие на последовательный порт, будут пропущены через SLIP-драйвер в обход программ уровня пользователя.

SLIP-драйвер непосредственно понимает несколько разновидностей протокола SLIP. Кроме обычного SLIP, он также понимает CSLIP, который выполняет так называемое Van Jacobson header compression (сжатие заголовков) на исходящих IP-пакетах (подробно описано в RFC-1144). Дополнительно имеются шестибитовые версии для каждого из протоколов.

Простой способ преобразовать последовательную линию в SLIP-режим, это использовать команду slattach. Допустим, что у Вас есть модем на /dev/ttyS3, и Вы удачно подсоеденились к SLIP-серверу. Затем Вы выполните:
# slattach /dev/ttyS3 &

Это включит line discipline SLIPDISC для порта ttyS3 и подсоединит ее к одному из интерфейсов SLIP-сети. Если это Ваша первая активная SLIP-связь, то линия будет подсоединена к sl0, вторая была бы подсоединена к sl1 и так далее. Текущие ядра поддерживают до 256 одновременных SLIP-связей.

Заданное по умолчанию оформление пакета, выбранное slattach, CSLIP. Вы можете выбрать любой другой режим, используя опцию -p. Для того, чтобы использовать нормальный SLIP (без сжатия), Вы должны использовать:
# slattach -p slip /dev/ttyS3 &

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

Таблица 7-1. Режимы Linux Slip

Режим | Описание
slip | Обычный SLIP.
cslip | Сжатый SLIP (Van Jacobsen header compression).
slip6 | SLIP с шестибитным кодированием. Метод кодирования похож на применяемый программой uuencode и переводит пакеты SLIP в печатаемые символы ASCII. Удобно, если линия не способна передавать восемь бит.
cslip6 | Сжатый SLIP (Van Jacobsen header compression) с шестибитным кодированием.
adaptive | Выясняет параметры удаленной машины и устанавливает у себя такие же.

Заметьте, что Вы обязаны использовать такое же оформление, какое имеет удаленная машина. Например, если сервер cowslip использует CSLIP, Вы должны использовать его же. Симптомы рассогласования будут такие, что связь просто не работает. Один способ избежать этой неприятности: использовать adaptive SLIP.

Фактически, slattach позволяет Вам включить не только SLIP, но и другие протоколы, которые используют последовательную линию, как PPP или KISS (другой протокол, используемый в ham radio). Подробно это рассмотрено на man-странице slattach(8).

После передачи линии SLIP драйверу, Вы должны сконфигурировать сетевой интерфейс. Снова используются команды ifconfig и route. Предположим, что с машины vlager Вы соединились с сервером cowslip. Тогда Вы должны выполнить:
# ifconfig sl0 vlager-slip pointopoint cowslip
# route add cowslip
# route add default gw cowslip

Первая команда конфигурирует интерфейс как связь point-to-point с cowslip, в то время как вторая и третья команды добавляют маршрут к cowslip и задают маршрут по умолчанию, используемый cowslip как шлюз.

Два замечания относительно ifconfig: опция pointopoint, которая определяет адрес удаленной машины в соединении типа point-to-point, и использование vlager-slip как адреса локального SLIP-интерфейса.

Я упомянул, что Вы можете использовать тот же самый адрес, который назначили интерфейсу Ethernet машины vlager и для связи по SLIP. В этом случае, vlager-slip может быть псевдонимом для адреса 172.16.1.1. Однако, также возможно, что Вы должны использовать совсем другой адрес для SLIP. Один такой случай: Ваша сеть использует незарегистрированный сетевой IP адрес (для частных сетей), как Brewery. Это будет подробно рассмотрено чуть позже, а пока будем всегда использовать vlager-slip, чтобы обратиться к адресу локального интерфейса SLIP.

При завершении SLIP-связи Вы сначала должны удалить все маршруты cowslip, используя route c опцией del, убрать интерфейс и передать slattach сигнал hangup:
# route del default
# route del cowslip
# ifconfig sl0 down
# kill -HUP 516
Здесь 516 надо заменить на process id (находится в списке, выводимом командой ps ax) процесса slattach.

Назад | Глобальное | Вперед
Serial Line IP | Локальное оглавление | Работа с внутренними IP-сетями


Original IP Firewall (2.0 Kernels)

Назад Глава 9. TCP/IP Firewall Вперед

IP Firewall (ядра 2.0)

Первое поколение IP firewall для Linux появилось в ядре 1.1. Это была версия BSD ipfw firewall для Linux (автор Alan Cox). Поддержка firewall второго поколения появилась в ядрах 2.0 (авторы Jos Vos, Pauline Middelink и другие) и с этого момента стало возможным реально работать с firewall в Linux.

Использование ipfwadm

Команда ipfwadm представляет собой инструмент конфигурации для второго поколения Linux IP firewall. Возможно, самый простой способ описывать использование команды ipfwadm это примеры. Начнем с примера сети.

Пример сети

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

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

Предположим, что наша сеть имеет 24-битную сетевую маску (класс C) и ее сетевой адрес 172.16.1.0. Правила будут такими:
# ipfwadm -F -f
# ipfwadm -F -p deny
# ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80
# ipfwadm -F -a accept -P tcp -S 0/0 80 -D 172.16.1.0/24

Параметр -F инструктирует ipfwadm, что мы определяем правило пересылки пакетов (forwarding). Первая команда предписывает ipfwadm очистить все правила. Это гарантирует, что мы работаем с известным состоянием, и после добавления правил не окажется, что остались еще какие-то неизвестные нам правила.

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

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

Давайте расмотрим все параметры:

-F

Определяет правило пересылки (Forwarding).

-a accept

Добавляет правило со стратегией "accept", позволяющей принимать все пакеты, соответствующие этому правилу.

-P tcp

Правило применимо к TCP-пакетам (не трогает пакеты UDP или ICMP).

-S 172.16.1.0/24

Исходящий адрес должен иметь маску подсети в 24 бита и адрес сети 172.16.1.0.

-D 0/0 80

Адрес назначения должен иметь нулевые биты (0.0.0.0). Это соответствует любому адресу. Число 80 определяет порт назначения, в этом случае WWW. Вы можете также использовать любую запись из файла /etc/servicesдля определения порта, например, -D 0/0 www.

ipfwadm принимает сетевые маски в форме, с которой Вы можете быть незнакомы. Запись /nn обозначает сколько бит адреса значительны или размер маски. Биты всегда считаются слева направо. Ряд примеров перечислен в таблице 9-1.

Таблица 9-1. Распространенные значения бит сетевой маски

Сетевая маска | Биты
255.0.0.0 | 8
255.255.0.0 | 16
255.255.255.0 | 24
255.255.255.128 | 25
255.255.255.192 | 26
255.255.255.224 | 27
255.255.255.240 | 28
255.255.255.248 | 29
255.255.255.252 | 30

ipfwadm имеет одну полезную возможность, которая упрощает создание правил. Это опция -b, которая создает двунаправленное правило. Эта опция позволяет сворачивать команды для двух правил в одну:
# ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

Рассмотрим внимательно набор правил

Итак, посмотрим на наш набор правил. Видите ли вы, что в нем есть дыра, через которую все еще можно атаковать систему?

Наш набор правил позволяет проходить в нашу сеть всем пакетам с исходным портом 80. Это будет включать и пакеты с установленным битом SYN! Бит SYN объявляет TCP-пакет запросом подключения. Если человек снаружи имел привилегированный доступ к компьютеру, он может сделать подключение через наш firewall на любой из наших компьютеров, если он использует порт 80 на своей стороне. Вот и дырка...

К счастью, проблема решаема. Команда ipfwadm имеет параметр, который позволяет формировать правила, которые будут соответствовать пакетам с битом SYN. Давайте изменим наш пример, чтобы включить такое правило:
# ipfwadm -F -a deny -P tcp -S 0/0 80 -D 172.16.10.0/24 -y
# ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

Опция -y заставляет правило соответствовать только, если в пакете установлен бит SYN. Так что наше новое правило предписывает отвергать любые внешние пакеты с порта 80 с установленным битом SYN.

Почему мы поместили это специальное правило перед основным правилом? IP firewall функционируют так, что используется первое соответствие. Оба правила соответствуют пакетам, которые мы хотим остановить, так что мы должны убедиться, что поместили отвергающее ( deny) правило перед пропускающим (accept).

Просмотр наших правил

После ввода правил можно попросить ipfwadm их показать в виде списка:
# ipfwadm -F -l
Эта команда внесет в список все конфигурированные правила пересылки. Вывод будет примерно таким:
# ipfwadm -F -l
IP firewall forward rules, default policy: accept
type  prot source               destination          ports
deny  tcp  anywhere             172.16.10.0/24       www -> any
acc   tcp  172.16.1.0/24        anywhere             any -> www
Команда ipfwadm будет пытаться транслировать номер порта в сервисное имя, использующее /etc/services, если там есть такая запись.

Заданный по умолчанию вывод не включает одну важную деталь: он не показывает действие параметра -y. Команда ipfwadm способна произвести более детализированный вывод, если Вы определяете параметр -e (расширенный вывод). Он включает в себя столбец opt (опции), в котором будет показан параметр -y для пакетов SYN:

# ipfwadm -F -l -e
P firewall forward rules, default policy: accept
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress   source        ...
    0     0 deny  tcp  --y- 0xFF 0x00 any     any         anywhere      ...
    0     0 acc   tcp  b--- 0xFF 0x00 any     any         172.16.1.0/24 ...

Более сложный пример

Предыдущий пример был самым простым. Не все сетевые услуги так просты, как WWW. Давайте добавим сюда сервис посложнее: FTP. Мы хотим, чтобы наши внутренние сетевые пользователи были способны работать с серверами FTP в сети Internet: заходить на них, принимать и передавать файлы. Но мы не хотим, чтобы все желающие из Internet работали с нашими FTP-серверами.

FTP интересен тем, что он использует два TCP-порта: 20 (данные) и 21 (команды):
# ipfwadm -a deny -P tcp -S 0/0 20 -D 172.16.1.0/24 -y
# ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 20 -b
# ipfwadm -a deny -P tcp -S 0/0 21 -D 172.16.1.0/24 -y
# ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 21 -b
Правильно? Не совсем. FTP-сервера могут функционировать в двух различных режимах: пассивный режим и активный режим. В пассивном режиме FTP-сервер ждет подключения от пользователя. В активном режиме сервер фактически делает подключение к пользователю. Активный режим обычно задан по умолчанию.

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

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

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

Обзор параметров ipfwadm

Команда ipfwadm имеет много параметров. В общем виде синтаксис таков:
ipfwadm category command parameters [options]

Категории (Categories)

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

-I

Правило ввода (Input)

-O

Правило вывода (Output)

-F

Правило пересылки (Forwarding)

Команды

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

-a [policy]

Добавить правило

-i [policy]

Вставить правило

-d [policy]

Удалить правило

-p policy

Установить заданную по умолчанию стратегию

-l

Показать все существующие правила

-f

Стереть все существующие правила

Стратегии представляют собой следующее:

accept

Пропускать все пакеты для приема, передачи или транзитные (forward)

deny

Блокировать все пакеты для приема, передачи или транзитные (forward)

reject

Блокировать все пакеты для приема, передачи или транзитные (forward) и послать компьютеру, который послал пакет ICMP-сообщение об ошибке

Параметры

Они определяют, к каким пакетам применяется правило:

-P protocol

TCP, UDP, ICMP или все. Например:

-P tcp

-S address[/mask] [port]

Исходный IP-адрес пакета. Если сетевая маска не задана, она принимается как “/32”. Можно дополнительно задать порты, к которым относится данное правило. Необходимо также задать протокол, используя параметр -P. Если порт или несколько портов не заданы, предполагаются все. Порты могут быть заданы именами, используя файл /etc/services. В случае протокола ICMP поле порта используется, чтобы задавать типы пакетов ICMP. Несколько портов описываются так: lowport:highport. Например:

-S 172.29.16.1/24 ftp:ftp-data

-D address[/mask] [port]

Указывает IP-адрес назначения. Во всем остальном аналогичен предыдущему параметру. Например:

-D 172.29.16.1/24 smtp

-V address

Указывает адрес сетевого интерфейса, на котором пакет получен (-I) или послан (-O). Это позволяет Вам создавать правила, которые применяются только к некоторым сетевым интерфейсам на Вашей машине. Например:

-V 172.29.16.1

-W name

Задает имя сетевого интерфейса. Этот параметр работает таким же образом, как параметр -V, но задавать нужно имя устройства вместо адреса. Например:

-W ppp0

Необязательные параметры

Эти параметры иногда бывают очень полезны:

-b

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

-o

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

-y

Используется, чтобы соответствовать TCP-пакетам запроса подключения. Этому правилу будут соответствовать только TCP-пакеты с установленным битом SYN и неустановленным битом ACK.

-k

Используется, чтобы соответствовать TCP-пакетам подтверждения попытки подключения. Этому правилу будут соответствовать только TCP-пакеты с установленным битом ACK.

Типы пакетов ICMP

Каждая из команд конфигурации firewall позволяет Вам определять типы пакетов ICMP. В отличие от портов TCP и UDP, не имеется никакого удобного файла конфигурации, который перечисляет типы пакетов и их значения. Типы пакетов ICMP определены в RFC-1700 (Assigned Numbers RFC). Они также перечислены в одном из стандартных библиотечных файлов C. Файл /usr/include/netinet/ip_icmp.h, который принадлежит обычной библиотеке GNU и используется C-программистами при написании сетевого программного обеспечения, работающего с протоколом ICMP, также определяет типы пакетов ICMP. Для Вашего удобства я привожу их в таблице 9-2. Интерфейс команды iptables позволяет Вам определять типы ICMP по их именам, так что я укажу и эти имена. Позже они пригодятся.

Таблица 9-2. Типы пакетов ICMP

Номер типа | Обозначение iptables | Описание
0 | echo-reply | Echo Reply
3 | destination-unreachable | Destination Unreachable
4 | source-quench | Source Quench
5 | redirect | Redirect
8 | echo-request | Echo Request
11 | time-exceeded | Time Exceeded
12 | parameter-problem | Parameter Problem
13 | timestamp-request | Timestamp Request
14 | timestamp-reply | Timestamp Reply
15 | none | Information Request
16 | none | Information Reply
17 | address-mask-request | Address Mask Request
18 | address-mask-reply | Address Mask Reply
Назад | Глобальное оглавление | Вперед
Три способа фильтрации | Локальное оглавление | IP Firewall Chains (2.2 Kernels)


Other Network Types

Назад Глава 3. Настройка сетевого оборудования Вперед

Другие типы сетей

Большинство других типов сетей настраиваются аналогично Ethernet. Параметры, переданные загружаемым модулям, будут другими, и некоторые драйверы не могут поддерживать больше одной платы, но все остальное примерно так же. Документация для этих плат доступна в подкаталоге /usr/src/linux/Documentation/networking исходных текстов ядра Linux.

Назад | Глобальное оглавление | Вперед
Драйверы PPP и SLIP | Локальное оглавление | Настройка последовательного оборудования


Overview

Назад Preface Вперед

Обзор

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

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

Глава 5 поможет Вам настроить машину для работы с сетями TCP/IP. Она описывает настройку для автономных компьютеров только с кольцевым интерфейсом loopback и для машин с подключением к Ethernet. Здесь также рассказано о ряде полезных инструментов для проверки настроек.

Глава 6 описывает конфигурацию сервера имен.

Глава 7 объясняет, как установить подключения SLIP и дает детальное описание программы dip, инструмента, который позволяет Вам автоматизировать большинство необходимых шагов.

Глава 8 охватывает протокол PPP и программу pppd, PPP daemon.

Глава 9 продолжает обсуждение сетевой защиты и описывает Linux TCP/IP firewall и инструментальные средства конфигурации: ipfwadm, ipchains и iptables. IP firewall обеспечивает возможность очень точно управлять тем, кто может обращаться к Вашей сети и ее компьютерам.

Глава 10 объясняет, как конфигурировать средство IP Accounting в Linux, так что Вы можете следить, сколько трафика проходит, а также какого именно, куда и откуда.

Глава 11 описывает свойство программного обеспечения работы с сетями в Linux под названием IP masquerade, которое позволяет целой IP-СЕТИ работать с Internet через ОДИН IP-адрес.

Глава 12 дает краткое введение в установку некоторых наиболее важных сетевых прикладных программ, типа rlogin, ssh и им подобных. Эта глава также рассказывает как сервисы управляются суперсервером inetd, и о том как Вы можете ограничить доступ к некоторым сервисам набором доверенных компьютеров.

Глава 13 и глава 14, рассматривают NIS и NFS. NIS используется для распространения административной информации (например, паролей в локальной сети). NFS позволяет нескольким машинам совместно использовать одну файловую систему.

В главе 15 рассмотрены протокол IPX и файловая система NCP. Это позволяет интегрировать Linux в сети Novell NetWare, разделять файлы и принтеры с не-Linux машинами.

Глава 16 посвящена администрированию пакета Taylor UUCP, свободной реализации UUCP.

Глава 17 представляет собой введение в концепцию электронной почты и показывает, как почта доходит до адресата.

Глава 18 и глава 19, рассматривают настройку почтовых серверов sendmail и exim соответственно. Сервер exim проще в установке, но не имеет ряда возможностей sendmail, например, поддержки UUCP.

Глава 20 и по главу 23, рассматривают новости Usenet, как поставить и использовать пакеты C News, nntpd и INN: три популярных средства для работы с Usenet. В главе 20 дается обзор. Затем в главе 21 обсуждается использование C News, сервиса с поддержкой UUCP. Следующие главы обсуждают современные альтернативы C News, которые используют Internet-протокол NNTP (Network News Transfer Protocol, протокол передачи сетевых новостей). Глава 22 как раз и рассматривает простой демон NNTP, nntpd. Глава 23 описывает более серьезный вариант: InterNet News daemon (INN).

В заключение глава 24 расскажет, как настроить разные программы чтения новостей (newsreaders).

Назад | Глобальное оглавление | Вперед
The Official Printed Version | Локальное оглавление | Соглашения, принятые в книге


Passive Collection of Accounting Data

Назад Глава 10. IP Accounting Вперед

Пассивные коллекции данных доступа

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

Вы должны сначала направить IP forwarding на Вашей Linux-машине так, чтобы она не пробовала маршрутизировать пакеты, которые получает, иначе повесите всю сеть. В ядрах 2.0.36 и 2.2 это делается так:
# echo 0 >/proc/sys/net/ipv4/ip_forward

Вы должны включить режим promiscuous на интерфейсе Ethernet командой ifconfig. Теперь Вы можете устанавливать правила учета, которые позволят собирать информацию относительно движения пакетов в локальной сети без включения Вашей Linux-машины в маршрут вообще. Заметьте, что это не следует делать, если Ваша Linux-машина служит как маршрутизатор. Если Вы отключаете IP forwarding, она перестанет работать как маршрутизатор! Делайте это только на машине с одним физическим сетевым интерфейсом.

Назад | Глобальное оглавление | Вперед
Очистка правил | Локальное оглавление | IP Masquerade и Network Address Translation


Using the passwd and group Maps

Назад Глава 13. Network Information System (NIS) Вперед

Использование карт passwd и group

Одна из главных прикладных программ NIS синхронизирует данные пользователя на всех машинах в домене NIS. Следовательно, Вы обычно храните только маленький локальный файл /etc/passwd, к которому добавляется информация из карт NIS. Однако, просто поиска NIS для этого сервиса в nsswitch.conf мало.

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

Если любой из числовых идентификаторов в /etc/passwd или /etc/group отличается от своего значения в картах, надо исправлять ситуацию с правами доступа. Сначала Вы должны изменить все uid и gid в файлах passwd и group на новые значения, затем поменять владельцев у объектов, принадлежащих пользователям, идентификаторы которых Вы сменили. Допустим, news имеет идентификатор 9, а okir имел идентификатор (user ID) 103, но теперь он сменился на что-то другое. Скомандуйте от имени root:
# 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, и собрать все имена файлов перед сменой их владельца. Чтобы модифицировать группу владельца, используйте подобный метод с gid вместо uid и chgrp вместо chown.

Теперь числовые идентификаторы на Вашей машине приведены в соответствие с остальной сетью. Следующим шагом надо добавить строки в nsswitch.conf, которые поиск через NIS данных о пользователе и группе:
# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group: nis files

Это воздействует на команду login и все остальные, которые собирают данные о пользователе. Когда пользователь пробует войти, login сначала запрашивает карту NIS, и в случае провала идет обратно к локальным файлам. Обычно Вы удаляете почти всех пользователей из локальных файлов и оставляете входы только для root и универсальные логины, подобно mail. Это потому, что некоторым жизненным задачам системы, вероятно, придется отображать uid к именам. Например, административные работы cron могут выполнить команду su, чтобы временно стать пользователем news, или подсистема UUCP может послать отчет о состоянии. Если news и uucp не имеют записей в локальном файле passwd, эти работы будут терпеть неудачу.

Наконец, если Вы используете любую старую реализацию NIS (поддерживаются режимом compat для файлов passwd и group в реализациях NYS или glibc), Вы должны вставить специальные записи. Они представляют, где полученные записи NIS будут вставлены в базу данных информации. Они могут добавляться в любом месте, но обычно добавляются только к концу. Записи для добавления к файлу /etc/passwd:
+::::::
и для добавления к файлу /etc/groups:
+:::

В glibc 2.x и NYS Вы можете отменять параметры в пользовательских записях, полученных от сервера NIS созданием записей со знаком "+" перед именем пользователя и исключать указанных пользователей добавлением перед их именами знака "-". Например, записи:
+stuart::::::/bin/jacl
-jedd::::::
переопределят оболочку для пользователя stuart, заданную сервером, и запретят пользователю jedd регистрацию на данной машине вообще. Пустые поля используют информацию с сервера NIS.

Еть две проблемы. Во-первых, приведенная здесь настройка не использует затенение паролей, а стоило бы. Сложность использования теневых паролей с NIS обсуждается ниже. Во-вторых, команда login не единственная, которой нужен файл passwd: есть часто используемая команда ls. При построении широкого вывода она отображает имена владельца файла и его группы. Значит, для каждого uid и gid будет послан запрос на сервер NIS. Это снижает производительность.

Но представим, что пользователь решил сменить пароль. Обычно он вызывает команду passwd, которая читает новый пароль и обновляет локальный файл passwd. Это невозможно с NIS, так как этот файл больше не доступен локально. NIS обеспечивает замену passwd по имени yppasswd, которая обрабатывает смену пароля через NIS. Для изменения пароля на сервере эта утилита связывается с yppasswdd daemon на сервере по RPC и передает ему требуемую информацию. Обычно Вы устанавливаете yppasswd вместо нормальной программы:
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd

В то же самое время, Вы должны установить rpc.yppasswdd на сервере и запускать его из скрипта для инициализации сети.

Назад | Глобальное оглавление | Вперед
Выбор правильных карт | Локальное оглавление | NIS и затенение паролей


Controlling Access to UUCP Features

Назад Глава 16. Управление Taylor UUCP Вперед

Контроль доступа к возможностям UUCP

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

Выполнение команд

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

По умолчанию Taylor UUCP разрешает выполнять на Вашей машине лишь rmail и rnews, которые обычно используются для e-mail и Usent новостей по UUCP. Заданный по умолчанию путь поиска, используемый uuxqt, настраивается во времея компиляции, но обычно содержит /bin, /usr/bin, и /usr/local/bin. Чтобы изменять набор команд для определенной системы, Вы можете использовать ключевое слово commands в файле sys. Аналогично, путь поиска может быть изменен указанием ключевого слова command-path. Например, Вы можете разрешить системе pablo выполнять команду bsmtp в дополнение к rmail и rnews:
system          pablo
...
commands        rmail rnews bsmtp

Передача файлов

Taylor UUCP также позволяет описывать передачу файлов в подробностях. Вы можете запретить любой обмен с определенной системой. Только установите request в no, и удаленная система не сможет ни искать, ни читать, ни посылать Вашей никаких файлов вообще. Аналогично Вы можете запретить пользователям Вашей системы пересылку файлов в систему или из нее, установив transfer в no. По умолчанию любая пересылка им разрешается.

Кроме того, Вы можете конфигурировать каталоги, из которых файлы могут быть скопированы. Обычно запрещают доступ с удаленных систем к определенным каталогам, но разрешают своим пользователям посылать файлы со своего исходного каталога. Обычно удаленным пользователям разрешается получить файлы только из общего каталога UUCP /var/spool/uucppublic. Это традиционное место, в котором хранятся публично доступные файлы. Очень похоже на FTP-сервис.

Taylor UUCP обеспечивает четыре различные команды конфигурирования каталогов для посылки и получения файлов: local-send определяет список каталогов, из которых пользователь может запросить файлы. local-receive задает список каталогов, в которые пользователь может просить UUCP записать файлы. remote-send и remote-receive, которые определяют то же самое для запросов в другую систему. Рассмотрим следующий пример:
system          pablo
...
local-send      /home
local-receive   /home /receive
remote-send      !/incoming !/receive
remote-receive  /incoming

Команда local-send разрешает пользователям Вашего компьютера посылать любые файлы ниже /home и из общего каталога UUCP на систему pablo. Команда local-receive разрешает им получать файлы или в общедеступный каталог receive в uucppublic, или в любой общедоступный каталог ниже /home. Команда remote-send разрешает pablo запрашивать файлы из /var/spool/uucppublic или из любого общедоступного его подкаталога, кроме подкаталогов incoming и receive. Это сообщается uucico восклицательным знаком, поставленным перед именем каталога. Последняя строка разрешает pablo записать любые файлы в каталог incoming.

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

Пересылка (Forwarding)

UUCP обеспечивает механизм, благодаря которому другие системы могут выполнять передачу файлов от Вашего имени. Например, Ваша система имеет доступ через uucp к системе seci, но не имеет доступа к uchile. Тогда пусть seci получит для Вас файлы с uchile и перешлет Вам. Следующая команда именно это и делает:
$ uucp -r seci!uchile!/find-ls.gz /uchile.files.gz

Эта методика прохождения работы через несколько систем называется пересылкой (forwarding). В вышеупомянутом примере причиной для использования пересылки могло быть то, что 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 посылать файлы только pablo через seci: любой другой путь недопустим.

Чтобы разрешить пересылку любой системе, используйте специальное ключевое слово ANY (обязательно заглавные буквы).

Назад | Глобальное оглавление | Вперед
Файлы настройки UUCP | Локальное оглавление | Настройка системы для приема входящих звонков (Dial In)


The PLIP Driver

Назад Глава 3. Настройка сетевого оборудования Вперед

Драйвер PLIP

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

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

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

РLIP поддерживало много людей. В настоящее время его поддерживает Niibe Yutaka. Если PLIP компилируется в ядро, он устанавливает сетевой интерфейс для каждого из возможных портов принтера, plip0 соответствует параллельному порту lp0, plip1 связан с lp1 и т.д.. В настоящее время интерфейсы отображаются на порты следующим образом (способ отображения в ядрах 2.0 отличается от ядер 2.2 и задан в файле drivers/net/Spacd.c исходного текста ядра):

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

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

В ядрах 2.2 PLIP-драйвер использует драйвер совместного использования параллельного порта parport, разработанный Philip Blundell. Новый драйвер распределяет сетевые имена устройств PLIP последовательно, точно как для Ethernet или PPP, так что первое созданное PLIP устройство plip0, второе plip1 и т.д. Физические аппаратные средства параллельного порта также будут распределены последовательно. По умолчанию драйвер параллельного порта будет пытаться обнаруживать аппаратные средства параллельного порта программой autoprobe, делая запись физической информации устройств в найденном порядке. Но лучше явно сообщить ядру физические параметры. Вы можете делать это с помощью параметров при загрузке модуля parport_pc.o, или если Вы скомпилировали драйвер в ядро, используя lilo, чтобы передать параметры ядру при начальной загрузке. Установка IRQ любого устройства может быть изменена позже записью нового значения IRQ в связанный файл /proc/parport/*/irq.

Конфигурирование физических параметров I/O в ядре 2.2 при загрузке модуля простое. Например, чтобы сообщить драйверу, что Вы имеете два параллельных порта PC-style с адресами I/O 0x278 и 0c378 с IRQ 5 и 7, соответственно, Вы загрузили бы модуль со следующими параметрами:
modprobe parport_pc io=0x278,0x378 irq=5,7
Соответствующие параметры для передачи ядру в случае скомпилированного непосредственно в него драйвера:
parport=0x278,5 parport=0x378,7
Здесь Вы использовали бы lilo с ключевым словом append, чтобы передать эти параметры ядру автоматически при начальной загрузке.

Когда PLIP драйвер инициализирован, каждый из параллельных портов будет иметь связанное с ним сетевое устройство plip. Устройство plip0 будет назначено первому устройству параллельного порта, plip1 второму и т.д. Вы можете вручную отменять это автоматическое назначение, используя другой набор ядерных параметров. Например, чтобы назначить parport0 на сетевое устройство plip0 и parport1 на plip1, задайте ядерные параметры:
plip=parport1 plip=parport0

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

Назад | Глобальное оглавление | Вперед
Установка Ethernet | Локальное оглавление | Драйверы PPP и SLIP


The Point-to-Point Protocol

Назад Вперед

Глава 8. Протокол Point-to-Point

Локальное оглавление
PPP и Linux
Запуск pppd
Использование файлов Options
Использование скрипта для автоматического дозвона
Опции настройки IP (IPCP)
Опции управления связью
Основы безопасности
Авторизация и PPP
Отладка Ваших настроек PPP
Тонкая настройка PPP

Точно так же, как SLIP, PPP протокол нужен для того, чтобы посылать пакеты через последовательную связь. Он позволяет сообщающимся сторонам обсудить опции такие, как IP-адрес, максимальный размер пакета во время запуска и обеспечивает авторизацию клиента. Для каждой из этих возможностей PPP имеет отдельный протокол. Ниже мы кратко рассмотрим эти базисные стандартные блоки PPP. Это обсуждение далеко не полно, и если Вы хотите выяснить что-либо еще относительно PPP, то я настоятельно рекомендую Вам прочитать спецификацию в RFC 1548 также, как и dozen или companion RFC. Кроме того, в O'Reilly издана хорошая книга "Using & Managing PPP" (автор Andrew Sun).

В самой основе PPP лежит управление передачей данных высокого уровня, сокращенно HDLC (High-Level Data Link Control), которое определяет границы структур PPP и обеспечивает 16 разрядов контрольной суммы. В противоположность более примитивному оформлению SLIP-пакета, PPP способен к захвату блоков из других протоколов таких, как IP, IPX Novell или 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-пакет, оба PPP-абонента должны сначала обсудить, какой из IP-адресов каждый из них использует. Протокол управления, используемый для этого, Internet Protocol Control Protocol (IPCP).

Помимо посылки IP-пакетов PPP также поддерживает Van Jacobson header compression IP-пакетов. Это метод для того, чтобы сократить заголовки TCP-блоков всего до трех байтов. Это также используется в CSLIP и относится к VJ header compression. Использование сжатия может быть задано во время запуска через IPCP.

PPP и Linux

В Linux функциональные возможности PPP разделены на две части: драйвер low-level HDLC (HDLC, IPCP, IPXCP,...), который размещен в ядре, и пользовательский демон pppd, обрабатывающий различные протоколы управления. Текущая версия PPP для Linux содержит ядро PPP-модуля, pppd и программу chat, которая используется для того, чтобы выполнить удаленную связь.

PPP kernel-драйвер был написан Michael Callahan. Демон pppd был выведен из реализации PPP для Sun и 386BSD, которая была написана Drew Perkins и другими, и сейчас поддерживается Paul Mackerras. Он был портирован в Linux Al Longyear. Программа chat была написана Karl Fox.

Точно так же, как и SLIP, PPP выполнен посредством специальной line discipline. Для того, чтобы использовать последовательную линию как PPP-связь, Вы сначала должны установить связь с помощью Вашего модема, как обычно, и перевести линию в PPP-режим. В этом методе все входящие данные проходят через PPP-драйвер, который проверяет входящие HDLC-структуры на целостность (каждая HDLC-структура несет 16 битов контрольной суммы). В настоящее время он способен к опциональному применению Van Jacobson header compression. Как только Linux стала поддерживать IPX, драйвер PPP был расширен для того, чтобы обрабатывать IPX-пакеты.

Kernel-драйверу помогает pppd, PPP daemon, который выполняет инициализацию и опознание, которое является необходимым перед тем, как трафик может быть послан по связи. Поведение pppd может подстраиваться, используя ряд опций. PPP подробно освещается в книге Using & Managing PPP, я рассмотрю его здесь лишь в общем виде, поскольку полное описание очень громоздко.

Эта работа не может покрыть все аспекты pppd, но даст Вам полное введение. Для более подробной информации, обратитесь к man-страницам и файлам README дистрибутива pppd, которые должны помочь Вам решить большинство вопросов. Если у Вас остаются проблемы даже после чтения всей документации, то Вы должны обратиться в конференцию comp.protocols.ppp. Там Вы узнаете многое о pppd, эти конференции просто необъятны.

Назад | Глобальное оглавление | Вперед
Запуск в режиме сервера |  | Запуск pppd


Authentication with PPP

Назад Глава 8. Протокол Point-to-Point Вперед

Авторизация и PPP

С PPP каждая система может требовать, чтобы другой конец линии опознал себя, используя один из двух опознавательных протоколов. Это Password Authentication Protocol (PAP) и Challenge Handshake Authentication Protocol (CHAP). Когда связь установлена, каждый может запросить другой конец линии, чтобы опознать себя, независимо от того, является ли он вызывающим или вызываемым. Ниже я буду говорить о "клиенте" и "сервере", когда захочу сделать различие между системой опознания и аутенфикатором. PPP daemon может спрашивать о подлинности, посылая LCP-запрос конфигурации, опознающий желаемый протокол.

PAP против CHAP

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

CHAP не имеет этих недостатков. С CHAP аутенфикатор (сервер) посылает беспорядочно сгенерированную "challenge"-строку клиенту, наряду с именем хоста. Клиент использует имя хоста (hostname) для того, чтобы искать соответствующий шифр, объединяет его с challenge и шифрует строку, используя однонаправленную hash-функцию. Результат будет возвращен на сервер наряду с hostname клиента. Сервер теперь выполняет те же самые вычисления и опознает клиента.

Другая особенность CHAP то, что он не требует опознания клиента для опознания самого себя при запуске, но посылает challenge в определенные промежутки времени, чтобы удостовериться, не был ли клиент заменен злоумышленником, например, переключив телефонные линии.

Пакет pppd хранит секретные ключи для CHAP и PAP в двух отдельных файлах, называемых соответственно /etc/ppp/pap-secrets и /etc/ppp/chap-secrets. Записывая удаленный хост в один или другой файл, Вы имеете хороший контроль над CHAP или PAP.

По умолчанию pppd не требует установления подлинности удаленной машины, но соглашается опознавать себя, когда она запросит опознание. Так как CHAP намного более совершенен, чем PAP, pppd пробует использовать его всякий раз, когда это возможно. Если удаленная машина этого не поддерживает, или если pppd не может найти CHAP-шифр для удаленной системы в файле chap-secrets, он возвращается к PAP. Если он не имеет также и PAP-шифра, то связь закроется.

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

Если все системы, с которыми Вы работаете по PPP соглашаются опознавать самих себя, Вы должны поместить опцию auth в глобальный файл /etc/ppp/options и определить пароли для каждой системы в файле chap-secrets. Если система не поддерживает CHAP, добавьте запись к файлу pap-secrets. Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом.

Следующие два раздела обсуждают два PPP файла шифров: pap-secrets и chap-secrets. Они размещены в /etc/ppp и содержат тройки клиентов, серверов и паролей, необязательно сопровождаемых списком адресов IP. Интерпретация клиента и сервера отлична для CHAP и PAP.

Файл для CHAP

Когда надо опознать себя с некоторым сервером, используя CHAP, pppd ищет в файле chap-secrets запись с именем клиента, равным локальному hostname, и именем сервера, равного удаленному hostname, посланному в CHAP Challenge. При требовании опознавания себя роли просто поменялись: pppd будет искать запись с именем клиента, приравненным к удаленному hostname (посланному в CHAP-ответе клиенту) и имя сервера, приравненное локальному хосту.

Типовой файл chap-secrets для vlager:

# 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 "arttoo! arttoo!"     c3po.lucas.com
*                 vlager.vbrew.com "TuXdrinksVicBitter"  pub.vbrew.com

При установлении PPP-связи с c3po, c3po просит vlager опознать себя, используя CHAP и посылая CHAP challenge. Затем pppd просматривает файл chap-secrets для записи с клиентской областью, приравненой к vlager.vbrew.com и областью сервера, приравненной к c3po.lucas.com, и находит первую строку, показанную выше. Затем производится CHAP-ответ из challenge string и шифра (Use The Source Luke) на машину c3po.

В то же самое время pppd составляет CHAP challenge для c3po, содержащую уникальную challenge string, и полностью квалифицированное доменное имя vlager.vbrew.com. В ответ c3po создает CHAP-ответ способом, который мы только что обсудили, и возвращает его vlager. Теперь pppd извлекает клиентский hostname (c3po.vbrew.com) из ответа и ищет в файле chap-secrets строку, соответствующую c3po как клиенту и vlager как серверу. Вторая строка задает pppd объединить CHAP challenge с паролем (arttoo! arttoo!), зашифровать результат и сравнить CHAР-ответом c3po.

Произвольное четвертое поле перечисляет адреса IP, которые допустимы для клиентов в первом поле. Адреса могут быть заданы в dotted quad notation или как имена машин, которые будут найдены через сервер имен. Например, если c3po запросил во время IPCP-переговоров использование IP-адреса, который не в этом списке, запрос будет отклонен, и IPCP будет выключено. В типовом файле, показанном выше, c3po будет ограничен использованием собственного адреса. Если поле адреса пусто, будут позволяться любые адреса. Задание тире (-) запрещает использование IP-адреса.

Третья строка в примере файла chap-secrets позволяет любому хосту установить связь PPP с vlager потому, что * в поле клиента или сервера соответствует любому hostname. Единственое требование: он знает пароль и использует адрес pub.vbrew.com. Запись с групповым символом для имен машин может появится где угодно в файле шифров, так как pppd будет всегда использовать наиболее подходящую запись, которая применима к паре сервер/клиент.

Нужно упомянуть способ, которым pppd находит имена машин: он ищет их в файле шифров. Как было объяснено выше, удаленное имя всегда передается в CHAP Challenge или в Response packet. Локальный hostname будет получен, если вызвать функцию gethostname(2). Если Вы установили имя системы в Ваше неквалифицированное hostname, то должны задать для pppd опцию domain:
# pppd -domain vbrew.com

Это добавит имя домена Brewery к vlager для всех действий по авторизации. Для локального имени интересны также опции usehostname и name. Когда Вы задаете локальный IP-адрес в командной строке, используя local: remote и имя local вместо IP-адреса, pppd использует его как локальный hostname.

Файл для PAP

Файл шифров PAP очень похож на тот, который используется CHAP. Первые два поля всегда содержат имена пользователя и сервера, третье поле хранит шифр PAP. Когда удаленная машина посылает запрос опознания, pppd использует запись, которая имеет поле сервера равное локальному hostname, и поле пользователя, равное имени пользователя, посланному в запросе. Когда опознание произойдет, pppd выберет шифр, который будет послан с полем пользователя, приравненным к локальному имени пользователя, и полем сервера, приравненным к удаленному hostname.

Образец файла шифров для PAP:
# /etc/ppp/pap-secrets
#
# user          server          secret          addrs
vlager-pap      c3po            cresspahl       vlager.vbrew.com
c3po            vlager          DonaldGNUth     c3po.lucas.com

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

Имя vlager-pap в столбце имени пользователя мы посылаем на c3po. По умолчанию pppd выберет локальный hostname как имя пользователя, но Вы можете также определить различные имена, давая опцию user, сопровождаемую эти именем.

При выборе записи из файла pap-secrets для авторизации pppd должен знать имя удаленного хоста. Поскольку он не имеет способа нахождения такой информации, Вы должны точно определить его в командной строке, используя ключевое слово remotename, сопровождаемое соответствующим hostname. Например, используя вышеупомянутую запись для установления подлинности c3po, мы добавляем следующую опцию к командной строке pppd:
# pppd ... remotename c3po user vlager-pap

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

Заметьте, что PAP довольно слабый опознавательный метод, и лучше использовать CHAP, если это возможно. Я не буду здесь описывать PAP в деталях: если Вы заинтересованы в использовании PAP, то найдете больше сведений на pppd(8) man-странице.

Назад | Глобальное оглавление | Вперед
Основы безопасности | Локальное оглавление | Отладка Ваших настроек PPP


Using Options Files

Назад Глава 8. Протокол Point-to-Point Вперед

Использование файлов Options

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

Первый файл опций /etc/ppp/options, который всегда просматривается тогда, когда запускается pppd. Использование его для установки глобальных значений по умолчанию удобно потому, что это позволит Вам избавить пользователей от выполнения нескольких вещей, которые могут поставить под угрозу защиту. Например, чтобы pppd запросил конкретный тип авторизации (PAP или CHAP), Вы бы добавили опцию auth к этому файлу. Эта опция необходима для того, чтобы стало невозможно установить PPP-связь с любой системой, которая не в наших опозназательных базах данных. Помните, что ряд опций может быть перехвачен, например, строка connect.

Другой файл опций, который читается после /etc/ppp/options, .ppprc в домашнем каталоге пользователя. Он позволяет каждому пользователю точно определить собственное множество опций по умолчанию.

Типовой файл /etc/ppp/options мог бы выглядеть следующим образом:
# Global options for pppd running on vlager.vbrew.com
lock                 # use UUCP-style device locking
auth                 # require authentication
usehostname          # use local hostname for CHAP
domain vbrew.com     # our domain name

Первые две из этих опций относятся к авторизации и будут объяснены ниже. Ключевое слово блокировки (lock) заставит pppd уступить стандарту UUCP метод блокировки устройства. Там каждый процесс, который обращается к последовательному устройству, скажем /dev/ttyS3, создает файл блокировки, названный LCK..ttyS3 в UUCP-катологе, чтобы сообщить, что это устройство находится в использовании. Необходимо предохранить любые другие программы типа minicom или uucico от использования этого локального устройства в то время, как используется PPP.

Причина задания этой опции в глобальном конфигурационном файле то, что опции типа тех, что были показанны выше, не могут быть отменены и обеспечивают приемлемый уровень защиты. Заметьте однако, что некоторые опции могут быть отменены позже. Один такой пример: строка connect. Следующие три опции связаны с авторизацией и, следовательно, защиты системы. Опции безопасности лучше всего поместить в этот файл потому, что они "привелигированные" и не могут быть перекрыты в пользовательских файлах ~/.ppprc.

Назад | Глобальное оглавление | Вперед
Запуск pppd | Локальное оглавление | Использование скрипта для автоматического дозвона


UUCP Low-Level Protocols

Назад Глава 16. Управление Taylor UUCP Вперед

Протоколы низкого уровня UUCP

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

Краткий обзор протоколов

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

Протоколы могут быть разделены на две категории: потоковые и пакетные (streaming и packet). Первые передают файл целиком, возможно, вычисляя при этом контрольную сумму. Нет непроизводственных затрат, но требуется надежное соединение, так как любая ошибка потребует повторной передачи файла. Эти протоколы обычно используются на соединениях TCP, но не подходят для использования с телефонными линиями. Хотя современные модемы хорошо исправляют ошибки, нельзя обнаружить ошибку между компьютером и модемом.

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

Ширина канала данных также дает различие. Иногда посылка восьмибитовых символов через последовательное соединение невозможна, например, если соединение использует простой сервер терминала. В этом случае символы с восьмым набором битов должны кодироваться при передаче. Когда Вы передаете восьмибитовые символы по соединению с семью линиями, они должны быть согласно предположениям с самым плохим случаем, это удваивает количество данных, которые будут переданы, хотя сжатие, выполненное аппаратными средствами, может компенсировать это. Строки, которые могут передавать произвольные восьмибитовые символы, обычно называются восьмибитовыми чистыми (8-bit clean). Дело обстоит так для всех соединений TCP, также как для большинства соединений модема.

Следующие протоколы доступны в Taylor UUCP 1.06:

g

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

i

Является двунаправленным пакетным протоколом, который может посылать и получать файлы одновременно. Требуется дуплексное соединение и восьмибитовый канал для данных. Он в настоящее время распознается только Taylor UUCP.

t

Протокол, предназначенный для использования над соединениями TCP или другими, свободными от ошибок. Использует пакеты в 1024 байта и требует восьмибитового чистого соединения.

e

Аналог t, но только потоковый.

f

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

G

Реализация протокола g в System V Release 4. Также распознается и некоторыми другими версиями UUCP.

a

Протокол, схожий с ZMODEM. Требуется восьмиразрядное соединение, кодируются некоторые управляющие символы, подобно XON и XOFF.

Настройка протокола передачи

Все протоколы учитывают некоторое изменение в размерах пакета, блокировках по времени и т.п. Обычно значения по умолчанию, обеспечивающие работу при стандартных обстоятельствах, не оптимальны для вашей системы. Протокол g, например, использует размеры окна от 1 до 7 и размеры пакета в степенях 2 в пределах от 64 до 4096. Если ваша телефонная линия обычно настолько шумная, что теряется более 5% всех пакетов, Вы должны уменьшить размер пакета и сократить окно. С другой стороны, на очень хороших телефонных линиях непроизводительные затраты протокола при посылке запроса черз каждые 128 байт могут оказзаться расточительными, так что Вы можете увеличивать размер пакета до 512 или даже 1024.

Taylor UUCP обеспечивает механизм настройки этих параметров командой protocol-parameter в файле sys. Например, чтобы установить пакет протокола g в 512 байт при обмене с pablo:
system          pablo
...
protocol-parameter g  packet-size  512

Настраиваемые параметры и их названия изменяются от протокола к протоколу. Для полного списка изучите документацию, поставляемую с Taylor UUCP.

Выбор специфических протоколов

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

Основываясь на типе используемого порта (модем, TCP или прямой), uucico составит заданный по умолчанию список протоколов. Для модема и прямых соединений этот список обычно включает i, a, g, G и j. Для соединений TCP это t, e, i, a, g, G, j и f. Вы можете изменить этот заданный по умолчанию список командой protocols, которая может быть определена в записи системы или порта. Например, Вы могли бы записать в файл port примерно следующее:
port            serial1
...
protocols       igG

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

Назад | Глобальное оглавление | Вперед
Настройка системы для приема входящих звонков (Dial In) | Локальное оглавление | Поиск неисправностей


Mail Delivery Modes

Назад Глава 19. Получение и запуск Exim Вперед

Режимы доставки почты

Как отмечено ранее, Exim способен доставить сообщения немедленно или поставить их в очередь для последующей обработки. Вся входящая почта будет сохранена в подкаталоге input ниже каталога /var/spool/exim. Когда формирование очереди не выполняется, процесс поставки будет начат для каждого сообщения, как только оно прибудет. Иначе оно будет оставлено в очереди, пока процесс queue-runner не подберет его. Формирование очереди может быть сделано безусловным, устанавливая queue_only в файле конфигурации, или условным, в зависимости от загрузки системы на протяжении минуты. Например:
queue_only_load = 4
Это заставляет сообщения встать в очередь, если загрузка системы превышает 4.

Если Ваш компьютер постоянно не соединен с Internet, можно включить формирование очереди для удаленных адресов, но разрешить Exim выполнять локальные доставки немедленно. Вы можете сделать это, устанавливая в файле конфигурации:
queue_remote_domains = *

Если Вы включаете любую форму формирования очереди, Вы должны удостовериться, что очереди проверяются регулярно, вероятно каждые 10 или 15 минут. Даже без явных параметров формирования очередей, все они должны быть проверены: в них могут быть сообщения, которые были отсрочены из-за временных сбоев доставки. Если Вы выполняете Exim в daemon-режиме, Вы должны добавить опцию -q15m в командной строке, чтобы обрабатывать очередь каждые 15 минут. Вы можете также вызывать exim -q из cron в этих интервалах.

Вы можете отображать текущую очередь почты, вызывая Exim с опцией -bp. Аналогично Вы можете сделать mailq связью с Exim и вызывать mailq:
$ mailq
 2h   52K 12EwGE-0005jD-00 <sam@vbrew.com>
        D bob@vbrew.com
          harry@example.net

Это показывает одно сообщение из sam@vbrew.com двум получателям. Оно было нормально доставлено bob@vbrew.com, но пока не доставлено harry@example.net, хотя ждет в очереди уже два часа. Размер сообщения 52K, идентификатор (ID), которым Exim идентифицирует это сообщение, 12EwGE-0005jD-00. Вы можете выяснить, почему доставка еще не завершена, с помощью индивидуального журнала сообщения, который сохраняется в подкаталоге msglog каталога spool для Exim. Опция -Mvl дает простой путь выполнения этого:
$ exim –Mvl 12EwGE-0005jD-00
2000-01-30 17:28:13 example.net [192.168.8.2]: Connection timed out
2000-01-30 17:28:13 harry@example.net: remote_smtp transport deferred:
  Connection timed out
Индивидуальные журналы хранят копию записей файла регистрации для каждого сообщения, так что Вы можете легко смотрить их. Та же самая информация могла бы быть извлечена из основного журнал, используя утилиту exigrep:
$ exigrep 12EwGE-0005jD-00 /var/log/exim/exim_mainlog
Это заняло бы больше времени, особенно на занятой системе, где журналы могут быть огромными. Утилита exigrep полезна при поиске нескольких сообщений. Первый параметр является регулярным выражением. Утилита выбирает все строки файла регистрации, связанные с любым сообщением, которое имеет по крайней мере одну строку файла регистрации, соответствующую заданному выражению. Таким образом, эта утилита может использоваться, чтобы выбрать все сообщения для одного адреса или все, которые пришли с определенного компьютера.

Вы можете сохранить немало времени, используя с Exim команду tail на основном журнале. Другой путь выполнения этого: используйте утилиту eximon, которая поставляется с Exim. Это X11-программа, которая показывает листающийся дисплей основного файла регистрации и показывает список сообщений, которые ожидают доставки вместе с краткой информацией относительно доставки.

Назад | Глобальное оглавление | Вперед
Компиляция Exim | Локальное оглавление | Опции настройки


Configuring Remote Loginand Execution

Назад/A> Глава 12. Важные сетевые возможности Вперед

Настройка удаленного выполнения

Часто очень полезно выполнить команду на удаленном компьютере. Причем ввод и вывод команды осуществляются по сети.

Традиционные команды, используемые для выполнения задач на удаленных компьютерах rlogin, rsh и rcp. Пример команды rlogin приведен в главе 1. Я кратко показал проблемы защиты, связанные с этим, в разделе о защите системы в главе 1 и предложил в качестве замены пакет ssh. Он обеспечивает команды slogin, ssh и scp.

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

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

Для повышения безопасности нужно выключить r-команды и настроить ssh на работу вместо них.

Выключение r-команд

Самый простой способ запретить r-команды, это закомментировать или удалить записи для них в файле /etc/inetd.conf. Соответствующие им строки этого файла выглядят так:
# Shell, login, exec and talk are BSD protocols.
shell    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rshd
login    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rlogind
exec     stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rexecd
Вы можете закомментировать их, помещая символ # в начале каждой строки. Не забудьте, что Вы должны перезапустить inetd daemon для вступления изменений в силу.

Установка и конфигурирование ssh

OpenSSH свободная версия набора программ ssh. Linux-версия есть на http://violet.ibs.com.au/openssh и во многих дистрибутивах Linux. Здесь я не буду рассматривать компиляцию: подробные указания есть в пакете с исходными текстами. Если Вы можете установить программу из откомпилированных модулей, лучше всего это сделать.

Для работы ssh нужно два компонента: клиент ssh, которого Вы должны конфигурировать и выполнить на локальном компьютере, и ssh daemon, который должен работать на удаленном компьютер, к которому нужно подключиться.

Ssh daemon

Sshd daemon это программа, которая слушает сетевые подключения клиентов ssh, управляет авторизацией и выполняет запрошенную команду. Он имеет один основной файл конфигурации /etc/ssh/sshd_config и специальный файл, содержащий ключ, используемый при авторизации и шифровании. Каждый компьютер и каждый пользователь имеет собственный ключ.

Утилита ssh-keygen генерирует случайные ключи. Это обычно используется один раз при установке для генерации главного ключа, который администратор системы обычно хранит в файле /etc/ssh/ssh_host_key. Ключи могут иметь длину 512 бит или больше. По умолчанию ssh-keygen генерирует ключи длиной 1024 бита, и большинство людей использует значение по умолчанию. Чтобы генерировать ключ, вызовите команду ssh-keygen:
# ssh-keygen -f /etc/ssh/ssh_host_key

Вас спросят о фразе-пароле. Но ключи хостов такую фразу использовать не должны, так что оставьте ее пустой и нажмите Enter. Вывод программы будет выглядеть примерно так:
Generating RSA keys:  ......oooooO...............................oooooO
Key generation complete.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_key
Your public key has been saved in /etc/ssh/ssh_host_key.pub
The key fingerprint is:
1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

В конце сказано, что два файла были созданы. Первый называется секретным ключом, и должен быть сохранен в тайне. Он попал в файл /etc/ssh/ssh_host_key. Второй называется публичным ключом и должен распространяться. Он хранится в файле /etc/ssh/ssh_host_key.pub.

Теперь нужно создать файл конфигурации. Пакет ssh очень мощный, и файл конфигурации может содержать много параметров. Следующий код показывает безопасный и минимальный файл конфигурации для sshd. Остальные опции детально описаны на man-странице sshd(8):

# /etc/ssh/sshd_config

# The IP adddresses to listen for connections on. 0.0.0.0 means all
# local addresses.
ListenAddress 0.0.0.0

# The TCP port to listen for connections on. The default is 22.
Port 22

# The name of the host key file.
HostKey /etc/ssh/ssh_host_key

# The length of the key in bits.
ServerKeyBits 1024

# Should we allow root logins via ssh?
PermitRootLogin no

# Should the ssh daemon check users' home directory and files permissions?
# are safe before allowing login?
StrictModes yes

# Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method?
RhostsAuthentication no
# Should we allow pure RSA authentication?
RSAAuthentication yes
# Should we allow password authentication?
PasswordAuthentication yes

# Should we allow /etc/hosts.equiv combined with RSA host authentication?
RhostsRSAAuthentication no
# Should we ignore ~/.rhosts files?
IgnoreRhosts yes
# Should we allow logins to accounts with empty passwords?
PermitEmptyPasswords no

Очень важно правильно задать права доступа к файлу настроек. Используйте следующие команды для их задания:
# chown -R root:root /etc/ssh
# chmod 755 /etc/ssh
# chmod 600 /etc/ssh/ssh_host_key
# chmod 644 /etc/ssh/ssh_host_key.pub
# chmod 644 /etc/ssh/sshd_config

Заключительная стадия настройки sshd daemon это его запуск. Следует создать для него rc-файл или вписать вызов в уже существующий, чтобы сервис автоматически вызывался при начальной загрузке. Daemon выполняется автономно и не требует записи в файле /etc/inetd.conf. Он должен быть выполнен от имени пользователя root. Синтаксис очень прост:
/usr/sbin/sshd
sshd автоматически переходит в фоновый режим. Теперь он готов к приему соединений по протоколу ssh.

Клиент ssh

Имеется ряд клиентов ssh: slogin, scp и ssh. Они используют один файл конфигурации, обычно /etc/ssh/ssh_config, и файлы настроек из каталога .ssh в домашнем каталоге пользователя, который их вызвал. Наиболее важные из этих файлов: .ssh/config, который может содержать параметры, отменяющие заданные в /etc/ssh/ssh_config, .ssh/identity, который содержит собственный секретный ключ пользователя и .ssh/identity.pub, содержащий публичный ключ пользователя. Другие важные файлы: .ssh/known_hosts и .ssh/authorized_keys; они будут рассмотрены ниже. Сначала надо создать глобальный файл настроек и файл ключа пользователя.

Файл /etc/ssh/ssh_config очень похож на файл настройки сервера. Есть большое количество свойств, которые Вы можете конфигурировать, но минимальная конфигурация приведена в примере 12-5. Остальная часть параметров рассмотрена на man-странице sshd(8). Вы можете добавлять секции для конкретных компьютеров или их групп. Параметром команды Host может быть любое полное имя компьютера или набор символов подстановки. В данном примере задано соответствие всем хостам. Можно, например, создать запись Host *.vbrew.com, соответствующую всем хостам в домене vbrew.com.

Пример 12-5. Клиентский файл настроек ssh

# /etc/ssh/ssh_config

# Default options to use when connecting to a remote host
Host *
  # Compress the session data?
  Compression yes
  # .. using which compression level? (1 - fast/poor, 9 - slow/good)
  CompressionLevel 6

  # Fall back to rsh if the secure connection fails?
  FallBackToRsh no

  # Should we send keep-alive messages? Useful if you use IP masquerade
  KeepAlive yes

  # Try RSA authentication?
  RSAAuthentication yes
  # Try RSA authentication in combination with .rhosts authentication?
  RhostsRSAAuthentication yes

Я упомянул в разделе конфигурации сервера, что каждый компьютер и пользователь имеет ключ. Ключ пользователя сохранен в его файле ~/.ssh/indentity. Чтобы генерировать ключ, используйте команду ssh-keygen, но Вы не должны определять имя файла, в котором сохраняете ключ. По умолчанию ssh-keygen использует правильное расположение, но попросит Вас ввести имя файла в случае, если Вы хотите сохранить ключ в другом месте. Иногда полезно иметь много авторизационных файлов. Как и прежде ssh-keygen запросит у Вас пароль, что добавляет другой уровень защиты, и его стоит использовать. Пароль не будет отображен на экране, когда Вы его напечатаете.

ПРЕДУПРЕЖДЕНИЕ

Пароль нельзя восстановить, если он забыт. Требования к паролю такие же, как и ко всем прочим паролям. Он должен быть длиной от 10 до 30 символов. Если пароль забыт, придется сгенерировать новый ключ.

Вы должны попросить каждого из Ваших пользователей, чтобы они выполнили ssh-keygen для правильного создания ключа. Команда ssh-keygen создаст их каталоги ~/.ssh/ с соответствующими правами доступа, а также их секретный и публичный ключи в .ssh/identity и .ssh/identity.pub, соответственно. Типовой сеанс:
$ ssh-keygen
Generating RSA keys:  .......oooooO..............................
Key generation complete.
Enter file in which to save the key (/home/maggie/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/maggie/.ssh/identity.
Your public key has been saved in /home/maggie/.ssh/identity.pub.
The key fingerprint is:
1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria
$

Теперь ssh готов к работе.

Использование ssh

Теперь пакет ssh и связанные с ним команды установлены и готовы к выполнению.

Сначала опробуем удаленный вход в систему. Можно использовать программу slogin точно так же, как использовалась программа rlogin в примере в первой главе. Первый раз, когда Вы делаете попытку подключения к компьютеру, ssh получит публичный ключ хоста и запросит подтверждение с помощью электронной подписи fingerprint.

Администратор удаленного компьютера должен предоставить электронную подпись, которую Вы должны добавить к Вашему файлу .ssh/known_hosts. Если он этого не сделал, Вы можете соединиться с удаленным компьютером, но ssh предупредит Вас о возникшей ситуации. Допустим, что Вы уверены в том, что работаете с тем компьютером, с которым хотели связаться (никто не перехватил DNS). Тогда ответьте на запрос положительно. Соответствующий ключ будет автоматически сохранен в Вашем файле .ssh/known_hosts без повторных запросов. Если при следующей попытке подключения, публичный ключ с этого компьютера не соответствует тому, который сохранен, Вы будете предупреждены, потому что это представляет потенциальную опасность.

Первый вход в систему на удаленном компьютере будет выглядеть так:
$ slogin vchianti.vbrew.com
The authenticity of host 'vchianti.vbrew.com' can't be established.
Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/
    known hosts.
maggie@vchianti.vbrew.com's password:
Last login: Tue Feb  1 23:28:58 2000 from vstout.vbrew.com
$

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

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

Можно копировать файлы по сети командой scp. Синтаксис подобен стандартной cp за исключением того, что Вы можете определять имя машины перед именем файла, указывая, что файл находится на определенном компьютере. Следующий пример иллюстрирует синтаксис scp, копируя локальный файл /tmp/fred в каталог /home/maggie/ на удаленный компьютер chianti.vbrew.com:
$ scp /tmp/fred vchianti.vbrew.com:/home/maggie

maggie@vchianti.vbrew.com's password:
fred                 100% |*****************************| 50165   00:01 ETA

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

Вы можете выполнять команды на удаленных компьютерах, использующих ssh. Синтаксис очень прост. Допустим, пользователь maggie просматривает оглавление корневого каталога на машине vchianti.vbrew.com. Команда:
$ ssh vchianti.vbrew.com ls -CF /
maggie@vchianti.vbrew.com's password:
bin/    console@  dos/     home/    lost+found/  pub@   tmp/  vmlinuz@
boot/   dev/      etc/     initrd/  mnt/         root/  usr/  vmlinuz.old@
cdrom/  disk/     floppy/  lib/     proc/        sbin/  var/

Можно помещать ssh в поток команд с перенаправлением ввода-вывода ("трубопровод"). Все будет работать как и в любой другой команде Linux с той лишь разницей, что ввод-вывод ssh пойдет по сети через защищенное соединение. Вот пример того, как Вы могли бы использовать эту возможность в комбинации с командой tar, чтобы скопировать целый каталог с подкаталогами и файлами с удаленного компьютера на локальный компьютер:
$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf -

maggie@vchianti.vbrew.com's password:
etc/GNUstep
etc/Muttrc
etc/Net
etc/X11
etc/adduser.conf
..
..

Здесь выполняемая команда взята в кавычки, чтобы она вся была воспринята как параметр ssh, а не обрабатывалась локальной оболочкой. Эта команда выполняет tar на удаленном компьютере, чтобы архивировать каталог /etc, и пишет результат на стандартный вывод. Мы имеем перенаправление на команду tar на локальном компьютере в режиме извлечения, причем чтение архива идет из стандартного ввода.

Конечно, везде и всегда запрашивается пароль. Теперь становится понятно, почему ssh часто настраивают так, что он не запрашивает Вас относительно паролей все время! Теперь настроим локальный клиент ssh, чтобы он не спрашивал пароль для связи с vchianti.vbrew.com. Я ранее упомянул файл .ssh/authorized_keys, здесь-то он и нужен. Файл .ssh/authorized_keys хранит публичные (public) ключи любых удаленных записей пользователя, к которым нужен автоматический вход. Можно устанавливать автоматические входы в систему, копируя содержание .ssh/identity.pub из удаленной (remote) системы в локальный файл .ssh/authorized_keys. Установите права доступа к файлу .ssh/authorized_keys так, чтобы только Вы могли его читать и писать. Это делается командой:
$ chmod 600 ~/.ssh/authorized_keys

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

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

Назад | Глобальное оглавление | Вперед
Процедура удаленного вызова (Remote Procedure Call) | Локальное оглавление | Сетевая информационная система (NIS)


Name Service and Resolver Configuration

Назад Вперед

Глава 6. Настройка сервера имен

Локальное оглавление
Библиотека Resolver
Как работает DNS
Запуск named

Как уже обсуждалось в главе 2, сеть TCP/IP может полагаться на различные схемы преобразования имен в адреса. Самый простой способ, у которого нет никаких преимуществ над способом, где все пространство имен разделено на зоны, таблица хостов, сохраненная в /etc/hosts. Это полезно только для маленьких LAN, которые управляются одним администратором, и не имеют никакого IP общения с внешним миром. Формат файлов hosts был уже описан главе 5.

С другой стороны Вы можете использовать BIND ( Berkeley Internet Name Domain) для перевода имен хостов в IP-адреса. Конфигурация BIND может быть сложной задачей, но если только Вы сделаете это, то изменения в сетевой топологии могут быть легко отслежены. На Linux, как и на многих других Unix-подобных cистемах, сервис обеспечивается через программу, называемую named. При запуске эта программа загружает множество основных файлов в собственный кэш и ждет запрос от удаленных или локальных пользовательских процессов. Имеющиеся способы требуют, чтобы Вы обязательно ввели имя сервера для каждого хоста.

Библиотека Resolver

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

Функции читают файл настройки. Он сообщает, какой сервис использовать и в каком порядке. Старая стандартная библиотека Linux, libc, использовала файл /etc/host.conf, но библиотека GNU Version 2, glibc, использует файл /etc/nsswitch.conf.

Файл host.conf

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

order

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

multi

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

nospoof

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

alert

Эта опция может принимать значения on или off. Если она включена, то любые попытки спуфинга будут внесены в протокол syslog.

trim

Эта опция берет как аргумент имя домена, которое будет удалено из имени хоста перед поиском. Это полезно для информационных элементов, где Вы хотите точно определить имя хоста с локальным доменом. При поиске хоста с именем локального домена будет удалено имя этого домена. Таким образом, легко осуществить поиск в /etc/hosts. Добавляемое имя домена должно оканчиваться точкой (.), например linux.org.au..

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

Типовой файл для vlager показан в примере 6-1.

Пример 6-1. Образец файла host.conf

# /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 domain (not really necessary).
trim    vbrew.com.

Resolver и переменные окружения

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

RESOLV_HOST_CONF

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

RESOLV_SERV_ORDER

Отменяет опцию order в host.conf. Сервисы, заданные как hosts, bind, и nis, разделяются пробелом, запятой, двоеточием или точкой с запятой.

RESOLV_SPOOF_CHECK

Определяет действия, принимаемые против спуфинга. Эта установка полностью отключается опцией off. Значения warn и warn off включают проверку спуфинга, но соответственно включают и выключают протоколирование (logging). Значение * включает проверку, но оставляет logging, как определено в файле host.conf.

RESOLV_MULTI

Эта переменная может быть использована для перекрытия опции multi из host.conf. Допустимы значения on или off.

RESOLV_OVERRIDE_TRIM_DOMAINS

Определяет список trim-доменов, который отключает те, что заданы в host.conf.

RESOLV_ADD_TRIM_DOMAINS

Определяет список trim-доменов, которые добавляются к заданным в host.conf.

Файл nsswitch.conf

Version 2 GNU standard library включает более мощный и гибкий механизм, чем старый host.conf. Понятие сервиса имен было расширено с включением ряда различных типов информации. Опции конфигурации для всех функций, которые делают запрос к базам данных, были вынесены в один файл конфигурации nsswitch.conf.

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

Опции в nsswitch.conf должны располагаться на отдельных строках. Поля разделяются пробелами или табуляцией. Знак # как обычно определяет комментарий. Каждая строка описывает свой сервис. Первое поле в каждой строке задает имя базы данных, заканчивающееся двоеточием. База данных для преобразования адресов hosts. Связанная база данных, которая используется для преобразования имен сетей в адреса, networks.

Доступны следующие параметры:

dns

Использовать Domain Name System (DNS), чтобы найти адрес. Это имеет смысл только для адресов машин, но не сетей. Этот механизм использует файл /etc/resolv.conf, который мы обсудим позже.

files

Искать локальный файл для хоста или имени сети и связанный адрес. Опция использует традиционные /etc/hosts и /etc/network.

nis или nisplus

Использовать Network Information System (NIS), чтобы найти адрес. NIS и NIS+ подробно рассмотрены в главе 13.

Порядок, в котором перечислены сервисы, определяет последовательность их опроса. Список порядка опроса находится в описании сервиса в файле /etc/nsswitch.conf. Сервисы опрашиваются слева направо, и по умолчанию опрос прекращается когда преобразование выполнено.

Простой пример спецификации баз данных host и network показан в примере 6-2.

Пример 6-2. Образец файла nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# Information about this file is available in the `libc6-doc' package.

hosts:          dns files
networks:       files

Этот пример заставляет систему искать компьютеры сначала в Domain Name System, а в случае неудачи в файле /etc/hosts. Поиск имени сети использует только файл /etc/networks.

Вы способны управлять поисковой таблицей более точно, используя "action items", которые описывают, какое действие использует результат предыдущего поиска. Action items появляются между сервисными спецификациями и включены в квадратные скобки ([]). Общий синтаксис здесь такой:
[ [!] status = action ... ]

Имеются два возможных действия:

return

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

continue

Resolver перейдет к следующему сервису в списке и будет пытаться использовать его.

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

Доступные значения состояния, которые мы можем использовать:

success

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

notfound

Не было ошибки в поисковой таблице, но компьютер адресата или сеть не найдены. Заданное по умолчанию действие для этого состояния continue.

unavail

Сервис недоступен. Файл hosts или networks нечитаем для сервиса files, сервер имен или NIS-сервер не отвечают на запросы сервисов dns или nis. Заданное по умолчанию действие для этого состояния continue.

tryagain

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

Простой пример того, как Вы могли бы использовать этот механизм, показан в примере 6-3.

Пример 6-3. Файл nsswitch.conf с командой Action

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# Information about this file is available in the `libc6-doc' package.

hosts:          dns [!UNAVAIL=return] files
networks:       files

Этот пример пытается искать компьютеры через Domain Name Service. Если состояние возврата не unavailable, resolver возвращает любой найденный адрес. Если, и только если, DNS возвращает unavailable, resolver делает попытку использовать локальный /etc/hosts. Это означает, что он должен использовать файл hosts, только если наш сервер имен является недоступным.

Настройка сервера имен: файл resolv.conf

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

Самая важная опция в resolv.conf это name server, которая задает IP-адрес используемого сервера. Если Вы определите несколько имен серверов, используя опцию name server несколько раз, то они будут проверяться в этом порядке. Поэтому Вы должны поместить наиболее надежный сервер первым. Могут поддерживаться не более трех серверов. Если опция name server не задана, то resolver попытается соединиться с сервером на локальном хосте.

Две других опции, domain и search, имеют дело с заданными по умолчанию доменами, которые берутся из имени хоста, если BIND не может найти адрес с первого запроса. Опция search определяет список доменов, которые необходимо проверить. Пункты списка разделены пробелом или табуляцией. Обычно при подключении к компьютер в локальном домене не указывают полностью квалифицированное имя, но использование имени вроде gauss в командной строке приведет на локальный домен, например, mathematics.groucho.edu.

Это только цель инструкции domain. Она позволяет Вам определять заданное по умолчанию имя домена, которое будет добавлено, когда DNS терпит неудачу при поиске имени хоста. Например, когда дано имя gauss, resolver не может найти машину gauss. в DNS, поскольку такого домена верхнего уровня нет. Когда дано mathematics.groucho.edu как значение по умолчанию, resolver повторяет запрос для gauss с заданным по умолчанию доменом.

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

Это делается с помощью search list. Список может быть определен, используя опцию search, которая является обобщением инструкции domain. Он задает перечень доменов, которые будут использовать для поиска машины с коротким именем.

Инструкции search и domain исключают друг друга и не могут появляться больше одного раза. Если никакая опция не задана, resolver пробует взять заданный по умолчанию домен из локального имени хоста (hostname) системным вызовом getdomainname(2). Если локальный hostname не имеет доменной части, заданный по умолчанию домен будет принят как корневой домен.

Если Вы помещаете инструкцию search в resolv.conf, Вы должны внимательно следить, какие домены туда попадают. Библиотека Resolver до BIND 4.9 создавала заданный по умолчанию список поиска из имени домена, когда список поиска не был задан. Этот заданный по умолчанию список был составлен из заданного по умолчанию домена и всех родительских доменов до корневого. Это вызывало проблемы потому, что запросы DNS попадали на сервера, которые никогда не имели дела с нужным доменом.

Предположим, что Вы из сети Virtual Brewery хотите обратиться к foot.groucho.edu. Но ошибочно вместо foot набираете foo, который не существует. Сервер имен GMU сообщит Вам, что не знает такой компьютер. Со списком поиска старого стиля resolver теперь продолжил бы пробовать найти имя с добавлением vbrew.com и com. Последнее проблематично, потому что groucho.edu.com вполне может оказаться реальным доменом. Их сервер имен мог бы даже найти в своем домене foo. В результате Вы попадете на машину, к которой совсем не стремились! Вряд ли Вы на ней зарегистрируетесь, но с толку будете сбиты основательно.

Для некоторых прикладных программ эти поддельные ведущие поисковые таблицы могут быть проблемой защиты. Следовательно, Вы должны обычно ограничивать домены в Вашем списке поиска локальная организацией. В отделе математики Groucho Marx University список поиска обычно установлен в maths.groucho.edu и groucho.edu.

Если заданный по умолчанию домен создает проблемы, посмотрите часть файла resolv.conf для Virtual Brewery:
# /etc/resolv.conf
# Our domain
domain         vbrew.com
#
# We use vlager as central name server:
name server     172.16.1.1

Когда запрашивается имя vale, resolver ищет vale, а в случае неудачи еще и vale.vbrew.com.

Ошибкоустойчивость Resolver

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

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

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

Альтернатива: Вы можете поддерживать резервную ведущую таблицу для домена или LAN в /etc/hosts. Это очень просто, Вы просто гарантируете, что библиотека resolver делает сначала запрос DNS, а во вторую очередь файла hosts. В файле /etc/host.conf Вы используете для этого order bind,hosts, а в файле /etc/nsswitch.conf следует задать hosts: dns files, чтобы resolver вернулся обратно к файлу hosts, если центральный сервер имен недоступен.

Назад | Глобальное оглавление | Вперед
Проверка ARP-таблиц |  | Как работает DNS


Configuring an IPX Router

Назад Глава 15. IPX и файловая система NCP Вперед

Настройка маршрутизатора IPX

Из нашего короткого обсуждения протоколов, используемых в окружении IPX следует, что IPX маршрутизуемый протокол, а для того, чтобы передать информацию маршрутизации используется Routing Information Protocol (RIP). IPX-версия RIP подобна IP-версии. Они используют тот же самый путь: одни маршрутизаторы периодически передают содержание своих таблиц маршрутов, а другие обучаются у них, слушая и интегрируя информацию, которую они получают. Хост должен знать только то, что является его локальной сетью, и на какую машину передавать пакеты для других сетей. Маршрутизатор ответственен за перенос этих пакетов.

В IPX-среде нужен еще один класс информации. Service Advertisement Protocol (SAP) несет информацию, какие сервисы являются доступными и на каких машинах. Это протокол SAP, который позволяет пользователям получать, например, списки серверов файлов или печати в сети. Протокол SAP работает при наличии компьютеров, которые обеспечивая сервисы, периодически передают список сервисов, которые они предлагают. Сетевые маршрутизаторы IPX собирают эту информацию и передают ее вместе с информацией о маршрутах. Чтобы быть правильным IPX-маршрутизатором, надо обрабатывать информацию RIP и SAP.

Точно так же, как IP, IPX в Linux обеспечивается демоном ipxd, чтобы выполнить задачи, связанные с управлением маршрутизацией. Снова, точно как с IP, это ядро, которое управляет пересылкой пакетов между сетевыми интерфейсами IPX, но выполняет это согласно набору правил, называемых таблицей маршрутизации IPX (IPX routing table). Демон ipxd поддерживает таблицу, слушая на каждом из активных сетевых интерфейсов и анализируя, когда изменение маршрутизации необходимо. Он также отвечает на запросы компьютеров, которые просят о информации маршрутизации.

Команда ipxd доступна в откомпилированном виде в ряде дистрибутивов и в исходниках с anonymous FTP http://metalab.unc.edu (файл /pub/Linux/system/filesystems/ncpfs/ipxripd-x.xx.tgz ).

Никакая конфигурация не является необходимой для ipxd. При запуске он автоматически управляет маршрутизацией IPX устройств, которые были конфигурированы. Вы должны гарантировать, что Ваши IPX-устройства конфигурированы правильно, используя команду ipx_interface прежде, чем запускаете ipxd. Каждые 30 секунд ipxd проверяет присоединенные локально IPX-сети и автоматически управляют ими. Это обеспечивает средства управления сетями на интерфейсах, которые не могут быть активны все время типа интерфейсов PPP.

Обычно ipxd запускается при старте системы из скрипта rc:
# /usr/sbin/ipxd
Символ & не нужен, потому что ipxd перейдет в фоновый режим по умолчанию. В то время как ipxd наиболее полезен на машинах, действующих как IPX маршрутизаторы, он также может пригодиться на сегментах, где есть несколько маршрутизаторов. Когда Вы определяете параметр -p, ipxd будет действовать пассивно: слушать информацию маршрутизации сегмента и модифицировать таблицы маршрутизации, но не будет передавать информацию маршрутизации. Этим путем компьютер может поддерживать таблицы маршрутизации актуальными, не запрашивая маршруты каждый раз, когда требуется входить в контакт с удаленным компьютером.

Статическая IPX-маршрутизация. Использование ipx_route

Имеются случаи, когда мы могли бы поставить жесткий IPX-маршрут. Точно как с IP, мы можем делать это с IPX. Команда ipx_route пишет маршрут в таблицы IPX-маршрутизации. Синтаксис очень прост (IPX не поддерживает множественные подсети):
# ipx_route add 203a41bc 31a10103 00002a02b102
Показанная команда добавила бы маршрут к удаленной IPX-сети 203a41bc через маршрутизатор на нашей локальной сети 31a10103 с узловым адресом 00002a02b102.

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

Вы можете удалять маршрут, используя команду ipx_route:
# ipx_route del 203a41bc

Вы можете просмотреть список маршрутов, которые являются активными в ядре, просмотром файла /proc/net/ipx_route. Наша таблица маршрутизации пока выглядит следующим образом:
# cat ipx_route
Network    Router_Net   Router_Node
203A41BC   31A10103     00002a02b102
31A10103   Directly     Connected
Маршрут к 31A10103 был автоматически создан, когда мы конфигурировали интерфейс IPX. Каждая из наших локальных сетей будет представляться в /proc/net/ipx_route подобной записью. Естественно, если наша машина должна действовать как маршрутизатор, ей будет нужно по крайней мере два интерфейса.

Внутренние сети IPX и маршрутизация

Компьютеры с несколькими IPX-интерфейсами имеют уникальную комбинацию адресов сеть/узел для каждого из интерфейсов. Чтобы соединяться с таким компьютером, Вы можете использовать любую из этих комбинаций. Когда SAP объявляет сервисы, это обеспечивает адрес сети/узла, связанный с сервисом. На компьютерах с несколькими интерфейсами это означает, что один из интерфейсов должен быть выбран как интерфейс для внесения в таблицы маршрутов, это функция флажка primary интерфейса, о котором мы уже говорили ранее. Но это представляет проблему: маршрут к этому интерфейсу не может всегда быть оптимальным, и если происходит сбой, который изолирует эту сеть от остальной части сети, компьютер станет недостижим даже при том, что имеются другие возможные маршруты к другим интерфейсам. Другие маршруты никогда не будут известны другим компьютерам, потому что они не вносятся в таблицы маршрутов, и ядро не может узнать, что оно должно выбрать другой первичный интерфейс. Чтобы избежать этой проблемы, разработано устройство, которое позволяет IPX-компьютеру быть известным, как независимая от маршрута пара адресов сеть/узел. Это решает нашу проблему потому, что эта новая пара доступна через все интерфейсы.

Рассмотрим сервер, подключенный к двум сетям IPX. Он выбирает один из своих интерфейсов как primary, пусть это будет 0000001a:0800000010aa, и объявляет его точкой доступа для некоего сервиса. Это работает нормально для сети 0000001a, но пользователи сети 0000002c пойдут кружным путем через первую сеть, несмотря на то, что сервер имеет порт и в их сети.

Это решается созданием виртуальной сети, которая является полностью программной конструкцией. Ее лучше рассматривать, как находящуюся внутри IPX-машины. SAP-информация нужна только для распространения адреса этой сети. Такие виртуальные сети известны как внутренние (internal network). Но как другие компьютеры узнают, каким путем достичь этой сети? Удаленные компьютеры направляются к внутренней сети через непосредственно связанные сети главного компьютера. Это означает, что надо смотреть на записи маршрутов, которые обращаются к внутренним сетям машин, имеющих несколько сетевых IPX-интерфейсов. Таким образом, в каждый момент будет выбран оптимальный маршрут. Допустим, мы сконфигурировали внутреннюю IPX-сеть с адресом 0x10000010 и используем адрес хоста 00:00:00:00:00:01. Это тот адрес, который будет нашим первичным интерфейсом. Он будет сообщаться через SAP. Наша маршрутизация отразит эту сеть как доступную через любой из реальных сетевых портов, так что компьютеры будут всегда использовать самый лучший сетевой маршрут, чтобы соединиться с этим сервером.

Для созадния внутренней сети используйте команду ipx_internal_net, входящую в пакет IPX tools (автор Greg Page). Простой пример:
# ipx_internal_net add 10000010 000000000001
Эта команда создаст внутреннюю IPX-сеть с адресом 10000010 и адресом узла 000000000001. Сетевой адрес, точно так же как любой другой сетевой адрес IPX, должен быть уникален в Вашей сети. Адрес узла произвольный, так как будет иметься только один узел в этой сети. Каждый компьютер может иметь только одну внутреннюю сеть IPX (IPX Internal Network), и если она сконфигурирована, то всегда будет первичной (primary) сетью.

Для удаления внутренней сети IPX используйте:
# ipx_internal_net del

Назад | Глобальное оглавление | Вперед
Настройка интерфейса IPX | Локальное оглавление | Монтирование удаленных томов NetWare


Remote Procedure Call

Назад Глава 12. Важные сетевые возможности Вперед

Процедура удаленного вызова (Remote Procedure Call)

Очень важный механизм для приложений "клиент-сервер" обеспечивается RPC (Remote Procedure Call). RPC был разработан Sun Micrsystems, и эта система представляет собой набор инструментальных средств и библиотечных функций. В частности на RPC работают NIS (Network Information System) и NFS (Network File System).

Сервер RPC состоит из системы таких процедур, что клиент может обратится, посылая RPC-запрос к серверу вместе с параметрами процедуры. Сервер вызовет обозначенную процедуру и вернет значение возврата процедуры, если оно есть. Чтобы быть машинно-независимыми, все данные, которыми обмениваются клиент и сервер, преобразуются к так называемому внешнему представлению данных (External Data Representation, XDR). RPC связан с сокетами UDP и TCP для передачи данных в формате XDR. Sun объявила RPC как public domain, и его описание доступно в серии документов RFC.

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

Сетевая связь между серверами и клиентами RPC немного особая. RPC-сервер предлагает одну или более системных процедур, каждое множество таких процедур называется программой (program) и однозначно идентифицировано номером программы (program number). Список имен сервисов обычно хранится в /etc/rpc, пример которого приведен ниже.

Пример 12-4. Образец файла /etc/rpc

#
# /etc/rpc - miscellaneous 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

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

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

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

В Linux portmapper называется /sbin/portmap или /usr/sbin/rpc.portmap. Кроме того, что он должен быть запущен из скрипта запуска сети, рortmapper не требует никакой работы по конфигурации.

Назад | Глобальное оглавление | Вперед
Файлы services и protocols | Локальное оглавление | Настройка удаленного выполнения


SAGE: The SystemAdministrators Guild

Назад

Приложение D. SAGE: The System Administrators Guild

Если Вы не того, в чем Вы нуждаетесь, в рассылках в comp.os.linux.* и в документации, может быть самое время присоединиться к SAGE, the System Administrators Guild, спонсируемой USENIX. Основная цель SAGE состоит в том, чтобы продвинуть администраторов системы профессионально. SAGE соединяет систему и сетевых администраторов, чтобы способствовать профессиональной разработке, общим проблемам и решениям, связываться с пользователями.

Текущие инициативы SAGE:

  • Поддержка проведения ежегодных конференций System Administration Conferences (LISA) совместно с USENIX.

  • Публикация Job Descriptions for System Administrators под редакцией Tina Darmohray, первого в ряде очень полезных руководств по настройке системы, проблемам и решениям.

  • Поддержка архива ftp.sage.usenix.org, для статей из System Administration Conferences и связанной документации.

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

Подробности по USENIX Association и специальной технической группе SAGE, доступны по телефону (510) 528-8649 в U.S. или по e-mail office@usenix.org. Чтобы получать информацию в электронном виде, пишите на info@usenix.org. Ежегодное членство в SAGE стоит $25 (Вы должны также быть членом USENIX). Членам группы доступны ежеквартальные технические журналы login: и Computing Systems, скидки на участие в разных конференциях и симпозиумах и ряд других сервисов.

Назад | Глобальное оглавление
10. Future Revisions of this License |


NIS Server Security

Назад Глава 13. Network Information System (NIS) Вперед

Безопасность NIS-сервера

NIS имеет большую дыру в защите: файл паролей доступен на чтение кому угодно. Зная имя домена NIS и адрес его сервера, можно просто попросить отобразить карту passwd.byname и немедленно получить зашифрованные пароли всей Вашей системы. Дальше в дело идет программа crack с хорошим словарем и пароли открыты!

К счастью, этому можно противостоять опцией securenets. Она просто ограничивает доступ к серверу NIS некоторыми хостами, основываясь на их IP-адресах или сетевых масках. Последняя версия ypserv реализует это свойство двумя способами. Первый полагается на специальный файл конфигурации, названный /etc/ypserv.securenets, а второй использует файлы /etc/hosts.allow и /etc/hosts.deny, с которыми Вы уже столкнулись в главе 12. Таким образом, чтобы ограничить доступ к серверу хостами из локальной сети добавьте строку к hosts.allow:
ypserv: 172.16.2.

Это позволит всем компьютерам из IP-сети 172.16.2.0 обращаться к NIS-серверу. Чтобы закрыть доступ всем остальным (внешним) машинам, допишите в hosts.deny:
ypserv: ALL

IP-адреса не единственный путь, которым Вы можете определять компьютеры или сети в hosts.allow и hosts.deny. Обратитесь за подробностями к man-странице hosts_access(5). Однако, не следует использовать в определениях для ypserv доменные хостов. При их использовании, сервер запросит у сервера DNS соответствующий IP, а ответ DNS может быть и подделан хакером. Еще хуже, когда DNS сам запросит карту от NIS, тот в свою очередь вызовет DNS и т.д.

Чтобы настроить securenets с использованием /etc/ypserv.securenets, нужно создать файл /etc/ypserv.securenets. Этот файл конфигурации прост: каждая строка описывает хост или сеть, которые будут иметь доступ к серверу. Любой адрес, не описанный в этом файле, будет заблокирован. Строки, начинающиеся с символа # считаются комментариями. Пример 13-1 показывает простой /etc/ypserv.securenets:

Пример 13-1. Образец файла /etc/ypserv.securenets

# allow connections from local host -- necessary
host 127.0.0.1
# same as 255.255.255.255 127.0.0.1
#
# allow connections from any host on the Virtual Brewery network
255.255.255.0   172.16.1.0

Первая запись в каждой строке задает сетевую маску для этой строки. Вторая запись определяет адрес соответствующего хоста, к которому маска применяется. Можно задать маску и адрес явно ключевыми словами host и netmask.

Третья опция (если определена) должна задавать для использования безопасный диспетчер портов (portmapper) вместо обычного securenets в ypserv. Безопасный portmapper (portmap-5.0) использует схему hosts.allow, но предлагает это для всех RPC-серверов, не только для ypserv. Однако, Вы не должны использовать опцию securenets и безопасный диспетчер портов вместе.

Назад | Глобальное оглавление | Вперед
Запуск NIS-сервера | Локальное оглавление | Установка клиента NIS с GNU libc


Sendmail

Назад Вперед

Глава 18. Sendmail

Локальное оглавление
Введение в Sendmail
Установка sendmail
Обзор файлов настроек
Файлы sendmail.cf и sendmail.mc
Построение файла sendmail.cf
Интерпретация и написание правил переписки
Опции sendmail
Наиболее распространенные конфигурации
Тестирование настроек
Запуск sendmail
Советы и секреты

Введение в Sendmail

Иногда говорят, что Вы не настоящий администратор системы Unix, пока не редактировали файл sendmail.cf. Также принято говорить, что Вы сумасшедший, если попытаетесь сделать это несколько раз.

sendmail невероятно мощная программа. Также для большинства людей ее невероятно трудно узнавать и понимать. Любая программа, чье окончательное руководство (sendmail, издано O'Reilly and Associatеs) состоит из 1050 страниц, отпугивает многих.

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

Здесь я рассмотрю sendmail, как его настроить, поставить и протестировать.

Назад | Глобальное оглавление | Вперед
Настройка elm |  | Установка sendmail


Configuring the Serial Hardware

Назад Вперед

Глава 4. Настройка последовательного оборудования

Локальное оглавление
Программы для модемной связи
Обзор последовательных устройств
Доступ к последовательным устройствам
Последовательное оборудование
Использование программ настройки
Последовательное оборудование и запрос login:

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

Эта глава написана для тех людей, кто полагается на модемы для доступа в сеть. Однако, существует много деталей, в которые мы не будем вдаваться, например, как конфигурировать модем. Все эти темы охвачены в Serial HOWTO (автор David Lawyer), который регулярно отправляется в конференцию comp.os.linux.announce. Зато мы рассмотрим специфичные для Linux аспекты управления устройствами, работы с портами, создание файлов устройств, программы для работы с модемом, последовательное оборудование и его настройку командами setserial и stty.

Программы для модемной связи

Есть ряд коммуникационных пакетов для Linux. Многие из них это терминальные программы (terminal programs), которые позволяют пользователю набрать номер другого компьютера, и работать, как будто Вы сидите перед простым терминалом. Традиционная терминальная программа для Unix называется kermit. Имеются более удобные программы, которые поддерживают список телефонных номеров, языки написания скриптов запросов и описания входа в удаленные системы и т.д. Одна из них minicom, которая близка к терминальным программам для DOS. Имеются также X11-пакеты, например, seyon.

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

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

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

Назад | Глобальное оглавление | Вперед
Другие типы сетей |  | Обзор последовательных устройств


Accessing Serial Devices

Назад Глава 4. Настройка последовательного оборудования Вперед

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

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

Файлы из первого множества требуются в случае, если порт используется для приема. Они имеет старший номер 4 и имена ttyS0, ttyS1, ttySn. Второе множество используется для передачи, файлы названы cua0, cua1, cuan и имеют старший номер 5. Младшие номера одинаковы для обоих типов. Если модем подключен к одному из портов от COM1 до COM4, младший номер будет номером COM-порта плюс 63. Если Ваша настройка отлична от этой, например, при использовании платы, поддерживающей множество последовательных линий, пожалуйста, обратитесь к Serial Howto. Таким образом, порт COM1: обозначен как /dev/ttyS0, COM2: как /dev/ttyS1 и так далее.

Файлы серии cua, или "callout", были созданы, чтобы решить проблему ухода от конфликтов на последовательных устройствах для модемов, которые должны поддерживать входящие и исходящие подключения. К сожалению, они создали только лишние проблемы и теперь, вероятно, выйдут из употребления. Давайте кратко рассмотрим проблему.

Linux, как и Unix, позволяет открыть устройство или любой файл более, чем одному процессу одновременно. К сожалению, это редко работает хорошо с tty-устройствами, поскольку два процесса будут почти наверняка сталкиваться друг с другом. К счастью, был изобретен механизм, позволяющий процессу проверять, было ли tty-устройство уже открыто другим процессом. Механизм использует файлы блокировки (lock files). Идея состояла в том, что, когда процесс открывает tty-устройство, он проверит существование файла в специальном месте, с именем, соответствующим устройству, которое процесс хочет открыть. Если файл не существует, процесс создает его и открывает tty-устройство. Если файл существует, процесс считает, что другой процесс уже открыл это tty-устройство, и выполняет соответствующее этой ситуации действие. Для построния системы управления файлами блокировки использован простой прием: создавший файл блокировки процесс должен записать свой process ID (pid) в него.

Механизм файлов блокировки работает хорошо, если все файлы пишутся в определенное место, и все программы знают, где их искать и создавать. Но в Linux единого мнения по данному вопросу не было до появления Linux Filesystem Standard, который определил стандартное расположение для файлов блокировки. Раньше эти файлы хранились минимум в четырех каталогах: /usr/spool/locks, /var/spool/locks, /var/lock и /usr/lock. Беспорядок вызвал хаос. Программы открывали файлы блокировки в различных каталогах и при этом пытались управлять одними и теми же устройствами. Получалось, будто файлы блокировки не использовались вообще.

Устройства cua были созданы, чтобы обеспечить решение этой проблемы. Вместо использования файлов блокировки, чтобы предотвратить столкновения между программами, желающими использовать последовательные устройства было решено, что ядро может обеспечивать простые средства для решения того, кто должен иметь доступ. Если устройство ttyS было уже открыто, попытка открыть cua кончится ошибкой, которую программа могла бы интерпретировать соответствующим образом. Если устройство cua было уже открыто, и была сделана попытка открыть ttyS, запрос будет заблокирован, то есть, он будет ждать, пока cua не будет закрыто другим процессом. Это работало хорошо, если Вы имели один модем, который сконфигурировали для дозвона к провайлеру и приема входящих звонков. Но это не работало в средах, где есть много программ, желающих работать на том же самом устройстве. Единственный способ решить проблему состоял в том, чтобы использовать файлы блокировки! С чего начали, к тому и вернулись...

Решение принес стандарт файловой системы Linux Filesystem Standard. Теперь файлы блокировки хранятся в /var/lock, а имя файла для блокировки устройства ttyS1 выглядит как LCK..ttyS1. Файлы блокировки cua должны также войти в этот каталог, но использование устройств cua теперь явно излишне.

Устройства cua какое-то время еще будут поддерживаться по соображениям совместимости, но едва ли это продлится долго. Лучше всего использовать ttyS и следить, чтобы система была совместима с Linux FSSTND или по крайней мере, чтобы все программы, использующие последовательные устройства, договаривались о месте хранения и именах файлов блокировки. Большая часть программного обеспечения, имеющего дело с последовательными tty-устройствами, обеспечивает опцию времени компиляции, чтобы определить расположение файлов блокировки. Ищите что-то подобное LOCKDIR в файле Makefile или в файле заголовка компиляции. Если Вы компилируете программное обеспечение самостоятельно, самое лучшее изменить этот параметр, чтобы соответствовать FSSTND. Если вы используете готовые двоичные файлы и не уверены, где программа будет создавать файлы блокировки, Вы можете использовать следующую команду, чтобы получить информацию:
strings binaryfile | grep lock
Если найденное расположение не соответствует остальной части Вашей системы, Вы можете попробовать создать символическую связь из каталога блокировок, который неправильная программа хочет использовать, обратно к /var/lock. Ничего хорошего в таком подходе нет, но это будет работать.

Файлы последовательных устройств

Младшие числа идентичны для обоих типов последовательных устройств. Если модем подключен к одному из портов от COM1 до COM4, младший номер будет номером COM-порта плюс 63. Если Ваша настройка отлична от этой, например, при использовании платы, поддерживающей множество последовательных линий, пожалуйста, обратитесь к Serial Howto.

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

$ ls -l /dev/ttyS*
0 crw-rw----   1 uucp     dialout    4,  64 Oct 13  1997 /dev/ttyS0
0 crw-rw----   1 uucp     dialout    4,  65 Jan 26 21:55 /dev/ttyS1
0 crw-rw----   1 uucp     dialout    4,  66 Oct 13  1997 /dev/ttyS2
0 crw-rw----   1 uucp     dialout    4,  67 Oct 13  1997 /dev/ttyS3

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

# mknod -m 666 /dev/ttyS1 c 4 65
# chown uucp.dialout /dev/ttyS1
Различные дистрибутивы Linux используют немного отличающиеся cтратегии в плане того, кто должен быть владельцем последовательных устройств. Иногда они будут принадлежать root, иногда другому пользователю, например, uucp в этом примере. Новые дистрибутивы имеют группу для набора номера телефона, и любой пользователь, которому разрешено это делать, должен быть просто внесен в нее.

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

Назад | Глобальное оглавление | Вперед
Обзор последовательных устройств | Локальное оглавление | Последовательное оборудование


Serial Hardware

Назад Глава 4. Настройка последовательного оборудования Вперед

Последовательное оборудование

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

Хотя аппаратные средства handshake необязательны, но очень полезны. Они позволяют любой из двух машин сигнализировать о готовности получить данные или о том, что другая машина должна подождать, пока приемник не обработает поступающие данные. Линии, используемые для этого, названы "Clear to Send" (CTS) и "Ready to Send" (RTS), соответственно. Это объясняет второе название handshake, а именно, "RTS/CTS". Другой тип handshake назван "XON/XOFF". Он использует два назначенных символа, традиционно Ctrl-S и Ctrl-Q, чтобы сообщать удаленной машине, что она должна остановить и продолжить передавать данные соответственно. Эти символы при передаче двоичных данных могут вызывать хаос на линии, поскольку они могут быть не управляющими, а частью передаваемых данных. Аппаратный handshake рекомендуется использовать всегда, при наличии такой возможности.

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

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

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

Назад | Глобальное оглавление | Вперед
Доступ к последовательным устройствам | Локальное оглавление | Использование программ настройки


Running an NIS Server

Назад Глава 13. Network Information System (NIS) Вперед

Запуск NIS-сервера

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

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

В настоящее время есть два NIS-сервера, свободно доступные для Linux: один в пакете yps (автор Tobias Reber) и второй в пакете ypserv (разработан Peter Eriksson). Особой разницы между ними нет.

После установки программы-сервера (ypserv) в каталог /usr/sbin, Вы должны создать каталог, хранящий файлы карт, которые Ваш сервер должен распределять. При установке домена NIS как brewery, карты окажутся в каталоге /var/yp/brewery. Сервер определяет, обслуживает ли он некий домен NIS по наличию каталога с картами, так что при отключении некоего домена удалите и соответствующий каталог.

Карты обычно хранятся в DBM-файлах, чтобы ускорить поиск. Они создаются из файлов-заготовок программой makedbm (для сервера Tobias) или dbmload (для версии Peter).

Преобразование главного файла-заготовки в форму для анализа программой dbmload требует довольно сложной работы с процессором awk или sed. Поэтому пакет ypserv Питера Ерикссона (Peter Eriksson) содержит Makefile (с именем ypMakefile), который управляет преобразованием наиболее часто встречающихся файлов. Вы должны установить его как Makefile в каталоге карт и отредактировать так, чтобы отразить карты, которые Вы хотите распространять. Строки для задания карт выглядят так:
all: ethers hosts networks protocols rpc services passwd group netid

Если Вы не хотите распространять, например, карты ethers.byname и ethers.byaddr, просто удалите записи ethers из этого правила. Чтобы проверить настройку, Вы можете запустить сервис с одной или двумя картами, например, services.*.

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

В разделе "Установка клиента NIS с GNU libc" будет рассказано, как конфигурировать клиент NIS. Если настройки не работают, Вы должны попробовать выяснить, достигают ли запросы сервера вообще. Если Вы определяете параметр командной строки --debug для ypserv, на консоли будут выведены данные о NIS-запросах и их выполнении. Данная опция не работает в сервере, разработанном Tobias Reber.

Назад | Глобальное оглавление | Вперед
Клиентская сторона NIS | Локальное оглавление | Безопасность NIS-сервера


The Services and Protocols Files

Назад Глава 12. Важные сетевые возможности Вперед

Файлы services и protocols

Номера портов для стандартных сервисов определены в документе Assigned Numbers RFC. Чтобы клиенты и серверы могли конвертировать номера портов в имена сервисов, каждая система хранит список соответствия. Он хранится в файле /etc/services. Каждая строка в этом файле имеет такой формат:
service port/protocol [aliases]

Здесь service задает имя сервиса, port определяет номер порта, используемого этим сервисом, а protocol определяет, каким транспортным протоколом пользуется сервис. Имеется возможность различия протоколов udp или tcp. Сервис может работать с разными протоколами, а может быть два сервиса работают на одном порте, но с разными протоколами. Поле aliases позволяет задавать несколько имен (псевдонимов) для одного сервиса.

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

Пример 12-2. Образец файла /etc/services

# 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 используется для двух различных сервисов, а именно, для системы спутниковой связи COMSAT daemon по UDP и для remote execution (rexec), использующего TCP.

Кроме файла services сетевым библиотекам нужен способ преобразования имен протоколов в номера портов при работе на уровне IP с другими системами. Это делается с помощью файла /etc/protocols. Каждая его строка хранит имя протокола и соответствующий номер порта. Пример файла:

Пример 12-3. Образец файла /etc/protocols

#
# 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

Назад | Глобальное оглавление | Вперед
Контроль доступа с помощью tcpd | Локальное оглавление | Процедура удаленного вызова (Remote Procedure Call)


Using NIS with Shadow Support

Назад Глава 13. Network Information System (NIS) Вперед

NIS и затенение паролей

Использование NIS вместе с теневыми файлами паролей несколько проблематично. Сначала плохие новости: использование NIS наносит поражение целям теневых паролей. Схема затенения паролей была разработана, чтобы предотвратить доступ не-root пользователей к зашифрованной форме паролей входа в систему. Использование NIS, чтобы совместно использовать данные shadow, делает шифрованные пароли доступными любому пользователю, который может слушать ответы NIS-сервера.

В libc5 нет никакого реального решения для совместного использования файлов shadow через NIS. Единственный способ распределять пароль и информацию пользователя по NIS сводится к обычным картам passwd.*. Если Вы используете теневые пароли, самый простой способ совместно использовать их состоит в том, чтобы генерировать соответствующий файл passwd из /etc/shadow с помощью утилит, подобных pwuncov, и создавать карты NIS из этого файла.

Поддержка NIS в GNU libc library (libc6) обеспечивает поддержку теневых баз данных паролей. Это упрощает управление паролями в средах, в которых Вы хотите использовать NIS с теневыми паролями. Чтобы использовать данное средство, Вы должны создать базу данных shadow.byname и добавить следующую строку к файлу /etc/nsswitch.conf:
# Shadow password support
shadow:         compat

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

Назад | Глобальное оглавление | Вперед
Использование карт passwd и group | Локальное оглавление | Сетевая файловая система (NFS)


UUCP Setup

Назад Глава 19. Получение и запуск Exim Вперед

Настройка UUCP

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

# Transport
uucp:
  driver = pipe
  user = nobody
  command = "/usr/local/bin/uux -r - \
    ${substr_-5:$host}!rmail ${local_part}"
  return_fail_output = true

# Router
uucphost:
  transport = uucp
  driver = domainlist
  route_file = /usr/exim/uucphosts
  search_type = lsearch

В полном файле конфигурации, транспорт был бы вставлен в описания других транспортов и маршрутизатор, вероятно, определен как первый маршрутизатор. Файл /usr/exim/uucphosts хранит запись:
darksite.example.com:           darksite.UUCP
Эта запись значит, что почта на домен darksite.example.com будет передана по UUCP на darksite. Эта конфигурация могла бы быть установлена еще проще без маршрутизатора, добавлением суффикса .UUCP к darksite , но такой путь лучше тем, что ясно дает понять различие между доменом darksite.example.com и UUCP-машиной darksite.

Всякий раз, когда маршрутизатор натолкнется на домен, который находится в файле маршрута, он пошлет адрес UUCP-транспорту, который впоследствии передаст письмо команде uux (описана в главе 16). Если имеется проблема, uux сгенерирует некоторый вывод и завершится с кодом ошибки, отличным от нуля. Установка return_fail_output удостоверится, что вывод возвращен отправителю.

Если входящие UUCP-сообщения сгруппированы в файлы в формате batched SMTP, они могут быть переданы непосредственно Exim командой:
exim -bS </var/uucp/incoming/001

Когда Exim получает сообщение в местном масштабе, он требует, чтобы отправитель был зарегистрированным в системе пользователем. Для UUCP-пакета надо, чтобы отправители брались из входящего сообщения. Exim будет делать это, если процесс, который вызывает его, запущен как доверенный пользователь (trusted user). Если Вы хотите, чтобы входящий трафик UUCP-почты был обработан пользователем, например, uucp, Вы должны в файле конфигурации Exim определить:
trusted_users = uucp
чтобы гарантировать, что адреса отправителя правильно обработаны.

Назад | Глобальное оглавление | Вперед
Противоспамовая оборона | Локальное оглавление | Netnews


Writing hosts and networks Files

Назад Глава 5. Настройка сети TCP/IP Вперед

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

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

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

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

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

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

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

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

#
# Hosts file for Virtual Brewery/Virtual Winery
#
# IP            FQDN                 aliases
#
127.0.0.1       localhost
#
172.16.1.1      vlager.vbrew.com      vlager vlager-if1
172.16.1.2      vstout.vbrew.com      vstout
172.16.1.3      vale.vbrew.com        vale
#
172.16.2.1      vlager-if2
172.16.2.2      vbeaujolais.vbrew.com vbeaujolais
172.16.2.3      vbardolino.vbrew.com  vbardolino
172.16.2.4      vchianti.vbrew.com    vchianti

Точно так же, как с IP-адресами хостов, можно дать символическое имя сетевым адресам. Поэтому файл hosts имеет компаньона /etc/networks, который отображает имя сети на сетевой адрес и наоборот. В Virtual Brewery мы могли бы устанавливать файл networks подобно этому:
# /etc/networks for the Virtual Brewery
brew-net      172.16.1.0
wine-net      172.16.2.0

Назад | Глобальное оглавление | Вперед
Создание подсетей | Локальное оглавление | Настройка интерфейса для IP


Serial Line IP

Назад Вперед

Глава 7. Serial Line IP (IP на последовательнхы линиях)

Локальное оглавление
Основные требования
Действия со SLIP
Работа с внутренними IP-сетями
Использование dip
Запуск в режиме сервера

Пакетные протоколы IP или IPX предполагают, что компьютер-приемник сам установит начало и конец каждого пакета. Механизм, используемый, чтобы отмечать и обнаруживать начало и конец пакетов, назван определением границ (delimitation). Протокол Ethernet управляет этим механизмом в среде LAN, а протоколы SLIP и PPP управляют им для последовательных линий связи.

Сравнительно низкая цена медленных dialup-модемов и телефонных схем сделали протоколы IP на последовательных линиях очень популярными, особенно для обеспечения связи конечным пользователям Internet. Аппаратные средства, требуемые, чтобы выполнить SLIP или PPP, просты и легко доступны. Все, что требуется, модем и последовательный порт, оборудованный FIFO-буфером.

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

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

Основные требования

Чтобы использовать SLIP или PPP, Вы должны конфигурировать некоторые базисные свойства работы с сетями, как описано в предыдущих главах. Вы должны установить loopback-интерфейс и настроить преобразование имен в адреса. При соединении с Internet понадобится использовать DNS. Ваши параметры здесь такие же, как для PPP: Вы можете выполнять запросы DNS по последовательной связи, настроив IP-адрес провайдера в файле /etc/resolv.conf или запустив кэширующий сервер имен, как описано в соответствующем разделе в главе 6."

Назад | Глобальное оглавление | Вперед
Запуск named |  | Действия со SLIP


Running in Server Mode

Назад Глава 7. Serial Line IP Вперед

Запуск в режиме сервера

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

Есть два способа работы в серверном режиме SLIP. Оба они требуют создания специального пользователя для клиента SLIP. Допустим, нужно предоставить SLIP-сервис пользователю Arthur Dent с машины dent.beta.com. Создайте логин dent добавлением в файл passwd такой строки:
dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

Затем установите пароль для dent командой passwd.

Команда dip может работать в серверном режиме под именем diplogin. Обычно diplogin является ссылкой на dip. Его главный файл конфигурации /etc/diphosts, который присоединяет имена пользователей к IP адресу. В качестве альтернативы Вы можете также использовать sliplogin, BSD-производное средство, которое описывает более гибкую схему конфигурации, которая позволяет Вам выполнить скрипт всякий раз, когда хост устанавливает и разрывает связь с Вашей машиной.

Когда SLIP-пользователь dent зарегистрируется в системе, dip перейдет в режим сервера. Чтобы определить, действительно, ли ему разрешено использовать SLIP, нужно найти имя пользователя в /etc/diphosts. Этот файл подробно описывает права доступа и параметры соединения для каждого SLIP-пользователя. Типовая запись в /etc/diphosts:
# /etc/diphosts
user:password:rem-addr:loc-addr:netmask:comments:protocol,MTU
Поля описаны в таблице 7-2.

Таблица 7-2. Поля записей файла /etc/diphosts

Поле | Описание
user | Имя пользователя, по которому dip ищет запись для вошедшего в систему пользователя.
password | Дополнительный пароль для защиты соединения. Здесь пароль хранится в зашифрованном виде (как в файле /etc/passwd). Если он указан, diplogin спросит у пользователя второй пароль после его входа в систему, но до предоставления ему сервиса SLIP. Этот пароль используется в дополнение к паролю для входа в систему.
rem-addr | Адрес, назначаемый удаленной машине. Можно вместо адреса задать имя, если оно есть у сервера имен, или IP-адрес.
loc-addr | IP-адрес для этого конца SLIP-связи. Тоже можно задать как имя, так и адрес.
netmask | Маска подсети для маршрутизации. Маска не применяется непосредственно для SLIP-связи, но используется в комбинации с rem-addr для построения маршрута к удаленному сайту.
comments | Просто текст для пояснения записи в /etc/diphosts. Программно не обрабатывается.
protocol | Задает протокол или line discipline для этой конкретной связи. Значения совпадают со значениями для параметра -p в команде slattach.
MTU | Задает максимальную длину пакетов при передаче по этой связи. Любой пакет, размером больше этого значения, будет фрагментирован (поделен на пакеты с длиной в пределах MTU).

Пример записи для dent:
dent::dent.beta.com:vbrew.com:255.255.255.0:Arthur Dent:CSLIP,296

Итак, пользователю dent будет предоставлен SLIP-сервис без запроса дополнительного пароля. Он получит IP-адрес, связанный с именем dent.beta.com с маской сети 255.255.255.0. Его маршрут по умолчанию должен быть нацелен на IP-адрес имени vbrew.com, и он должен использовать протокол CSLIP с длиной MTU в 296 байт.

Когда dent входит в систему, diplogin получает сведения о нем из файла diphosts. Если второе поле содержит некое значение, diplogin спросит внешний пароль соединения ("external security password"). Строка, введеная пользователем, будет зашифрована, а результат сверен с паролем в diphosts. Если не совпало, соединение будет запрещено. Если поле пароля хранит строку s/key, и dip откомпилирован с поддержкой S/Key, выполняется авторизация по этому алгоритму. S/Key описан в документации на dip.

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

diplogin требует привилегий администратора. Есои dip не объявлен как setuid к пользователю root, следует сделать diplogin отдельной копией dip вместо простой ссылки. Безопасней объявить diplogin как setuid без изменения статуса dip.

Назад | Глобальное оглавление | Вперед
Использование dip | Локальное оглавление | Протокол Point-to-Point


Submitting Changes

Назад Preface Вперед

Подписка на обновления

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

O'Reilly & Associates, Inc.
101 Morris Street
Sebastopol, CA 95472
1-800-998-9938 (in the U.S. or Canada)
1-707-829-0515 (international or local)
1-707-829-0104 (FAX)

Вы можете посылать нам сообщения по e-mail. Чтобы запросить каталог или присоединиться к списку рассылки, пошлите письмо на адрес info@oreilly.com

Чтобы уточнить технические вопросы или дать комментарий относительно книги, пошлите e-mail на адрес bookquestions@oreilly.com

Есть и web-сайт этой книги с подробным описанием, примерами и планами на будущее. Он находится по адресу:

http://www.oreilly.com/catalog/linag2

Наконец, за полной инофрмацией о разных книгах издательства O'Reilly обращаейтесь на его web-сайт:

http://www.oreilly.com

Назад | Глобальное оглавление | Вперед
Conventions Used in This Book | Локальное оглавление | Acknowledgments


Creating Subnets

Назад Глава 5. Настройка сети TCP/IP Вперед

Создание подсетей

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

Например, менеджер сети Brewery обращается к NIC за сетевым адресом класса В. Чтобы разместить две сети Ethernet, он решает использовать восемь битов части хоста как дополнительные подсетевые биты. Это оставляет другие восемь битов для хоста, то есть по 254 хоста в каждой полсети. Он также назначает подсеть 1 brewery и 2 winery. Их сетевые адреса таким образом 172.16.1.0 и 172.16.2.0. Сетевая маска 255.255.255.0.

vlager, который является gateway между двумя сетями, получил адрес хоста, равный 1 в обоех из них, что дает ему IP-адреса 172.16.1.1 и 172.16.2.1 соответственно.

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

Назад | Глобальное оглавление | Вперед
Установка IP-адресов | Локальное оглавление | Написание файлов hosts и networks


The sys File

Назад Глава 21. C-News Вперед

Файл sys

Файл sys, расположенный в /etc/news, управляет иерархией получения и передачи статей другим сайтам. Хотя имеются инструментальные средства addfeed и delfeed, я думаю, что лучше править этот файл вручную.

Файл sys содержит записи для каждого сервера, на который Вы передаете новости, и описание групп, которые Вы принимаете. Запись выглядит так (запись ME обозначает Ваш сайт):
ME:all/all::
Можно добавить по строке для каждого сайта, с которого Вы принимаете новости:

site[/exclusions]:grouplist[/distlist][:flags[:cmds]]

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

site

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

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

Так как C-News проверяет имена серверов в поле заголовка Path: на основе имен записей, Вы должны удостовериться, что они соответствуют действительности. Некоторые абоненты используют полное имя домена в этом поле или специальное, подобно news.site.domain. Чтобы предотвратить возврат статей к этому абоненту, Вы должны добавить их к списку исключения, отделяя их запятыми.

Для записи о машине moria поле имени сервера (site) содержало бы moria/moria.orcnet.org. Если moria также имеет псевдоним news.orcnet.org, поле site будет содержать moria/moria.orcnet.org,news.orcnet.org.

grouplist

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

Иерархия или группа исключается из пересылки приписыванием восклицательного знака. Если группа новостей проверяется по списку, применяется самое длинное соответствие. Например, если grouplist содержит:
!comp,comp.os.linux,comp.folklore.computers
то никакие группы из иерархии comp, за исключением comp.folklore.computers и всех групп из иерархии comp.os.linux, не будут поданы этому серверу.

Если сервер просит послать все новости, которые Вы получаете, впишите all в grouplist .

distlist

Содержит список областей распространения, которым будут посланы статьи. Вы можете исключать некоторые области, ставя перед ними восклицательный знак. Все области обозначены all. Отсутствие distlist подразумевает рассылку всем.

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

Обычно имеются по крайней мере две области: world, которая является часто заданным по умолчанию, используемым значением для случая, когда ничего не определено пользователем, и local. Могут иметься другие области. В заключение, имеются две области, используемые только C-News: это sendme и ihave, они используются для протокола sendme/ihave.

flags

Здесь описывются некоторые параметры для feed. Их может не быть, или они могут быть комбинацией следующего:

F

Этот флаг дает возможность пакетированию.

f

Почти идентичен флагу F, но позволяет C-News вычислять размер исходящих пакетов более точно.

I

Этот флаг заставит C-News создать список статей, подходящих для использования ihave/sendme. Дополнительные изменения файлов sys и batchparms требуются, чтобы дать возможность работать ihave/sendme.

n

Это создает командные файлы для активных клиентов передачи NNTP (например, nntpxmit). Командные файлы содержат имя файла статьи наряду с id сообщения (см. главу 22).

L

Предписывает C-News передать только статьи, зарегистрированные на Вашем сервере. Этот флаг может сопровождаться десятичным числом n, которое заставит C-News передать статьи, зарегистрированные только внутри n переходов с Вашего сервера. C-News определяет число переходов по полю Path:.

u

Разрешить C-News принимать только статьи из групп unmoderated.

m

Разрешить C-News принимать только статьи из групп moderated.

Вы можете использовать не больше одного из F, f, I или n.

cmds

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

Заданная по умолчанию команда:
uux - -r -z remote-system!rnews

Она вызывает rnews на удаленной системе, подавая статью на стандартный ввод.

Заданный по умолчанию путь поиска для команд, заданных в этом поле, /bin:/usr/bin:/usr/lib/news/batch. Последний каталог содержит ряд команд оболочки, чьи имена начинается с via. Они будут кратко описаны позже в этой главе.

Если пакетирование допускается использованием флагов F, f, I или n, C-News ожидает найти в этом поле имя файла, а не команду. Если имя файла не начинается с наклонной черты вправо (/), оно воспринимается относительно /var/spool/news/out.going. Если поле пусто, то значение по умолчанию remote-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

Назад | Глобальное оглавление | Вперед
Installation | Локальное оглавление | The active File


The tcpd Access Control Facility

Назад Глава 12. Важные сетевые возможности Вперед

Контроль доступа с помощью tcpd

Начиная с открытия компьютера для сетевого доступа, в работу вовлекается много средств защиты. Некоторые из них, однако, могут быть непригодны (наиболее явно это показал RTM Internet worm) или могут не различать безопасные хосты, просьбы о частном обслуживании из которых будут приняты, и опасные хосты, чьи запросы должны быть отклонены. Мы уже кратко обсуждали сервисы finger и tftp. Увы, на уровне inetd нельзя ограничить доступ определенным хостам.

Полезное средство для этого tcpd так называемый "daemon wrapper". Для сервиса ТСP, который Вы хотите контролировать или защищать, вместо него вызывается tcpd. Он регистрирует запрос через syslog daemon, проверяет позволено ли этому хосту использовать затребованный сервис и только, если это так, запускает программу соответствующего сервера. Заметьте, что такой подход не работает с udp-сервисами.

Например, чтобы ограничить доступ к finger, Вы должны изменить строку в inetd.conf:
# unwrapped finger daemon
finger    stream tcp nowait bin    /usr/sbin/fingerd in.fingerd
на:
# wrap finger daemon
finger  stream  tcp     nowait  root    /usr/sbin/tcpd   in.fingerd

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

А вот теперь добавим контроль доступа. Он выполнен посредством двух файлов: /etc/hosts.allow и /etc/hosts.deny. Они содержат разрешения и запреты доступа к некоторым сервисам и хостам. Когда tcpd обрабатывает просьбу о доступе к finger от клиентского хоста biff.foobar.com, он просматривает hosts.allow и hosts.deny (именно в этом порядке!) в поисках соответствующей записи для сервиса и клиентского хоста. Если запись была найдена в hosts.allow, доступ будет предоставлен независимо от записей в hosts.deny. Если соответствие найдено в hosts.deny, то запрос будет отклонен. Если никакого соответствия не найдено вообще, запрос будет принят.

Записи в файлах доступа выглядят так:
servicelist: hostlist [:shellcmd]

servicelist задает список имен сервисов из /etc/services или ключевое слово ALL. Чтобы соответствовать всем сервисам, за исключением finger и tftp, используйте ALL EXCEPT finger, tftp.

hostlist задает список имен хостов, адресов IP или ключевых слов ALL, LOCAL, UNKNOWN или PARANOID. ALL соответствует любому хосту, LOCAL имени хоста, не содержащему точек. UNKNOWN соответствует любым множествам, чьи названия или адреса ошибочны. Наконец, PARANOID соответствует любому хосту, чье имя не преобразуется в IP-адрес. Имя, начинающееся с точки, соответствует всем хостам, чьи домены являются равными этому имени. Например, .foobar.com подойдет для biff.foobar.com. Имеются также условия для сетевых адресов IP и подсетей. Имя, заканчивающиееся на точку, соответствует всем адресам, которые начинаются на заданный шаблон. Так, 172.16. подойдет для 172.16.32.0, но не для 172.15.9.1. Шаблон вида n.n.n.n/m.m.m.m задает адрес и сетевую маску подсети, например, 172.16.0.0/255.255.0.0. Необязательно здесь указывать все адреса и имена. Их можно разместить в файле, а в этом месте вписать имя файла, начинающееся с "/", допустим, /var/access/trustedhosts.

Для того, чтобы отказать в доступе к finger и tftp всем, кроме локальных хостов, сделайте пустым /etc/hosts.allow и поместите в /etc/hosts.deny:
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.log \
      fi

Аргументы %h и %d tcpd превратит в имя хоста клиента и имя сервиса. Подробности есть на man-странице hosts_access(5).

Назад | Глобальное оглавление | Вперед
Важные сетевые возможности | Локальное оглавление | Файлы services и protocols


TCP/IP Networks

Назад Глава 1. Введение в сети Вперед

Сети TCP/IP

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

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

Введение в сети TCP/IP

TCP/IP происходит от проекта, финансируемого американским DARPA (Defense Advanced Research Projects Agency) в 1969. Это была экспериментальная сеть ARPANET, которая была преобразована в эксплуатационную в 1975 после того, как была доказана ее полезность.

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

Для более конкретного рассмотрения TCP/IP повсюду в следующих разделах мы будем пользоваться как примером университетом Groucho Marx (GMU), большинство его отделов используют собственную локальную сеть, а другие используют несколько таких сетей. Они все связаны и подключены к 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-приложением. Чтобы сказать этому приложению, что Вы хотите видеть окна на экране Вашего хоста, Вы должны отрегулировать среду. Это делается переменной окружения DISPLAY:
$ DISPLAY=erdos.maths:0.0
$ export DISPLAY

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

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

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

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

Ethernet

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

Ethernets бывает трех типов: толстый (thick), тонкий (thin) и витая пара (twisted pair). Тонкий и толстый Ethernet использует коаксиальный кабель, отличающейся толщиной (отсюда и название) и способом подключения машины к кабелю. Тонкий Ethernet использует BNC-коннектор в форме буквы Т, в который Вы вставляете кабель и вкручиваете сзади компьютера в гнездо сетевой платы. Толстый Ethernet требует, чтобы Вы проделали маленькую дырочку в кабеле и воткнули коннектор "методом вампира" (vampire tap). Один или больше хостов может быть присоединено к одному такому коннектору. Тонкий и толстый кабель Ethernet может иметь длину не больше 200 и 500 метров соответственно, поэтому они также названы 10base-2 и 10base-5. Витая пара использует кабель, сделанный из медных проводов, но обычно требует дополнительных аппаратных средств (активных концентраторов, active hubs). Он также известен как 10base-T. Здесь "base" является сокращением от "baseband modulation", это значит, что данные непосредственно поданы на кабель без каких-либо модемов и других подобных устройств. Число в начале показывает скорость в мегабитах в секунду, число в конце показывает максимальную длину кабеля. "T" обозначает витую пару. Витая пара на 100 мегабит в секунду обозначается как "100base-T".

Добавление хоста к толстому Ethernet не слишком сложно, оно даже не разрушает временно сеть. Чтобы добавить машину к сети с тонким Ethernet Вы должны прервать работу сети по крайней мере на несколько минут потому, что надо разрезать кабель, чтобы вставить Т-connector. Витая пара в этом плане очень удобна: в ней используется концентратор (hub), который является точкой обмена данными. Машина может быть подключена к нему или отключена от него независимо от работы других машин в сети.

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

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

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

Структура, посланная одной машиной, видна и всем остальным, но только хост места назначения подбирает и обрабатывает ее. Если две машины пробуют послать сообщение одновременно, происходит столкновение ( collision), которое решается двумя машинами с помощью остановки передачи и повторной попытки передачи данных несколько позже. Число столкновений доходит до 30% от пропускной способности сети, но при сильной нагрузке, этот показатель будет расти. Это нормально. Беспокоиться стоит начинать, когда он достигнет 60%. Тут может сильно помочь витая пара: в ней пакеты идут по двум разным проводам и поэтому не сталкиваются. Именно поэтому, все крупные сети делают на витой паре.

Другие типы оборудования

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

Если Вы работаете с аппаратурой IBM, часто придется иметь дело с сетью IBM Token Ring. Token Ring является альтернативой Ethernet в LAN и использует решения, аналогичные применяемым в FDDI, но на низкой скорости (4 Mbps или 16 Mbps). В Linux Token Ring настраивается аналогично Ethernet, так что я не буду рассматривать его отдельно. Раньше за право быть наиболее распространенным стандартом бились Ethernet и Token Ring. В конце концов победил Ethernet, но стандарты по своим возможностям находятся примерно на одном уровне.

Есть и совершенно другие сетевые технологии, например, ArcNet и DECNet. Linux поддерживает и их, но из-за малой популярности, я не буду говорить о них в этой работе.

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

Более современный протокол называется Frame Relay. Frame Relay совместно использует ряд технических свойств с X.25, но гораздо больше похож в поведении на IP. Подобно X.25 Frame Relay требует специальных синхронных последовательных аппаратных средств. Из-за их сходства много плат поддерживают оба эти протокола. Доступен вариант, который не требует никаких специальных внутренних аппаратных средств. Это Frame Relay Access Device (FRAD), который формирует пакеты Frame Relay из пакетов Ethernet для передачи по сети. Frame Relay идеально подходит для переноса TCP/IP между сайтами. Linux обеспечивает драйверы многих внутренних устройств Frame Relay.

Если Вы нуждаетесь в работе с высокоскоростной сетью, Вас должен заинтересовать ATM (Asynchronous Transfer Mode). ATM является новой сетевой технологией, специально созданной для того, чтобы обеспечить управляемый, быстрый, с низким временем ожидания обмен данными. Она обеспечивает контроль над качеством обслуживание (QoS). Много компаний создают сети ATM, потому что это позволяет свести много услуг на одну платформу. ATM часто используется для передачи TCP/IP. Networking-HOWTO предлагает информацию относительно поддержки ATM в Linux.

Часто радиолюбители используют свое оборудование для создания сети из своих компьютеров. Это называется пакетное радио (packet radio) или ham-радио. Протокол, используемый ham-радио, назван AX.25 (он получен из X.25). Он также используется для передачи TCP/IP и других протоколов. AX.25 подобно X.25 требует последовательных аппаратных средств, способных к синхронному действию, или внешнее устройство Terminal Node Controller, чтобы преобразовать пакеты. Есть немало плат с поддержкой этого протокола, они имеют общее название "Z8530 SCC based" (по имени наиболее популярного контроллера связи, используемого в проектах). Есть два протокола, которые работают поверх AX.25: NetRom и Rose, являющиеся протоколами сетевого уровня. Linux поддерживает полные реализации AX.25, NetRom и Rose. AX25-HOWTO является хорошим источником информации по использованию этих протоколов в Linux.

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

Internet Protocol

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

Эта связь управляется специальным хостом, так называемым gateway, который направляет поступающие и исходящие пакеты, копируя их между двумя Ethernet и FDDI. Например, если Вы в математическом отделе и хотите получить доступ к машине quark в локальной сети физического отдела, сетевое программное обеспечение не может послать пакеты непосредственно quark, потому что он находится на другом Ethernet. Поэтому этим занимается gateway. Gateway (назовем его sophus) посылает эти пакеты другому gateway (niels) в отделе физики, niels же отправляет их на требуемую машину.

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

Основное преимущество IP в том, что он преобразует физически несовместимые сети в одну с виду однородную сеть. Это называется internetworking, в результате получаем "метасеть" называемую internet. Обратите внимание на различие между inetrnet и Internet! Последнее является официальным названием одного специфического глобального inetrnet.

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

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

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

IP на последовательных линиях

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

Transmission Control Protocol

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

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

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

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

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

User Datagram Protocol

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

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

Еще о портах

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

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

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

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

Библиотека сокетов

В Unix-подобных операционных системах программное обеспечение, выполняющее все задачи и протоколы, описанные выше, обычно является частью ядра, аналогично сделано и в Linux. Интерфейс программирования, наиболее общий для мира Unix, библиотека гнезд Berkeley (Berkeley Socket Library). Свое название она получила из-за популярной аналогии, которая рассматривает порты как гнезда (розетки). Правда, в современной русской сетевой терминологии устоялся термин "сокет". Она обеспечивает запрос bind, который определяет удаленный хост, транспортный протокол и сервис, к которому программа может присоединиться или слушать (используя системные вызовы connect, listen и accept). Библиотека сокетов обеспечивает не только TCP/IP-сокеты (сокеты типа AF_INET), но также класс, который обрабатывает подключения, локальные для машины (AF_UNIX). Некоторые реализации могут также обрабатывать другие классы подобно XNS (Xerox Networking System) или X.25.

В Linux библиотека сокетов является частью стандартной C-библиотеки libc. Типы сокетов, которые она поддерживает в настоящее время, указаны в таблице 1-1.

Таблица 1-1. Типы сокетов, поддерживаемых libc .

Протокол | Классы сокетов
TCP/IP | AF_INET и AF_INET6
Локальные соединения | AF_UNIX
Сети Novell | AF_IPX
X.25 | AF_X25
ATM | AF_ATMPVC и AF_ATMSVC
Amateur Radio | AF_AX25, AF_NETROM и AF_ROSE

Ведутся работы по добавлению сокетов и для других протоколов.

Назад | Глобальное оглавление | Вперед
Введение в сети | Локальное оглавление | Сети UUCP


TOS Bit Manipulation

Назад Глава 9. TCP/IP Firewall Вперед

Управление битами TOS

Биты типа обслуживания (Type Of Service, TOS) представляют собой набор из четырехбитных флагов в заголовке IP-пакета. Когда любой из этих флажков установлен, маршрутизаторы могут обрабатывать пакет иначе, чем пакет без TOS-набора битов. Каждый из четырех битов имеет различную цель, и только один из TOS-битов может быть установлен в один момент времени, так что комбинации не позволяются. Флаги названы типом обслуживания потому, что они дают возможность прикладной программе, передающей данные, сообщить сети тип требуемого сетевого обслуживания.

Доступные классы обслуживания сети:

Minimum delay

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

Maximum throughput

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

Maximum reliability

Используется, когда важно иметь некоторую уверенность что данные достигнут адресата без повторной передачи. IP-протокол может быть передан по большому числу основных сред передачи. В то время как SLIP и PPP хорошие для передачи обычных протоколы, они не столь надежны, как X.25 network. Для таких пакетов выбираются самые надежные каналы связи.

Minimum cost

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

Задание TOS-битов с помощью ipfwadm или ipchains

Команды ipfwadm и ipchains имеют дело с TOS-битами. В обоих случаях Вы определяете правило, которое соответствует пакетам с конкретным TOS-битом, и используете параметр -t, чтобы определить изменение, которое Вы желаете сделать.

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

Разрядные маски определяются, используя восьмиразрядные шестнадцатеричные значения. ipfwadm и ipchains используют одинаковый синтаксис:
-t andmask xormask

Наиболее полезные применения для масок приведены вместе с их значениями в таблице 9-3.

Таблица 9-3. Использование TOS-битов

TOS | ANDmask | XORmask | Рекомендуемое использование
Minimum Delay | 0x01 | 0x10 | ftp, telnet, ssh
Maximum Throughput | 0x01 | 0x08 | ftp-данные, www
Maximum Reliability | 0x01 | 0x04 | snmp, dns
Minimum Cost | 0x01 | 0x02 | nntp, smtp

Установка TOS-битов с помощью iptables

Команда iptables позволяет Вам определять правила для сбора данных с заданными TOS-битами, используя параметр -m tos и устанавливать биты с помощью параметра -j TOS. Вы можете устанавливать TOS-биты только на правилах цепочек FORWARD и OUTPUT. Соответствие и установка происходит совершенно независимо. Вы можете конфигурировать много интересных правил. Например, Вы можете конфигурировать правило для отклонения пакетов с задаными TOS-битами или для установки TOS-битов в пакетах с некоего конкретного компьютера.

В отличие от ipfwadm и ipchains , iptables использует более простой подход, явно определяя чему TOS-биты должны соответствовать, или какие TOS-биты должны быть установлены. Для битов заданы имена, что куда лучше запоминания их числовых масок

Синтаксис для задания соответствия TOS-битов в правилах:
-m tos --tos mnemonic [other-args] -j target

Синтаксис для установки TOS-битов в правилах:
[other-args] -j TOS --set mnemonic

Помните, что они обычно используются вместе, но могут использоваться совершенно независимо, если это нужно.

Имя | Шестнадцатеричное значение
Нормальый сервис | 0x00
Minimize-Cost | 0x02
Maximize-Reliability | 0x04
Maximize-Throughput | 0x08
Minimize-Delay | 0x10
Назад | Глобальное оглавление | Вперед
Netfilter и таблицы IP (ядра 2.4) | Локальное оглавление | Проверка конфигурации Firewall


trn Configuration

Назад Глава 24. Newsreader Configuration Вперед

Настройка trn

Программа trn является преемником более старого newsreader, а именно, rn. Он написан Wayne Davidson.

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

Невыполнение mthreads,, однако, не означает, что Вы не можете обращаться к новым статьям, это только означает, что Вы будете иметь все статьи "A GENUINE INVESTMENT OPPORTUNITY", рассеянными в меню выбора статей, вместо одного экземпляра (который Вы можете легко пропустить).

Чтобы включить отсеивание для определенных newsgroups, mthreads вызывается со списком newsgroup в командной строке. Список сделан как в файле sys:
$ mthreads "comp,rec,!rec.games.go"

Отсеивает все comp и rec, кроме rec.games.go. После этого Вы просто вызываете mthreads без опций вообще, чтобы заставить обработать любые недавно прибывшие статьи. Отсеивание всех групп, найденных в файле active, может быть включено вызовом mthreads со списком групп all.

Если Вы получаете новости ночью, то будете обычно выполнять mthreads один раз утром, но Вы можете также делать это более часто, если необходимо. Абоненты, которые имеют очень большой трафик, могут выполнять mthreads в daemon-режиме. Когда mthreads запускается при начальной загрузке, используя опцию -d, он помещает себя в фон и пробуждается каждые 10 минут, чтобы проверить, имеются ли недавно прибывшие статьи, и просеивает их. Чтобы выполнять mthreads в daemon-режиме, поместите следующую строку в скрипт rc.news:
/usr/local/bin/rn/mthreads -deav

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

Старые статьи, которые больше не доступны, должны быть удалены из индексных файлов. По умолчанию только статьи, чье число меньше метки ожидания (low-water mark), будут удалены. Статьи с числом выше этого, которые устарели (потому что самая старая статья была назначена на дальнюю дату старения полем Expires: заголовка) могут быть удалены командой mthreads с опцией -e, чтобы вынудить расширенную чистку. Когда mthreads выполняется в daemon-режиме, опция -e заставит выполнять такое расширенное старение один раз в день, в полночь.

Назад | Глобальное оглавление | Вперед
Newsreader Configuration | Локальное оглавление | nn Configuration


Introduction to Serial Devices

Назад Глава 4. Настройка последовательного оборудования Вперед

Обзор последовательных устройств

Ядро Unix обеспечивает обращение к последовательным устройствам tty. Это сокращение от Teletype device, по названию фирмы, которая в прошлом была одним из основных изготовителей терминалов. Этот термин используется в настоящее время для любого основанного на символьных данных устройства. В этой главе мы будем использовать этот термин исключительно по отношению к физическим устройствам.

В Linux существует три класса tty: виртуальные консоли, псевдотерминалы (подобные дуплексному каналу, используемому приложениями типа X11) и последовательные устройства. Последние также причисляется к tty потому, что они позволяют создавать диалоговые сессии по последовательной связи: будь то простой терминал или удаленный, компьютер соединенный с Вашим по телефонной линии. Обратиться к виртуальным консолям можно с локальной консоли клавишами с Alt-F1 по Alt-Fnn, где nn задает номер консоли.

SLIP и PPP имеют много общего в своей реализации в ядре. Ядро, действительно, не обрабатывает tty как сетевое устройство, которым Вы можете управлять, подобно устройству Ethernet, используя команды типа ifconfig. Однако, оно обрабатывает tty-устройства как места, где сетевые устройства могут быть подключены. Для этого ядро включает код для устройств tty, получивший название "line discipline". Общая идея состоит в том, что последовательный драйвер обрабатывает данные по-разному, а как именно, зависит от заданной line discipline. В заданной по умолчанию line discipline драйвер просто передает каждый символ, который получил в свою очередь. Когда выбрана line discipline для SLIP или PPP, драйвер читает блок данных, создает его заголовок для правильной обработки принимающей стороной и передает новый блок данных в сеть.

Назад | Глобальное оглавление | Вперед
Программы для модемной связи | Локальное оглавление | Доступ к последовательным устройствам


What Is Usenet, Anyway?

Назад Глава 20. Netnews Вперед

Что такое Usenet?

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

Базисный модуль Usenet-новостей статья (article). У статьи есть так называемый заголовок. Это очень похоже на формат заголовка почты, установленный в Internet, стандарт RFC 822, в котором он состоит из отдельных строк текста, каждая начинается с имени поля, завершенного двоеточием и значением поля.

Статьи представлены на рассмотрение в одну или большее количество групп новостей (newsgroup). Можно рассматривать newsgroup форумом для статей в отношении общего предмета. Все newsgroup организованы в иерархии с именем каждой группы, указывающим место в иерархии. Например, любой может по имени newsgroup понять, что comp.os.linux.announce используется для объявлений относительно операционной системы Linux.

Статьями обмениваются все сайты Usenet, которые поддерживают новости из конкретной группы. Когда два сайта соглашаются обмениваться новостями, они свободны обмениваться любыми группами и могут даже добавлять их собственные локальные иерархии новостей. Например, groucho.edu мог бы иметь связь новостей с barnyard.edu, который является главным сервером новостей, и несколько связей с малыми сайтами, которые он подпитывает новостями. Теперь Barnyard College мог бы получать все группы Usenet в то время, как GMU хочет нести только несколько главных иерархий, подобно sci, comp или rec. Некоторые из сайтов-получателей, например, UUCP-сайт brewhq, хотят получать еще меньше групп, потому что они не имеют достаточных сетевых или аппаратных ресурсов. С другой стороны brewhq мог бы хотеть получать новости иерархии fj, которую GMU не несет. Следовательно, он поддерживает другую связь с gargleblaster.com, который несет все группы fj и передает их на brewhq.

Назад | Глобальное оглавление | Вперед
Netnews | Локальное оглавление | Как в Usenet обрабатывают новости?


ManagingTaylor UUCP

Назад Вперед

Глава 16. Управление Taylor UUCP

Локальное оглавление
Обзор передачи UUCP и удаленного выполнения
Файлы настройки UUCP
Контроль доступа к возможностям UUCP
Настройка системы для приема входящих звонков (Dial In)
Протоколы низкого уровня UUCP
Поиск неисправностей
Log-файлы и отладка

UUCP был разработан в конце семидесятых Mike Lesk в AT&T Bell Laboratories, чтобы обеспечить простое соединение по модему. Так как большинство людей, которые хотят иметь email и новости Usenet на своей домашней машине все еще связываются через модемы, UUCP стал очень популярен. Хотя имеется много реализаций, разработанных для различных аппаратных платформ и операционных систем, все они совместимы с высокой степенью.

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

Одна разновидность, это так называемая Версия 2 UUCP (Version 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.06, является версией, которую описывает эта глава. Версия Taylor UUCP 1.06 была выпущена в августе 1995. Кроме традиционных файлов конфигурации Taylor UUCP может быть скомпилирована так, чтобы понимать новый стиль "Taylor-файлы конфигурации".

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

Цель этой главы не в том, чтобы дать исчерпывающее описание опций командной строки для команд UUCP, а в том, чтобы дать Вам введение в установку работающего узла UUCP. Первый раздел дает введение в то, как UUCP осуществляет удаленное выполнение и передачу файла. Если Вы не новичок в UUCP, Вы можете пропустить этот раздел и перейти к разделу "Файлы настройки UUCP", который объясняет различные файлы, используемые для установки UUCP.

Считается, что Вы знакомы с пользовательскими программами набора программ UUCP uucp и uux. За описанием обратитесь, пожалуйста, к их man-страницам.

Кроме общедоступных программ uucp и uux набор программ UUCP содержит ряд команд, используемых только для административных целей. Они используются для контроля трафика UUCP через узел, удаления старых регистрационных файлов, или для обработки статистики. Они не будут описаны здесь, потому что они периферийные к основным задачам UUCP. Кроме того, они хорошо документированы и довольно легки для понимания. Однако, имеется третий класс, который включает рабочие программы UUCP. Они называются uucico (где cico обозначает copy-in copy-out) и uuxqt, которая выполняет работы, посланные из удаленных систем.

Если Вы в этой главе не найдете то, что хотите, прочитайте документацию, которая поставляется с пакетом. Это набор texinfo-файлов, которые описывают установку с использованием Taylor-схемы конфигурации. Texinfo может быть преобразован в dvi файлы информации, используя команду texi2dvi. Для просмотра служит xdvi.

Хорошим источником сведений по UUCP является Guylhem Aznar's UUCP-HOWTO. Он есть на зеркалах Linux Documentation Project и регулярно рассылается в группу новостей comp.os.linux.answers.

Для обсуждения вопросов по UUCP есть специальная группа новостей comp.mail.uucp.

Обзор передачи UUCP и удаленного выполнения

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

Например, допустим, что на Вашей системе выдали следующую команду, которая заставляет UUCP копировать файл netguide.ps на машину pablo и выполнить команду lpr, чтобы напечатать файл:

$ uux -r pablo!lpr !netguide.ps

UUCP не вызывает удаленную систему немедленно, чтобы выполнить задачу (иначе Вы могли это сделать kermit). Вместо этого он временно сохраняет описание задачи на удаленной системе. Это называется буферизацией задачи (spooling). Каталог, в котором сохраняется задача, называется буферным каталогом (spool directory) и обычно находится в /var/spool/uucp. В нашем примере описание задачи содержало бы информацию относительно удаленной команды, которая будет выполнена (lpr), пользователя, который запросил выполнение, и пары других предметов. В дополнение к описанию задачи, UUCP должен сохранить входной файл netguide.ps.

Точное расположение и наименование буферных файлов может изменяться в зависимости от некоторых опций времени компиляции. HDB-совместимые UUCP вообще сохраняют буферные файлы в подкаталогах структуры /var/spool/uucp с именем удаленной машины. Скомпилированный для Taylor-конфигурации, UUCP создаст подкаталоги в /var/spool/uucp/site для различных типов буферных файлов.

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

Для различия между очень важными и менее важными задачами, UUCP с каждой задачей связывает уровень приоритета (grade). Это один знак, в пределах от 0 до 9, от А до Z и через z, в уменьшающемся старшинстве. Почта обычно записывается в буферный файл с приоритетом B или C в то время, как новости записываются с приоритетом N. Работы с более высоким приоритетом передаются раньше. Приоритеты могут быть назначены, используя опцию -g при вызове uucp или uux (так вот, что значат эти имена файлов!).

Вы можете также запретить передачу задач в определенное время с приоритетом ниже заданного. Это также называется максимальным приоритетом буфера (maximum spool grade), допустимым в течение диалога (по умолчанию z). Обратите внимание на терминологическую неоднозначность: файл будет перемещен только, если он имеет приоритет выше максимального приоритета буфера!

Внутренние действия uucico

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

Когда Вы выполняете из командной строки команду uucico -s system, сначала происходит физическое соединение. Предпринимаемые действия зависят от типа открываемого соединения. Например, при использовании телефонной линии, команда должна найти модем и набрать номер. Если используется TCP, uucico должна вызвать функцию gethostbyname, чтобы преобразовать имя в сетевой адрес, выяснить, какой порт открывать, и связать адрес с соответствующим сокетом.

После того, как соединение будет установлено, должна выполниться процедура идентификации пользователя. Она состоит из запроса удаленной системой имени, и, возможно, пароля. Все это называется login chat. Процедура идентификации выполняется обычным набором программ getty/login или (на сокетах TCP) непосредственно uucico. Если разрешение на вход получено, удаленная система запускает uucico. Локальная копия uucico, которая инициализировала соединение, назначается главной (master), а удаленная подчиненной (slave).

Затем следует фаза рукопожатия (handshake phase): главная копия посылает cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли hostname право входить в нее, посылать и принимать файлы и т.д. Флаги описывают (кроме всего прочего) максимальный приоритет буферизации передаваемых файлов. Если возможно, счет диалога или проверка порядкового номера обращения происходит здесь. Благодаря этой возможности, обе копии поддерживают счет успешных соединений (call sequence number), которые сравниваются. Если они не соответствуют, рукопожатиe прерывается. Это помогает защищаться от самозванцев-хакеров.

В заключение uucico пытается установить общий протокол передачи (transfer protocol). Этот протокол обеспечивает способ перемещения данных, проверку на непротиворечивость и повторную передачу в случае ошибки. Имеется потребность в различных протоколах из-за отличающихся типов обеспечиваемых соединений. Например, телефонные линии требуют "безопасный" протокол, который включает в себя жесткую проверку ошибок в то время, как передача TCP по существу надежна и может использовать более эффективный протокол.

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

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

Мы не будем вникать во все детали: пожалуйста, обратитесь за ними к исходным текстам или к любой хорошей книге по UUCP. Есть также очень старая статья, касающаяся сети, написанной David A. Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP FAQ также обсуждает некоторые подробности UUCP. Это всегда есть в группе новостей comp.mail.uucp.

Опции командной строки uucico

Этот раздел описывает наиболее важные опции командной строки uucico. За полным списком, пожалуйста обратитесь к man-странице uucico.

-system, -s system

Вызов по имени системы system, если нет запрета в соответствии c ограничениями времени обращения.

-S system

Вызов по имени системы system безоговорочно.

-master, -r1

Запукает uucico в режиме master. Это опция задана по умолчанию, когда указаны -s или -S. Опция -r1 заставляет uucico пробовать вызывать все системы в sys, если не запрещено обращение и нет ограничения времени повторения.

-slave, -r0

Запускает uucico в режиме подчиненного. Это используется как значение по умолчанию, когда не заданы -s или -S. В непривилегированном режиме любой стандартный ввод-вывод соединяется с последовательным портом, порт TCP используется, если задана опция -p.

-ifwork, -C

Предписывает uucico вызывать указанную систему только при наличии задач для нее.

-debug type, -x type, -X type

Включают отладку заданного типа. Несколько типов могут быть разделены запятой. Допустимы следующие типы: abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming и outgoing. Использование all включает все опции сразу. Для совместимости с другими реализациями UUCP, взамен может быть определен номер, который включает отладку для первых n типов из вышеупомянутого списка.

Отладочные сообщения будут регистрироваться в файле Debug в /var/spool/uucp.

Назад | Глобальное оглавление | Вперед
Эмуляция сервера NetWare |  | Файлы настройки UUCP


UUCP Networks

Назад Глава 1. Введение в сети Вперед

Сети UUCP

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

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

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

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

Мы рассмотрим настройку UUCP в отдельной главе, но в основном будем говорить о более распространенных сетях TCP/IP.

Назад | Глобальное оглавление | Вперед
Сети TCP/IP | Локальное оглавление | Сети в Linux


Checking the ARP Tables

Назад Глава 5. Configuring TCP/IP Networking Вперед

Проверка ARP-таблиц

В некоторых случаях бывает полезно просмотреть или изменить содержание ARP-таблицы, например, когда Вы подозреваете, что двойной адрес является причиной сетевой неустойчивости. Утилита arp была сделана для исправления подобных вещей. Синтаксис командной строки:
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
172.16.1.3      10Mbps Ethernet         00:00:C0:5A:42:C1
172.16.1.2      10Mbps Ethernet         00:00:C0:90:B3:42
172.16.2.4      10Mbps Ethernet         00:00:C0:04:69:AA

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

При использовании опции -t Вы увидите информацию только о том типе аппаратных средств, который укажете. Это могут быть: ether, ax25 или pronet для Ethernet 10Mbps, 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 для любого хоста из подсети Brewery ( 172.16.1.0), но не для хоста из подсети Winery (172.16.2.0).

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

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

Запись proxy ARP может быть удалена:
# arp -d fnord

Назад | Глобальное оглавление | Вперед
Команда netstat | Локальное оглавление | Настройка сервера имен


Using IP Accounting Results

Назад Глава 10. IP Accounting Вперед

Использование результатов IP Accounting

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

Команды ipfwadm, ipchains и iptables отличаются по тому, как обрабатываются собираемые данные, так что мы рассмотрим их независимо.

Просмотр данных с помощью ipfwadm

Команда ipfwadm позволяет смотреть собранные данные о трафике следующим образом:
# ipfwadm -A -l
IP accounting rules
 pkts bytes dir prot source             destination          ports
 9833 2345K i/o all  172.16.3.0/24      anywhere             n/a
56527   33M i/o all  172.16.4.0/24      anywhere             n/a

Это сообщает нам число пакетов представляющее каждое направление. Если мы используем расширенный выходной формат с опцией -e (не показан здесь, потому что вывод слишком широк для страницы), мы также получим список опций и имена интерфейсов. Большинство полей в выводе понятны, так что я поясню только некоторые:

dir

Направление, в котором применяется правило. Ожидаемые здесь значения: in, out или i/o (оба направления).

prot

Протокол, для которого применяются правила.

opt

Кодированная форма параметров, использованных при вызове ipfwadm.

ifname

Имя интерфейса, к которому применяется правило.

ifaddress

Адрес интерфейса, к которому применяется правило.

По умолчанию ipfwadm отображает счетчики пакетов и байтов в сокращенной форме, округленной к ближайшей тысяче (K) или миллиону (M). Можно задать вывод точных чисел без округления:
# ipfwadm -A -l -e -x

Просмотр данных с помощью ipchains

Команда ipchains не будет отображать данные учета (счетчики пакетов и байтов), если не задан параметр -v:
# ipchains -L -v

Точно как с ipfwadm мы можем отображать счетчики пакетов и байтов точно, используя опцию -x:
# ipchains -L -v -x

Просмотр данных с помощью iptables

Команда iptables ведет себя очень похоже на ipchains. Снова мы должны использовать -v для просмотра результатов учета трафика:

# iptables -L -v

Как и с командой ipchains можно использовать -x для показа точных данных.

Назад | Глобальное оглавление | Вперед
Настройка IP Accounting | Локальное оглавление | Перезапуск счетчиков


IPX and Linux

Назад Глава 15. IPX и файловая система NCP Вперед

IPX и Linux

Alan Cox разработал поддержку IPX для ядра Linux в 1985. Первоначально это было полезно почти исключительно для маршрутизации IPX-пакетов. С тех пор другие люди, особенно Greg Page, обеспечили дополнительную поддержку. Greg разработал утилиты конфигурации IPX, которые мы используем в этой главе, чтобы настроить наши интерфейсы. Volker Lendecke разработал поддержку для файловой системы NCP, чтобы позволить Linux монтировать тома с серверов NetWare. Он также создал инструментальные средства, которые позволяют печатать на и из Linux-машин. Ales Dryak и Martin Stover независимо разработали демоны файлового сервера NCP для Linux, которые позволяют клиентам NetWare монтировать каталоги Linux, экспортируемые как тома NCP, точно как демон NFS позволяет Linux обслуживать клиентов по протоколу NFS. Caldera Systems, Inc. предлагает коммерческие и полностью лицензионные клиент и сервер NetWare, которые поддерживают последние стандарты Novell, включая Novell Directory Service (NDS).

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

Поддержка Caldera

Caldera основана Ray Noorda, бывшим CEO Novell. Поддержка Caldera NetWare коммерческое изделие. Caldera обеспечивает поддержку NetWare как компонент собственного дистрибутива Linux (называется Caldera OpenLinux). Это идеальный путь введения Linux в среды, которые требуют коммерческую поддержку и интеграцию в существующие или новые Novell-сети.

Caldera NetWare полностью запатентована Novell, обеспечивая уверенность, что программы двух компаний будут совместимы. Две исключительных ситуации в этой уверенности: "pure IP" для клиента и сервер NDS: ни один из этих сервисов пока недоступен в данном дистрибутиве. NetWare клиент и сервер доступны вместе. Набор инструментальных средств управления также входит в поставку. Подробности есть на web-сайте Caldera.

О поддержке NDS

Начиная с NetWare Version 4, Novell добавила новый сервис NetWare Directory Service (NDS). Спецификации NDS не доступны в открытом виде. Это ограничение, которое препятствует разработке свободной поддержки. Только Version 2.2.0 или позже пакета ncpfs, который мы обсудим позже, имеет поддержку NDS. Эта поддержка была разработана техникой обратного анализа протокола NDS. Поддержка работает, но все еще официально рассматривается экспериментальной. Вы можете использовать не-NDS инструментальные средства с серверами NetWare 4, если они имеют включенный режим "bindery emulation mode".

Программное обеспечение Caldera имеет полную поддержку NDS, потому что их реализация запатентована у Novell. Эта реализация не свободна. Так что Вы не будете иметь доступ к исходному тексту и не сможете свободно копировать и распространять программное обеспечение.

Назад | Глобальное оглавление | Вперед
IPX и файловая система NCP | Локальное оглавление | Настройка ядра для IPX и NCPFS


Linux Networking

Назад Глава 1. Введение в сети Вперед

Сети и Linux

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

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

Net-4 Linux Network предлагает широкое разнообразие драйверов устройства и продвинутых свойств. Стандартные протоколы Net-4 включают SLIP и PPP (для работы с последовательными линиями), PLIP (для параллельных линий), IPX (для Novell-совместимых сетей, которые мы обсудим в главе 15 ), Appletalk (для сетей Apple), AX.25, NetRom и Rose (для любительских радиосетей). Другие стандартные свойства Net-4 включают IP firewalling, IP accounting (обсуждаются позже в главе 9 и главе 10) и IP Masquerade (обсуждается позже в главе 11). IP tunnelling поддержан в паре различных разновидностей и продвинутой стратегии маршрутизации. Поддерживается очень большое число устройств Ethernet. К тому же, есть поддержка многих плат FDDI, Token Ring, Frame Relay, ISDN и ATM.

Дополнительно, имеется ряд других свойств, которые значительно расширяют гибкость Linux. Эти свойства включают реализацию файловой системы SMB, что позволяет работать с lanmanager и Microsoft Windows. Пакет называется Samba, написан Andrew Tridgell. Есть поддержка Novell NCP (NetWare Core Protocol).

Различные полосы разработки

Fred продолжил разработку после того, как Net-2Debugged был сделан официальной сетевой реализацией. Эта разработка привела к пакету Net-2e. Fred пытался стандартизовать интерфейс драйверов устройств (Device Driver Interface, DDI), но сейчас работа над Net-2e уже закончена.

Другая реализация работы с сетями TCP/IP исходила от Matthias Urlichs. Он написал драйвер ISDN для Linux и FreeBSD. Для этого драйвера он интегрировал часть BSD-кода работы с сетями в ядро Linux. Этот проект также уже свернут.

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

Сетевая реализация Net-4 стала стандартом и используется на очень большом числе машин во всем мире. Много работы было выполнено по улучшении эффективности Net-4, и теперь она конкурирует с самыми лучшими реализациями, доступными для тех же самых аппаратных платформ. Linux распространяется в среде Internet Service Provider и часто используется, чтобы формировать дешевые и надежные серверы World Wide Web, е-mail и news для этих организаций.

Где взять код

Последние устойчивые ядра Linux могут быть найдены на ftp.kernel.org в каталоге /pub/linux/kernel/v2.x , где x четное число. Последние экспериментальные ядра Linux могут быть найдены на ftp.kernel.org в каталоге /pub/linux/kernel/v2.y , где y нечетное число. Есть зеркала этого сайта по всему миру.

Назад | Глобальное оглавление | Вперед
UUCP Networks | Локальное оглавление | Maintaining Your System


Log Files and Debugging

Вперед Глава 16. Управление Taylor UUCP Вперед

Log-файлы и отладка

При компиляции пакета UUCP с использованием протоколов в стиле Taylor, Вы будете иметь только три глобальных протокола в каталоге spool. Основной файл протокола называется 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
uucico 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. В зависимости от избранного Вами режима отладки, он может хранить имя пользователя и пароль, которые Вы используете, чтобы соединиться с удаленной системой.

Если используются инструментальные средства, которые ожидают, что файлы будут в традиционном формате, используемом HDB-совместимой версией UUCP, Вы можете также откомпилировать Taylor UUCP с поддержкой протоколов в стиле HDB. Для этого задайте соответствующую опцию компиляции в файле config.h.

Назад | Глобальное оглавление | Вперед
Поиск неисправностей | Локальное оглавление | E-Mail


Maintaining Your System

Назад Глава 1. Введение в сети Вперед

Управление Вашей системой

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

Абсолютный минимум поддержки сводится к проверке файлов протоколов системы и программ в поисках сообщений об ошибках и необычных событиях. Часто это удобно делать с помощью скриптов, периодически запускаемых из cron. Дистрибутивы некоторых пакетов, например, inn или C-News имеют такие скрипты в готовом виде.

Вывод любой из задач cron должен быть отправлен по почте администратору. По умолчанию многие прикладные программы шлют отчеты об ошибках, статистику использования или резюме журнала пользователю root. Это имеет смысл только, если Вы часто работаете как root. Лучше переназначить почту root на Ваш логин, устанавливая псевдоним почты как описано в главе 19 или главе 18.

Как бы тщательно не был настроен сайт, что-то непременно произойдет. Следовательно, поддержание системы также означает поддержку адреса для жалоб пользователей. Обычно люди ожидают, что администратор системы может быть достигнут по e-mail по крайней мере как root, но имеются также другие адреса, которые обычно используются, чтобы достать (во всех смыслах) человека, ответственного за специфический аспект системы. Например, жалобы относительно конфигурации почты будут обычно адресованы postmaster, а проблемы с системой новостей могут быть сообщены newsmaster или usenet. Почта на hostmaster должна быть переназначена человеку, отвечающему за базисные сетевые услуги компьютера и обслуживание имен DNS, если Вы выполняете сервер имен.

Защита системы

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

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

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

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

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

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

Еще одним источником головной боли являются программы, которые допускают вход в систему или выполнение команды с ограниченной авторизацией. Команды rlogin, rsh и rexec очень полезные, но их проверка сводится к авторизации стороны вызова. Авторизация основана на доверии к имени вызывающего компьютера, полученного из сервера имен (мы будем говорить о нем позже), который может быть фальшивым. Сегодня должно стать обычной задачей полностью отключить r-команды и заменить их на набор инструментальных средств ssh. Эти инструментальные средства используют намного более надежный опознавательный метод и обеспечивают также другие услуги, типа шифрования и сжатия.

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

Назад | Глобальное оглавление | Вперед
Сеть в Linux | Локальное оглавление | Настройка сетей TCP/IP


Installing sendmail

Назад Глава 18. Sendmail Вперед

Установка sendmail

Агент передачи почты sendmail входит в готовом виде почти во все дистрибутивы Linux. Установка в этом случае относительно проста. Несмотря на этот факт, имеются веские причины установить sendmail из исходников, особенно, если Вы заботитесь о безопасности своей системы. Программа sendmail очень сложна и за эти годы в ней отлавливалось немало критичных для защиты ошибок. Один из самых лучших известных примеров: RTM Internet worm, который эксплуатировал проблему переполнения буфера в ранних версиях sendmail. Об этом кратко упомянуто в главе 9. Большинство проблем с защитой связаны с переполнением буфера, и здесь очень важна версия sendmail. Дело в том, что все атаки переполнения буфера полагаются на данные, сохраняемые в специфических местах, а эти места различаются от версии к версии. Построение sendmail из исходников может помочь уменьшить риск. Современные версии sendmail менее уязвимы, потому что они прошли чрезвычайно тщательное исследование, поскольку защита стала очень важна.

Исходники sendmail доступны через анонимный FTP с ftp.sendmail.org.

Компиляция пакета очень проста, поскольку sendmail непосредственно поддерживает Linux на уровне исходного кода. Чтобы собрать пакет, надо скомандовать:
# cd /usr/local/src
# tar xvfz sendmail.8.9.3.tar.gz
# cd src
# ./Build
Вам нужны права root, чтобы завершить установку. Для этого скомандуйте:
# cd obj.Linux.2.0.36.i586
# make install
Вы установили двоичные файлы sendmail в каталог /usr/sbin. Несколько символических связей к sendmail будут установлены в каталог /usr/bin. Мы будем говорить относительно этих связей, когда будем обсуждать общие задачи в управлении sendmail.

Назад | Глобальное оглавление | Вперед
Sendmail | Локальное оглавление | Обзор файлов настроек


Overview of Configuration Files

Назад Глава 18. Sendmail Вперед

Обзор файлов настроек

Обычно sendmail бывает установлен через файл конфигурации системы (как правило, с именем /etc/mail/sendmail.cf или (в старых дистрибутивах) /etc/sendmail.cf или /usr/lib/sendmail.cf). Этот файл построен на собственном макроязыке и его редактирование чрезвычайно сложно.

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

Назад | Глобальное оглавление | Вперед
Установка sendmail | Локальное оглавление | Файлы sendmail.cf и sendmail.mc


The sendmail.cf and sendmail.mc Files

Назад Глава 18. Sendmail Вперед

Файлы sendmail.cf и sendmail.mc

Макропроцессор m4 генерирует файл sendmail.df, когда обрабатывает макрофайл конфигурации, созданный локальным администратором системы. Обычно он называется sendmail.mc.

Процесс конфигурации, в основном, вопрос создания подходящего файла sendmail.mc, который включает макрокоманды, описывающие желательную конфигурацию. Макрокоманды представляют собой выражения, которые макропроцессор m4 понимает и разворачивает в синтаксис файла sendmail.cf. Макровыражения составлены из макроимени (текст в заглавных буквах в начале), которое может быть уподоблено функции в языках программирования, и некоторых параметров (текст внутри скобок), которые используются в расширении. Параметры могут быть переданы буквально в генерируемый файл sendmail.cf или использоваться, чтобы управлять путем, которым происходит обработка данной макрокоманды в подготовленном файле sendmail.mc.

Файл sendmail.mc для минимальной конфигурации (UUCP или SMTP со всей нелокальной почтой, передаваемой на непосредственно связанный интеллектуальный хост (smart host), может быть длиной всего в 10 или 15 строк, исключая комментарии.

Два примера файла sendmail.mc

Если Вы администратор нескольких различных почтовых хостов, не стоит называть Ваш файл конфигурации sendmail.mc. Вместо этого общей традицией является называть файл именем хоста, например, vstout.m4. Имя действительно не имеет значения, пока вывод назван sendmail.cf. Обеспечение уникального имени файла конфигурации для каждого хоста позволяет хранить все файлы конфигурации в одном и том же каталоге. Рассмотрим два примера файлов.

Большинство конфигураций sendmail сегодня использует только SMTP. Очень просто сконфигурировать sendmail для SMTP. Пример 18-1 ожидает, что сервер DNS будет доступен и будет пытаться принимать и доставлять всю почту для хостов, используя только SMTP.

Пример 18-1. Образец файла настройки vstout.smtp.m4

divert(-1)
#
# Sample configuration file for vstout - smtp only
#
divert(0)
VERSIONID(`@(#)sendmail.mc      8.7 (Linux) 3/5/96')
OSTYPE(`linux')
#
# Include support for the local and smtp mail transport protocols.
MAILER(`local')
MAILER(`smtp')
#
FEATURE(rbl)
FEATURE(access_db)
# end

Файл sendmail.mc для vstout показан в примере 18-2. Машина vstout использует SMTP, чтобы общаться со всеми хостами в LAN. Кроме того, конфигурация для vstout посылает всю почту для других адресатов на межсетевой почтовый хост moria по протоколу UUCP

Пример 18-2. Образец файла настройки vstout.uucpsmtp.m4

divert(-1)
#
# Sample configuration file for vstout
#
divert(0)
VERSIONID(`@(#)sendmail.mc      8.7 (Linux) 3/5/96')
OSTYPE(`linux')
dnl
# moria is our smart host, using the "uucp-new" transport.
define(`SMART_HOST', `uucp-new:moria')
dnl
# Support the local, smtp and uucp mail transport protocols.
MAILER(`local')
MAILER(`smtp')
MAILER(`uucp')
LOCAL_NET_CONFIG
# This rule ensures that all local mail is delivered using the
# smtp transport, everything else will go via the smart host.
R$* < @ $* .$m. > $*    $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3
dnl
#
FEATURE(rbl)
FEATURE(access_db)
# end

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

Обычно используемые параметры sendmail.mc

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

  1. VERSIONID

  2. OSTYPE

  3. DOMAIN

  4. FEATURE

  5. Local macro definitions

  6. MAILER

  7. LOCAL_* rulesets

Комментарии (Comments)

Строки в sendmail.mc, которые начинаются с #, не обрабатываются m4 и будут по умолчанию выводиться непосредственно в файл sendmail.cf. Это полезно, если Вы хотите комментировать, что Ваша конфигурация делает.

Допустимы комментарии в sendmail.mc, которые не попадут в файл sendmail.cf: Вы можете использовать лексемы m4 divert и dnl. Команда divert(-1) прекратит весь вывод, divert(0) восстановит его к значению по умолчанию. Любой вывод, сгенерированный строками между ними будет отброшен. В нашем примере, мы использовали этот механизм для создания комментария, который появляется только в файле sendmail.mc. Чтобы достичь того же самого результата для одной строки, можно использовать команду dnl, которая означает, буквально, "удаление всех символов следующей строки и перевод на новую строку". Я также использовал это в примере.

Это стандартные свойства m4, и Вы можете получить больше информации относительно их из man-страницы.

VERSIONID и OSTYPE

VERSIONID(`@(#)sendmail.mc  8.9 (Linux) 01/10/98')
Макрокоманда VERSIONID факультативная, но полезно записать версию конфигурации sendmail в файл sendmail.cf. Так что Вы будете часто сталкиваться с этим. В любом случае убедитесь в наличии:

OSTYPE(`linux')
Это, вероятно, наиболее важное определение. Макрокоманда OSTYPE заставляет включить файл определений, которые являются хорошими значениями по умолчанию для Вашей операционной системы. Большинство определений в файле OSTYPE устанавливают имена различных файлов конфигурации, имена разных служебных каталогов и имя почтовой программы. Стандартный комплект исходных кодов sendmail включает такой файл для Linux. Многие дистрибутивы Linux, особенно Debian, имеют собственный файл определения, который является полностью совместимым с Linux-FHS. При наличии такого файла следует использовать именно его, а не поставляемую в комплекте с sendmail версию.

Определение OSTYPE должно располагаться поближе к началу файла sendmail.mc, так как много других определений зависят от него.

DOMAIN

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

Стандартная установка имеет каталог шаблонов макрокоманд m4, используемых, чтобы управлять процессом конфигурации. Этот каталог обычно называется /usr/share/sendmail.cf. Здесь Вы найдете подкаталог, названный domain, содержащий проблемно-зависимые шаблоны конфигурации. Для использования определения DOMAIN, надо создать свой файл, содержащий стандартные определения для соответствующего домена, и вписать его в каталог domain.

Пакет исходных кодов sendmail приходит с рядом типовых файлов макрокоманд domain, которые Вы можете использовать как примеры при построении своего.

Если Вы сохранили Ваш файл макрокоманды domain как /usr/share/sendmail.cf/domain/vbrew.m4, надо включить в файл sendmail.mc определение:
DOMAIN(`vbrew')

FEATURE

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

Чтобы использовать любое из перечисленных свойств, Вы должны включить в Ваш sendmail.mc строку наподобие:
FEATURE(name)
где name задает имя свойства. Некоторые свойства берут один факультативный параметр. Если Вы желаете использовать нечто отличное от значения по умолчанию, Вы должны использовать запись:
FEATURE(name, param)
где param задает параметр.

Локальные макроопределения

Стандартные макрофайлы конфигурации sendmail обеспечивают большое количество обработчиков прерываний и переменных, которыми Вы можете настраивать конфигурацию. Они названы локальными макроопределениями (local macro definitions) . Многие из них перечислены в файле CF в пакете с исходными кодами sendmail.

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

Определение протокола транспортировки почты

Если Вы хотите использовать sendmail для передачи нелокальной почты, Вы должны сообщить какой транспорт использовать. Макрокоманда MAILER делает это очень простым. Текущая версия sendmail поддерживает ряд протоколов транспорта почты. Некоторые из них экспериментальны, другие, вероятно, очень редко используются.

В нашей сети мы нуждаемся в SMTP транспорте, чтобы посылать и получать почту в локальной сети, и в UUCP транспорте, чтобы посылать и получать почту от нашего интеллектуального хоста. Чтобы достичь этого, мы просто включаем транспорты smtp и uucp. Транспорт local включен по умолчанию, но может быть определен для ясности, если Вы желаете. Если Вы включаете оба транспорта, smtp и uucp, Вы должны всегда убедиться, что определили smtp первым.

Обычно используемые транспорты, доступные Вам в макрокоманде MAILER, описаны в следующем списке:

local

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

smtp

Этот транспорт осуществляет Simple Mail Transport Protocol (SMTP), который является наиболее общим средством транспортировки почты в Internet. Когда Вы включаете этот транспорт, четыре агента будут конфигурированы: smtp (нормальный SMTP), esmtp (расширенный SMTP), smtp8 (8-битный двоичный SMTP) и relay (специально разработан для шлюзования писем между разными хостами).

uucp

Транспорт uucp обеспечивает поддержку двух агентов: uucp-old, который является традиционным UUCP, и uucp-new, который позволяет указывать много получателей, которые будут обработаны в одной передаче сразу.

usenet

Этот агент позволяет Вам посылать сообщения почты непосредственно в сети Usenet. Любое локальное сообщение, направленное к адресу news.group.usenet, будет подано в сеть новостей для группы новостей news.group.

fax

Если Вы имеете установленное программное обеспечение HylaFAX, этот агент позволит Вам направлять письма так, что можно будет создать шлюз email-fax. Это свойство было экспериментальным на момент написания книги, и более подробная информация может быть получена на http://www.vix.com/hylafax.

Имеются другие агенты, например, pop, procmail, mail11, phquery и cyrus, которые являются полезными, но менее распространенными. Документация к ним есть в пакете исходных кодов.

Настройка маршрутизации почты для локальных хостов

Конфигурация Virtual Brewery, вероятно, более сложная, чем требуется для большинства мест. Большинство машин сегодня использовало бы только транспорт SMTP и не работали бы с UUCP вообще. В нашей конфигурации мы настроили "интеллектуальный хост (smart host)", который используется, чтобы обработать всю исходящую почту. Так как мы используем транспорт SMTP в нашей локальной сети, мы должны сообщить sendmail, что он не должен посылать локальную почту через smart host. Макрокоманда LOCAL_NET_CONFIG позволяет Вам вставить правила sendmail непосредственно в sendmail.cf, чтобы изменять путь, которым локальная почта обработана. Позже эти правила будут рассмотрены подробнее, пока же примем тот факт, что любая почта для хоста vbrew.com должна доставляться через SMTP.

Назад | Глобальное оглавление | Вперед
Обзор файлов настроек | Локальное оглавление | Построение файла sendmail.cf


Generating the sendmail.cf File

Назад Глава 18. Sendmail Вперед

Построение файла sendmail.cf

Когда Вы завершили редактирование файла конфигурации m4, Вы должны его обработать, чтобы построить файл /etc/mail/sendmail.cf. Это делается так:

# cd /etc/mail
# m4 /usr/share/sendmail.cf/m4/cf.m4 vstout.uucpsmtp.mc >sendmail.cf

Эта команда вызывает макропроцессор m4 и передает ему имена двух файлов макроопределений. Затем m4 обрабатывает файлы в порядке поступления. Первый файл стандартный шаблон макрокоманд, обеспеченный исходным пакетом sendmail, второй, конечно, является файлом, содержащим наши собственные определения макрокоманд. Вывод команды направлен в файл /etc/mail/sendmail.cf, который является адресатом.

Вы можете теперь запустить sendmail с новой конфигурацией всех параметров.

Назад | Глобальное оглавление | Вперед
Файлы sendmail.cf и sendmail.mc | Локальное оглавление | Интерпретация и написание правил переписки


Interpreting and Writing Rewrite Rules

Назад Глава 18. Sendmail Вперед

Интерпретация и написание правил переписки

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

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

sendmail.cf: команды R и S

В файле sendmail.cf наборы определяются, используя команды Sn , где n определяет текущий набор.

Правила непосредственно появляются в командах R. Поскольку каждая команда R читается, это правило будет добавлено к текущему набору.

Если вы имеете дело только с файлом sendmail.mc, Вы не должны заботиться о командах S, поскольку макрокоманды будут формировать их для Вас автоматом. Но нужно самому кодировать правила команд R.

Набор правил в sendmail выглядит так:
Sn
Rlhs rhs
Rlhs2 rhs2

Полезные макросы

sendmail использует ряд стандартных макросов. Наиболее полезные из них применительно к написанию правил:

$j

Полное доменное имя хоста.

$w

Компонент hostname из записи FQDN.

$m

Компонент domain name записи FQDN.

Эти макросы можно включать в правила. Наша конфигурация использует макрос $m.

Левая сторона

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

$@

Соответствует строго нулю элементов.

$*

Соответствует нулю или большему числу элементов.

$+

Соответствует одному или большему числу элементов.

$-

Соответствует строго одному элементу.

$=x

Соответствует любой фразе в классе x

$x

Соответствует любому слову НЕ в классе x

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

Правая сторона

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

$ n

Этот метасимвол будет заменен на n-ое выражение с левой стороны.

$[name $]

Этот метасимвол превратит hostname в каноническое имя.

$(map key $@arguments $:default $)

Это более общая форма поисковой таблицы. Вывод: результат поиска ключа в таблице map с использованием параметров arguments. Здесь map может быть любой из поддерживаемых sendmail карт, таких как virtusertable, которые я опишу немного позже. Если поиск провалился, будет использовано значение default. Если оно не задано, ничего не изменится, а запись key будет выведена так, как пришла.

$>n

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

$#mailer

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

$@host

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

$:user

Определяет целевого пользователя для сообщения почты.

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

$@

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

$:

Заставляет это правило завершаться немедленно, но остаток текущего набора будет обработан.

Пример простого правила

Рассмотрим следующее правило левой стороны:
$* < $+ >

Это правило соответствует нулю или большему количеству элементов, сопровождаемых символом <, за которым идет один или большее число лексем и символ > после них.

Если это правило применить к brewer@vbrew.com или к Head Brewer < >, соответствия не будет. В первом случае потому, что нет символа <. Во втором из-за того, что $+ соответствует одному или большему числу лексем, а в данном случае никаких лексем между символами <> нет. В любом случае при несоответствии правила, правая сторона не используется.

Если правило применить к Head Brewer < brewer@vbrew.com >, то оно сработает, и на правой стороне $1 заменится на Head Brewer, а $2 на brewer@vbrew.com.

Если правило применить к < brewer@vbrew.com > оно сработает потому, что $* соответствует нулю или более лексем, а на правой стороне $1 заменится на пустую строку.

Семантика наборов правил

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

LOCAL_RULE_3

Набор 3 ответственен за преобразование адреса в произвольном формате в общий формат, который sendmail будет обрабатывать. Ожидаемый выходной формат: local-part@ host-domain-spec.

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

LOCAL_RULE_0 и LOCAL_NET_CONFIG

Набор 0 применяется к адресам получателя после набора 3. Макрос LOCAL_NET_CONFIG управляет правилами для вставки в нижнюю половину набора 0.

Набор 0 выполнит доставку сообщения получателю, он должен установить три параметра: транспорт, хост и получатель. Правила будут помещены перед любым определением интеллектуального хоста. Этим способом обрабатываются все smtp-соединения для пользователей LAN в нашем примере.

LOCAL_RULE_1 и LOCAL_RULE_2

Набор 1 применяется ко всем адресам отправителей, а набор 2 ко всем адресам получателей. Обычно они пустые.

Интерпретация правил в нашем примере

В примере 18-3 использована макрокоманда LOCAL_NET_CONFIG, чтобы объявить локальное правило, которое гарантирует, что любая почта внутри нашего домена будет доставлена непосредственно, используя транспорт smtp. Теперь, когда мы рассмотрели, как строятся правила, мы сможем понять, как это правило работает. Давайте возьмем другой пример, чтобы рассмотреть этот процесс.

Пример 18-3. Правило из vstout.uucpsmtp.m4

LOCAL_NET_CONFIG
# This rule ensures that all local mail is delivered using the
# smtp transport, everything else will go via the smart host.
R$* < @ $* .$m. > $*  $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

Известно, что макрос LOCAL_NET_CONFIG вызовет правило, которое будет вставлено где-нибудь близко к концу набора 0, но перед любым определением интеллектуального хоста. Также известно, что набор 0 последний. Здесь должны быть три параметра: транспорт, хост и пользователь.

Две строки комментария можно игнорировать: они все равно ничего не делают. Правило задано строкой, начинающейся с R. Мы знаем, что R является командой sendmail и добавляет это правило к текущему набору. В данном случае это набор 0. Давайте рассматривать левую и правую стороны.

Левая сторона правила выглядит так: $* < @ $* .$m. > $*.

Набор 0 ищет символы < и > потому, что они должны прийти из набора 3. Набор 3 преобразует адреса в общую форму и делает синтаксический анализ проще, он также помещает часть host адреса почты в символы <>.

Это правило соответствует любому адресу почты, который напоминает: 'DestUser < @ somehost.ourdomain. > Some Text' . То есть, это соответствует почте для любого пользователя на любом компьютере в нашем домене.

Помните, что текст, согласованный метасимволами на левой стороне правила, будет назначен макроопределениям для использования на правой стороне. В примере первое определение $* соответствует тексту от начала адреса до символа <. Весь этот текст назначается переменной $1 для работы с ним на правой стороне. Второе определение $* назначено $2, а последнее к $3.

Мы теперь имеем достаточно данных, чтобы понять левую сторону. Эти правила соответствуют почте для любого пользователя в любом компьютере в нашем домене. Имя пользователя будет в $1, имя хоста в $2, любой сопроводительный текст в $3. Затем вызывается правая сторона, чтобы обработать эти данные.

Давайте теперь рассматривать то, что мы ожидаем видеть в выводе. Правая сторона нашего правила выглядит так: $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3.

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

Метасимвол $# заставляет это правило использовать указанный транспорт, в данном случае smtp.

Метасимвол $@ задает целевой хост. В этом примере целевой компьютер определен как $2.$m., что является полным доменным именем в нашем домене, то есть FQDN, созданный из компонента hostname, назначенного $2 левой стороной, с добавлением доменного имени (.$m.).

Метасимвол $: определяет целевого пользователя, который тоже задан на левой стороне правила и хранится в $1.

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

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

Назад | Глобальное оглавление | Вперед
Построение файла sendmail.cf | Локальное оглавление | Опции sendmail


Configuring sendmail Options

Назад Глава 18. Sendmail Вперед

Опции sendmail

Пакет sendmail имеет ряд параметров, которые позволяют Вам настраивать выполнение ряда задач. Я рассмотрю лишь основные, полный перечень огромен.

Чтобы конфигурировать любые из этих параметров, Вы можете определять их в файле конфигурации m4, что является предпочтительным методом, или вставлять их непосредственно в файл sendmail.cf. Например, если нужно, чтобы sendmail запускал новый процесс для каждого сообщения почты, нужно добавить строку к файлу конфигурации m4:
define(`confSEPARATE_PROC',`true')

Соответствующая запись в файле sendmail.cf:
O ForkEachJob=true

Следующий список описывает общие параметры sendmail m4 и эквиваленты sendmail.cf:

confMIN_FREE_BLOCKS (MinFreeBlocks)

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

confME_TOO (MeToo)

При раскрытии псевдонимов отправитель письма может оказаться в списке получателей. Эта опция определяет, получит ли отправитель копию. Имеющие силу значения: "true" и "false" (значение по умолчанию false).

confMAX_DAEMON_CHILDREN (MaxDaemonChildren)

При получении sendmail входящего соединения SMTP с удаленного хоста, для его обработки запускается отдельная копия sendmail. Но память-то у Вашей машины не резиновая! При большом количестве таких подключений кончится все, что угодно. Тем более, sendmail не относится к числу программ с низким потреблением ресурсов. Эта опция позволяет задать максимальное число копий, которые работают одновременно. Если лимит исчерпан, входящие соединения будут отклоняться до завершения работы какой-то копии. Значение по умолчанию: undefined (не определено).

confSEPARATE_PROC (ForkEachJob)

При обработке очереди почты и посылке сообщений sendmail обрабатывает одно сообщение за раз. Когда эта опция включена, sendmail будет порождать по копии для каждого письма. Это особенно полезно, когда имеются некоторые сообщения, которые увязли в очереди потому, что есть проблемы с целевым хостом. (Значение по умолчанию: false).

confSMTP_LOGIN_MSG (SmtpGreetingMessage)

При подключении sendmail выдает приветствие. По умолчанию, это сообщение содержит hostname, имя агента передачи почты, версию sendmail, локальную версию и текущую дату. RFC 821 определяет, что первым словом приветствия должно быть полным доменным именем компьютера, но остальная часть может быть произвольной. Вы можете определять здесь даже макрокоманды sendmail, они будут нормально работать! Единственные люди, которые это сообщение увидят, это администраторы, пытающиеся понять, почему не работает почта у них, и люди, которым интересна настройка Вашего сервера (например, хакеры). Слово "EMSTP" между первым и вторым словами служит сигналом удаленным хостам о поддержке этого протокола (значение по умолчанию: $j Sendmail $v/$Z; $b).

Назад | Глобальное оглавление | Вперед
Интерпретация и написание правил переписки | Локальное оглавление | Наиболее распространенные конфигурации


Some Useful sendmail Configurations

Назад Глава 18. Sendmail Вперед

Наиболее распространенные конфигурации

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

Заполнение поля From: пользователями

Иногда полезно переписывать поле From: исходящих писем. Например, есть web-программа, которая отсылает почту. Обычно письмо от нее придет от имени пользователя, которому принадлежит web-сервер. Но можно определить другой исходный адрес так, чтобы почта исходила с другого адреса. Пакет sendmail обеспечивает средства определения того, для каких пользователей это делать.

Опция use_ct_file допускает спецификацию и использование файла, который вносит в список имена доверенных пользователей. По умолчанию таких пользователей мало (root, например). Имя этого файла обычно /etc/mail/trusted-users в системах, использующих каталог настроек /etc/mail или /etc/sendmail.ct во всех остальных. Вы можете определять имя и расположение файла макросом confCT_FILE.

Добавьте FEATURE(use_ct_file) к Вашему файлу sendmail.mc для поддержки возможности.

Управление почтовыми псевдонимами

Псевдонимы почты мощное свойство, которое дает возможность письмам попадать в почтовые ящики, которые являются альтернативными именами для пользователей или процессов на компьютере адресата. Например, обычным явлением считается адрес для комментариев, связанных с сервером WWW, названный "webmaster". Часто нет пользователя, известного как "webmaster" на целевой машине, взамен него подставляется имя другого пользователя системы. Другое общее применение псевдонимов: списки рассылки. Здесь псевдоним направляет входящие сообщения серверу списка рассылки для обработки.

Файл /etc/aliases обычно хранит псевдонимы. Пакет sendmail консультируется с этим файлом при определении, как обработать входящее сообщение почты. Если он находит запись в этом файле, соответствующую пользователю назначения в сообщении почты, он переназначает сообщение на нового получателя.

Есть три ситуации, которые связаны с использованием псевдонимов:

  • Псевдоним обеспечивает адрес для почты, направляемой одному или нескольким получателям.

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

  • Псевдоним может посылать почту в файл.

Все системы требуют псевдонимов для Postmaster и MAILER-DAEMON, для совместимости с ошибками различных описаний RFC.

Следует быть очень осторожным с программами, которым передается почта, поскольку sendmail выполняется с правами root.

Детали, относительно псевдонимов почты, могут быть найдены на man-странице aliases(5). Образец файла aliases показан в примере 18-4.

Пример 18-4. Образец файла aliases

# The following two aliases must be present to be RFC-compliant.
# It is important to resolve them to 'a person' who reads mail routinely.
postmaster:    root                            # required entry
MAILER-DAEMON: postmaster                      # required entry
#
# demonstrate the common 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 file
changefeed:    |/usr/local/lib/gup             # alias that invokes program
complaints:    /var/log/complaints             # alias writes mail to file

После обновления файла /etc/aliases выполните:
# /usr/bin/newaliases
Это пересоздаст базу данных, используемую sendmail для работы с псевдонимами. Команда /usr/bin/newaliases является эквивалентом выполнения:
# /usr/lib/sendmail -bi
Такое имя понадобилось из-за распространенности команды newaliases для этих целей.

Использование интеллектуальных хостов (Smart Host)

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

Такой подход упрощает настройку. Вы можете упростить управление при наличии только одного компьютера со всесторонней конфигурацией почты, которая знает, как обработать типы транспорта почты, например UUCP, Usenet и прочие. Все остальные компьютеры нуждаются только в одном транспорте для передачи писем на этот центральный хост. Хосты, которые выполняют центральную маршрутизацию почты названы интеллектуальными хостами (smart hosts). Если Вы имеете такой хост, который примет Вашу почту, то можете смело обрушить на него весь поток писем: разберется.

Еще одним применением такого хоста является протаскивание почты через частный firewall. Часто встречаются сети, в которых используются недействительные IP-адреса. Такие сети подключаются к Internet через firewall. Прямая отправка почты из такой сети невозможна: машины в ней не могут работать по SMTP в Internet непосредственно. Вместо этого можно оснастить firewall интеллектуальной почтовой функцией. Интеллектуальный хост способен установить прямые сетевые подключения с компьютерами в частной сети и в Internet. Заодно он поработает маршрутизатором, пересылая входящую почту на внутренние машины.

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

Пакет sendmail обеспечивает простой метод конфигурирования интеллектуальных хостов, использующий свойство SMART_HOST;
define(`SMART_HOST', `uucp-new:moria')
LOCAL_NET_CONFIG
# This rule ensures that all local mail is delivered using the
# smtp transport, everything else will go via the smart host.
R$* < @ $* .$m. > $*    $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

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

В нашей конфигурации мы используем транспорт uucp-new для передачи на UUCP-хост moria. Если бы мы хотели конфигурировать sendmail, чтобы использовать интеллектуальный хост с поддержкой SMTP, надо было бы написать следующее:
define(`SMART_HOST', `mail.isp.net')
Мы не должны определять SMTP как транспорт, так как это принято по умолчанию.

Давайте подумаем, что сделают правило переписки и макрос LOCAL_NET_CONFIG.

Макрос LOCAL_NET_CONFIG позволяет добавлять к Вашей конфигурации правила sendmail, которые определяют, какая почта должна остаться внутри локальной системы. В нашем примере, мы использовали правило, которое соответствует любому адресу e-mail, где компьютер принадлежит нашему домену (.$m.), и почта будет переслана на него напрямую по SMTP. Это гарантирует, что любое сообщение для компьютера в нашей локальной сети будет направлено немедленно к SMTP-транспорту и послано на тот компьютер до того, как свалиться на наш интеллектуальный хост, который является заданной по умолчанию стратегией обработки.

Противоспамовая оборона

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

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

Real-time Blackhole List

Real-time Blackhole List представляет собой публичное средство, предназначенное уменьшить объем спама. Известные адреса e-mail и хосты перечисляются в базе данных, доступной через Internet. Они вводятся туда людьми, получившими спам с этих адресов. Домены иногда находятся в списке из-за ошибок при вычислении пути спама. Но эти ошибки система исправляет, ориентируясь на поступающие новые сообщения. Детальную информацию о сервисе можно получить на его сайте Mail Abuse Protection System http://maps.vix.com/rbl.

Если включить соответствующую поддержку в sendmail, он проверит исходный адрес каждого входящего сообщения почты по Real-time Blackhole List, чтобы определить, принимать ли сообщение. Если у Вас большой сервер и много пользователей, это свойство может сохранять значительный объем дискового пространства. Это свойство принимает параметр, задающий имя сервера для использования. По умолчанию это главный сервер rbl.maps.vix.com.

Для настройки поддержки Real-time Blackhole List добавьте в файл sendmail.mc следующее определение настроек:
FEATURE(rbl)

Чтобы определить другой сервер RBL, используйте определение:
FEATURE(rbl,`rbl.host.net')

База данных доступа (access database)

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

Это очень важный аспект, поскольку такой подход позволяет бороться со спамерами, обходящими Real-time Blackhole List. Вместо того, чтобы посылать почту Вам непосредственно, спамер передаст почту через некоторый другой компьютер, который в списке не отмечен. В результате спам дойдет-таки до адресата! Чтобы гарантировать, что Ваш компьютер не используются таким образом, Вы должны передавать почту только для известных компьютеров. Версии sendmail 8.9.0 и старше вообще блокируют ретрансляцию почты по умолчанию.

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

База данных доступа это совокупность правил, которые описывают, какое действие должно быть выполнено для сообщений, полученных от указанных компьютеров. Заданный по умолчанию файл управления доступом называется /etc/mail/access. Таблица в нем имеет простой формат. Каждая строка таблицы содержит правило доступа. Левая сторона каждого правила образец, используемый, чтобы сравнивать с ним адреса. Это может быть полный адрес email, hostname или адрес IP. Правая сторона задает действие. Имеются пять типов действия, а именно:

OK

Принять сообщение почты.

RELAY

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

REJECT

Отклонить сообщение почты.

DISCARD

Отклонить сообщение почты, используя транспорт $#discard.

### any text

Вернуть сообщение об ошибке, используя код ошибки ### (указаны в RFC-821) или "any text" в качестве ответного сообщения.

Простой пример файла /etc/mail/access:
friends@cybermail.com   REJECT
aol.com                 REJECT
207.46.131.30           REJECT
postmaster@aol.com      OK
linux.org.au            RELAY

Этот пример отклонит все письма с адреса friends@cybermail.com, любого хоста в домене aol.com и хоста 207.46.131.30. Следующее правило разрешает принять почту с postmaster@aol.com, несмотря на тот факт, что домен имеет запрещающее правило. Последнее правило позволяет передачу почты с любого хоста в домене linux.org.au.

Для включения поддержки access database впишите определение в sendmail.mc:
FEATURE(access_db)

Заданное по умолчанию определение формирует базу данных, используя вызов hash -o /etc/mail/access, который генерирует простую базу данных из текстового файла. Этого достаточно в большинстве случаев. Есть другие параметры, которые Вы должны изучить при использовании большой базы данных доступа. Но ввиду малой распространенности таких конфигураций, я не буду рассматривать их.

Запрещение пользователям получать почту

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

Для включения данного свойства добавьте в sendmail.mc:
FEATURE(access_db)
FEATURE(blacklist_recipients)

Чтобы отключить получение почты для локального пользователя, просто добавьте его в базу данных доступа. Обычно Вы будете использовать запись ###, которая возвратит сообщение об ошибке отправителю, так что он будет знать, почему почта не доходит. Это свойство применяется и для виртуальных доменов, но Вы должны включить виртуальный домен в спецификации базы данных доступа. Образец файла /etc/mail/access:
daemon          550 Daemon does not accept or read mail.
flacco          550 Mail for this user has been administratively disabled.
grump@dairy.org 550 Mail disabled for this recipient.

Настройка виртуальных хостов

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

Прием почты для других доменов

Когда sendmail принимает сообщение e-mail, он сравнивает хост назначения в заголовке с именем локальной машины. Если они совпали, sendmail принимает сообщение для локальной доставки. В противном случае, sendmail может принять письмо для последующей пересылки адресату (подробности в разделе База данных доступа (access database) выше).

Если нужно конфигурировать виртуальные домены, первое, что нужно сделать, это убедить sendmail в необходимости приема почты для виртуальных доменов. Это очень легко.

В sendmail есть свойство use_cw_file, позволяющее определить имя файла, где мы сохраняем имена доменов, для которых sendmail принимает почту. Чтобы конфигурировать это свойство, добавьте объявление свойства к файлу sendmail.mc:
FEATURE(use_cw_file)

Заданное по умолчанию имя файла будет /etc/mail/local-host-names для дистрибутивов, хранящих настройки в каталоге /etc/mail или /etc/sendmail.cw для всех остальных. Впрочем, Вы можете определять имя и расположение файла, переопределив макрос confCW_FILE:
define(`confCW_FILE',`/etc/virtualnames')

Если нужно создать виртуальные домены bovine.net, dairy.org и artist.org, впишите в файл /etc/mail/local-host-names:
bovine.net
dairy.org
artist.org

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

Пересылка почты с вирутальных хостов на другие пункты назначения

Возможность sendmail под названием virtusertable предоставляет поддержку таблицы настройки виртуальных доменов. Таблица виртуальных пользователей отображает входящую почту, предназначенную для адресов user@host на другие адреса otheruser@otherhost. Можно рассматривать это как продвинутое свойство псевдонима почты, которое функционирует, используя не только имя пользователя, но и его домен.

Для включения поддержки virtusertable допишите в свой файл sendmail.mc:
FEATURE(virtusertable)

По умолчанию файл, содержащий правила трансляции почты, называется /etc/mail/virtusertable. Это можно поменять пернастройкой макроса, подробности в документации на sendmail, там много опций.

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

Типичный образец записи:
samiam@bovine.net     colin
sunny@bovine.net      darkhorse@mystery.net
@dairy.org            mail@jhm.org
@artist.org           $1@red.firefly.com
В этом примере есть три виртуальных домена: bovine.net, dairy.org и artist.org.

Первая запись перешлет почту, посланную пользователю в виртуальном домене bovine.net локальному пользователю на данной машине. Вторая запись переназначает почту пользователю в другой домен. Обратите внимание, что первая и вторая записи работают с разными пользователями одного домена! Третья запись переназначает всю почту любого пользователя виртуального домена dairly.org на один адрес в другом домене. Наконец, четвертая запись переназначает всю почту пользователей в artist.org тем же самым пользователям, но уже в другом домене: например, julie@artists.org будет переназначена на julie@red.firefly.com.

Назад | Глобальное оглавление | Вперед
Опции sendmail | Локальное оглавление | Тестирование настроек


Testing Your Configuration

Назад Глава 18. Sendmail Вперед

Тестирование настроек

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

sendmail поддерживает "режим адресного теста" (address test mode), который позволяет проверять конфигурацию и идентифицировать любые ошибки. В этом режиме работы sendmail вызывается из командной строки и запрашивает определения правил и почтовые адреса назначения. Затем sendmail обрабатывает адреса, используя определенные правила и показывая вывод каждого правила. Чтобы перейти в этот режим, вызовите sendmail с указанием параметра -bt:

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>

Заданный по умолчанию файл конфигурации /etc/mail/sendmail.cf. Вы можете определять альтернативу параметром -C. Чтобы проверить конфигурацию, надо выбрать ряд адресов, чтобы обработать их по правилам доставки почты. Для иллюстрации используем более сложную настройку для UUCP (пример 18-2).

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

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac
rewrite: ruleset   3   input: isaac
rewrite: ruleset  96   input: isaac
rewrite: ruleset  96 returns: isaac
rewrite: ruleset   3 returns: isaac
rewrite: ruleset   0   input: isaac
rewrite: ruleset 199   input: isaac
rewrite: ruleset 199 returns: isaac
rewrite: ruleset  98   input: isaac
rewrite: ruleset  98 returns: isaac
rewrite: ruleset 198   input: isaac
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset   0 returns: $# local $: isaac

Этот вывод показывает нам, как sendmail обрабатывает почту, адресованную isaac на этой системе. Каждая строка показывает информацию, переданную правилу, или результат, полученный из его обработки. Мы сообщили sendmail, что надо использовать наборы правил 3 и 0, чтобы обработать адрес. По умолчанию вызывается именно набор 0, поэтому набор 3 был вызван в принудительном порядке. Последняя строка показывает, что набор 0 направляет почту пользователю isaac.

Теперь проверим почту, адресованную по SMTP адресу isaac@vstout.vbrew.com. Должен получиться тот же самый результат, что и в предыдущем примере:

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vstout.vbrew.com
rewrite: ruleset   3   input: isaac @ vstout . vbrew . com
rewrite: ruleset  96   input: isaac < @ vstout . vbrew . com >
rewrite: ruleset  96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   0   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset   0 returns: $# local $: isaac

Тест прошел успешно. Теперь проверим хождение почты на тот же адрес, но в UUCP-формате vstout!isaac.

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 vstout!isaac
rewrite: ruleset   3   input: vstout ! isaac
rewrite: ruleset  96   input: isaac < @ vstout . UUCP >
rewrite: ruleset  96 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   3 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset   0   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset  98 returns: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198   input: isaac < @ vstout . vbrew . com . >
rewrite: ruleset 198 returns: $# local $: isaac
rewrite: ruleset   0 returns: $# local $: isaac

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

Теперь проверим хождение почты на другие хосты в домене vbrew.com по протоколу SMTP:

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vale.vbrew.com
rewrite: ruleset   3   input: isaac @ vale . vbrew . com
rewrite: ruleset  96   input: isaac < @ vale . vbrew . com >
rewrite: ruleset  96 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset   3 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset   0   input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199   input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset  98   input: isaac < @ vale . vbrew . com . >
rewrite: ruleset  98 returns: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198   input: isaac < @ vale . vbrew . com . >
rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . /
    $: isaac < @ vale . vbrew . com . >
rewrite: ruleset   0 returns: $# smtp $@ vale . vbrew . com . /
    $: isaac < @ vale . vbrew . com . >

Письмо по SMTP было перенаправлено на хост vale.vbrew.com пользователю isaac. Этот тест подтверждает, что определение LOCAL_NET_CONFIG работает правильно. Для хождения почты таким способом, имя машины должно быть корректно связано с IP-адресом через файл /etc/hosts или сервис DNS. Если адрес найден не будет, произойдет следующее:

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@vXXXX.vbrew.com
rewrite: ruleset   3   input: isaac @ vXXXX . vbrew . com
rewrite: ruleset  96   input: isaac < @ vXXXX . vbrew . com >
vXXXX.vbrew.com: Name server timeout
rewrite: ruleset  96 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset   3 returns: isaac < @ vXXXX . vbrew . com >
== Ruleset 3,0 (3) status 75
rewrite: ruleset   0   input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199   input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 199 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset  98   input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset  98 returns: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset 198   input: isaac < @ vXXXX . vbrew . com >
rewrite: ruleset  95   input: < uucp-new : moria > isaac </
    @ vXXXX . vbrew . com >
rewrite: ruleset  95 returns: $# uucp-new $@ moria $: isaac </
    @ vXXXX . vbrew . com >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
    @ vXXXX . vbrew . com >
rewrite: ruleset   0 returns: $# uucp-new $@ moria $: isaac </
    @ vXXXX . vbrew . com >

Здесь результат совсем иной. Сначала набор 3 вернул сообщение об ошибке, показывающее, что имя хоста не может быть корректно преобразовано в адрес. Теперь интеллектуальный хост должен обработать любую почту, которая является недоставляемой, а данное письмо к ней как раз относится. Почта попадет на интеллекуальный хост moria через транспорт uucp-new. Этот хост может быть информирован лучше и знать, что делать с такой почтой.

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

# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 isaac@linux.org.au
rewrite: ruleset   3   input: isaac @ linux . org . au
rewrite: ruleset  96   input: isaac < @ linux . org . au >
rewrite: ruleset  96 returns: isaac < @ linux . org . au . >
rewrite: ruleset   3 returns: isaac < @ linux . org . au . >
rewrite: ruleset   0   input: isaac < @ linux . org . au . >
rewrite: ruleset 199   input: isaac < @ linux . org . au . >
rewrite: ruleset 199 returns: isaac < @ linux . org . au . >
rewrite: ruleset  98   input: isaac < @ linux . org . au . >
rewrite: ruleset  98 returns: isaac < @ linux . org . au . >
rewrite: ruleset 198   input: isaac < @ linux . org . au . >
rewrite: ruleset  95   input: < uucp-new : moria > isaac </
    @ linux . org . au . >
rewrite: ruleset  95 returns: $# uucp-new $@ moria $: isaac </
    @ linux . org . au . >
rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac </
    @ linux . org . au . >
rewrite: ruleset   0 returns: $# uucp-new $@ moria $: isaac </
    @ linux . org . au . >

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

Назад | Глобальное оглавление | Вперед
Наиболее распространенные конфигурации | Локальное оглавление | Запуск sendmail


Running sendmail

Назад Глава 18. Sendmail Вперед

Запуск sendmail

Демон sendmail может быть запущен из inetd или в качестве самостоятельного демона.

При запуске sendmail в автономном режиме, поместите команду в rc-файл, чтобы он запускался при начальной загрузке. Синтаксис обычно такой:
/usr/sbin/sendmail -bd -q10m
Аргумент -bd сообщает, чтобы sendmail выполнился как daemon. Он будет выполняться в фоновом режиме. Параметр -q10m сообщает, что надо проверять очередь каждые десять минут. Вы можете выбирать для разных очередей разное время проверки.

Для запуска sendmail из inetd используйте запись вида:
smtp  stream  tcp nowait  nobody  /usr/sbin/sendmail -bs
Аргумент -bs сообщает sendmail, использовать протокол SMTP на stdin/stdout, который требуется для использования с inetd.

Команда runq обычно представляет собой более удобную форму вызова:
# sendmail -q

Когда sendmail вызывается так, он обрабатывает любую почту в очереди. При запуске sendmail из inetd Вы должны также создать задачу cron, которая периодически выполняет runq, чтобы гарантировать, что очередь почты обслуживается сервером периодически.

Подходящая запись для cron:
# Run the mail spool every fifteen minutes
0,15,30,45 * * * * /usr/bin/runq

Большинство инсталляций sendmail обрабатывают очередь почты каждые 15 минут, как показано в данном примере.

Назад | Глобальное оглавление | Вперед
Тестирование настроек | Локальное оглавление | Советы и секреты


Tips and Tricks

Назад Глава 18. Sendmail Вперед

Советы и секреты

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

Управление почтовой очередью

Почтовая очередь хранится в каталоге /var/spool/mqueue. Программа sendmail обеспечивает средства показа форматируемого списка всех помещенных в очередь сообщений почты и их состояния.

Команда /usr/bin/mailq ведет себя идентично:
# sendmail -bp
Вывод отображает message ID, размер, время помещения в очередь, кто послал письмо и сообщение, указывающее текущее состояние. Следующий пример показывает сообщение почты, увязшее в очереди с проблемой:
$ mailq
                Mail Queue (1 request)
--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
RAA00275      124 Wed Dec  9 17:47 root
                 (host map: lookup (tao.linux.org.au): deferred)
                                   terry@tao.linux.org.au
Это сообщение все еще в очереди почты потому, что IP-адрес хоста назначения пока не нашелся.

Мы можем вынуждать sendmail начать обрабатывать очередь немедленно командой /usr/bin/runq.

Команда runq не производит вывода. sendmail начнет обрабатывать очередь почты в фоне.

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

Если Вы используете временное подключение к Internet по модему с фиксированным (fixed) IP-адресом и полагаетесь на MX-хост для сбора почты в то время, когда соединение не установлено, Вы найдете очень полезной возможность вынудить MX-хост обрабатывать очередь почты после того, как Вы устанавливаете связь.

Маленькая программа на языке perl включена в пакет sendmail именно для этого. Скрипт etrn имеет тот же эффект на удаленном хосте, какой команда runq имеет на Вашем. Если мы вызываем команду etrn, как показано в этом примере:
# etrn vstout.vbrew.com
то хост vstout.vbrew.com будет обрабатывать любую почту, поставленную в очередь для нашей локальной машины.

Обычно стоит добавить эту команду к скрипту PPP ip-up, чтобы она была выполнена сразу после того, как сетевое подключение будет установлено.

Анализ почтовой статистики

Пакет sendmail собирает данные относительно объемов передачи почты и некоторую информацию относительно хостов, которым она была доставлена. Там есть две команды, чтобы отображать эту информацию: mailstats и hoststat.

mailstats

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

Поле | Значение
M | Транспортный протокол
msgsfr | Число принятых сообщений
bytes_from | Объем принятой почты в килобайтах
msgsto | Число переданных сообщений
bytes_to | Объем передаиной почты в килобайтах
msgsreg | Сколько сообщений отклонено
msgsdis | Сколько сообщений пропущено
Mailer | Имя транспортного агента
Образец вывода команды mailstats показан в примере 18-5.

Пример 18-5. Образец вывода команды mailstats

# /usr/sbin/mailstats
Statistics from Sun Dec 20 22:47:02 1998
 M   msgsfr  bytes_from   msgsto    bytes_to  msgsrej msgsdis  Mailer
 0        0          0K       19        515K        0       0  prog
 3       33        545K        0          0K        0       0  local
 5       88        972K      139       1018K        0       0  esmtp
=============================================================
 T      121       1517K      158       1533K        0       0

Эти данные будут собраны, если опция StatusFile в sendmail.cf включена и файл состояния существует. Обычно Вы добавили бы следующее к sendmail.cf:
# status file
O StatusFile=/var/log/sendmail.st

Для перезапуска сбора статистики, Вы должны обнулить файл статистики:
> /var/log/sendmail.st
и перезапустить пакет sendmail.

hoststat

Команда hoststat отображает информацию относительно состояния хостов, которым sendmail попытался доставить почту. Вызов hoststat эквивалентен вызову:
sendmail -bh

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

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

Пример 18-6. Образец вывода команды hoststat

# hoststat
-------------- Hostname ---------- How long ago ---------Results---------
 mail.telstra.com.au                    04:05:41 250 Message accepted for
 scooter.eye-net.com.au              81+08:32:42 250 OK id=0zTGai-0008S9-0
 yarrina.connect.com.a               53+10:46:03 250 LAA09163 Message acce
 happy.optus.com.au                  55+03:34:40 250 Mail accepted
 mail.zip.com.au                        04:05:33 250 RAA23904 Message acce
 kwanon.research.canon.com.au        44+04:39:10 250 ok 911542267 qp 21186
 linux.org.au                        83+10:04:11 250 IAA31139 Message acce
 albert.aapra.org.au                    00:00:12 250 VAA21968 Message acce
 field.medicine.adelaide.edu.au      53+10:46:03 250 ok 910742814 qp 721
 copper.fuller.net                   65+12:38:00 250 OAA14470 Message acce
 amsat.org                            5+06:49:21 250 UAA07526 Message acce
 mail.acm.org                        53+10:46:17 250 TAA25012 Message acce
 extmail.bigpond.com                 11+04:06:20 250 ok
 earthlink.net                       45+05:41:09 Deferred: Connection time

Команда purgestat сбрасывает собранные статистические данные и является эквивалентной вызову:
# sendmail -bH

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

Назад | Глобальное оглавление | Вперед
Запуск sendmail | Локальное оглавление | Получение и запуск Exim


If Your Mail Doesn't Get Through

Назад Глава 19. Получение и запуск Exim Вперед

Если почта не работает

Доступен ряд свойств для поиска неисправностей. Первое место, которое стоит проверить, журналы Exim. В Linux-системах они обычно сохраняются в /var/log/exim/log и называются exim_mainlog, exim_rejectlog и exim_paniclog. В других операционных системах они часто сохраняются в /var/spool/exim/log. Вы можете выяснить, где искать журналы, командой:
exim -bP log_file_path

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

Типичные записи в основном (main) файле регистрации показаны ниже. Каждая запись является одной строкой текста, начинающегося с даты и времени. Они здесь разделены на несколько строк, чтобы поместить на страницу:
2000-01-30 15:46:37 12EwYe-0004WO-00 <= jack@vstout.vbrew.com
  H=vstout.vbrew.com [192.168.131.111] U=exim P=esmtp S=32100
  id=38690D72.286F@vstout.vbrew.com
2000-01-30 15:46:37 12EwYe-0004WO-00 => jill <jill@vbrew.com>
  D=localuser T=local_delivery
2000-01-30 15:46:37 12EwYe-0004WO-00 Completed

Эти записи показывают, что сообщение из jack@vstout.vbrew.com на jill@vbrew.com успешно доставлено в почтовый ящик на локальном компьютере. Отправка письма помечается <=, а доставка =>.

Есть два вида ошибок доставки: постоянный и временный. Постоянные ошибки регистрируются в записи файла регистрации и помечаются ** :
2000-01-30 14:48:28 12EvcH-0003rC-00 ** bill@lager.vbrew.com
  R=lookuphost T=smtp: SMTP error from remote mailer after RCPT TO:
  <bill@lager.vbrew.com>: host lager.vbrew.com [192.168.157.2]:
  550 <bill@lager.vbrew.com>... User unknown

При таком сбое Exim посылает отправителю отчет о сбое доставки, часто называемый bounce message.

Временные ошибки отмечаются ==:
2000-01-30 12:50:50 12E9Un-0004Wq-00 == jim@bitter.vbrew.com
  T=smtp defer (145): Connection timed out

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

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

Назад | Глобальное оглавление | Вперед
Получение и запуск Exim | Локальное оглавление | Компиляция Exim


Compiling Exim

Назад Глава 19. Получение и запуск Exim Вперед

Компиляция Exim

Exim все еще в активной разработке. Версия Exim, включенная в дистрибутив Linux, вероятно, не последний выпуск. Если Вы нуждаетесь в некоем свойстве или устранении ошибки, найденной в более позднем выпуске, то должны получить копию исходного текста и откомпилировать его. Последний выпуск может быть найден через web-страницу Exim на http://www.exim.org.

Linux одна из многих операционных систем, для которых есть версия Exim. Чтобы компилировать Exim для Linux, Вы должны отредактировать файл src/EDITME и поместить результат в файл Local/Makefile. Комментарии в src/EDITME сообщат Вам, для чего используются различные параметры настройки. Затем выполните make.

Назад | Глобальное оглавление | Вперед
Если почта не работает | Локальное оглавление | Режимы доставки почты


Sources of Information

Назад Preface Вперед

Источники информации

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

Linux Documentation Project

Linux Documentation Project включает книги по Linux, документы HOWTO и man-страницы решительно по всем аспектам системы: от установки до программирования ядра. LDP включает книги:

Linux Installation and Getting Started

Автор Matt Welsh. Книга описывает, как получить и поставить Linux. Включает довольно подробную информацию о базовых командах, системном администрировании, X Window System и сетевой поддержке.

Linux System Administrators Guide

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

Linux System Adminstration Made Easy

Автор Steve Frampton. Книга описывает повседневные задачи администрирования ОС Linux.

Linux Programmers Guide

Авторы B. Scott Burkett, Sven Goldt, John D. Harper, Sven van der Meer и Matt Welsh. Книга будет интересна всем, кто хочет разрабатывать программы для Linux.

The Linux Kernel

Автор David A. Rusling. Книга подробно описывает устройство и функционирование ядра Linux.

The Linux Kernel Module Programming Guide

Автор Ori Pomerantz. Книга описывает как писать и отлаживать модули для ядра Linux.

Еще несколько книг сейчас пишутся. Все о LDP можно найти на сайте проекта http://www.linuxdoc.org и его многочисленных зеркалах в разных странах.

Документы HOWTO

Linux HOWTO представляют собой серию документов по настройке всего, что настраивается в Linux. Здесь можно найти информацию о написании программ, компиляции ядра, настройке всех сервисов и распространенных пакетов программ. Найти их можно в подкаталоге HOWTO на FTP сайтах Linux Documentation Project. Файл HOWTO-INDEX хранит перечень статей с кратким описанием.

Например, Installation HOWTO предоставляет советы по установке Linux, Hardware Compatibility HOWTO имеет список известного Linux оборудования, Distribution HOWTO предлагает перечень поставщиков Linux на дискетах и CD-ROM.

Linux Frequently Asked Questions

Документ Linux Frequently Asked Questions with Answers (FAQ) освещает большой перечень вопросов и ответов по системе.

Документы, доступные по FTP

Если у Вас есть доступ к anonymous FTP, можете получить всю документацию по Linux с разных сайтов. Основные здесь metalab.unc.edu:/pub/Linux/docs и tsx-11.mit.edu:/pub/linux/docs. Эти сайты имеют много зеркал.

Документы, доступные по WWW

Есть много WWW-сайтов по Linux. Главный сайт Linux Documentation Project: http://www.linuxdoc.org.

Open Source Writers Guild (OSWG) проект, который имеет область интересов за пределами Linux. OSWG нацелен на разработку документации по OpenSource разработкам и программам. OSWG доступен на сайте http://www.oswg.org:8080/oswg.

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

Документы, доступные на коммерческой основе

Многие компании публикуют наработки Linux Documentation Project:

Specialized Systems Consultants, Inc . (SSC)
http://www.ssc.com/
P.O. Box 55549 Seattle, WA 98155-0549
1-206-782-7733
1-206-782-7191 (FAX)
sales@ssc.com

Linux Systems Labs
http://www.lsl.com
18300 Tara Drive
Clinton Township, MI 48036
1-810-987-8807
1-810-987-3562 (FAX)
sales@lsl.com

Есть несколько компаний, издающих документацию по Linux в виде книг.

O'Reilly & Associates издает серию книг по Linux. В этой серии вышли:

Running Linux

Описывает установку и дает общие сведения по системе.

Learning Debian GNU/Linux, Learning Red Hat Linux

В общем, то же самое, что и Running Linux, но с ориентацией на конкретные дистрибутивы на CD-ROM.

Linux in a Nutshell

Книга из популярной серии "in a Nutshell", ориентируется на разные общие сведения и ссылки на другие документы по Linux.

Linux Journal и Linux Magazine

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

Linux Journal самый старый журнал. Издается S.S.C. Incorporated. Вы можете найти его по адресу http://www.linuxjournal.com.

Linux Magazine более новая, независимая публикация. Его сайт: http://www.linuxmagazine.com.

Linux Usenet Newsgroups

Если Вы имеете доступ к Usenet, посмотрите следующие группы новостей:

comp.os.linux.announce

Моделируемая (контролируемая) телеконференция, содержащая объявления и важные сообщения относительно Linux (например, сообщения об ошибках, существенные исправления и т.п.). Если Вы вообще собираетесь читать телеконференции Linux, эту читайте обязательно. Часто важные сообщения этой конференции не дублируются в другие. Также в этой же телеконференции бывают важные оперативные сообщения. Подписка через linux-announce@news.ornl.gov.

comp.os.linux.help

Вопросы и ответы по уствновке и использованию Linux.

comp.os.linux.admin

Дискуссии о системном администрировании.

comp.os.linux.networking

Дискуссии о сетях в Linux.

comp.os.linux.development

Разработка ядра и системных программ Linux.

comp.os.linux.misc

Все, что не вошло в предыдущие группы новостей.

Есть конференции и на других языках, например, на французском fr.comp.os.linux и на немецком de.comp.os.linux.

Списки рассылки по Linux

Есть огромное число специализированных списков рассылки.

Очень много списков поддерживаются Rutgers University. Подписка письмом:
To: majordomo@vger.rutgers.edu
Subject:
Body:
subscribe listname

Нам интересны списки:

linux-net

Дискуссии о сетях в Linux.

linux-ppp

Реализация Linux PPP.

linux-kernel

Обсуждение ядра Linux.

Поддержка Linux

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

OpenProjects IRC Network представляет собой IRC-сеть, посвященную полностью Open Projects: Open Source и Open Hardware. Некоторые из каналов разработаны, чтобы обеспечить интерактивную поддержку Linux.

Имеется ряд активных каналов на OpenProjects IRC network, где Вы всегда найдете пользователей. Вы можете использовать этот сервис программой-клиентом IRC, например, irc-II, для связи с сервером irc.openprojects.org:6667. Соединитесь для начала с общим каналом #linpeople.

Linux User Groups

Многие Linux User Groups оказывают помощь пользователям. Имеется ряд списков групп пользователей Linux. Некоторые из знаменитых:

Groups of Linux Users Everywhere

http://www.ssc.com/glue/groups

LUG list project

http://www.nllgg.nl/lugww

LUG registry

http://www.linux.org/users

Получение Linux

Единого дистрибутива Linux нет. Вместо него существует множество разных. Из коммерческих можно назвать Debian, RedHat, Caldera, Corel, SuSE и Slackware. Каждый такой полный дистрибутив включает полную систему: ядро, основные утилиты, библиотеки, файлы поддержки и много прикладных программ. Разница как раз именно в наборе этих программ.

Кроме того, есть мини-дистрибутивы, предназначенные для какой-то конкретной задачи, например, организации роутера. Такие часто заявляются как "Linux на одной дискете". Много ссылок можно найти на http://www.linuxlinks.com.

Дистрибутивы Linux можно скачать с большого числа сайтов по всему миру. Каждый уважающий себя дистрибутив имеет свои FTP и web-сайты. Вот данные для наиболее крупных и популярных:

Caldera

http://www.caldera.com ftp://ftp.caldera.com

Corel

http://www.corel.com ftp://ftp.corel.com

Debian

http://www.debian.org ftp://ftp.debian.org

RedHat

http://www.redhat.com ftp://ftp.redhat.com

Slackware

http://www.slackware.com ftp://ftp.slackware.com

SuSE

http://www.suse.com ftp://ftp.suse.com

Многие популярные FTP-архивы также зеркалируют дистрибутивы Linux. Наиболее известны в этом плане:

metalab.unc.edu:/pub/Linux/distributions
ftp.funet.fi:/pub/Linux/mirrors
tsx-11.mit.edu:/pub/linux/distributions
mirror.aarnet.edu.au:/pub/linux/distributions

Многие современные дистрибутивы поддерживают установку прямо через Internet. Это удобно при наличии быстрого канала или обновлении пакетов.

Linux можно купить на CD-ROM в комплекте с богатым набором программ. Многие продавцы предлагают несколько дистрибутивов на разных дисках. В России есть еще традиция комплектовать некоторые книги по этой ОС такими дисками. Это идеальное решение для установки: не надо долго качать из сети.

Назад | Глобальное оглавление | Вперед
Preface | Локальное оглавление | File System Standards


Protecting Against Mail Spam

Назад Глава 19. Получение и запуск Exim Вперед

Противоспамовая оборона

Спам (Mail spam), или непрошенная реклама, самое плохое, что только есть в современной электронной почте. Это проблема для многих пользователей. Был создан проект Mail Abuse Protection System (MAPS) и механизм Real Time Blackhole List (RBL), который уменьшает проблему. Информация о том, как работает MAPS RBL, может быть получена из интерактивной документации на http://maps.vix.com/rbl. Идея проста. Сайты, за которыми замечена рассылка спама, будут добавлены в базу данных. Затем данные о них отправляются по почте агентам передачи, которые перед принятием почты способны сделать запрос базы данных, чтобы подтвердить, что источник не является спамером.

После появления RBL, были созданы несколько других подобных списков. Один из наиболее полезных Dial-Up List (DUL), который вносит в список IP-адреса dial-up компьютеров. Они должны обычно посылать почту только почтовым серверам своих провайдеров. Многие сайты блокируют почту с внешних модемных машин, поскольку это обычно спамеры.

Exim обеспечивает поддержку для обработки черных списков в реальном времени. Это очень легко настроить. Для включения такой поддержки впишите в свой файл /etc/exim.conf:

# Vixie / MAPS RBL (http://maps.vix.com/rbl)
rbl_domains = rbl.maps.vix.com : dul.maps.vix.com

Этот пример проверяет RBL и DUL, отклоняя любые сообщения с компьютеров, которые находятся в любом из этих списков. Опция rbl_hosts позволяет Вам определять группы компьютеров, к которым проверка RBL будет (или не будет) применяться. По умолчанию задано:
rbl_hosts = *
Это означает, что все компьютеры подчиненны проверке RBL. Если Вы хотите для какого-то компьютера отменить проверку, используйте:
rbl_hosts = ! nocheck.example.com : *
Метка восклицания перед первым элементом в этом списке указывает инвертированный элемент: если компьютер называется nocheck.example.com, эта запись будет соответствовать ему. Но из-за отрицания проверка RBL не выполняется. Любой другой компьютер соответствует второму элементу в списке.

Назад | Глобальное оглавление | Вперед
Маршрутизация и доставка почты | Локальное оглавление | Настройка UUCP


Installation

Назад Глава 21. C News Вперед

Установка

C-News доступен в откомпилированном виде во многих новых дистрибутивах Linux, так что установка не должна вызвать проблемы. Исходники можно получить с ftp.cs.toronto.edu/pub/c-news/c-news.tar.Z. После установки надо поправить файлы настройки C-News. Их формат описан ниже:

sys

Файл sys управляет тем, какие группы новостей передаются и принимаются Вашим сайтом. Рассмотрен детально ниже.

active

Хранит указания по обработке статей в группах новостей.

organization

Имя Вашей организации. Например, "Virtual Brewery, Inc". На домашней машине введите "private site" или что-либо, что Вы находите приятным. Большинство людей не будет называть Ваш сайт правильно отконфигурированным, если Вы не настроили этот файл.

newsgroups

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

mailname

Почтовое имя Вашего сервера, например, vbrew.com.

whoami

Имя Вашего сайта для целей новостей. Часто используется имя UUCP, например, vbrew.

explist

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

Чтобы создать начальную иерархию новостных групп, получите файлы active и newsgroups с сайта, который передает Вам новости, и установите их в /etc/news. Объявите их принадлежащими пользователю news и задайте права доступа 644 командой chmod. Удалите все группы to.* из файла active и добавьте to.my-site, to.feed-site, 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, потоковый редактор в Unix. Этот вызов заменяет две строки цифр на строку нулей и строку 000001 соответственно.

В заключение, создайте каталог для хранения новостей и подкаталоги, используемые для входящих и исходящих новостей:
# cd /var/spool
# mkdir news news/in.coming news/out.going news/out.master

# chown -R news.news news
# chmod -R 755 news

Если Вы используете программы чтения новостей из другого дистрибутива, а не из C-News, Вы можете обнаружить, что некоторые из них ожидают найти хранилище новостей в /usr/spool/news, а не в /var/spool/news. Если Ваш newsreader не находит статьи, создайте ссылку из /usr/spool/news в /var/spool/news:
# ln -sf /usr/spool/news /var/spool/news

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

В частности это случается со всеми группами, в которых новости пересеклись. Через некоторое время Вы найдете в своем каталоге новостей подкаталоги для групп, на которые никогда не подписывались, например, alt.lang.teco. Вы можете предотвратить это удалением всех нежелательных групп из файла active или удаляя все пустые каталоги ниже /var/spool/news из какого-либо скрипта (исключение составляют каталоги out.going и in.coming).

C-News нуждается в пользователе, которому можно послать сообщения об ошибках и отчеты состояния. По умолчанию это usenet. Если Вы используете значение по умолчанию, Вы должны установить специальные права для него. Вы можете также отменять это поведение, устанавливая переменную среды NEWSMASTER в соответствующее имя. Это можно делать из списка заданий пользователя news для отложенного выполнения (crontab) перед запуском утилит администрирования. Можно установить и почтовый псевдоним, что подробно описано в главе 18 и главе 19.

При правке файла /etc/passwd проследите, чтобы каждый пользователь имел свое реальное имя в записи pw_gecos (это четвертое поле). Это вопрос сетевого этикета Usenet, который предписывает, чтобы реальное имя пользователя значилось в поле From: его статей.

Назад | Глобальное оглавление | Вперед
C-News | Локальное оглавление | Файл sys


Newsreaders and INN

Назад Глава 23. Internet News Вперед

Программы чтения новостей и INN

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

Но есть другой вариант: программа может обращаться к серверу дистанционно через протокол NNTP. Этот тип подключения будет обработан по-другому. Всякий раз, когда программа подключается к серверу NNTP, innd порождает отдельную копию обработчика nnrpd, который обрабатывает сеанс, в то время как innd возвращается к более важным вещам (получение входящих новостей, например). Как процесс innd различает входящую подачу новостей и соединение от клиентского newsreader? Ответ прост: протокол NNTP требует, чтобы программа-newsreader при соединении выдала команду mode reader после соединения с сервером. Когда эта команда будет получена, сервер запустит процесс nnrpd, вручает ему подключение и возвращается к ожиданию подключений. Проблема в том, что сам innd не распознает никаких команд для работы с новостями, так что программа-клиент должна начинать сеанс корректно.

Назад | Глобальное оглавление | Вперед
Internet News | Локальное оглавление | Установка INN


Installing INN

Назад Chapter 23. Internet News Вперед

Установка INN

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

Дистрибутивы Linux некоторое время включали INN Version 1.4sec. Увы, эта версия имела две тонких проблемы защиты. Современные версии не имеют этих проблем, и большинство дистрибутивов включают откомпилированный INN Version 2 или старше.

Если Вам нужно откомпилировать INN лично, можете получить исходники с ftp.isc.org (каталог /isc/inn). Это требует, чтобы Вы редактировали файл конфигурации, который сообщает INN подробности относительно операционной системы и некоторых ее свойств.

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

После установки всех двоичных файлов могут потребоваться некоторые дополнительные настройки, чтобы связать INN с другими прикладными программами, которые могут обращаться к rnews или inews. UUCP, например, ожидает найти rnews в /usr/bin или /bin в то время, как INN устанавливает ее в /usr/lib/bin по умолчанию. Удостоверьтесь, что /usr/lib/bin находится в заданном по умолчанию пути поиска файлов, или что есть символические связи, указывающие на фактическое расположение команд rnews и inews.

Назад | Глобальное оглавление | Вперед
Программы чтения новостей и INN | Локальное оглавление | Настройка INN


Configuring INN: the Basic Setup

Назад Глава 23. Internet News Вперед

Настройка INN

Одно из самых больших препятствий для новичков в том, что INN требует, чтобы сеть функционировала правильно, даже при работе на автономном хосте. Следовательно, необходимо, чтобы ядро поддержило работу с сетями TCP/IP при выполнении INN, и чтобы Вы установили интерфейс loopback, как объяснено в главе 5.

Затем Вы должны удостовериться, что innd запускается при начальной загрузке. Заданная по умолчанию установка INN имеет файл скрипта boot в каталоге /etc/news. Если Ваш дистрибутив использует пакет init в стиле SystemV, все, что Вы должны сделать, это создать символическую связь из Вашего /etc/init.d/inn на /etc/news/boot. Для других разновидностей init Вы должны удостовериться, что /etc/news/boot выполнен из одного из скриптов rc. Так как INN требует поддержки работы с сетями, скрипт запуска должен быть выполнен только после того, как сетевые интерфейсы будут полностью сконфигурированы.

Назад | Глобальное оглавление | Вперед
Установка INN | Локальное оглавление | Файлы настройки INN


INN Configuration Files

Назад Глава 23. Internet News Вперед

Файлы настройки INN

INN использует несколько файлов настройки, все они хранятся в каталоге /etc/news. Некоторые изменения файлов конфигураций появились в Version 2, и именно ее я рассмотрю здесь.

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

Глобальные параметры

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

Файл inn.conf

Главный файл настройки INN называется inn.conf. Помимо прочего, он задает имя Вашей машины в сети Usenet. INN Version 2 имеет огромное количество настроек в этом файле. Удачно, что большинство параметров имеет значения по умолчанию, которые являются приемлемыми для многих случаев. Страница справочника inn.conf(5) имеет подробное описание всех деталей параметров этого файла, и Вы должны ее внимательно изучить, если испытываете проблемы с настройкой.

Простой пример inn.conf:
# Sample inn.conf for the Virtual Brewery
server:          vlager.vbrew.com
domain:          vbrew.com
fromhost:        vbrew.com
pathhost:        news.vbrew.com
organization:    The Virtual Brewery
mta:             /usr/sbin/sendmail -oi %s
moderatormailer: %s@uunet.uu.net
#
# Paths to INN components and files.
#
pathnews:               /usr/lib/news
pathbin:                /usr/lib/news/bin
pathfilter:             /usr/lib/news/bin/filter
pathcontrol:            /usr/lib/news/bin/control
pathdb:                 /var/lib/news
pathetc:                /etc/news
pathrun:                /var/run/news
pathlog:                /var/log/news
pathhttp:               /var/log/news
pathtmp:                /var/tmp
pathspool:              /var/spool/news
patharticles:           /var/spool/news/articles
pathoverview:           /var/spool/news/overview
pathoutgoing:           /var/spool/news/outgoing
pathincoming:           /var/spool/news/incoming
patharchive:            /var/spool/news/archive
pathuniover:            /var/spool/news/uniover
overviewname:           .overview

Первая строка сообщает, где искать программы rnews и inews, с которыми компьютер должен входить в контакт при поставке статей. Это очень важно, поскольку innd должен установить соединение по NNTP для связи с сервером.

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

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

Строка pathhost определяет имя хоста INN для добавления к полю Path: в заголовке статей. В большинстве случаев Вы будете использовать доменное имя сервера новостей. В этой ситуации поле можно пропустить: значением по умолчанию как раз и является доменное имя сервера новостей. Иногда Вы можете использовать универсальное имя, типа news.vbrew.com, при обслуживании большого домена. Это позволяет Вам легко перемещать систему новостей с одной машины на другую в зависимости от технических требований.

Следующая строка имеет ключевое слово organization. Эта инструкция позволяет Вам конфигурировать, какой текст inews поместит в поле Organization: заголовков статей, зарегистрированных Вашими локальными пользователями. Формально здесь нужно указать описание или название Вашей организации.

Ключевое слово organization обязательно и определяет имя агента транспортировки почты, который будет использован для отправки сообщений модератору. Здесь вместо %s будет подставлен e-mail адрес модератора группы.

Слово moderatormailer определяет заданный по умолчанию адрес, используемый, когда пользователь пробует послать статью в модерируемую группу. Список адресов модераторов для каждой группы обычно хранится в отдельном файле. Запись moderatormailer используется как последняя инстанция: если она определена, inews заменит %s на адрес для соответствующей группы новостей. Например, при регистрации в soc.feminism статья будет отправлена по почте на адрес soc-feminism@uunet.uu.net, заданный в данной конфигурации для модератора данной группы.

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

Настройка групп новостей

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

Файлы active и newsgroups

Файлы active и newsgroups используются, чтобы сохранять и описывать группы, поддерживаемые этим сервером. Они вносят в список группы, в получении и поддержке которых заинтересован данный сервер, и административную информацию о них. Эти файлы обычно лежат в каталоге /var/lib/news.

Файл active определяет группы новостей, поддерживаемые данным сервером. Синтаксис у него простой. Каждая строка имеет четыре поля, разделенные пробелами:
name himark lomark flags

Поле name задает имя группы. Поле himark определяет самый старший номер, который использовался для статьи в этой группе. Аналогично поле lomark задает младший номер. Чтобы проиллюстрировать, как это работает, рассмотрим пример. Допустим, что мы имеем недавно созданную группу: himark и lowmark в ней пока 0, потому что нет статей. Если послать 5 статей, они будут пронумерованы от 1 до 5. Теперь himark будет равняться 5, самому старшему номеру, а lowmark соответственно будет равен 1. Если статью 5 удалить, ничего не изменится; himark будет равен 5, чтобы гарантировать, что номер статьи не перераспределен, и lowmark останется в 1, самом младшем номере активной статьи. Если мы теперь отменяем статью 1, himark останется неизменяемым, но lowmark будет теперь равен 2, потому что 1 больше не активен. Если мы теперь регистрируем новую статью, ей будет назначенный номер 6, так что himark будет теперь равен 6. Статья 5 была использована, так что мы не будем переназначать этот номер. Значение lowmark остается в 2. Этот механизм позволяет нам легко распределять уникальные числа статьи для новых статей и вычислять приблизительно, как много активных статей находятся в группе: himark- lowmark.

Поле flags может иметь одно из следующих значений:

y

Отправка статей непосредственно на этот сервер разрешена.

n

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

m

Группа модерируемая. Любые статьи будут посланы модератору для утверждения прежде, чем они войдут в группу. Больше всего немодерируемых групп новостей.

j

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

x

Статья не может быть послана в эту группу. Единственный путь, которым статья может сюда попасть, это прийти с другого сервера.

=foo.bar

Местные статьи регистрируются в группе ``foo.bar''.

В нашей простой конфигурации файл /var/lib/news/active выглядит так:
control                      0000000000 0000000001 y
junk                         0000000000 0000000001 y
rec.crafts.brewing           0000000000 0000000001 y
rec.crafts.brewing.ales      0000000000 0000000001 y
rec.crafts.brewing.badtaste  0000000000 0000000001 y
rec.crafts.brewing.brandy    0000000000 0000000001 y
rec.crafts.brewing.champagne 0000000000 0000000001 y
rec.crafts.brewing.private   0000000000 0000000001 y
Числа himark и lomark в этом примере те, которые Вы использовали при создании новой группы. Числа будут выглядеть совершенно разными для групп, которые были активны некоторое время.

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

Формат файла newsgroups:
name description
Поле name задает имя группы, а description строку описания для нее.

В данном случае мы хотим описывать группы, которые поддерживает наш сервер, так что напишем такой файл newsgroups:
rec.crafts.brewing.ales         Home brewing Ales and Lagers
rec.crafts.brewing.badtaste     Home brewing foul tasting brews
rec.crafts.brewing.brandy       Home brewing your own Brandy
rec.crafts.brewing.champagne    Home brew your own Champagne
rec.crafts.brewing.private      The Virtual Brewery home brewers group

Настройка подачи новостей

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

Файл newsfeeds

Файл newsfeeds определяет, куда какие статьи рассылать. Обычно он лежит в каталоге /etc/news.

Формат файл newsfeeds сначала может показаться сложным. Здесь я опишу его в общих чертах, а за подробностями отсылаю к man-странице newsfeeds(5). Синтаксис файла:
# newsfeeds file format
site:pattern:flags:param
site2:pattern2\
     :flags2:param2
Каждая запись состоит из одной строки. Можно использоваать и несколько строк, но тогда требуется применить символ \ в качестве знака переноса. Символ # в начале строки обозначает комментарий.

Поле site определяет имя сайта, передача которому описана этой строкой. Здесь можно вписать любое имя, на которое потом будут ссылаться другие определения. Единственное, что здесь нельзя писать, это доменное имя сайта. Записанное здесь имя понадобится позже для поиска в таблице имен для программы innxmit, которая передает статьи по протоколу NNTP на удаленный сервер. Можно иметь несколько записей для одного сайта: они обрабатываются индивидуально.

Поле pattern указывает имена групп, которые надо передать этому сайту. Значение по умолчанию должно послать все группы, так что, если нужно именно это, оставьте поле пустым. Это поле обычно хранит разделенный запятыми список шаблонов имен. Символ * как обычно соответствует любой строке символов или ее отсутствию, символ . (точка) не имеет никакой специальной нагрузки, зато символ ! (при использовании в начале выражения) задает логический NOT. Наконец, символ @ в начале имени группы запрещает пересылать любые статьи, которые посланы в эту группу. Список читается и обрабатывается слева направо, так что Вы должны поместить более специфические правила сначала. Например, шаблон:

rec.crafts.brewing*,!rec.crafts.brewing.poison,@rec.crafts.brewing.private

пошлет все новости иерархии rec.crafts.brewing за исключением группы rec.crafts.brewing.poison. Он не пошлет никаких статей, которые пришли в группу rec.crafts.brewing.private: эти статьи будут доступны только тем людям, которые используют этот сервер.

Поле flags контролирует подачу новостей к заданному сайту. Здесь используется разделенный запятыми список из следующих команд:

<size

Статья должна быть размером меньше заданного значения в байтах.

A items

Статья проверяется на соответствие критериям: d (должен быть заголовок Distribution) или p (не проверять сайт в поле Path заголовка).

B high/ low

Размер внутреннего буфера перед записью.

H [count]

Статья должна иметь меньше, чем count записей о пересылке, по умолчанию 1.

I size

Размер внутреннего буфера для передачи файлов.

M pattern

Этому шаблону соответствуют только модерируемые группы.

N pattern

Этому шаблону соответствуют только немодерируемые группы.

S size

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

T type

Типы подачи новостей: f (файл), m (поток, поле param в соответствующей записи указывает, что статья будет подаваться потоком), p (канал к программе), c (послать каналу stdin подпроцесса, заданного в поле param) и x (аналог c).

W items

Что записывать: b (размер статьи в байтах), f (полный путь), g (первая группа новостей), m (Message ID), n (относительный путь), s (сайт для подачи статьи), t (время приема), * (имя потока или перечень всех сайтов, которые получают статью), N (поле newsgroups заголовка), D (поле distribution заголовка), H (весь заголовок), O (обзорные данные) и R (данные для ответа).

Поле param имеет специальное кодирование, которое зависит от типа передачи. В наиболее общей конфигурации здесь хранится имя выходного файла, в который Вы будете записывать исходящие данные. В других конфигурациях Вы можете оставлять его пустым или задавать другие значения. Если Вы хотите сделать что-либо нестандартное, обратитесь за подробностями к man-странице newsfeeds(5).

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

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

Наш сервер новостей будет обеспечивать только одну внешнюю подачу новостей, которая идет на Groucho Marx University, они получают все статьи из всех групп, кроме control и junk, а также группы rec.crafts.brewing.private, которая является местной, и rec.crafts.brewing.poison, в которую не могут ничего послать локальные пользователи.

Мы используем команду nntpsend для транспортировки новостей по NNTP на сервер news.groucho.edu. Программа nntpsend требует, чтобы мы использовали метод поставки "file" и писали путевое имя статьи и ее ID. Заметьте, что надо установить поле param в имя файла для вывода. Конфигурация в файле:
# /etc/news/newsfeeds file for the Virtual Brewery
#
# Send all newsgroups except the control and junk ones by default
ME:!control,!junk::
#
# Generate overview data for any newsreaders to use.
overview::Tc,WO:/usr/lib/news/bin/overchan
#
# Feed the Groucho Marx University everything except our private newsgroup
# and any articles posted to the rec.crafts.brewing.poison newsgroup.
gmarxu:!rec.crafts.brewing.poison,@rec.crafts.brewing.private:\
       Tf,Wnm:news.groucho.edu

Файл nntpsend.ctl

Программа nntpsend управляет передачей новостей, используя протокол NNTP и вызывая команду innxmit. Простое использование nntpsend было только что показано, но у нее есть свой файл настройки, который обеспечивает некоторую гибкость при передаче новостей.

Команда nntpsend ожидает найти пакетные файлы для сайтов, с которыми работает. Предполагается, что эти пакетные файлы будут именованы как /var/spool/news/out.going/ sitename. Демон innd создает эти пакетные файлы при обработке записи в newsfeeds, который приведен в предыдущем разделе. Там имя сайта было определено как имя файла в поле param, и это удовлетворяет входные требования команды nntpsend.

Команда nntpsend имеет файл конфигурации nntpsend.ctl, который обычно сохраняется в каталоге /etc/news.

Файл nntpsend.ctl позволяет связывать полное доменное имя, настройки подачи новостей и ряд параметров передачи с именем сайта назначения. Общий формат файла:
sitename:fqdn:max_size:[args]

Элементы этого формата:

sitename

Имя сайта из файла newsfeeds.

fqdn

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

max_size

Максимальный объем новостей, передаваемых одним блоком.

args

Дополнительные параметры для команды innxmit.

Наш пример конфигурации требует очень простой файл nntpsend.ctl. Мы имеем только одну подачу новостей. Ограничим максимальный блок новостей 2 MB и передадим параметр innxmit, который устанавливает 3-минутное (180 секунд) время ожидания. Если бы мы поддерживали большой сайт новостей с несколькими клиентами, пришлось бы создать дополнительные записи для каждого клиента:
# /etc/news/nntpsend.ctl
#
gmarxu:news.groucho.edu:2m:-t 180

Контроль доступа программ работы с новостями

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

Файл incoming.conf

Я упомянул в обзоре по INN, что данный пакет достигает хороших результатов, отделяя механизм рассылки новостей от работы с клиентскими программами. Файл /etc/news/incoming.conf как раз то место, где Вы определяете, какие хосты будут подавать Вам новости, используя протокол NNTP и ряд параметров подачи. Любой хост, не перечисленный в этом файле, не будет обработан демоном innd. Вместо этого для него будет запущен демон nnrpd.

Синтаксис файла /etc/news/incoming.conf очень прост. Допустимы три типа записей: пары "ключ/значение", задающие значения параметров, доменные имена, задающие имена хостов для доступа по NNTP (peer), и группы (group), задающие связь между двумя первыми типами записей. Пары ключ/значение могут иметь три различных типа контекста. Глобальные пары относятся ко всем записям хостов, определенным в файле. Группы обращаются ко всем определенным хостам в своей группе.

Фигурные скобки ({}) задают начало и конец записей типов group и peer. Символ # задает комментарий. Пары ключ/значение разделяются двоеточием и располагаются по одной на строке.

Наиболее часто используются следующие ключи:

hostname

Определяет разделенный запятыми список полных доменных имен или IP-адресов хостов, которым разрешено посылать новости на наш сервер.

streaming

Задает, разрешены ли потоковые команды с этого хоста. Тип переменной Boolean. По умолчанию значение true.

max-connections

Максимальное количество подключений из этой группы или с данного сервера. Значение 0 (ноль) задает неограниченное число подключений, аналогично значению none.

password

Задает пароль, используемый для передачи новостей. По умолчанию не определен, то есть пароль не требуется.

patterns

Определяет группы, которые принимаются от соответствующего сервера (или группы). Это поле кодируется по правилам из файла newsfeeds.

В нашем примере мы имеем только один хост, с которым надо обмениваться новостями. Пароль задавать не будем, но обеспечим, чтобы частные группы не выходили за пределы нашей сети. Файл hosts.nntp выглядит примерно так:
# Virtual Brewery incoming.conf file.
# Global settings
streaming:       true
max-connections: 5

# Allow NNTP posting from our local host.
peer ME {
  hostname: "localhost, 127.0.0.1"
}

# Allow groucho to send us all newsgroup except our local ones.
peer groucho {
  hostname: news.groucho.edu
  patterns: !rec.crafts.brewing.private
}

Файл nnrp.access

Я упомянул ранее, что программы чтения новостей (а фактически любой компьютер, не перечисленный в hosts.nntp), которые соединяются с INN, обрабатываются программой nnrpd. Демон nnrpd использует файл /etc/news/nnrp.access, чтобы определить, кто и с какими правами может использовать сервер.

Файл nnrp.access имеет структуру, схожую с файлами настройками, рассмотренными выше. Он включает набор образцов, используемых для проверки соответствия доменных имен или IP-адресов соединяющихся машин и определения прав доступа. Каждая запись должна быть на отдельной строке, поля разделяются двоеточиями. Для работы используется последнее найденное соответствие. Каждая запись включает пять полей:

Hostname или IP-адрес

Это поле соответствует правилам wildmat(3) соответствия шаблонов. Это образец, который описывает имя соединяющегося компьютера или его IP-адрес.

Permissions

Это поле определяет то, какие права нужно предоставлять. Есть два права: R для чтения и P для посылки статей в группы.

Username

Необязательно, но позволяет Вам определять имя пользователя для его регистрации клиентом NNTP на сервере перед тем, как он будет посылать статьи (для чтения авторизация не требуется).

Password

Необязательно, но может задавать пароль для отправки статей и задается в паре с username. Пустое поле определяет, что пароль не нужен.

Newsgroups

Задает группы, к которым разрешен доступ клиенту. Шаблон определен по правилам из файла newsfeeds.

В нашем примере разрешается каждому пользователю нашего домена читать статьи и посылать их по NNTP. Кроме того, всем клиентам NNTP предоставляется доступ только на чтение (read-only) ко всем конференциям, кроме внутренних. Файл nnrp.access выглядит так:
# Virtual Brewery - nnrp.access
# We will allow public reading of all newsgroups except our private one.
*:R:::*,!rec.crafts.brewing.private

# Any host with the Virtual Brewery domain may Read and Post to all
# newsgroups
*.vbrew.com:RP::*

Старение статей

Когда статьи принимаются сервером, они сохраняются на диске. Статьи должны быть доступными пользователям некоторое время. Но крупный сервер очень требователен к месту на диске. Для эффективного использования диска, надо удалять периодически устаревшие статьи. Можно это автоматизировать, что называется старение статей (article expiration). INN обеспечивает средства автоматического удаления старых статей.

Файл expire.ctl

Сервер INN использует программу expire, чтобы удалить устаревшие статьи. Она в свою очередь использует файл /etc/news/expire.ctl, чтобы конфигурировать правила, которые управляют этим процессом.

Синтаксис /etc/news/expire.ctl довольно прост. Как и в большинстве файлов конфигурации строки, начинающиеся с символа # или пустые, игнорируются. Общая идея состоит в том, что Вы определяете одно правило на строку. Каждое правило определяет, как будет стареть указанная группа статей. Синтаксис правила выглядит следующим образом:
pattern:
modflag:keep:
default:purge

Поля имеют смысл:

pattern

Разделенный запятыми список образцов имен групп. Для проверки используется программа wildmat. Будет применено последнее подходящее правило.

modflag

Описывает, как это правило применяется к модерируемым группам. Допустимо указание M для модерируемых групп, U для немодерируемых групп, или A, чтобы указать, что это правило применимо к любым группам новостей.

keep

Позволяет Вам определять минимальное время, которое статья с полем "Expires" в заголовке будет храниться. Единицами измерения являются дни. Можно использовать плавающую точку, например, 7.5 для указания семи с половиной дней. Можно также указать never, чтобы статья не сохранялась вообще.

default

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

purge

Это поле позволяет Вам определять максимальное время. которое статья с полем Expires в заголовке будет храниться до начала процесса старения. Правила задания аналогичны полю keep.

Наши требования просты. Мы будем хранить все статьи во всех группах в течение 14 дней по умолчанию и от 7 до 21 для статей с полем Expires в заголовке. Группа rec.crafts.brewing.private является внутренней, и в ней статьи бессмертны:
# expire.ctl file for the Virtual Brewery

# Expire all articles in 14 days by default, 7-21 days for those with
# Expires: headers
*:A:7:14:21

# This is a special internal newsgroup, which we will never expire.
rec.crafts.brewing.private:A:never:never:never

Есть один специальный тип записи, который Вы можете иметь в файле /etc/news/expires.ctl. Допустима только одна строка, которая выглядит следующим образом:
/remember/:days
Она позволяет Вам определять минимальное число дней. которое статья будет упоминаться в файле хронологии (history file), независимо от старения статьи. Это полезно, если один из подающих новости сайтов медленный и имеет тенденцию иногда присылать старые статьи. Установка поля /remember/ помогает избавиться от поступления статей, уже удаленных с Вашего сервера. Если он помнит, что уже получал такую статью, он отклонит попытки снова послать ее. Важно не забыть, что эта установка не имеет вообще никакого эффекта над самим процессом устаревания новостей, а воздействует только на время, которое статьи сохраняются в базе данных.

Обработка сообщений Control

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

Файл control.ctl

Файл control.ctl довольно прост. Правила синтаксиса для этого файла аналогичны правилам для прочих файлов INN. Строки, начинающиеся с # игнорируются, строки могут быть продолжены, используя символ переноса /, поля разделяются двоеточиями (:).

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

message:from
:newsgroups:
action

Поля имеют смысл:

message

Имя контрольного сообщения. Типичные сообщения описаны ниже.

from

Образец в стиле оболочки, соответствующий e-mail адресу отправителя сообщения. Адрес будет преобразован в нижний регистр перед сравнением.

newsgroups

Если пришло сообщение newgroup или rmgroup, это поле хранит соответствие образца в стиле оболочки (shell-style) с именем соответствующей группы.

action

Это поле определяет, какое действие выполнять для любого сообщения, соответствующего правилу. Имеется множество действий, которые мы можем выполнить, они будут описаны ниже.

Поле message каждой строки может иметь одно из значений:

checkgroups

Предписывает администраторам новостей синхронизировать их базы данных активных групп со списком в сообщении.

newgroup

Создать новую группу. Сообщение должно содержать короткое описание создаваемой группы новостей.

rmgroup

Удалить группу новостей.

sendsys

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

version

Вернуть отправителю сообщения имя хоста и версию программного обеспечения сервера новостей.

all

Соответствует любому типу сообщений управления.

Поле message может также включать любые следующие действия:

doit

Запрошенная команда выполняется. Во многих случаях будет послано e-mail сообщение администратору, чтобы уведомить его о выполнении.

doit=file

Аналог doit, но сообщение протокола пишется в файл протокола с именем file. Если в качестве имени файла задано mail, протокол отсылается по e-mail. Если в качестве имени задана пустая строка, сообщение будет записано в дыру памяти /dev/null, эквивалентно использованию неквалифицированного действия doit. Если строка file начинается с символа /, имя считается абсолютным (путевым или полным). В противном случае указанное имя транслируется в /var/log/news/file.log.

doifarg

Запрошенная команда выполняется, если имеет параметр. Если команда не имеет никакого параметра, сообщение управления игнорируется.

drop

Запрошенная команда игнорируется.

log

Сообщение протокола будет послано на stderr процессом innd. Это обычно направляется в файл /var/log/news/errlog.

log=file

Аналог log, но файл протокола определен согласно правилам, заданным для действия doit=file.

mail

Будет послано e-mail сообщение администратору новостей, содержащее запрошенные команды. Никаких других действий не будет выполнено.

verify-*

Если действие начинается со строки "verify-", то сообщение управления заверено, используя PGP (или GPG).

Пример простого файла control.ctl:

## Sample /etc/news/control.ctl
##
## Warning: You should not use this file, it is illustrative only.
##
##      Control Message Handling
all:*:*:mail
checkgroups:*:*:mail
ihave:*:*:drop
sendme:*:*:drop
sendsys:*:*:log=sendsys
senduuname:*:*:log=senduuname
version:*:*:log=version
newgroup:*:*:mail
rmgroup:*:*:mail

##  Handle control messages for the eight most important news heirarchies
##  COMP, HUMANITIES, MISC, NEWS, REC, SCI, SOC, TALK
checkgroups:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
newgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
rmgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop
checkgroups:group-admin@isc.org:*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups
newgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups
rmgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups

## GNU ( Free Software Foundation )
newgroup:gnu@prep.ai.mit.edu:gnu.*:doit
newgroup:news@*ai.mit.edu:gnu.*:doit
rmgroup:gnu@prep.ai.mit.edu:gnu.*:doit
rmgroup:news@*ai.mit.edu:gnu.*:doit

## LINUX (Newsfeed from news.lameter.com)
checkgroups:christoph@lameter.com:linux.*:doit
newgroup:christoph@lameter.com:linux.*:doit
rmgroup:christoph@lameter.com:linux.*:doit

Назад | Глобальное оглавление | Вперед
Настройка INN | Локальное оглавление | Запуск INN


Running INN

Назад Chapter 23. Internet News Вперед

Запуск INN

Пакет исходников inn имеет скрипт для запуска inn при начальной загрузке. Он обычно назван /usr/lib/news/bin/rc.news. Скрипт читает параметры из другого скрипта, обычно /usr/lib/news/innshellvars, который содержит определения имен файлов и путей, используемых inn. Очень хорошим подходом является выполнять inn как не-root, например, от имени пользователя news.

Чтобы гарантировать, что inn запустится при начальной загрузке, Вы должны проверить, что /usr/lib/news/innshellvars сконфигурирован правильно, и затем вызвать /usr/lib/news/bin/rc.news во время загрузки.

Имеются административные задачи, которые должны выполняться периодически. Эти задачи обычно конфигурируются так, чтобы быть выполненными командой cron. Самый лучший способ сделать это состоит в том, чтобы добавить соответствующие команды к Вашему файлу /etc/crontab, или даже лучше, создать файл в каталоге /etc/cron.d, если Ваш дистрибутив такой сервис поддерживает. Пример такого файла:
# Example /etc/cron.d/inn file, as used in the Debian distribution.
#
SHELL=/bin/sh
PATH=/usr/lib/news/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Expire old news and overview entries nightly, generate reports.

15 0 * * *      news    news.daily expireover lowmark delayrm

# Every hour, run an rnews -U. This is not only for UUCP sites, but
# also to process queued up articles put there by in.nnrpd in case
# innd wasn't accepting any articles.

10 * * * *      news    rnews -U

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

Назад | Глобальное оглавление | Вперед
Файлы настройки INN | Локальное оглавление | Управление INN: команда ctlinnd


Managing INN: The ctlinnd Command

Назад Глава 23. Internet News Вперед

Управление INN: команда ctlinnd

Сервер новостей INN поставляется с командой для управления ежедневными операциями. Команда ctlinnd может использоваться, чтобы управлять группами новостей, закачкой статей, получать состояние сервера, запускать, перезагружать и останавливать его.

Краткий обзор команд ctlinnd выводится по:
# ctlinnd -h

Здесь я рассмотрю наиболее важные опции настройки, за подробностями отсылаю Вас к man-странице на ctlinnd.

Добавление группы новостей

Используйте следующую команду для добавления группы новостей:
ctlinnd newgroup group rest creator

Ее параметры имеют такой смысл:

group

Имя создаваемой группы.

rest

Этот параметр должен быть кодирован таким же образом, как поле flags файла active. Эти значения по умолчанию выставлены в y.

creator

Имя человека, создавщего группу. Заключите эту строку в кавычки, если есть пробелы в имени.

Изменение группы

Параметры группы меняются следующим образом:
ctlinnd changegroup group rest

Аргументы имеют смысл:

group

Имя изменяемой группы.

rest

Этот параметр должен быть кодирован таким же образом, как поле flags файла active.

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

Удаление группы

Удаление группы выполняется такой командой:
ctlinnd rmgroup group

Аргументы имеют смысл:

group

Имя удаляемой группы.

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

Перенумерация группы

Для перенумерации группы используется команда:
ctlinnd renumber group

Аргументы имеют смысл:

group

Имя группы. Если параметр group определен как пустая строка, будут обработаны все группы.

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

Доступ для Newsreaders

Чтобы разрешить или запретить доступ программ чтения новостей (newsreaders), используйте команду:
ctlinnd readers flag text

Аргументы имеют смысл:

flag

Указание n запрещает подключение newsreader. Наоборот, значение y такие подключения разрешает.

text

Задает текстовое сообщение, которое будет передано при подключении newsreader. Обычно в нем описываются причины запрета доступа. Чтобы убрать сообщение, задайте его пустой строкой.

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

Блокировка входящих новостей

Чтобы заблокировать входящий поток новостей, скомандуйте:
ctlinnd reject reason

Аргументы имеют смысл:

reason

Текст с пояснениями, почему входящие подключения к innd отклоняются.

Эта команда не воздействует на подключения, которые пришли от nnrpd (т.е. newsreaders); она воздействует только на подключения от innd, то есть, на входящие новости от других серверов.

Разблокирование входящих новостей

Для разблокирования входящих новостей скомандуйте:
ctlinnd allow reason

Аргументы имеют смысл:

reason

Задает любое текстовое сообщение. Если оно не нужно, задайте просто пустую строку.

Эта команда обратна команде reject.

Выключение сервера новостей

Чтобы выключить сервер новостей скомандуйте:
ctlinnd throttle reason

Аргументы имеют смысл:

reason

Причина выключения сервера.

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

Перезапуск сервера новостей

Для перезапуска сервера новостей скомандуйте:
ctlinnd go reason

Аргументы имеют смысл:

reason

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

Эта команда используется для перезапуска после команд throttle, pause или reject.

Отображение статуса поступления новостей

Для отображения статуса новостей скомандуйте:
ctlinnd feedinfo site

Аргументы имеют смысл:

site

Имя сайта (из файла newsfeeds), для которого Вы желаете отобразить состояние.

Прекращение подачи новостей

Для прекращения подачи новостей скомандуйте:
ctlinnd drop site

Аргументы имеют смысл:

site

Имя сайта (из файла newsfeeds), которому не следует впредь передавать новости. Если это поле пустая строка, команда будет применена ко всем сайтам.

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

Начало подачи новостей

Для начала подачи новостей скомандуйте:
ctlinnd begin site

Аргументы имеют смысл:

site

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

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

Отмена статьи

Чтобы отменить статью, скомандуйте:
ctlinnd cancel Message-Id

Аргументы имеют смысл:

Message-ID

ID отменяемой статьи.

Эта команда удаляет определенную статью с сервера. Она не генерирует сообщение отмены статьи.

Назад | Глобальное оглавление | Вперед
Запуск INN | Локальное оглавление | Настройка программ работы с новостями


File System Standards

Назад Preface Вперед

Стандарты файловой системы

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

Чтобы улучшать эту ситуацию, в августе 1993 несколько энтузиастов сформировали Группу по стандартизации файловой системы Linux (Linux File System Standard Group, FSSTND). После шести месяцев обсуждения, группа создала проект, который представляет собой последовательную структуру файловой системы, и определяет расположение наиболее существенных программ и главных файлов конфигурации.

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

Linux FSSTND продолжает развиваться, но в 1997 году у него появился конкурент: стандарт файловой иерархии Linux (Linux File Hierarchy Standard, FHS). FHS учитывает проблемы мультиархитектурных пакетов, чего FSSTND не делал. FHS может быть получен из документационного каталога Linux на всех основных FTP-сайтах Linux или с домашнего сайта http://www.pathname.com/fhs. Daniel Quinlan, координатор группы FHS, доступен как quinlan@transmeta.com.

Назад | Глобальное оглавление | Вперед
Источники информации | Локальное оглавление | Standard Linux Base


Standard Linux Base

Назад Preface Вперед

Стандартная база Linux

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

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

Чтобы помочь преодолеть эту проблему, создан новый проект "Стандартная база Linux" (Linux Standard Base). Его задача описать некую стандартную базу. Если разработчик ориентируется на нее, его программа будет корректно работать во всех дистрибутивах с поддержкой стандарта.

Подробности можно найти на соответствующем web-сайте: http://www.linuxbase.org.

Назад | Глобальное оглавление | Вперед
File System Standards | Локальное оглавление | About This Book


About This Book

Назад Preface Вперед

Про эту книгу

Когда Olaf присоединился к Linux Documentation Project в 1992 году, он написал две маленьких главы по UUCP и smail, которые он хотел добавить к System Administrator's Guide. Разработка работы с сетями TCP/IP только начиналась, и когда те маленькие главы стали расти, он задался вопросом, стоит ли иметь руководство по работе с сетями (Networking Guide). По здравом размышлении было принято решение, создать Networking Guide, первая версия которого вышла в сентябре 1993 года.

Olaf продолжал работать над Networking Guide и результатом стала сильно расширенная версия. Vince Skahan дописал главу про sendmail, которая в этой версии полностью переписана из-за нового интерфейса настройки sendmail.

Текущая версия была модифицирована и дополнена по просьбе издательства O'Reilly & Associates под редакцией Terry Dawson. Terry был около 20 лет оператором любительского радио и примерно 15 лет связан с индустрией телекоммуникаций. Он соавтор оригинального NET-FAQ, и с тех пор поддерживал ряд документов HOWTO, связанных с сетями. Terry всегда был сторонником проекта Network Administrators Guide, и именно он добавил несколько новых глав к этой версии, описывающих новые свойства работы с сетями Linux.

Глава про exim написана Philip Hazel, координатором разработки этого пакета.

Книга орагнизована ступенчато. В начале даются базовые сведения о работе с сетями, заостряя внимание на сетях TCP/IP. Затем изложение плавно переходит к настройке аппаратуры, протокола TCP/IP, различных сервисов, включая firewall, accounting и masquerade, настройке сетевых приложений, например, rlogin, сетевой файловой системы (Network File System) и сетевой информационной системы (Network Information System). Далее рассказывается о настройке поддержки UUCP. Несколько разделов посвящены настройке важных для TCP/IP и UUCP сервисов: e-mail и news. Отдельная глава посвящена протоколу IPX и файловой системе NCP, поскольку они часто применяются в средних организациях вместе с Linux.

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

Описание службы новостей (news) дает Вам краткий обзор того, как работают новости Usenet. Это охватывает INN и C-News, два наиболее широко используемых пакета программ транспортировки новостей, и использование NNTP, чтобы обеспечить программам работы с новостями доступ к локальной сети.

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

Назад | Глобальное оглавление | Вперед
Standard Linux Base | Локальное оглавление | The Official Printed Version


The Official Printed Version

Назад Preface Вперед

Официальные печатные версии

Осенью 1993 Энди Орам, один из подписчиков списка рассылки LDP, спросил Olaf относительно публикации этой книги в O'Reilly & Associates. В конце концов была достигнута договоренность о том, что O'Reilly выпустит печатную версию Networking Guide, но Olaf будет иметь права на оригинал, что позволит ему сохранить исходный текст книги открытым.

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

O'Reilly & Associates печатает Networking Guide для всех желающих купить именно книгу. Как показывает опыт этой уважаемой фирмы, люди охотно покупают книги даже при наличии бесплатной электронной версии. Почему? А потому, что читать с экрана неудобно. Конечно, можно и самому отпечатать, но затраты на это нередко оказываются выше стоимости печатной книги, а уж качество... Так что нет ничего удивительного в том, что проект бесплатного документирования успешно сотрудничает с коммерческой издательской фирмой.

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

Какая разница между электронной и печатной версиями по содержанию? Никакой. В печатной версии есть все то же самое, что и в электронной.

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

Назад | Глобальное оглавление | Вперед
About This Book | Локальное оглавление | Overview


Conventions Used in This Book

Назад Preface Вперед

Соглашения, принятые в книге

Все примеры ориентированы на использование оболочки, совместимой с sh. Оболочка bash вполне совместима с sh и является стандартной для многих дистрибутивов Linux. Если Вы пользуетесь csh, внесите соответствующие корректировки в примеры.

Ниже приведен перечень использованных в книге шрифтовых выделений:

Italic

Использован для имен файлов, программ, каталогов, опций командной строки, адресов e-mail, путевых имен, URL и для новых терминов.

Boldface

Использован для имен машин, хостов, сайтов, пользователей и ID.

Constant Width

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

Constant Width Italic

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

Constant Width Bold

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

Предупреждение

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

Назад | Глобальное оглавление | Вперед
Overview | Локальное оглавление | Submitting Changes


Acknowledgments

Назад Preface Вперед

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

Эта редакция Networking Guide создана усилиями Olaf и Vince. Трудно оценить усилия, которые для этого потребовались. Обновление униги было тоже задачей не из легких, но с хорошей базой, работа была приятной.

Эта книга создана благодаря многим людям, которые внимательно читали ее и писали сови отзывы, комментарии об ошибках и пожелания. Phil Hughes, John Macdonald и Erik Ratcliffe обеспечили подпитку книгу обновлениями.

Мы также очень благодарны людям в O'Reilly, с которым мы имели удовольствие работать: Sarah Jane Shangraw, которая привела книгу в нормальный вид, Maureen Dempsey, правивший текст, Rob Romano, Rhon Porter и Chris Reilley, создавшие иллюстрации, Hanna Dyer, автор обложки, Alicia Cech, David Futato и Jennifer Niedherst, проработавшие внутреннее оформление, Lars Kaufman, создавший общий стиль оформления, Judy Hoer, автор оглавления, и Tim O'Reilly, который взялся за такой проект.

Мы значительно обязаны Andres SepЗlveda, Wolfgang Michaelis, Michael K. Johnson и всем разработчикам, которые потратили свое время на проверку сведений в Networking Guide. Phil Hughes, John MacDonald и Eric Ratcliffe пожертвовали неоценимые комментарии относительно второго издания. Мы также желаем поблагодарить всех тех, кто читал первую версию Networking Guide и прислал исправления и предложения. В заключение, эта книга не была бы создана без поддержки Holger Grothe, предоставившего доступ в Internet для Olaf.

Olaf также хотел бы поблагодарить следующие группы и компании, которые напечатали первое издание Networking Guide и пожертвовали деньги ему или Linux Documentation Project в целом: Linux Support Team, Erlangen, Germany; S.u.S.E. GmbH, Fuerth, Germany; and Linux System Labs, Inc., Clinton Twp., United States, RedHat Software, North Carolina, United States.

Terry благодарит его жену, Maggie, которая терпеливо поддерживала его в течение его участия в проекте несмотря на проблемы. Он также благодарит многих членов сообщества Linux за помощь в работе.

Зал славы

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

Имеется список тех, чье содействие оставило след в книге:

Al Longyear, Alan Cox, Andres SepЗlveda, Ben Cooper, Cameron Spitzer, Colin McCormack, D.J. Roberts, Emilio Lopes, Fred N. van Kempen, Gert Doering, Greg Hankins, Heiko Eissfeldt, J.P. Szikora, Johannes Stille, Karl Eichwalder, Les Johnson, Ludger Kunz, Marc van Diest, Michael K. Johnson, Michael Nebel, Michael Wing, Mitch D'Souza, Paul Gortmaker, Peter Brouwer, Peter Eriksson, Phil Hughes, Raul Deluth Miller, Rich Braun, Rick Sladkey, Ronald Aarts, Swen ThЭemmler, Terry Dawson, Thomas Quinot и Yury Shevchuk.

Перевод на русский язык выполнен Паутовым Алексеем в рамках проекта Russian LDP. ▌ёЮ╝╛╜╝╔ А╞═А╗║╝ ·.┌. ≤╔╒ГЦ╙Ц ╖═ Е╝АБ╗╜ё ╓╚О ╞Ю╝╔╙Б═!

█═╖═╓ | ┐╚╝║═╚Л╜╝╔ ╝ё╚═╒╚╔╜╗╔ | ┌╞╔Ю╔╓
▐╝╓╞╗А╙═ ╜═ ╝║╜╝╒╚╔╜╗О | ▀╝╙═╚Л╜╝╔ ╝ё╚═╒╚╔╜╗╔ | ┌╒╔╓╔╜╗╔ ╒ А╔Б╗


Dealing with Private IP Networks

Назад Глава 7. Serial Line IP Вперед

Работа с внутренними IP-сетями

Как уже упоминалось в главе 5, Virtual Brewery имеет Ethernet-сеть с незарегистрированным IP-адресом из зарезервированного для внутреннего использования диапазона. Пакеты из таких сетей не могут маршрутизироваться в Internet. Если нам нужно, чтобы vlager звонил на cowslip и работал как маршрутизатор для сети Virtual Brewery, компьютеры внутри сети Brewery не смогут работать с реальными машинами в Internet непосредственно, потому что их пакеты будут отброшены первым же маршрутизатором.

Для обхода этой проблемы настроим vlager, чтобы он работал как стартовая площадка для доступа к сервисам Internet. Для внешнего мира он представится как нормальный SLIP-хост Internet с зарегистрированным адресом IP (вероятно, назначенным провайдером, управляющим cowslip). Любой пользователь vlager может использовать программы ftp, telnet, lynx и тому подобные для работы с Internet. Любой пользователь Virtual Brewery LAN может с помощью telnet зайти на vlager и использовать программы на нем. Для некоторых прикладных программ могут быть решения, которые не требуют регистрироваться на vlager. Для пользователей WWW, например, стоит применить прокси-сервер (proxy server) на vlager, который передаст все запросы пользователей на соответствующие сервера в сети.

Необходимость заходить на vlager вызывает неудобства. Но это может быть применимо в небольшой сети, особенно в случае невозможности регистрации нормальной IP-сети. Здесь полезно использовать фильтрацию трафика, чтобы не открывать всю внутреннюю сеть всем в Internet через шлюзовой компьютер. Настройка firewall подробно описана в главе 9. В главе 11 мы подробно рассмотрим Linux IP masquerade, который обеспечивает хорошую замену прокси-серверу.

Допустим, что Brewery имеет IP-адрес 192.168.5.74 для SLIP-доступа. Этот адрес необходимо ввести в файл /etc/hosts с именем vlager-slip. Процедура обеспечения связи по SLIP остается неизменяемой.

Назад | Глобальное оглавление | Вперед
Действия со SLIP | Локальное оглавление | Использование dip


Running pppd

Назад Глава 8. Протокол Point-to-Point Вперед

Запуск pppd

Когда Вы хотите соединитьcя с Internet через PPP-связь, Вы должны установить базисные возможности работы с сетями: loopback-интерфейс и поддержку сервера имен. Обе задачи были описаны в предыдущих главах. Имеются некоторые особенности, которые нужно помнить относительно использования DNS с последовательной связью, пожалуйста, обратитесь к главам 5 и 6 за подробностями. Вы можете просто настроиться на сервер имен провайдера, указав его в файле /etc/resolv.conf, но это будет означать, что каждый запрос к DNS пойдет по последовательной связи. Эта ситуация не оптимальна: чем ближе сервер имен, тем быстрее происходит преобразование. Альтернативное решение состоит в том, чтобы конфигурировать только кэширующий сервер имен в Вашей сети. Это означает, что первый раз, когда Вы делаете запрос к DNS для конкретного компьютера, он будет послан по последовательной связи, но на все следующие запросы для этого же компьютера будет отвечать непосредственно локальный сервер имен, что будет намного быстрее. Эта конфигурация описана в главе 6.

Как вводный пример того, как устанавливать PPP-связь с помощью pppd, представьте, что Вы работаете на машине vlager. Вы уже соединились с сервером c3po по телефону и зарегистрировались под именем ppp. Машина c3po уже запустила свой PPP-драйвер. После выхода из коммуникационных программ, которые Вы используете для соединения по телефону, Вам необходимо выполнить следующую команду:
# pppd /dev/ttyS3 38400 crtscts defaultroute

Эта команда переведет последовательную линию ttyS3 в PPP-режим и установит IP-связь с c3po. Скорость передачи, используемая на последовательном порте будет 38400bps. Опция crtscts включает аппаратное соединение (hardware handshake) на порт, который должен работать на скорости более, чем 9600 bps.

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

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

pppd будет договариваться о IP-параметрах с сервером, используя IPCP (IP control protocol). Так как мы не определяли точно IP-адрес в pppd выше, то он попробует использовать адрес, полученный при просмотре локального hostname. Затем машины объявят этот адрес друг другу.

Обычно, с этими значениями по умолчанию ничего не делается. Даже если Ваша машина находится в Ethernet, Вы можете использовать тот же самый IP-адрес для Ethernet и для PPP-интерфейса. Но тем не менее pppd позволяет Вам использовать различные адреса или даже спрашивать сервер для того, чтобы использовать некоторый специфический адрес. Эти опции будут рассмотрены чуть позже в разделе Опции настройки IP (IPCP).

После прохождения периода установки IPCP, pppd подготовит Ваш сетевой интерфейс для того, чтобы использовать PPP-связь. Сначала будет сконфигурирован сетевой интерфейс PPP как связь point-to-point, используя ppp0 для первой PPP-cвязи, которая является активной, ppp1 для второй и так далее. Затем, он установит маршрутную таблицу, которая указывает на хост в другом конце связи (сервер). В примере, показанном выше, pppd создаст сетевой маршрут по умолчанию к c3po опцией defaultroute. Он заставляет все пакеты к хостам не в локальной сети идти через c3po. Есть ряд различных маршрутов, которые поддерживает pppd, их мы обсудим позже в этой главе.

Назад | Глобальное оглавление | Вперед
Протокол Point-to-Point | Локальное оглавление | Использование файлов Options


Using chat to Automate Dialing

Назад Глава 8. Протокол Point-to-Point Вперед

Использование скрипта для автоматического дозвона

Одна из вещей, которые могут испугать Вас как неудобные в вышеизложенном примере то, что Вы должны установить связь вручную прежде, чем запустить pppd. В отличие от dip, pppd не имеет собственного языка скриптов для набора номера и регистрации, а полагается на внешнюю программу или shell-скрипт для того, чтобы сделать это. Команда, которая будет выполнена, может быть передана pppd опцией connect командной строки. pppd переназначит ввод и вывод к последовательной линии. Пакет pppd имеет очень простую программу chat для этих целей.

Хорошая альернатива для этого expect, написанная Don Libes. Она имеет очень мощный язык, основанный на Tcl, и была разработана для этого типа приложений. Именно ее стоит использовать в случае длинного и сложного процесса входа в систему.

Программа chat позволяет Вам определить скрипт в стиле UUCP. В основном скрипт состоит из последовательности чередующихся строк, которые ожидается получить от удаленной системы, и ответов, которые мы должны ей послать. Мы будем называть expect и send строки, соответственно для приема и передачи. Типичная часть chat-скрипта:
ogin: b1ff ssword: s3|<r1t

Он сообщает chat, что нужно ждать ответ удаленной системы с запросом имени пользователя (login prompt) и вернуть ей в ответ имя b1ff. Мы ждем только ogin: таким образом, не имеет значения с символа в верхнем или нижнем регистре начинается запрос, или он приходит искаженным. Следующяя строка заставит chat ждать запрос пароля и послать свой пароль в ответ.

Это, в основном, все то, для чего предназначены chat-скрипты. Полный скрипт для соединения с 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-скрипта работает точно так же, как описано выше.

Опция -v сообщает chat о необходимости вести подробный протокол средствами демона syslog вызовом local2.

Определение chat-скрипта в командной строке несет оправданный риск, потому что пользователи могут просматривать командную строку любого процесса с использованием команды ps. Вы можете избежать этого, помещая chat-скрипт в файл, скажем dial-c3po. Вы можете заставить chat взять скрипт из файла вместо командной строки, передавая ему опцию -f, сопровождаемую именем файла. Наш скрипт dial-c3po будет выглядеть так:
''      ATZ
OK      ATDT318714
CONNECT ''
ogin:   ppp
word:   GaGariN
Слева написаны строки, которые мы ждем, справа наши ответы на них для передачи удаленной машине.

Вызов pppd будет таким:
# pppd connect "chat -f dial-c3po" /dev/ttyS3 38400 -detach \
        crtscts modem defaultroute

Помимо опции connect, которая определяет скрипт дозвона, мы добавили еще две опции в командной строке: -detach, которая сообщает pppd не отделяться от консоли и стать фоновым процессом. Ключевое слово modem заставит его выполнить некоторые действия, специфичные для модема, на последовательном устройстве, подобно "повесить трубку" после вызова. Если Вы не используете это ключевое слово, pppd не будет определять линию DCD и не обнаружит неожиданного обрыва связи.

Примеры, показанные выше были довольно просты; chat позволяет создавать намного более сложные скрипты. Одна очень полезная особенность, это способность к точному определению строки, на которой можно прервать chat с сообщением об ошибке. Типичные аварийные строки BUSY или NO CARRIER, которые модем обычно генерирует, когда вызываемый номер занят или не поднимает трубку. Для того, чтобы сделать так, чтобы chat их распознавал, Вы можете определить начало скрипта, используя ключевое слово ABORT:
$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

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

Иногда нужно иметь возможность условного выполненич частей скрипта. Например, когда Вы не получаете запрос имени пользователя с удаленной машины, возможно, стоит послать BREAK или возврат каретки. Вы можете достичь этого, присоединяя sub-скрипт к expect-строке. Он состоит из последовательности send и expect строк точно таких же, как и обычный скрипт. Sub-скрипт отделяется тире и выполняется всякий раз, когда не было ничего получено в качестве ожидаемой строки. В примере, изложенном выше, мы модифицировали бы chat-скрипт следующим образом:
ogin:-BREAK-ogin: ppp ssword: GaGariN

Теперь, когда chat видит, что удаленная система не посылает запрос на вход в систему, sub-скрипт выполняется, сначала посылая BREAK, а затем снова ожидает запрос для входа в систему. Если теперь запрос появится, то основной скрипт будет продолжаться как обычно, иначе он прервется с сообщением об ошибке.

Назад | Глобальное оглавление | Вперед
Использование файлов Options | Локальное оглавление | Опции настройки IP (IPCP)


Link Control Options

Назад Глава 8. Протокол Point-to-Point Protocol Вперед

Опции управления связью

Выше Вы уже столкнулись с LCP (Link Control Protocol, протокол управления связью), который используется для того, чтобы задать характеристики связи и проверить ее работу.

Две наиболее важных опции, которые могут быть включены LCP: максимальная длина получаемых пакетов (Maximum Receive Unit) и асинхронное отображение управляющего символа (Asynchronous Control Character Map). Имеется ряд других опций конфигурации LCP, но они слишком специализированы для обсуждения их здесь (большинству пользователей они никогда не понадобятся). Пожалуйста, обратитесь к RFC 1548 за их описанием.

Asynchronous Control Character Map, коротко именуется async map, используется на асинхронных связях, типа телефонных линий, для опознания управляющих символов, которые нужно найти (заменить специфической последовательностью с двумя символами). Например, Вы, может быть, захотите избежать символов XON и XOFF, используемых для установления связи программным обеспечением, потому что плохо сконфигурированный модем может нарушить получение стоп-сигнала. Другим символом, передача которого в чистом виде нежелательна, является Ctrl-] (символ ESC в telnet). PPP позволяет Вам обходить любой символ с ASCII-кодом от 0 до 31, определяя их в аsync-отображении.

Async-отображение предсавляет собой растр длиной в 32 бита с самым младшим битом, соответствующим ASCII-символу NULL, и старшим битом, соответствующим ASCII-коду 31. Если бит установлен, он сообщает, что соответствующий символ должен быть пропущен при передаче.

Для того, чтобы сообщить серверу, что он не должен пропускать все управляющие символы, а только некоторые из них, Вы можете точно определить новый asyncmap для pppd, используя опцию asyncmap. Например, если должны быть пропущены только ^S и ^Q (ASCII-коды 17 и 19, обычно используются для старт-сигнала (XON) и стоп-сигнала (XOFF)), то Вам надо использовать следующую опцию:
asyncmap 0x000A0000

Первоначально, async-отображение установлено в 0xffffffff, то есть все управляющие символы будут пропущены.

Максимальная длина получаемого пакета или Maximum Receive Unit (MRU) сообщает максимальный размер HDLC-фрейма, который мы хотим получить. Хотя это может напоминать Вам значение MTU (Maximum Transfer Unit), но эти два параметра имеют мало общего. MTU параметр ядра для работы с сетями, он описывает максимальный размер структуры для передачи через сетевой интерфейс (неважно какой). MRU советует передающей стороне, какой размер пакетов оптимален.

Выбор MRU задает не скорость связи, а скорее количество пакетов, пришедших без ошибок. Если Вы имеете в виду интерактивные приложения, то установить MRU в значение около 296 является хорошей идеей, чтобы случайный больший блок данных (например, из FTP-сеанса) не сделал курсор "прыгающим". Чтобы сообщить pppd о том, что ему надо запросить MRU 296, задайте ему опцию mru296. Но маленький MRU имеет смысл только, если Вы используете VJ-сжатие заголовков (оно включается по умолчанию).

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

В заключение есть две опции, которые обращаются к LCP-ECHO сообщениям. PPP определяет эти два сообщения, Echo Request и Echo Response. pppd использует эту особенность, чтобы проверить, действует ли связь. Вы можете отключить это, используя опцию lcp-echo-interval. Время задается в секундах. Если никаких структур от удаленного хоста не получено за этот интервала, то pppd сгенерирует запрос ECHO и будет ожидать, какой ECHO-ответ вернет сервер. Если он не возвращает ответ, связь будет прервана после некоторого числа посланных запросов. Это число может быть установлено, используя опцию lcp-echo-failure. По умолчанию эта возможность отключена.

Назад | Глобальное оглавление | Вперед
Опции настройки IP (IPCP) | Локальное оглавление | Основы безопасности


General Security Considerations

Назад Глава 8. Протокол Point-to-Point Protocol Вперед

Основы безопасности

Плохо сконфигурированный PPP daemon может быть разрушителен с точки зрения защиты системы. Это может быть так же плохо, как разрешение подсоединиться любому человеку со своего компьютера к Вашей сети Ethernet (а это ОЧЕНЬ плохо). В этом разделе мы обсудим несколько критериев, которые должны сделать Вашу конфигурацию PPP безопасной.

Замечание:

Настройка сетевого интерфейса и таблицы маршрутизации требуют привилегии root. Обычно Вы будете решать эту проблему, выполняя setuid root. Однако, pppd позволяет пользователям установить различные защитные опции. Для защиты против любого нападения, пользователь может манипулировать этими опциями, Вам следует установить пару значений по умолчанию в глобальном файле /etc/ppp/options, подобно показанным в главе "Использование файлов Options". Некоторые из них, например, авторизационные опции, не могут быть отменены пользователем.

Для зашиты важна опция connect. Если Вы предполагаете позволить не-root пользователям вызывать pppd, чтобы соединиться с Internet, Вы должны всегда добавлять параметры connect и noauth к глобальному файлу параметров /etc/ppp/options. Если Вы этого не сделаете, пользователи смогут выполнить произвольные команды с привилегиями root, определяя команду как параметр connect в строке запуска pppd или в их персональном файле параметров.

Другая хорошая идея состоит в том, чтобы ограничить, какие пользователи могут выполнять pppd, создав группу в /etc/group и добавляя только тех пользователей, которым это разрешено. Вы должны затем изменить группу владельца pppd на эту группу и удалить разрешение на выполнение для всех остальных пользователей. Допустим, свежая группа называется dialout, тогда выполните:
# chown root /usr/sbin/pppd
# chgrp dialout /usr/sbin/pppd
# chmod 4750 /usr/sbin/pppd

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

Назад | Глобальное оглавление | Вперед
Link Control Options | Локальное оглавление | Авторизация с PPP


Debugging Your PPP Setup

Назад Глава 8. Протокол Point-to-Point Вперед

Отладка Ваших настроек PPP

По умолчанию pppd регистрирует любые предупреждения и сообщения об ошибках через syslog daemon. Вы должны добавить запись в syslog.conf, которая переназначит их к файлу или даже к консоли, иначе syslog просто отбросит эти сообщения. Следующая запись посылает все сообщения в /var/log/ppp-log:
daemon.*                /var/log/ppp-log

Если настройка PPP не работает, при просмотре этого log-файла Вы должны получить подсказку, что что-то идет неправильно. Если это не помогает, то Вы можете включить особо подробный вывод, используя опцию отладки debug. После этого протокол для pppd будет содержать все управляющие блоки, посланные или полученные syslog. Все сообщения будут идти через daemon.

В заключение, наиболее радикальная возможность: включение отладки на уровне ядра, вызовом pppd с опцией kdebug. Она сопровождается числовым аргументом, который является поразрядным ИЛИ следующих значений: 1 для общих сообщении отладки, 2 для печати содержания всей входящей HDLC-структуры, и 4 для того, чтобы сделать драйвер принтера выходящим на HDLC-структуру. Для того, чтобы захватить сообщения ядра, Вы должны также запустить syslogd, который будет читать файл /proc/kmsg или klogd daemon. Каждый из них направляет отладку ядра в syslog kernel.

Назад | Глобальное оглавление | Вперед
Авторизация и PPP | Локальное оглавление | Тонкая настройка PPP


More Advanced PPP Configurations

Назад Глава 8. Протокол Point-to-Point Вперед

Тонкая настройка PPP

При конфигурировании PPP для приема входящих звонков возникает ряд дополнительных требований. В этом разделе мы рассмотрим тонкую настройку PPP под Linux для такого случая.

PPP-сервер

При запуске pppd нужно учитывать, что запуск в режиме сервера, это только вопрос добавления соответствующей опции в командной строке и конфигурирования последовательного tty-устройства так, чтобы вызвать pppd с соответствующими параметрами, когда было получено входящее обращение. Было бы идеально создать специального пользователя, скажем ppp, и задать ему скрипт или программу, которая вызывает pppd с этими опциями как оболочку входа в систему. Другой вариант: если Вы предполагаете поддерживать авторизацию по PAP или CHAP, можно использовать программу mgetty, чтобы поддерживать модем и использовать свойство "/AutoPPP/".

Чтобы создать сервер с использованием метода входа в систему, добавьте следующую строку в файл /etc/passwd:
ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin
Если Ваша система использует затенение паролей, добавьте в файл /etc/shadow строку:
ppp:!:10913:0:99999:7:::

Конечно, UID и GID, которые Вы используете, зависят от того, какой пользователь использован для подключения. Вы также должны установить пароль для этого пользователя, используя команду passwd.

Скрипт ppplogin может выглядеть так:
#!/bin/sh
# ppplogin - script to fire up pppd on login
mesg n
stty -echo
exec pppd -detach silent modem crtscts

Команда mesg отключает других пользователей от записи в tty с использованием, например, вызова write. Команда stty выключает повторение символов (эхо). Эта команда необходима: без нее все, что посылает клиент будет послано ему назад. Наиболее важная опция pppd -detach. Она не дает pppd отсоединится от управления tty. Если мы не определили эту опцию, pppd перейдет в фоновый режим, а скрипт входа завершится. Это в свою очередь приведет к завершению связи. Опция silent заставляет pppd ждать получения пакета с вызываемой системы и не начинать свою передачу до его прибытия. Эта опция предотвращает разрыв связи, если удаленная система медлительная. Параметр modem предписывает pppd управлять линиями контроля модема на последовательных портах. Вы должны всегда задать эту опцию при использовании pppd с модемом. Опция crtscts включает аппаратное соединение (hardware handshake).

Помимо этих параметров можно использовать какой-либо вариант авторизации, например, определяя auth в командной строке pppd или в глобальном файле параметров.

Если Вы хотите использовать mgetty, все, что Вы должны сделать, это настроить mgetty так, чтобы поддерживать последовательное устройство с которым связан модем (подробности изложены в главе 4), затем настроить pppd для авторизации по PAP или CHAP с помощью соответствующих параметров в файле options и добавить раздел, подобный следующему, к файлу конфигурации /etc/mgetty/login.config:
# Configure mgetty to automatically detect incoming PPP calls and invoke
# the pppd daemon to handle the connection.
#
/AutoPPP/ -     ppp   /usr/sbin/pppd auth -chap +pap login

Первое поле используется, чтобы обнаружить входящее обращение к PPP (чувствительно к регистру). Третий столбец задает имя пользователя, которое появится в выводе команды who. Остальная часть строки команда для вызова сервиса. В нашем примере мы определяем, что нужна авторизация PAP, запрещаем CHAP и определяем, что системный файл passwd должен использоваться для авторизации пользователей. Не забудьте, что Вы можете определять параметры в файле options или в командной строке.

Чтобы запустить PPP на Вашей машине, нужно сделать следующее:

  1. Настроить модем на автоответ. Hayes-совместимые модемы используют для этого команду ATS0=3. Если вы хотите использовать mgetty daemon, это необязательно.

  2. Настройте последовательное устройство с помощью команды getty на прием входящих звонков. Обычно это делается с помощью варианта getty, команды mgetty.

  3. Решите какой вариант авторизации будет использован. Системный логин, PAP или CHAP?

  4. Настройте pppd для работы в режиме сервера.

  5. Рассмотрите маршрутизацию. Вы должны обеспечить сетевой маршрут к вызывающим абонентам или нет? Маршрутизация может выполняться, используя скрипт ip-up.

Дозвон по требованию

Далеко не всегда возможно держать телефонную линию, занятой модемной связью постоянно. Это все-таки не выделенный канал... Поэтому было разработано решение, получившее название demand dialing (дозвон по требованию). Суть метода сводится к тому, что соединение устанавливается только при появлении некоего трафика, который нужно передать по модему. В этом случае компьютер должен сам дозвониться до провайдера, зарегистрироваться на сервере и выполнить обмен данными. По окончании сеанса связи компьютер должен просто завершить соединение. На деле он ждет некоторое время, не появится ли еще информация для передачи через Internet.

Традиционные Linux-решения использовали команду diald, которая работала хорошо, но была довольно сложна в настройке. Версии 2.3.0 и старше PPP daemon имеют встроенную поддержку дозвона по запросу, в результате чего процесс существенно упростился. Вы должны использовать для этого современное ядро (на деле любое ядро старше версии 2.0).

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

Параметр | Описание
demand | Указывет, что PPP-связь работает в режиме "дозвон по запросу". Сетевое устройство PPP будет создано, но команда connect не будет использоваться, пока не придет пакет с локального компьютера. Эта опция обязательна для данного режима.
active-filter expression | Позволяет Вам определять, какие пакеты стоит рассматривать как трафик. Любой трафик, соответствующий заданным критериям, перезапустит таймер неактивности сетевого соединения, гарантируя, что pppd подождет указанное время перед закрытием связи. Синтаксис фильтра был заимствован из команды tcpdump. Заданный по умолчанию фильтр соответствует всем пакетам.
holdoff n | Позволяет Вам определять минимальное время в секундах, которое нужно ждать перед перезапуском линии в случае обрыва связи. Если подключение терпит неудачу в то время, как pppd полагает, что оно находится в активном пользовании, соеднение будет восстановлено после того, как кончится время на этом таймере. Этот таймер не относится к перезапуску связи после окончания времени бездействия линии.
idle n | Если эта опция задана, pppd разъединит связь всякий раз, когда время в этом таймере истекает. Каждый новый активный пакет сбросит таймер. Время неактивности задается в секундах.
Простая конфигурация для дозвона по требованию:
demand
holdoff 60
idle 180
Эта конфигурация включает дозвон по запросу, предписывает ждать минуту перед восстановлением оборванной связи и разрывает связь, если она не использовалась свыше 180 секунд.

Постоянный дозвон

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

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

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

Типичная конфигурация для постоянного дозвона:
persist
holdoff 600
Время в опции holdoff определено в секундах. В нашем примере pppd ждет пять минут перед повторным набором.

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

Назад | Глобальное оглавление | Вперед
Отладка Ваших настроек PPP | Локальное оглавление | TCP/IP Firewall


More About Network Address Translation

Назад Глава 11. IP Masquerade и Network Address Translation Вперед

Еще о сетевой трансляции адресов (Network Address Translation)

Пакет netfilter способен к различным типам Network Address Translation. IP Masquerade является частным случаем этого.

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

Трансляция исходного адреса пакета известна как Source NAT или SNAT в документации netfilter . Трансляция адреса назначения пакета известна как Destination NAT или DNAT. Трансляция портов TCP или UDP известна как REDIRECT. SNAT, DNAT и REDIRECT могут быть адресатами, которые Вы можете использовать с командой iptables, чтобы формировать более сложные правила.

Тема сетевой трансляции слишком велика, чтобы охватить ее целиком в этой главе. Подробности можно найти в IPTABLES-HOWTO.

Назад | Глобальное оглавление | Вперед
Перехват обращений к серверу имен | Локальное оглавление | Важные сетевые возможности


Setting Up an NIS Client with GNU libc

Назад Глава 13. Network Information System (NIS) Вперед

Установка клиента NIS с GNU libc

Теперь обсудим конфигурацию клиента NIS, использующего поддержку библиотеки GNU libc.

Вашим первым шагом должно быть сообщение клиенту GNU libc NIS того, какой сервер использован для NIS, устанавливая это в файле конфигурации /etc/yp.conf. Очень простой типовой файл для сети может выглядеть следующим образом:

# yp.conf - YP configuration for GNU libc library.
#
ypserver vbardolino

Инструкция ypserver предписывает использовать хост, заданный как NIS-сервер для локального домена. В этом примере мы определили NIS-сервер как vbardolino. Конечно, соответствие IP-адреса машине vbardolino должно быть задано в файле hosts. Впрочем, можно использовать IP-адрес явно в качестве аргумента параметра server.

В форме, показанной в примере, команда ypserver сообщает ypbind, что нужно использовать заданный сервер, независимо от текущего домена NIS. Если Вы часто перемещаете свою машину между NIS-доменами, хорошо бы хранить информацию для нескольких доменов в файле yp.conf. Вы можете иметь информацию для различных NIS-доменов в одном файле yp.conf, конкретизируя с использованием команды domain. Например, можно переделать предыдущий типовой файл ноутбука:
# yp.conf - YP configuration for GNU libc library.
#
domain winery server vbardolino
domain brewery server vstout

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

Имеется третья весьма полезная опция. Она учитывает случай, когда Вы не знаете имя или IP-адрес сервера, чтобы использовать его в настройках, но можете использовать фиксированный сервер в некоторых доменах. Измените свой файл настройки yp.conf так:
# yp.conf - YP configuration for GNU libc library.
#
domain winery server vbardolino
domain brewery broadcast

Команда broadcast сообщает ypbind, что надо использовать любой сервер, который удалось найти для NIS-домена.

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

# ypcat hosts.byname
172.16.2.2      vbeaujolais.vbrew.com    vbeaujolais
172.16.2.3      vbardolino.vbrew.com     vbardolino
172.16.1.1      vlager.vbrew.com         vlager
172.16.2.1      vlager.vbrew.com         vlager
172.16.1.2      vstout.vbrew.com         vstout
172.16.1.3      vale.vbrew.com           vale
172.16.2.4      vchianti.vbrew.com       vchianti

Вывод, который Вы получаете, должен походить на показанный. Если Вы получаете сообщение об ошибке Can't bind to server which serves domain, то домен NIS не соответствует серверу, заданному в yp.conf, или сервер недоступен. В последнем случае удостоверьтесь, что ping для этого хоста выдает положительный результат, и что сервер NIS запущен. Вы можете проверить последний факт использованием rpcinfo, который должен произвести следующий вывод:
# rpcinfo -u serverhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

Назад | Глобальное оглавление | Вперед
Безопасность NIS-сервера | Локальное оглавление | Выбор правильных карт


Resetting the Counters

Назад Глава 10. IP Accounting Вперед

Перезапуск счетчиков

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

Команды ipfwadm и ipchains позволяют сделать это просто:
# ipfwadm -A -z
или:
# ipchains -Z
или:
# iptables -Z
Вы можете даже объединять вывод списка и обнуление, чтобы гарантировать что никакие данные учета не потеряны между этими действиями:
# ipfwadm -A -l -z
или:
# ipchains -L -Z
или:
# iptables -L -Z -v
Эти команды сначала отобразят все данные со счетчиков, затем немедленно обнулят счетчики и начнут учет сначала. Если Вы регулярно собираете статистику, имеет смысл написать скрипт с соответствующими командами и вызывать его через cron.

Назад | Глобальное оглавление | Вперед
Использование результатов IP Accounting | Локальное оглавление | Очистка правил