В этой книге описаны принципы действия и область применения многих серверов, выполняющихся в системе Linux. Здесь рассматриваются DHCP-сервер, серверы Samba и NFS, серверы печати, NTP-сервер, средства удаленной регистрации и система X Window. He забыты и средства, традиционно используемые для обеспечения работы Internet-служб: серверы DNS, SMTP, HTTP и FTP. Большое внимание уделено вопросам безопасности сети. В данной книге нашли отражения также средства удаленного администрирования — инструменты Linuxconf, Webmin и SWAT.
Данная книга несомненно окажется полезной как начинающим, так и опытным системным администраторам.
Отзывы о книге Сетевые средства Linux
Появилась прекрасная книга по Linux, осталось воспользоваться ею. Не упустите свой шанс.Александр Стенцин, Help Net Security, www.net-security.org
Если вы стремитесь в полной мере использовать сетевые возможности Linux — эта книга для вас. Я настоятельно рекомендую прочитать ее.Майкл Дж. Джордан, Linux Online
Выхода подобной книги давно ожидали читатели. Менее чем на 700 страницах автор смог изложить суть самых различных вопросов, связанных с работой Linux. Автор является высококвалифицированным специалистом в своей области и щедро делится своими знаниями с читателями.Роджер Бертон, West, DiverseBooks.com
Введение
Компьютерные сети изменили нашу жизнь. Они были почти незаметны в 1970-х и даже в 1980-х. Однако в начале 1990-х годов что-то произошло. Возможно, это было появление World Wide Web и графических Web-броузеров, благодаря которым Internet пришла во многие семьи. Возможно, число сетевых соединений превысило какой-то критический предел. Может быть, этот предел превысило количество сетевых программ. Как бы то ни было, сейчас о сетях знают все. А самое главное, что каждый знает о существовании Internet.
Internet объединяет миллионы компьютеров, на многих из которых выполняются серверы — программы, принимающие запросы от клиентов и обрабатывающие их. Благодаря тому что протоколы, на которых базируется Internet, допускают межплатформенное взаимодействие, в обмене данными могут участвовать клиенты и серверы, выполняющиеся на различных компьютерах и в разных операционных средах. В последние годы одной из самых популярных операционных систем стала Linux. Установленная на недорогом компьютере x86, система Linux обеспечивает эффективную работу серверов, поддерживающих узлы небольшого и среднего размеров. С увеличением производительности компьютеров появляется возможность выполнения в среде Linux серверов, обрабатывающих большие объемы данных. В результате от системного администратора часто требуется умение настраивать систему Linux и серверы, выполняющиеся в ее среде.
На каких же серверах следует остановить свой выбор? Существуют сотни, если не тысячи, серверных программ. В большинстве книг, посвященных системе Linux, основное внимание уделяется нескольким популярным серверам: HTTP-серверу (обычно это Apache), серверам удаленной регистрации, таким как Telnet и SSH, файловым серверам, примерами которых являются NFS и Samba, и некоторым другим типам серверов. В данной книге рассматриваются самые различные серверы. Разнообразие рассматриваемых вопросов не дает возможности подробно изучить работу и особенности настройки каждого из серверов, но все же приведенной информации достаточно, чтобы обеспечить выполнение соответствующих программ. Помимо наиболее популярных серверов, в настоящей книге также рассматриваются средства, которым обычно уделяется мало внимания, но которые, тем не менее, чрезвычайно важны для нормального функционирования сети. Так, например, здесь есть главы, посвященные DHCP-серверу, временному серверу и системе Kerberos. В данной книге не излагаются основы функционирования сетей. Считается, что читатель уже имеет представление о сетевых средствах и собирается повысить свою квалификацию.
Главы, в которых описываются сложные серверы, такие как Apache и Samba, не содержат исчерпывающего их описания. За общей информацией об этих инструментах следует рассмотрение их расширенных функций, ориентированное на администратора, имеющего некоторый опыт работы. Новичкам, прежде чем изучать эти главы, желательно прочитать книги, содержащие вводный курс администрирования данных серверов.
ЧАСТЬ I
Низкоуровневая конфигурация системы
Глава 1
Настройка сетевых средств ядра
"Все дороги ведут в Рим" — гласит пословица. Нечто подобное можно сказать и о сетевых средствах Linux; в этом случае в роли Рима выступает ядро операционной системы. Рано или поздно весь сетевой трафик будет обработан ядром. Различные компьютеры и разные сети отличаются друг от друга, поэтому для ядра Linux предусмотрен ряд опций, изменяя значения которых вы можете оптимизировать систему с учетом задач, которые ей придется выполнять. Установку некоторых опций можно производить в процессе загрузки системы, передавая ядру необходимые параметры, либо впоследствии, после окончания загрузки. Подобные опции будут рассмотрены в последующих главах. Существуют также характеристики, для изменения которых надо перекомпилировать ядро системы.
В данной главе описаны опции, которые задают конфигурацию ядра. Сначала здесь рассматривается процедура настройки ядра. Затем обсуждаются опции, которые определяют свойства TCP/IP и других сетевых протоколов, а также сетевых фильтров. Далее речь пойдет о драйверах Linux, предназначенных для поддержки различных сетевых устройств. В конце главы кратко описывается процесс компиляции ядра системы.
Конфигурация ядра
Для того чтобы установить опции, определяющие процесс компиляции ядра, необходимо иметь в наличии исходный код ядра. Исходный код входит в состав всех дистрибутивных пакетов, но при установке системы можно либо разрешить, либо запретить копирование исходного кода на жесткий диск компьютера. Следует заметить, что в некоторых случаях исходный код, поставляемый в составе дистрибутивного пакета, может быть изменен по сравнению со стандартным кодом ядра (так, например, в состав кода могут быть включены специальные драйверы). Целесообразно вначале инсталлировать стандартное ядро, а затем, по мере необходимости, установить дополнительные модули (не исключено, что для выполнения ваших задач никакие дополнения не потребуются). Список основных узлов, содержащих архивы Linux, находится по адресу
http://www.kernel.org
. В частности, там вы найдете ссылку на
ftp://sunsite.unc.edu
и адреса других узлов, содержащих последние варианты исходного кода ядра Linux. (Конечно, вы можете работать с исходным кодом ядра, который входит в состав дистрибутивного пакета, но, как было сказано выше, в нем могут быть установлены дополнительные модули. Если в процессе работы возникнут проблемы, то устранить их будет легче, если у вас инсталлировано стандартное ядро.)
Обычно исходный код ядра содержится в каталоге
/usr/src/linux
либо в одном из подкаталогов
/usr/src
(при этом в имени каталога присутствует номер версии ядра, например
/usr/src/linux-2.4.17
). В последнем случае желательно создать ссылку
/usr/src/linux
, указывающую на каталог с исходным кодом ядра. Если вы поступите так, то обеспечите нормальную работу программ, которые предполагают, что исходный код ядра содержится в каталоге
/usr/src/linux
. Таким образом, удобно работать с несколькими версиями исходного кода ядра, а если надо перейти от одной версии к другой, достаточно лишь изменить символьную ссылку.
Разархивировав исходный код ядра в каталог
/usr/src/linux
, надо сделать это каталог рабочим в используемой вами оболочке. После этого можно задать одну из описанных ниже команд конфигурирования ядра.
•
Поддержка сетевых протоколов
Меню Networking Options содержит опции, влияющие на работу сетевых протоколов. Вы можете включить или исключить средства поддержки стека протоколов либо отдельных протоколов (в основном данные опции касаются семейства протоколов TCP/IP). Опции из этого меню позволяют также оптимизировать ядро для выполнения конкретных функций, например маршрутизации или фильтрации пакетов.
Опции для работы с пакетами и гнездами
Низкоуровневые сетевые средства Linux позволяют программам передавать и принимать фрагменты данных, называемые
пакетами
, посредством специальных структур, которые называются
гнездами
(socket). В большинстве случаев обмен данными через гнездо осуществляется по тому же принципу, что и обмен данными с файлом. Стек сетевых протоколов обеспечивает передачу информации по адресу назначения, где происходит ее интерпретация.
В некоторых случаях желательно и даже необходимо изменить принцип обработки данных; иногда приходится расширять стандартный набор операций над пакетами. Сделать это позволяют специальные опции, рассмотрению наиболее важных из них посвящены разделы данной главы. Некоторые из опций кратко описаны ниже.
•
Packet Socket
. Эта опция позволяет приложениям непосредственно обращаться к требуемому протоколу, минуя некоторые уровни стека протоколов. Для большинства программ такая возможность не нужна; ее используют лишь инструментальные средства сетевой диагностики и специальные утилиты, действующие на нижнем уровне. В качестве примера подобных программ можно привести утилиту
tcpdump
, которая выводит информацию о пакетах TCP и IP. Данная опция не обязательна. Она несколько увеличивает размер ядра и дает возможность злоумышленникам воспользоваться утилитами сетевой диагностики. С другой стороны, отключив данную опцию, вы не сможете воспользоваться целым рядом утилит.
•
Packet Socket: Mapped IO
. Если данная подопция Packet Socket включена, производительность инструментальных средств, использующих низкоуровневые соединения, повышается.
•
Unix Domain Sockets
. Некоторые важные программы Linux используют сетевые протоколы для обмена данными даже в том случае, если они выполняются на одном и том же компьютере. В качестве примеров можно привести средство протоколирования
syslogd
и программы, выполняющиеся в среде X-Window (X-программы используют сетевой протокол для взаимодействия с X-сервером, выполняющим отображение данных). Опция
Unix Domain Sockets
допускает взаимодействие в пределах одной системы даже в тех случаях, когда на компьютере не установлено сетевое оборудование. Даже если средства поддержки сетевого обмена присутствуют, опция
Опции сетевой фильтрации
Опции сетевой фильтрации блокируют или преобразуют пакеты, поступающие на компьютер или покидающие его. Данные опции используются при создании брандмауэров и выполнении IP-маскировки (подробно эти вопросы будут обсуждаться в главе 25). Брандмауэры блокируют нежелательные обращения к компьютеру или сети, а IP-маскировка позволяет организовать работу в Internet пользователей всей локальной сети при наличии одного IP-адреса. Опции ядра системы, предназначенные для фильтрации, перечислены ниже.
•
Socket Filtering
. В обычных условиях ядро направляет все пакеты, полученные через некоторое гнездо, программе, которая создала это гнездо. Опция
Socket Filtering
позволяет указать ядру на то, что принятые пакеты должны быть сначала переданы небольшой программе (которая называется фильтром). Эта программа способна блокировать некоторые из пакетов. Как правило, программы могут работать без данной опции. Исключение составляют последние варианты серверов DHCP и клиентов DHCP. Если в вашей сети используются средства DHCP (Dynamic Host Configuration Protocol — протокол динамической конфигурации узла), данная опция должна быть установлена.
•
Network Packet Filtering
. Данная опция является наиболее важным средством фильтрации, так как именно она делает возможной работу брандмауэра и IP-маскировку. Обычно опция
Network Packet Filtering
устанавливается; при этом становится доступной опция
Network Packet Filtering Debugging
, которую можно использовать для решения возникающих проблем. Кроме того, становится также доступным подменю
IP: Netfilter Configuration
. В этом подменю отображаются описанные ниже опции.
•
Connection Tracking
. Эта опция обеспечивает более высокую степень контроля над сетевыми соединениями, чем это возможно в обычных условиях. Как правило, маршрутизаторы ограничиваются пересылкой информационных пакетов между сетевыми интерфейсами. Если опция
Connection Tracking
активна, система запоминает IP-адрес источника, IP-адрес назначения и порты для дальнейшего использования. Эта возможность необходима для реализации IP-маскировки. В других случаях опцию
•
Опции маршрутизации TCP/IP
Маршрутизатор
— это компьютер, который непосредственно передает данные из одной сети в другую. Маршрутизаторы также часто называют
шлюзами
. Так, например, маршрутизатор может понадобиться для связи сети, принадлежащей отделу большой корпорации, с корпоративной сетью. Корпорация, в свою очередь, использует маршрутизатор для обеспечения связи своей сети с Internet. Рассмотрению опций маршрутизации посвящена глава 24. Сейчас вам достаточно знать лишь то, что для ядра Linux предусмотрен ряд опций, являющихся подопциями
IP: Advanced Route
r.
Опции поддержки IPv6
Работа Internet обеспечивается за счет протоколов семейства TCP/IP, в частности, для передачи пакетов используется протокол IP (IPv4). К сожалению, на сегодняшний день уже невозможно игнорировать тот факт, что версия IPv4 устарела. Для представления IP-адреса в IPv4 используется 32-разрядное число, т.е. общее число адресов равно 2³², или 4294967296. Вследствие неэффективности механизма распределения адресов реальное их количество оказывается намного меньшим. В результате возникла проблема нехватки IP-адресов. Кроме того, недостатки в защите IPv4 позволяют злоумышленникам вмешиваться в сеансы сетевого взаимодействия. На момент написания данной книги, т.е. в 2002 г., с проблемами, связанными с использованием IPv4, еще можно мириться, но их придется решить в течение ближайшего десятилетия.
В настоящее время разрабатывается версия IPv6, призванная заменить IPv4. В IPv6 поддерживаются 128-разрядные IP-адреса. Общее число IP-адресов равно 2
128
, или 3,4×10
38
— приблизительно 2,2×10
18
адресов на квадратный миллиметр поверхности Земли. IPv6 также обеспечивает дополнительные средства защиты. В настоящее время число сетей, в которых используется IPv6, очень мало. Если ваш компьютер подключен к такой сети или если вы собираетесь в качестве эксперимента организовать обмен данными во внутренней сети предприятия посредством IPv6, вам надо активизировать средства поддержки IPv6, установив для этого опцию
IPv6 Protocol (Experimental)
в меню
Networking Options
. После установки данной опции вам станут доступны дополнительные опции, объединенные в подменю
IPv6: Netfilter Configuration
. В этом подменю также находятся описанные ранее опции фильтрации, но они ориентированы на работу с протоколом IPv6.
Опции для работы с аппаратными средствами
В меню
Network Device Support
содержатся опции, определяющие взаимодействие системы с различными сетевыми устройствами. Самые важные из этих опций управляют использованием драйверов сетевых карт. Несмотря на то что в настоящее время наиболее распространены Ethernet-карты, в меню
Network Device Support
содержатся опции для работы и с другими устройствами, предназначенными для создания локальных сетей. Кроме того, Linux предоставляет опции, включающие драйверы устройств дальней связи и драйверы беспроводных устройств. Устройства PC Card (применяющиеся в портативных компьютерах) описаны в отдельном подменю, которое входит в состав меню
Network Device Support
. Вы также можете выбрать устройства, позволяющие устанавливать соединения по телефонным линиям через модемы, и другие аппаратные средства.
Для того чтобы получить доступ к описанным выше опциям, надо установить опцию
Network Device Support
, которая находится в начале меню
Network Device Support
. Если вы не сделаете это, опции в данном меню будет не доступны.
Устройства Ethernet
На момент написания данной книги, т.е. в 2002 г., подавляющее большинство локальных сетей строились на базе Ethernet. Беспроводные технологии также пользуются определенной популярностью, но сети, созданные на их основе, проигрывают сетям Ethernet в скорости обмена. Одной из проблем, усложняющих процесс администрирования операционных систем, является тот факт, что число разновидностей Ethernet-карт исчисляется сотнями и даже тысячами.
К счастью, при построении Ethernet-карт применяется ограниченный набор микросхем, поэтому для поддержки подавляющего большинства таких устройств достаточно шестидесяти драйверов. Опции, управляющие использованием этих драйверов, сосредоточены в двух подменю: Ethernet (10 or 100Mbit) и Ethernet (1000 Mbit). Большинство опций находится в первом меню. Соответствующие им драйверы, как следует из названия подменю, ориентированы на устройства, обеспечивающие скорость обмена 10 и 100 Мбод. На момент написания этой книги наибольшей популярностью пользуются Ethernet-платы 100 Мбод (100-мегабитовая Ethernet), а в некоторых случаях применяются более новые платы 1000 Мбод (или гигабитовая Ethernet). Разрабатываются также Ethernet-карты 10 Гбод.
Структура меню Ethernet (10 or 100 Mbit) далека от совершенства. В начале меню перечислены сетевые карты 3Com, SMC, Racal-Interlan и некоторых других производителей. За ними расположены устройства ISA (Industry Standard Architecture), затем следуют устройства EISA (Extended ISA), VLB (VESA Local Bus) и PCI (Peripheral Component Interconnect). Завершается список группой параллельных Ethernet-адаптеров. В результате для поиска требуемого устройства приходится просматривать две-три группы опций.
Существуют также Ethernet-устройства, драйверы которых не устанавливаются посредством опций меню
Network Device Support
или его подменю. Так, например, для устройств PC Card используются специальные драйверы, а адаптеры USB — Ethernet описаны в меню
USB Support
. Для того чтобы использовать устройство USB, вам надо, в зависимости от контроллера, присутствующего на материнской плате, установить либо опцию
Альтернативные средства для создания локальных сетей
Несмотря на свою популярность, Ethernet — отнюдь не единственное устройство, позволяющее создать локальную сеть. В ядре Linux предусмотрена поддержка различных типов сетей. Число драйверов для устройств, отличных от Ethernet, невелико, но это не означает, что средства для организации соответствующих сетей разработаны недостаточно хорошо. Ниже приведены некоторые опции, присутствующие в меню
Network Device Support
.
•
Token Ring
. В течение многих лет технология Token Ring, разработанная IBM, была главным конкурентом Ethernet, однако начиная с 1990 г. преимущество Ethernet стало очевидным. Большинство карт Token Ring поддерживают скорость обмена до 16 Мбод, но в настоящее время появились модели 100 Мбод. Максимальное расстояние между устройствами в сети Token Ring составляет 150-300 метров. Средства поддержки устройств Token Ring сосредоточены в подменю
Token Ring Devices
меню
Network Device Support
.
•
LocalTalk
. Для компьютеров Macintosh компания Apple разработала сетевую технологию, включающую протоколы как аппаратного (LocalTalk), так и программного (AppleTalk) уровня. Для взаимодействия с сетями LocalTalk были разработаны устройства x86; некоторые из них поддерживает система Linux. Соответствующие опции находятся в меню
AppleTalk Devices
. Как ни странно, версия Linux, разработанная для Macintosh, не поддерживает LocalTalk. На момент написания данной книги максимальная скорость обмена данными в сети LocalTalk составляла 2 Мбод.
•
ARCnet
. Это сетевая технология, которая в основном используется в специальных целях, например, для подключения охранных устройств или для сбора результатов научных экспериментов. Устройства ARCnet обеспечивают скорость обмена от 19 Кбод до 10 Мбод. Соединение устройств осуществляется с помощью коаксиального кабеля, витой пары или волоконно-оптического кабеля. Опции поддержки ARCnet находятся в подменю
ARCnet Devices
. Помимо драйвера устройства, вам необходимо включить драйвер, предназначенный для поддержки формата ARCnet-пакетов (RFC 1051 или RFC 1201).
•
Устройства с широкой полосой пропускания и устройства, обеспечивающие связь на большой дальности
Термин "устройства с широкой полосой пропускания" имеет несколько значений. Во-первых, этот термин обозначает устройства, позволяющие одновременно передавать различные типы информации, например, видео, аудио и обычные цифровые данные. Во-вторых, устройствами с широкой полосой пропускания называют устройства с большой пропускной способностью, позволяющие увеличить скорость передачи данных по коммутируемым линиям (например, реализовать скорость обмена до 200 Кбод). Конечно, величина 200 Кбод выглядит более чем скромно по сравнению со скоростями, которые обеспечивает технология Ethernet, но все же 200 Кбод — это значительно больше, чем скорость 56 Кбод, которой позволяют добиться обычные телефонные линии.
Устройства с широкой полосой пропускания часто применяются в небольших компаниях для связи с серверами Internet-провайдеров или для организации взаимодействия компьютеров, расположенных далеко друг от друга. В большинстве случаев посредством устройств с широкой полосой пропускания пользователи подключают свои компьютеры к Internet. Этим данные устройства отличаются от других сетевых устройств, которые связывают несколько компьютеров в одну локальную сеть. Часто, подключая компьютеры пользователей через устройства с широкой полосой пропускания, провайдеры накладывают ограничения на их действия. Так, например, провайдер может запретить пользователю устанавливать на своем компьютере серверы.
На момент написания данной книги наиболее популярными из устройств с широкой полосой пропускания были DSL (Digital Subscribe Line — цифровая линия подписки) и кабельные модемы. Существует несколько разновидностей DSL, например ADSL (Asymmetric DSL — асимметричная DSL) и SDSL (Single-Line, или Symmetric DSL — одиночная линия, или асимметричная DSL). В процессе работы DSL-устройства передают высокочастотные сигналы по обычным телефонным линиям. Кабельные модемы пересылают данные по кабельным телевизионным сетям и используют полосу частот свободного телевизионного калана. Некоторые из устройств с широкой полосой пропускания передают данные через спутниковые системы, по радиоканалам и по волоконно-оптическим кабелям.
Большинство соединений с широкой полосой пропускания используют специальные внешние модемы, а подключение к локальным компьютерам производится через Ethernet-порты. Поэтому, для того, чтобы работа через такое соединение стала возможной, необходим Ethernet-адаптер, кроме того, надо обеспечить поддержку этого адаптера с помощью стандартного драйвера Linux. Сам по себе широкополосный модем может работать без специального драйвера, но некоторые провайдеры используют РРРоЕ (Point-to-Point Protocol over Ethernet — протокол межузлового взаимодействия через Ethernet). В этом случае необходимо обеспечить поддержку данного протокола в системе Linux, для чего надо установить опцию
Некоторые широкополосные модемы используют вместо Ethernet интерфейс USB. В ядре 2.4.17 поддержка данных устройств не предусмотрена, но Alcatel предоставляет Linux-драйверы для своего модема Speed Touch USB DSL (
Беспроводные устройства
В течение последних лет сети, созданные на базе беспроводных устройств, становятся все более популярными. Беспроводные технологии позволяют компьютерам обмениваться данными, даже если они не подключены к сети с помощью сетевых кабелей. Беспроводные сети очень удобно устанавливать, если прокладка кабеля по каким-либо причинам затруднена или в том случае, если пользователь, работающий на портативном компьютере, вынужден часто перемещаться и не имеет возможности подключиться к сетевому кабелю.
К сожалению, на момент написания данной книги беспроводные сети по многим характеристикам уступают Ethernet-сетям. Беспроводные сети гораздо дороже Ethernet-сетей, скорость передачи данных относительно мала, а разработка стандартов, регламентирующих структуру и работу таких сетей, еще продолжается. В настоящее время основными стандартами являются 802.11 и 802.11b. Стандарт 802.11 определяет скорость обмена 2 Мбод со снижением до 1 Мбод.
Снижением
называется повторный обмен инициализационными параметрами в случае, если уровень сигнала слишком низкий или если помехи искажают сигнал. Стандарт 802.11b определяет скорость 11 Мбод со снижением до 5,5, 2 и 1 Мбод. Существует также беспроводная технология Bluetooth, которая поддерживает скорость обмена до 1 Мбод. Основное направление развития беспроводных сетей связано с увеличением скорости передачи данных. Планируется разработать беспроводные версии ATM со скоростью обмена до 155 Мбод.
Как правило, беспроводные локальные сети создаются на базе беспроводных устройств PC Card, используемых в портативных компьютерах. В одних случаях эти устройства могут непосредственно обмениваться данными друг с другом, в других случаях для взаимодействия необходима базовая станция, которая может выполнять роль шлюза к сети, созданной традиционными средствами. С помощью базовой станции можно также организовать подключение к Internet. Существуют беспроводные ISA и PCI-карты, которые позволяют подключать к беспроводным сетям настольные компьютеры и рабочие станции. Для поддержки устройств PC Card, ISA и PCI в системе Linux необходимо установить соответствующие драйверы; для обеспечения работы базовой станции никакое специальное программное обеспечение не требуется.
Для включения средств поддержки беспроводных устройств в ядре Linux предусмотрены опции, которые содержатся в меню
Компиляция и установка ядра
До сих пор мы рассматривали опции ядра, имеющие отношение к сетевым протоколам и аппаратным средствам, используемым для соединения вашего компьютера с сетью. Компиляция ядра непосредственно не связана с обеспечением сетевого взаимодействия, однако значение этой задачи нельзя недооценивать. Чтобы добавить или удалить некоторые сетевые средства, необходимо перекомпилировать ядро. В данном разделе рассматриваются основные вопросы компиляции и установки ядра системы.
Драйверы, встроенные в ядро, и драйверы, реализуемые в виде модулей
Как вы уже знаете, при настройке ядра можно включить или отключить некоторые свойства ядра, например, вы можете разрешить или запретить использование конкретного Ethernet-адаптера. На рис. 1.1 видно, что существуют опции, значения которых можно выбирать более чем из двух возможных вариантов. В качестве примера рассмотрим опцию
Packet Socket
. Для этой опции могут быть заданы значения
Y
,
M
и
N
. Значение
Y
(Yes) указывает на то, что средства, соответствующие данной опции, должны быть включены в основной файл ядра, а значение
N
(No) запрещает использование этих средств. Значение
M
задает некоторое "промежуточное" решение. Если вы выберете значение
M
, то соответствующие средства будут скомпилированы, но не войдут в основной файл ядра. Вместо этого фрагмент кода будет реализован как отдельный модуль ядра, который по мере надобности загружается или удаляется из памяти. Для опций, являющихся подопциями других опций (например,
Packet Socket: Mmapped IO
, показанной на рис. 1.1), значение
M
обычно не предусмотрено. Решение о включении их в основной файл ядра или реализации в виде отдельного модуля принимается в зависимости от значения родительской опции.
Средства, включенные в основной файл ядра, доступны с момента загрузки системы и до окончания ее работы. Ситуация, при которой фрагмент кода будет удален из памяти, возникнуть не может. Существуют опции, для которых реализующий их программный код должен быть включен в основной файл ядра. Так, например, файловая система, в которой содержится корневой каталог системы, должна быть доступна с момента загрузки, поэтому соответствующий драйвер должен быть включен непосредственно в ядро. Если вы установили рассмотренную ранее опцию
Root File System on NFS
, вам придется скомпилировать средства поддержки сетевых устройств и включить их в ядро.
На первый взгляд может показаться, что все средства, которые будут использоваться при работе системы, следует включить в основной файл ядра, однако такой подход имеет серьезный недостаток: при этом увеличивается объем оперативной памяти, занимаемой ядром. Кроме того, размер файла ядра на диске также увеличивается, что может создавать трудности при загрузке системы. Поэтому в системе Linux предусмотрена возможность компилировать средства, соответствующие большей части опций, в виде модулей. Это позволяет работать с ядром небольшого размера и в то же время обеспечивает поддержку большого количества разнообразных устройств. В частности, в виде модулей могут быть скомпилированы средства для работы с большинством сетевых устройств, поэтому драйверы, включаемые в состав дистрибутивных пакетов, обычно подготавливаются именно в таком виде.
Если администрирование компьютера под управлением Linux является вашей обязанностью, то именно вам предстоит решить, следует ли использовать драйверы сетевых карт, реализованные в виде модулей, или их следует включить в состав ядра. Если вы включите драйвер сетевой карты непосредственно в ядро системы, вам не придется обеспечивать при настройке системы, чтобы перед началом сетевого обмена загружался требуемый модуль. (На самом деле система, поставляемая как дистрибутивный пакет, изначально сконфигурирована так, что данная задача решается корректно.) С другой стороны, если вы администрируете большое количество компьютеров, на которых установлена система Linux, то, возможно, предпочтете создать ядро и набор модулей, которые будете устанавливать на различные компьютеры. В этом случае целесообразно реализовать драйверы в виде модулей.
Программные средства поддержки стека протоколов также могут быть непосредственно включены в ядро или скомпилированы как модули. (Исключением являются протоколы TCP/IP; их можно либо включить в основной файл ядра, либо не использовать вовсе; в виде модулей можно реализовать лишь средства, соответствующие некоторым подопциям опции, управляющей использованием данного стека протоколов.) Так, например, если вы знаете, что каталоги в файловых системах других компьютеров, предоставляемые средствами NFS, будут использоваться лишь непродолжительное время, целесообразно реализовать средства поддержки клиента NFS как отдельный модуль. Поступив таким образом, вы сэкономите часть оперативной памяти в течение времени, когда средства NFS не используются, но монтирование внешних каталогов будет осуществляться несколько дольше, чем это было бы в том случае, если бы фрагмент кода, реализующий клиент NFS, был включен непосредственно в ядро.
Компиляция ядра
После того как вы сконфигурировали ядро системы, выполнив
make xconfig
или другую команду, приведенную в начале данной главы, вы должны скомпилировать ядро и установить его модули. Для этого необходимо выполнить следующие команды:
# make dep
# make bzImage
# make modules
# make modules_install
Проблемы, возникающие при компиляции ядра
Если вы корректно установили опции, компиляция ядра, как правило, проходит без проблем, но в некоторых случаях возникают ошибки. Проблемы, встречающиеся при компиляции ядра, описаны ниже.
•
Ошибки в исходном коде или несовместимость кода
. Иногда встречаются драйверы, которые содержат ошибки в исходном коде либо несовместимы с остальными компонентами ядра. Такая ситуация может возникнуть при работе с ядром, находящимся в процессе разработки, либо при попытке включить в состав ядра нестандартный драйвер. В этом случае при компиляции отображается одно или несколько сообщений об ошибке. Чтобы избавиться от ошибок, надо обновить версию ядра или, по крайней мере, заменить драйвер, который стал источником проблем. Если без этого драйвера можно обойтись, лучше вовсе отказаться от его использования.
•
Отсутствие информации о зависимости файлов
. Если работа драйвера зависит от другого драйвера, то первый драйвер должен выбираться лишь после того, как будет выбран второй. В некоторых случаях сценарий, посредством которого выполняется конфигурирование системы, работает некорректно. При компиляции ядра это проявляется следующим образом: каждый файл по отдельности компилируется нормально, но собрать файл ядра не удается. Если драйвер компилируется как отдельный модуль, то при попытке загрузить отображается сообщение об ошибке. Иногда в сообщении об ошибке содержится информация о том, какие действия надо предпринять, чтобы избавиться от нее. В некоторых случаях решить проблему удается, вызвав команду
make dep
, а затем повторно скомпилировав ядро. Иногда работоспособное ядро можно получить, отказавшись от включения драйвера непосредственно в основной файл и скомпилировав его в виде отдельного модуля (в некоторых случаях приходится принимать обратное решение, т.е. включать в ядро драйвер, который, будучи подготовленным в виде отдельного модуля, стал источником проблем).
•
Устаревшие объектные файлы
. Если вы компилируете ядро, а затем изменяете конфигурацию и компилируете его повторно, утилита
•
Инсталляция нового ядра и его использование
Чтобы готовое ядро можно было использовать, его необходимо инсталлировать. Как было сказано ранее, скомпилированное ядро помещается в каталог
/usr/src/linux/arch/i386/boot
(вместо
i386
может присутствовать другой каталог, имя которого отражает название процессора). Файл ядра надо скопировать или переместить в каталог
/boot
. Желательно переименовать файл так, чтобы его имя отражало версию ядра и изменения, которые вы внесли в него. Например, вы можете назвать файл ядра
bzImage-2.4.17
или
bzImage-2.4.17-xfs
. Если команда
make modules_install
до сих пор не выполнялась, надо вызвать ее, инсталлировав тем самым модули ядра в каталог
/lib/modules/x.y.z
, где
x.y.z
— это номер версии ядра.
Копирования файла ядра в каталог
/boot
недостаточно. Чтобы ядро можно было использовать, необходимо также модифицировать загрузчик. Большинство дистрибутивных пакетов содержит Linux Loader (LILO); настройка этого загрузчика на новое ядро осуществляется путем редактирования файла конфигурации
/etc/lilo.conf
. В листинге 1.1 показано содержимое файла
lilo.conf
, настроенного на загрузку одного ядра.
Листинг 1.1.
Простой файл
lilo.conf
boot=/dev/sda
Глава 2
Настройка сетевых средств TCP/IP
Несмотря на то что ядро является главным компонентом системы Linux и помимо выполнения прочих задач контролирует процесс обмена данными по сети, настройка системы для работы в сети не исчерпывается конфигурированием ядра. В данной главе рассматриваются вопросы, имеющие непосредственное отношение к организации сетевого взаимодействия: использование статических IP-адресов, а также применение протоколов DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки узла) и PPP (Point-to-Point Protocol). Протокол DHCP позволяет организовать автоматическое выделение IP-адресов, а протокол PPP обеспечивает соединение по коммутируемой линии. При использовании статических IP-адресов приходится устанавливать конфигурацию соответствующих компонентов системы вручную. Существует большое количество инструментальных средств, упрощающих как автоматическую, так и ручную установку конфигурации системы. Если вы собираетесь выполнять работы по администрированию системы, вам следует ознакомиться с этими инструментами. Однако, перед тем как приступать к обсуждению вопросов, связанных с настройкой системы, необходимо рассмотреть процесс загрузки сетевых драйверов.
Загрузка сетевых драйверов
Первым шагом в настройке сетевых устройств является загрузка соответствующих драйверов. Как было сказано в главе 1, драйверы подготавливаются к работе одним из двух способов: драйвер может быть непосредственно включен в состав ядра Linux либо скомпилирован в виде отдельного модуля. В первом случае загрузка сетевого драйвера не вызывает затруднений. Драйверам некоторых сетевых карт приходится передавать параметры, используя для этого опции загрузки. Если вы применяете LILO, параметры передаются посредством опции append, содержащейся в файле
/etc/lilo.conf
. Например, приведенная ниже строка сообщает ядру о том, что устройство
eth0
(первая сетевая карта) подключено через порт с номером 0x240.
append="ether=0,0,0x240,eth0"
После ключевого слова
append
можно указать несколько значений, поместив их в кавычки и разделив пробелами. Указание порта для конкретного устройства чаще всего используется в системах, содержащих несколько сетевых интерфейсов; в данном примере логическое устройство явным образом связывается с конкретным физическим устройством. В большинстве случаев передавать параметры драйверам, встроенным в ядро, нет необходимости. Драйвер выявляет сетевую карту и обеспечивает доступ к ней без вмешательства администратора.
Если драйвер скомпилирован как отдельный модуль, параметры передаются ему посредством файла
/etc/modules.conf
(в некоторых системах этот файл имеет имя
/etc/conf.modules
). Например, данный файл может содержать следующие строки:
alias eth0 ne options ne io=0x240
Использование клиента DHCP
Если в вашей локальной сети присутствует сервер DHCP, вы можете сконфигурировать систему Linux так, что компьютер будет автоматически получать у сервера IP-адрес, используя для этого клиентскую программу DHCP. Клиент DHCP ищет сервер DHCP, посылая в широковещательном режиме запрос, который принимают все компьютеры локальной сети. Если сервер отвечает на запрос и последующие переговоры заканчиваются успешно, то система получает IP-адрес, кроме того, выполняются настройки, необходимые для осуществления сетевого обмена.
Большинство дистрибутивных пакетов Linux позволяет включать поддержку DHCP в процессе инсталляции системы, в частности, при настройке сетевых средств. Если соответствующая опция отсутствует или если вы хотите изменить конфигурацию системы после ее инсталляции, проще всего сделать это, используя специальный инструмент с графическим пользовательским интерфейсом. К таким инструментальным средствам относятся Linuxconf (Red Hat или Mandrake), COAS (Caldera), YaST и YaST2 (SuSE). На рис. 2.1 показано окно YaST2 с установленной опцией
Automatic address setup (via DHCP)
. В результате установки данной опции система настраивается для получения IP-адресов посредством DHCP.
Рис. 2.1.
Специальные инструменты с графическим пользовательским интерфейсом упрощают использование клиента DHCP
Использование статических IP-адресов
Несмотря на то что система DHCP используется во многих сетях, в ряде случаев приходится выделять IP-адреса другими способами. Некоторым компьютерам (например, на которых выполняются серверы DHCP) чрезвычайно трудно присваивать адреса с помощью DHCP. Кроме того, сервер DHCP попросту может отсутствовать в сети. В подобных случаях приходится распределять IP-адреса вручную. Средства для решения данной задачи рассматриваются в данном разделе. Кроме того, далее в этой главе рассказывается, как настроить систему, чтобы ее конфигурация автоматически устанавливалась при загрузке.
Настройка сетевых интерфейсов
Загрузка драйвера — это лишь первое действие, которое надо выполнить, чтобы обеспечить доступ к сетевому интерфейсу. Для того чтобы интерфейс можно было использовать, ему необходимо присвоить IP-адрес и выполнить дополнительные настройки, например задать маску подсети. Для решения этой задачи используется утилита
ifconfig
, которая, в зависимости от способа ее вызова, либо отображает информацию об интерфейсе, либо изменяет его конфигурацию.
Синтаксис
ifconfig
достаточно прост. Для вызова данной утилиты надо задать в командной строке следующее выражение:
ifconfig [ интерфейс ] [ опции ]
Набор передаваемых параметров определяет поведение
ifconfig
. Данная утилита может выполнять следующие действия.
Заполнение таблицы маршрутизации
Таблица маршрутизации выполняет две задачи. Во-первых, она сообщает системе, на какой из интерфейсов следует передавать информационные пакеты. На первый взгляд может показаться, что если на компьютере установлен лишь один сетевой интерфейс, то ответ на этот вопрос очевиден. На самом деле это не так. Дело в том, что на каждом из компьютеров, работающих под управлением системы Linux, поддерживается интерфейс обратной петли. Этот интерфейс соответствует сети 127.0.0.0/8, но реально при работе с ним используется лишь один IP-адрес 127.0.0.1. Поскольку этот интерфейс присутствует на всех компьютерах, многие программы используют его для взаимодействия с другими локальными программами. При этом обеспечивается более высокая скорость обмена, чем при использовании традиционных сетевых интерфейсов. Для того чтобы распределять трафик между интерфейсом локальной петли и обычными сетевыми интерфейсами, существуют специальные правила. Вторая задача, которую выполняет таблица маршрутизации, состоит в управлении трафиком, предназначенным для компьютеров в локальной сети. Для маршрутизации в локальной сети используется протокол ARP (Address Resolution Protocol — протокол преобразования адресов). Пакеты, предназначенные узлам локальной сети, непосредственно передаются соответствующим компьютерам, а пакеты, адресованные удаленным узлам, передаются посредством маршрутизатора, или шлюза. В большинстве случаев в таблице маршрутизации Linux указывается лишь один шлюз, но встречаются также более сложные конфигурации с несколькими шлюзами. Для заполнения таблицы маршрутизации используется команда route.
Таблица маршрутизации содержит набор записей, которые определяют, как должны обрабатываться пакеты, в зависимости от адреса их назначения. Когда программа передает пакет, предназначенный для передачи ядру, последнее сравнивает адрес назначения с адресами или диапазонами адресов, указанными в записях таблицы, начиная с наиболее конкретных адресов, т.е. с диапазона, определяющего сеть наименьшего размера. Если адрес назначения пакета соответствует очередному адресу или диапазону, для передачи пакета используется правило, указанное в таблице маршрутизации, в противном случае сравнение продолжается. Самое универсальное из правил носит название маршрута по умолчанию, оно определяет любой адрес Internet. Маршрут по умолчанию обычно направляет пакет через шлюз локальной сети.
Для чтобы лучше понять, как используется таблица маршрутизации, рассмотрим пример такой таблицы. На рис. 2.2 показана таблица маршрутизации, которая отображается в результате выполнения команды
Настройка DNS
После активизации интерфейсов и установки маршрутов компьютер может обмениваться пакетами как с компьютерами локальной сети, так и с любыми другими компьютерами, с которыми он соединен системой шлюзов. Для указания адреса назначения пакета используются IP-адреса. Такая адресация естественна для маршрутизаторов, но чрезвычайно неудобна для пользователей. Преобразование символьных имен (например,
www.awl.com
) в IP-адреса, используемые при маршрутизации пакетов, осуществляет система доменных имен (DNS — Domain Name System). Кроме того, DNS может также осуществлять обратное преобразование.
DNS поддерживает глобальную распределенную базу данных, для работы с которой используется большое количество серверов. Для того чтобы пользоваться этой базой, компьютер должен знать адрес лишь одного сервера DNS. Большинство организаций и провайдеров Internet устанавливают у себя один или несколько серверов. Чтобы узнать адрес такого сервера, надо обратиться к администратору сети. Получив эти сведения, надо включить их в файл
/etc/resolv.conf
. В данном файле может содержаться до трех строк, начинающихся с ключевого слова
nameserver
, за которым следует IP-адрес сервера DNS. В этом файле также указывается домен по умолчанию (для этого используется ключевое слово
domain
) и произвольное число доменов, в которых выполняется поиск имени. Поиск проводится в том случае, если указано лишь имя компьютера, а имя домена пропущено (например, если вместо
mail.threeroomco.com
пользователь задал имя
). Пример файла
/etc/resolv.conf
, содержащего все три типа записей, приведен в листинге 2.1.
Листинг 2.1
. Пример файла
/etc/resolv.conf
domain threeroomco.com
Определение имени узла
При использовании многих протоколов семейства TCP/IP необходимо, чтобы к компьютеру можно было обращаться по имени. Для того чтобы упростить настройку отдельных программ, в Linux содержится специальная утилита
hostname
, позволяющая определить имя узла. Если вызвать эту утилиту без параметров, она выведет текущее имя узла. Если за именем утилиты следует имя узла (например,
hostname larch.threeroomco.com
), это имя присваивается узлу. Имя узла можно хранить в файле и с помощью опции
-f
или
-file
передавать
hostname
имя того файла, например
hostname -f /etc/HOSTNAME
. В большинстве дистрибутивных пакетов предусмотрена автоматическая установка имени узла при загрузке системы, но имя узла в различных системах хранится в разных файлах. Это может быть файл
/etc/hostname
,
/etc/HOSTNAME
или файл, указанный в составе дополнительного конфигурационного файла (см. табл. 2.1).
Имя узла должно устанавливаться единожды, но это не всегда возможно. Некоторые прикладные программы, в частности почтовые клиенты и программы просмотра сообщений Usenet, позволяют пользователям переопределять имена, используемые по умолчанию. Задать имя узла можно также в файле
/etc/hosts
. Этот файл используется при работе системы преобразования имен, альтернативной DNS. В файле
/etc/hosts
содержатся строки, начинающиеся с IP-адреса, за которым следует набор имен узла. Чаще всего первым после IP-адреса указывается полностью определенное доменное имя, в его состав входит имя компьютера и домен, которому он принадлежит, например
larch.threeroomco.com
. За полностью определенным доменным именем следуют так называемые
псевдонимы
. Обычно они представляют собой сокращенную форму имени, например
larch
. Если ваш компьютер корректно настроен для работы с сервером DNS и если на этом сервере содержатся записи для вашего компьютера, нет необходимости определять имя узла в файле
/etc/hosts
. Если сервер DNS работает ненадежно или если в результате некорректной работы маршрутизаторов сервер DNS периодически становится недоступным, записи в
10.92.68.1 larch.threeroomco.com larch
127.0.0.1 localhost.localdomain localhost
Использование PPP-соединений
При рассмотрении вопросов сетевого взаимодействия предполагается, что компьютер под управлением Linux подключен к обычной локальной сети, узлы которой соединены посредством сетевых кабелей (например, к сети Ethernet). В такой среде можно инсталлировать серверы (работа серверов рассматривается в части II и III). При организации работы серверов необходимо учитывать вопросы безопасности, которые обсуждаются в части IV. В реальных сетях не все узлы подключены посредством постоянных соединений. Некоторые компьютеры подключаются через коммутируемые линии с помощью модемов. В большинстве случаев устанавливать сервер на компьютере, подключаемом через телефонную линию, не имеет смысла, но иногда модемы используются для подключения небольших сетей к Internet; в такой сети могут присутствовать различные серверы. Возможно, что при подключении по коммутируемой линии возникнет необходимость обеспечить взаимодействия с Internet всех компьютеров локальной сети, имея в наличии лишь один IP-адрес. В этом случае придется воспользоваться средствами NAT, которые будут подробно обсуждаться в главе 25. Однако, для того чтобы средства NAT могли работать, необходимо сначала установить PPP-соединение. Вопросы PPP-взаимодействия обсуждаются в последующих разделах.
Использование программы с графическим интерфейсом для обмена по коммутируемой линии
PPP — достаточно сложный протокол; при его настройке используется большое число различных опций. Если значения этих опций выбраны неправильно, взаимодействие посредством PPP может не состояться. По этой причине многие пользователи избегают работать с конфигурационными сценариями и предпочитают устанавливать PPP-соединение с помощью специальной программы с графическим интерфейсом. Программы, поддерживающие PPP-соединение в системе Linux, очень похожи на программы аналогичного назначения, используемые в других операционных системах, например в Windows. Поэтому для тех, кто имеет опыт в использовании PPP-соединений в других системах, не составит труда решить ту же задачу в Linux.
Разные программы установления соединений по коммутируемым линиям различаются между собой лишь в деталях. В данном разделе рассматривается популярная программа KPPP, которая входит в состав K Desktop Environment (KDE). С KPPP можно работать, даже не используя KDE. Кроме KDE для установления соединений по телефонным линиям можно применять программу GNOME PPP (она входит в состав GNU Network Object Model Environment, или GNOME), а также инструменты, не являющиеся частями интегрированных сред, например X-ISP (
http://xisp.hellug.gr
).
Для того чтобы запустить KPPP, надо выбрать соответствующий пункт меню на рабочем столе либо ввести в окне
xterm
команду
kppp
. В результате на экране отобразится окно, показанное на рис. 2.4. Если вы запускаете KPPP впервые, в списке
Connect to
будет отсутствовать имя провайдера, а поле
Login ID
будет пустым. Для того чтобы настроить программу так, чтобы с ее помощью можно было пользоваться учетной записью, выполните следующие действия.
Редактирование конфигурационных сценариев
Программы с графическим интерфейсом удобны для тех пользователей, которые не имеют достаточного опыта работы с PPP-соединениями, но в некоторых случаях эти инструменты оказываются непригодными. Например, если вы хотите, чтобы PPP-соединение устанавливалось автоматически, программа с графическим интерфейсом не позволит вам сделать это. В этом случае для инициализации соединения приходится использовать сценарии. Такие сценарии можно запускать либо вручную, либо как часть системы автоматического соединения. При этом необходимо установить опции аутентификации и задать конфигурацию самих сценариев.
Как было сказано ранее, для аутентификации пользователей, обращающихся по коммутируемым линиям, большинство провайдеров применяет протокол PAR Для того чтобы сценарий, предназначенный для установления соединения, мог использовать этот протокол, необходимо отредактировать файл
/etc/ppp/pap-secrets
. (При работе с протоколом CHAP используется файл
/etc/ppp/chap-secrets
. Содержимое файла
chap-secrets
имеет тот же формат, что и данные в файле
pap-secrets
.) В файле
/etc/ppp/pap-secrets
содержится последовательность строк; каждая строка соответствует отдельной учетной записи PPP и имеет следующий формат:
имя_пользователя сервер пароль IP-адрес
Компоненты строки отделяются друг от друга одним или несколькими пробелами или символами табуляции. Назначение этих компонентов описано ниже.
Установление соединения по запросу
При работе на отдельной рабочей станции или компьютере необходимость использовать специальную программу установления взаимодействия или вручную запускать соответствующий сценарий практически не мешает работе. Если же PPP-соединением пользуется несколько компьютеров, подключенных к локальной сети, могут возникать проблемы. Часто пользователи пытаются установить соединение в то время, когда оно активно, разорвать соединение, когда другие пользователи обмениваются через него информацией с Internet, либо по окончании работы оставляют соединение активным на длительное время. Для решения этих проблем были созданы средства установления
соединения по запросу
(dial-on-demand). В системе Linux подобные функции выполняет инструмент под названием
diald
. Эта программа выявляет трафик, направленный из локальной сети к внешним узлам, и инициализирует PPP-соединение. Кроме того, если в течение определенного времени сетевая активность отсутствует, эта программа разрывает соединение. В результате клиентские программы, расположенные в локальной сети, могут работать почти так же, как и программы, находящиеся на компьютерах, постоянно подключенных к Internet; для того чтобы установить или разорвать PPP-соединение, пользователям не приходится предпринимать никаких действий. Различия проявляются лишь в том, что с момента, когда
diald
обнаруживает попытку обращения к внешнему узлу и до установления PPP-соединения, проходит определенное время. Это связано с тем, что система должна обратиться к модему, а модем, в свою очередь, установить соединение с модемом провайдера. Через некоторое время после прекращения сетевой активности соединение разрывается. Если вы зададите слишком малое значение этого интервала, задержка будет возникать слишком часто, так как с момента получения Web-страницы до запроса очередного документа сетевое взаимодействие отсутствует и система может разорвать соединение. Заметьте также, что если PPP-соединение не активно, при обращении к Web-странице броузер выведет сообщение о том, что документ не доступен. Причина в том, что время тайм-аута, используемое при работе броузера, значительно меньше времени, необходимого для установления PPP-соединения.
Чтобы программа
К сожалению,
Для настройки программы
•
Глава 3
Альтернативные стеки протоколов
Компьютерная программа — идеальный инструмент для решения тех задач, которые предполагают скрупулезное следование предписаниям. В ситуациях, не предусмотренных инструкциями, компьютер становится практически беспомощным. Поэтому для обеспечения работы сетей тщательно разработаны протоколы — подробное описание действий узлов сети при выполнении транзакций. Как было сказано в главе 1, протоколы объединяются в иерархическую систему, называемую
стеком сетевых протоколов
, или
стеком протоколов
. Наиболее часто в настоящее время используется стек протоколов TCP/IP. На базе протоколов семейства TCP/IP построена вся сеть Internet, кроме того, протоколы данного семейства широко используются при работе различных операционных систем, в частности Linux. В главе 2 была описана конфигурация системы для поддержки TCP/IP. Помимо TCP/IP, существует ряд альтернативных стеков протоколов, которые также поддерживаются в Linux.
В начале данной главы представлены обзор стеков протоколов и краткое описание TCP/IP. Далее обсуждаются три наиболее часто используемых стека: AppleTalk, IPX и NetBEUI. Эти стеки протоколов применяются в основном в локальных сетях, содержащих компьютеры Macintosh и PC под управлением Windows. С их помощью обеспечивается разделение файлов и принтеров.
Общие сведения о стеках протоколов
Для того чтобы вести предметный разговор о стеках протоколов и обсуждать их достоинства и недостатки, необходимо иметь хотя бы общее представление о том, как организован стек, какие функции выполняют протоколы, входящие в его состав, и как они реализованы. Большинство стеков протоколов действует по единому принципу и отличается лишь в деталях. Однако именно эти детали и являются основным аргументом в пользу выбора тех или иных протоколов.
Модель сетевого взаимодействия OSI
В основу работы стека протоколов положена модель OSI (Open System Interconnection — взаимодействие открытых систем). Данная модель предусматривает семь уровней сетевого взаимодействия, на каждом из которых решаются конкретные задачи. Источником данных, предназначенных для передачи, является программа, находящаяся на верхнем уровне модели OSI, который называется прикладным уровнем. Программа передает данные нижележащему представительскому уровню, и далее информация перемещается вниз по стеку. На каждом уровне выполняется определенная обработка данных. Нижним уровнем OSI является физический уровень, на котором решаются вопросы передачи электрических сигналов, использования кабелей, концентраторов, коммутаторов и т.д. Именно на физическом уровне осуществляется реальная передача данных от передающего компьютера к принимающему. (Если оба компьютера принадлежат одному сегменту сети, данные передаются достаточно просто. В противном случае передача осуществляется поэтапно, и на каждом этапе выполняется дополнительная обработка информации.) На принимающем компьютере данные перемещаются вверх по стеку протоколов и в конечном итоге достигают программы на прикладном уровне. Получив информацию, программа может передать ответ. Данные, составляющие ответ, также движутся вниз по стеку, передаются через сетевые соединения, а затем на компьютере, которому они предназначены, перемещаются вверх по стеку протоколов. На рис. 3.1. проиллюстрирован описанный выше процесс.
Рис. 3.1
. Компоненты стека протоколов выполняют обработку данных для передачи их на другой компьютер
Каждый уровень модели OSI взаимодействует только с двумя уровнями; один из них расположен непосредственно над ним, а другой — под ним. (Исключениями являются прикладной и физический уровни. Прикладная программа взаимодействует непосредственно с пользователем, а на физическом уровне решаются вопросы соединения двух компьютеров.) Для программных средств, реализующих различные уровни стека протоколов на конкретном компьютере, должен быть четко определен интерфейс межуровневого взаимодействия. Компоненты, соответствующие определенным уровням, должны допускать замену. Так, например, на прикладном уровне могут работать Web-броузеры и Web-серверы. Если вы замените один броузер или сервер другим, работа всего стека протоколов не нарушится. (В некоторых броузерах и серверах могут отсутствовать определенные возможности, например, броузер может не поддерживать средства SSL, однако на самом деле такие вопросы скорее относятся к интеграции сетевых средств.) Аналогично вы можете на физическом уровне заменять сетевые кабели, концентраторы и даже сетевые карты с драйверами. При этом средства поддержки более высоких уровней не нуждаются в модификации.
Инкапсуляция и извлечение данных
Стек протоколов хорошо иллюстрирует перемещение данных между программными компонентами, поддерживающими сетевое взаимодействие, однако он не дает ответа на вопрос, какие же изменения претерпевает информация на этом пути. На различных уровнях стека протоколов выполняются инкапсуляция и извлечение данных. При инкапсуляции данные разбиваются на фрагменты, и к каждому фрагменту добавляется управляющая информация (после добавления управляющей информации фрагменты данных, в зависимости от уровня протокола, становятся пакетами или кадрами). Кроме того, информация, предназначенная для передачи, может быть модифицирована, но подобная обработка выполняется крайне редко. При извлечении данных выполняются действия, противоположные инкапсуляции.
Рассмотрим в качестве примера передачу содержимого файла с помощью протокола FTP (File Transfer Protocol — протокол передачи файлов) в сети Ethernet. При этом используется стек протоколов TCP/IP. Размер файла может превышать максимальный размер пакета данных, допустимый в TCP/IP или Ethernet. В этом случае содержимое файла должно быть разбито на несколько фрагментов. На различных уровнях стека протоколов к каждому из этих фрагментов добавляется заголовок и, возможно, суффикс (служебная информация, следующая за передаваемыми данными). Заголовок и суффикс содержат информацию, необходимую для того, чтобы система могла передавать и обрабатывать остальную часть пакета. Результат действий по инкапсуляции данных показан на рис. 3.2. На самом деле ситуация может быть более сложной. На некотором уровне стека протоколов пакет может быть разбит на несколько фрагментов меньшего размера, так, например, драйверы Ethernet могут разбить IP-пакет на два Ethernet-кадра. Подобные действия могут выполнять и маршрутизаторы. При этом заголовки IP, TCP и FTP, показанные на рис. 3.2, остаются в одном из кадров и не дублируются в другом кадре. Однако если на некотором уровне стека протоколов пакет разбивается на кадры, то на том же уровне стека на принимающем узле эти кадры обязательно объединяются в исходный пакет. Точно так же дело обстоит в том случае, если разбиение пакета выполнит маршрутизатор.
В зависимости от используемого стека протоколов и даже от состава стека, структура пакета может отличаться от представленной на рис. 3.2. Например, если для обмена данными используется Web-броузер, то вместо заголовка FTP, показанного на рис. 3.2, в составе пакета будет присутствовать заголовок HTTP. Если же для подключения компьютера к сети будут использованы сетевые карты и драйверы, отличные от Ethernet, то заголовок и суффикс Ethernet будут заменены на заголовок и суффикс, соответствующие другой сетевой технологии. Заметьте, что при передаче пакета из одной локальной сети в другую маршрутизатор реально выполняет подобную замену, т.е. удаляет существующие заголовок и суффикс и включает вместо них заголовок и суффикс другой сети. Такая процедура выполняется несколько раз за время перемещения пакета по Internet, но содержащиеся в составе пакета, доставляются в неизменном виде.
Рис. 3.2
Роль стека протоколов TCP/IP в развитии сетей
В настоящее время TCP/IP является самым популярным стеком протоколов. В состав этого стека входят наиболее часто используемые протоколы, которые обсуждаются в данной книге. В большинстве приложений не реализована поддержка нескольких стеков протоколов, поэтому чаще всего приложение может работать с одним конкретным стеком. Одна из причин популярности стека протоколов TCP/IP — его гибкость. Протоколы TCP/IP являются маршрутизируемыми протоколами, т.е. пакеты TCP/IP могут передаваться из одной локальной сети в другую. Для передачи пакетов между различными сетями не нужна единая карта Internet; при маршрутизации используется распределенная информация о структуре сети, хранящаяся на различных маршрутизаторах. Число допустимых адресов в сетях TCP/IP достаточно велико (в IPv4 адрес представляется 32 битами, а в IPv6 используются 128-битовые адреса; подробно IP-адреса рассматривались в главе 2), кроме того, в этих сетях поддерживается иерархическая структура имен. Эти положительные качества стали причиной того, что протоколы TCP/IP были выбраны в качестве основы для создания глобальной сети Internet.
Впервые протоколы TCP/IP были использованы в UNIX; система Linux "унаследовала" их. Как в Linux, так и в UNIX средства TCP/IP используются для обеспечения работы различных компонентов системы. Сеть, в состав которой входят только компьютеры, работающие под управлением UNIX или Linux, может быть создана на основании TCP/IP, без использования других стеков протоколов.
В состав семейства TCP/IP входят HTTP, FTP, SMTP (Simple Network Mail Protocol — простой протокол передачи почтовых сообщений), NFS (Network File System — сетевая файловая система), Telnet, SSH (Secure Shell — защищенная оболочка), NNTP (Network News Transfer Protocol — протокол передачи сетевых новостей), X Window и многие другие протоколы. Широкое использование TCP/IP привело к тому, что в инструментах, изначально ориентированных на работу с другими стеками протоколов, была реализована поддержка TCP/IP. Например, несмотря на то, что в системе Windows используется стек протоколов NetBEUI (NetBIOS Extended User Interface — расширенный пользовательский интерфейс NetBIOS), средства поддержки протоколов SMB (Server Message Block — блок сообщений сервера) / CIFS (Common Internet Filesystem — общая межсетевая файловая система) могут взаимодействовать с TCP/IP через NetBIOS (Network Basic Input/Output System — базовая сетевая система ввода-вывода). Начиная с Windows 95 все версии Windows поддерживают TCP/IP. Аналогично, протоколы Apple, предназначенные для разделения файлов, могут работать не только с AppleTalk, но и с TCP/IP.
Несмотря на свои достоинства и популярность, стек TCP/IP не позволяет решить все задачи, возникающие при создании сетей. Так, например, в некоторых сетях могут присутствовать компьютеры, не поддерживающие TCP/IP. В частности, старые компьютеры Macintosh обеспечивают обмен файлами только средствами AppleTalk, а некоторые машины под управлением DOS или Windows могут быть сконфигурированы лишь для работы с IPX или NetBEUI. Поэтому поддержка альтернативных средств протоколов является положительным качеством системы Linux.
AppleTalk
Стек протоколов создавался компанией AppleTalk параллельно с разработкой сетевого оборудования LocalTalk. Он нашел применение в компьютерах Macintosh, выпущенных в начале 1980-х. (Первоначально как аппаратные, так и программные средства назывались AppleTalk; в настоящее время это название используется лишь для обозначения программных компонентов.) С ростом популярности Ethernet Apple доработала AppleTalk для работы с аппаратным обеспечением Ethernet; этот вариант программ иногда называют EtherTalk. В системе Linux поддерживается стек протоколов AppleTalk и обеспечивается его работа как посредством аппаратуры LocalTalk, так и через Ethernet.
Особенности AppleTalk
Подобно TCP/IP, AppleTalk использует 32-разрядные адреса. Подобно IP-адресу, адрес AppleTalk состоит из двух компонентов: адреса сети и адреса компьютера. В отличие от IP, длина каждого из компонентов фиксирована: 16 из 32 битов выделены для представления адреса сети, а остальные 16 битов — для идентификации компьютера. В сетях AppleTalk поддерживается процедура переговоров, предпринимаемых для получения компьютером сетевого адреса. Благодаря наличию такой процедуры администратор избавлен от необходимости явно указывать адреса. (Если вы захотите, можете задать адрес явно или запросить его из определенного диапазона, но обычно в этом нет надобности.)
Кроме адресов для идентификации компьютеров в AppleTalk-сетях существует система имен, предназначенная для того, чтобы упростить работу пользователей. Каждому компьютеру присваивается имя, кроме того, для этого компьютера определяется принадлежность к локальной группе машин, которая называется зоной. Полное имя состоит из имени компьютера и имени зоны. В небольших сетях информация о зоне может не использоваться, в этом случае компьютеры идентифицируются только посредством имени. Netatalk (основной пакет, предназначенный для поддержки AppleTalk в Linux) по умолчанию генерирует AppleTalk-имена на базе доменных имен TCP/IP. Так, например, если компьютеру соответствует доменное имя
larch.threeroomco.com
, Netatalk назначит ему имя
larch
. Информация о домене при этом будет утеряна. (Если сеть разбита на зоны, имя зоны также генерируется автоматически, но оно не имеет никакого отношения к имени домена TCP/IP.) Двухкомпонентные имена существенно ограничивают размеры AppleTalk-сетей, в частности, создать сеть, насчитывающую больше нескольких тысяч компьютеров, затруднительно.
Основное назначение AppleTalk — обеспечение совместного использования файлов и принтеров. Многие сетевые принтеры могут непосредственно взаимодействовать посредством протокола AppleTalk, а средства разделения файлов поддерживаются в MacOS, Windows NT и 2000, Linux, BeOS и других операционных системах. Для решения других задач AppleTalk используется лишь в сетях, состоящих из компьютеров, которые работают под управлением MacOS. В сетях, компоненты которых используют иные операционные системы, целесообразнее применять другие стеки протоколов. Если в состав сети входят различные машины, на компьютерах устанавливают систему MacOS X, обеспечивающую работу с NFS. Пакет Netatalk (
IPX/SPX
IPX (Internetwork Packet Exchange — межсетевой обмен пакетами) был разработан специалистами Novell как низкоуровневый транспортный протокол. При создании протокола разработчики основывались на ранних работах, выполненных компанией Xerox. Чаще всего IPX используется совместно с протоколом SPX (Sequences Packet Exchange — упорядоченный обмен пакетами). IPX и SPX составляют основы стека протоколов, возможности и популярность которого сопоставимы со стеками AppleTalk и NetBEUI. Традиционно протоколы IPX/SPX используются в продуктах NetWare, кроме того, в DOS, Windows и других операционных системах применяются программные пакеты, созданные на базе IPX/SPX. Одно из самых распространенных применений IPX/SPX — поддержка протокола NCP (NetWare Core Protocol — базовый протокол NetWare), используемого для разделения файлов и принтеров. Протоколы IPX/SPX поддерживаются в системе Linux; для этого используются как средства ядра (настройка ядра обсуждалась в главе 1), так и клиентские и серверные пакеты.
Возможности IPX/SPX
Подобно TCP/IP и AppleTalk, в IPX/SPX используются 32-разрядные адреса, которые обычно представляются в шестнадцатеричном виде, например 0x23a91002. Однако каждый адрес ставится в соответствие не одному компьютеру, а сегменту сети, который либо соединяется с другими сегментами с помощью маршрутизаторов, либо полностью изолирован от внешнего мира. В описании сети также указывается тип кадра, передаваемого на нижнем уровне; в сети IPX/SPX могут использоваться только кадры одного типа. Для идентификации отдельных компьютеров применяются аппаратные адреса узлов сети, на базе которой создается сеть IPX/SPX, например, если сеть IPX/SPX создана на основе Ethernet, то компьютеры, подключенные к ней, идентифицируются с помощью 48-разрядных адресов.
Как легко догадаться по названию и применяемой схеме адресации, протоколы разработаны для организации межсетевого обмена. Такой обмен обеспечивают IPX-маршрутизаторы, которые функционируют подобно маршрутизаторам TCP/IP. (При необходимости одна система может маршрутизировать пакеты IP и IPX. В изолированной сети маршрутизатор не нужен, но программы поддержки IPX/SPX включают соответствующие средства.
Серверы IPX/SPX используют протокол SAP (Service Advertisement Protocol — протокол объявления служб). Посредством этого протокола в сети периодически объявляются имя сервера и услуги, которые он предоставляет. Эти сообщения принимаются локальными компьютерами, а IPX-маршрутизаторы передают их в другие сегменты сети. Таким образом клиенты постоянно имеют информацию о доступных серверах, но в то же время при увеличении размеров сети этот подход приводит к возрастанию сетевого трафика, так как по сети постоянно передаются широковещательные SAP-сообщения.
Программы поддержки IPX/SPX в системе Linux
Как и большинство Linux-программ, средства поддержки IPX/SPX в основном распространяются в исходных кодах. (Caldera лицензировала NetWare, и специалисты компании реализовали в Linux поддержку взаимодействия с этой системой, однако сопровождение данного порта прекращено. Версия для трех пользователей доступна по адресу
ftp://ftp.calderasystems.com/pub/old-products/netware/
, но она может работать только с ядром 2.0.35.) Средства поддержки IPX/SPX для Linux перечислены ниже.
•
Поддержка NCPFS ядром системы
. В состав ядра Linux входят средства поддержки файловой системы NCP. Соответствующие опции находятся в подменю
Network File Systems
меню
File Systems
. Эти средства позволяют монтировать в системе Linux разделяемые каталоги NetWare. Для монтирования используется программа
ncpmount
, которая обычно входит в состав пакета
ncpfs
.
•
LinWare
. Этот пакет обеспечивает ограниченную поддержку сервера NCP. На момент написания данной книги последней была версия 0.95 beta, ориентированная на работу с ядром 1.3.x, другими словами, пакет не обновлялся с 1996 года. Однако в будущем ситуация может измениться. В настоящее время данный пакет хранится под именем
lwared
по адресу
ftp://sunsite.unc.edu/pub/Linux/system/network/daemons/
.
•
Mars_nwe
. Этот пакет, реализующий NetWare-сервер в системе Linux, в настоящее время доступен по адресу
http://www.compu-art.de/mars_nwe/
. Информация о пакете в основном представлена на немецком языке. Английская документация ограничивается документом Mars_mwe HOWTO, который можно получить, обратившись по адресу
http://www.redhat.com/support/docs/tips/Netware/netware.html. Mars_nwe
поддерживает как файловый сервер, так и сервер печати. Настройка пакета осуществляется посредством конфигурационного файла
/etc/nwserv.conf
или
/etc/nwserv/nwserv.conf
. Если Mars_nwe не запускается при загрузке системы, для его запуска можно использовать команду
nwserv
.
Все перечисленные выше пакеты требуют, чтобы средства поддержки IPX были скомпилированы в составе ядра (о включении компонентов ядра рассказывалось в главе 1). В ряде систем используется специальный пакет
NetBEUI
NetBEUI во многом напоминает AppleTalk и IPX, однако средства NetBEUI в основном используются IBM и Microsoft для организации сетевого взаимодействия в системах DOS, Windows и OS/2. В системе Linux (по крайней мере в версиях ядра 2.4.x) стек NetBEUI не поддерживается. Тем не менее возможности NetBEUI могут быть реализованы средствами NetBIOS на базе TCP/IP, которые присутствуют в Linux (такую конфигурацию NetBIOS часто называют NBT). Кроме того, поддержка стека NetBEUI обеспечивается продуктами независимых производителей, но на сегодняшний день такие продукты находят лишь ограниченное применение.
Возможности NetBEUI
Подобно AppleTalk и IPX, стек NetBEUI был разработан для обеспечения взаимодействия в небольших сетях. Сеть под управлением NetBEUI может насчитывать не больше 256 компьютеров. В NetBEUI используются имена, подобные доменным именам TCP/IP, но, в отличие от TCP/IP, AppleTalk и IPX, числовая адресация не применяется. В NetBEUI компьютеры идентифицируются лишь с помощью имен. Имена NetBEUI состоят из двух компонентов: имени компьютера и имени группы. В зависимости от наличия централизованного сервера, предназначенного для управления регистрацией пользователя, группа компьютеров называется
рабочей группой
либо
доменом
. С момента включения компьютер, настроенный для взаимодействия посредством NetBEUI, передает широковещательные сообщения, свидетельствующие о его присутствии.
Средства NetBEUI могут работать практически в любой сетевой среде, но чаще всего сети, использующие этот стек, создаются на базе Ethernet. Подобно AppleTalk и IPX, NetBEUI может использоваться вместе с TCP/IP и другими стеками протоколов.
Средства NetBEUI очень часто применяются с протоколами SMB/CIFS, обеспечивающими разделение файлов и принтеров. По степени популярности их можно сравнить с NFS/lpd для Linux и UNIX или NCR SMB/CIFS могут работать на базе TCP/IP; такая конфигурация используется чрезвычайно часто, даже в сетях, состоящих исключительно из компьютеров под управлением Windows. Маршрутизация сообщений NetBEUI затруднена, и это обеспечивает дополнительную степень защиты сетей. В настоящее время неизвестны средства, с помощью которых злоумышленник, работающий на удаленном компьютере, мог бы незаконно получить доступ к серверу NetBEUI.
Средства поддержки NetBEUI для Linux
Компьютеры под управлением Linux редко участвуют в NetBEUI-взаимодействии, так как в стандартном ядре отсутствует поддержка этого стека. В 2000 г. силами Procom Technologies (
http://www.procom.com
) были реализованы средства поддержки NetBEUI для Linux, а также дополнения к Samba (подробно об этом рассказывается в главе 7), обеспечивающие работу Samba посредством NetBEUI. Эти дополнения не нашли широкого применения; они даже не были размещены на Web-узле Procom. Для того чтобы получить необходимые программные средства, надо обратиться в отдел технической поддержки компании. Совместно с ядрами, отличными от версий 2.0.x, средства поддержки NetBEUI могут работать некорректно (лично мне не удалось найти программы, совместимые с ядром 2.2.18). Стек NetBEUI ориентирован на работу с версиями Samba, предшествующими 2.0.7, однако были сообщения о том, что впоследствии будет реализована поддержка Samba 3.0. Для работы с NetBEUI необходимо перекомпилировать как ядро Linux, так и Samba. Таким образом, для того, чтобы устанавливать средства поддержки NetBEUI в Linux, надо иметь достаточно веские основания, например, делать это имеет смысл тогда, когда в сети запрещена поддержка стека протоколов TCP/IP. Для работы с NetBEUI вам придется использовать ядро Linux 2.0.x и Samba 2.0.6 либо более раннюю версию этого продукта.
Кроме дополнений к ядру Linux и Samba средства поддержки стека NetBEUI содержат большое количество специальных утилит, предназначенных для настройки стека и выполнения различных действий в сети NetBEUI. Настройка системы обычно не вызывает затруднений; в большинстве случаев для управления поведением NetBEUI можно использовать опции Samba. Среди утилит следует выделить
netb
; с ее помощью запускаются средства поддержки стека NetBIOS.
Использование программ поддержки NetBEUI
Пакет, предназначенный для поддержки стека NetBEUI, содержит файл
README
, в котором полностью описан процесс инсталляции. Установка пакета может быть выполнена двумя способами. Следуя одному из них, надо отредактировать файл Makefile, указав в нем ссылки на каталоги, содержащие коды ядра Linux и исходные тексты Samba, а также установив некоторые опции, специфические для конкретной системы. Затем необходимо скомпилировать ядро Linux и коды Samba, установить новое ядро и перезагрузить систему. Второй способ инсталляции также требует редактирования
Makefile
, но при этом надо предоставить системе детальные инструкции о выполнении каждого шага установки. Второй способ предпочтительнее первого, особенно если при установке возникают затруднения. В этом случае вы можете локализовать проблему и устранить ее.
Каким бы способом вы ни воспользовались, вам потребуются исходные коды как ядра Linux, так и пакета Samba. Найти их вы сможете, обратившись по адресам
http://www.kernel.org
и
http://www.samba.org
, а также на других узлах, содержащих архивы программ, например
ftp://sunsite.unc.edu
. Компиляция каждого пакета займет несколько минут. Если же при этом возникнут проблемы, то для установки средств поддержки NetBEUI вам потребуется значительно больше времени.
После окончания процесса инсталляции для включения средств поддержки NetBEUI и управления взаимодействием по сети можно воспользоваться перечисленными ниже утилитами.
•
netb
. Передавая этой утилите параметр
start
, вы можете запустить средства поддержки NetBEUI. Чтобы запретить поддержку NetBEUI, надо выполнить команду
netb stop
. Использовать NetBEUI в Linux можно лишь после вызова утилиты
netb
.
•
nbview
. Эта утилита сообщает сведения о текущем состоянии локального стека NetBEUI. Она считает файл
/proc/sys/netbeui
, в котором содержатся соответствующие данные, отформатирует их и отобразит в виде, удобном для восприятия.
Глава 4
Запуск серверов
В основном данная книга (в особенности части II и III) посвящена работе различных серверов. Как правило, программы-серверы начинают работать с момента загрузки компьютера, на котором они установлены, и постоянно предоставляют свои услуги клиентам. В некоторых случаях планируются перерывы в работе серверов, связанные с необходимостью выполнения работ по обслуживанию компьютера; кроме того, доступ к тому или иному серверу может быть ограничен по соображениям безопасности. Администрируя локальную сеть, необходимо ясно представлять себе процедуру запуска серверов, в противном случае вы не сможете запустить сервер после установки или перезапустить его в случае изменения конфигурации.
Чаще всего серверы, установленные в системе Linux, начинают работать сразу же после инсталляции; в редких случаях для их запуска приходится перезагрузить компьютер. Существуют три основных способа запуска серверов: использование сценариев запуска System V (SysV), настройка
суперсервера
, например
inetd
или
xinetd
, или применение локальных сценариев запуска. В большей части дистрибутивных пакетов содержатся инструментальные средства с графическим пользовательским интерфейсом, позволяющие выполнять подобные задачи. В данной главе рассматриваются все три метода запуска серверов. Если вы не будете знать их, у вас могут возникнуть затруднения при изучении материала, изложенного в последующих главах.
Использование сценариев запуска SysV
Многие технические решения, которые используются в системе System V UNIX, разработанной AT&T, стали стандартом для современных версий UNIX и Linux. Одним из них является способ запуска системных служб, в том числе серверов. Согласно схеме загрузки SysV, каждой службе должен соответствовать специальный сценарий запуска, поддерживающий параметры
start
и
stop
. В зависимости от полученного параметра, сценарий запускает программу поддержки данной службы или завершает ее работу. Многие сценарии запуска поддерживают дополнительные параметры, например,
restart
, используемый при изменении конфигурации программы. При получении параметра
restart
сценарий завершает работу сервера, а затем снова запускает его.
Схема запуска SysV непосредственно связана с понятием
уровня выполнения
(runlevel). Каждому уровню выполнения соответствует набор сценариев запуска, который определяет службы, выполняющиеся в системе. (Посредством сценариев SysV запускаются не только серверы, но и другие службы, например, средства протоколирования, поддержки файловой системы и прочие программы.) Таким образом, настройка системы для запуска серверов с помощью сценариев SysV по сути сводится к выбору конфигурации уровней выполнения. Для решения данной задачи надо создать ссылки на требуемые сценарии и поместить их в каталог, соответствующий требуемому уровню выполнения.
Расположение сценариев запуска и соглашения по их именованию
Несмотря на то что основные принципы использования сценариев запуска SysV соблюдаются во всех системах, особенности такого использования могут различаться в зависимости от конкретного дистрибутивного пакета. В разных системах сценарии запуска размещаются в различных каталогах, имена сценариев могут различаться, но эти различия, как правило, не существенны. В табл. 4.1 описаны каталоги, используемые разными системами при работе со сценариями запуска SysV. Обратите внимание на то, что в табл. 4.1 указано размещение реальных сценариев, ссылок на эти сценарии, соответствующих определенным уровням выполнения, а также расположение локальных сценариев запуска (подробно локальные сценарии будут рассматриваться далее в данной главе). В именах ссылок на сценарии символом
?
обозначается число, соответствующее уровню выполнения (от 0 до 6).
Таблица 4.1
. Сценарии запуска для основных дистрибутивных пакетов Linux
Управление сценариями запуска вручную
Если вам необходимо разрешить или запретить запуск сервера с помощью сценариев SysV, вы можете сделать это, изменяя сценарии запуска или ссылки на них. Проще всего запретить запуск сервера, удалив соответствующий сценарий из каталога сценариев SysV. Этим вы добьетесь того, что сервер не будет присутствовать ни на одном из уровней выполнения системы, но такое решение нельзя назвать элегантным. Кроме того, если вам потребуется не запретить, а разрешить выполнение сервера, вам все равно придется искать способы сделать это.
Более приемлемое решение данной задачи — переименовать ссылку на сценарий запуска в каталоге, соответствующем требуемому уровню выполнения. Например, для того, чтобы запретить выполнение сервера, надо переименовать ссылку, заменив символ "
S
" в начале ее имени на символ "
K
". Чтобы разрешить работу сервера, надо сделать обратную замену. Сложности, возникающие при этом, связаны с тем, что последовательность запуска серверов может отличаться от последовательности их завершения. Для того чтобы решить эту проблему, надо найти ссылки на этот сценарий в каталогах, соответствующих различным уровням запуска. Если хотя бы на одном уровне выполняется нужное вам действие, вы узнаете требуемый номер. Например, в результате выполнения приведенной ниже команды отображаются все ссылки на сценарий запуска системы Mandrake, соответствующий почтовому серверу Postfix.
$ find /etc/rc.d -name "*postfix"
/etc/rc.d/rc0.d/K30postfix
/etc/rc.d/rc1.d/K30postfix
Использование утилит управления сценариями запуска
Некоторые дистрибутивные пакеты включают специальные утилиты, которые упрощают управление сценариями запуска. Пользуясь этими утилитами, вы уменьшаете риск неправильно задать имя сценария. Так, например, изменяя набор серверов, выполняемых в системе, вручную, вы можете вместо
S80postfix
случайно задать имя
s80postfix
(т.е. вместо "
S
" в верхнем регистре задать "
s
" в нижнем регистре). При использовании специализированных утилит такая ситуация не возникнет. К сожалению, подобные утилиты присутствуют не во всех системах; чаще всего они входят в состав Red Hat и систем, созданных на ее основе, например Mandrake. Перенос утилиты из одной системы в другую не дает желаемого результата, так как в разных системах расположение и имена сценариев запуска и ссылок SysV, а также номера, определяющие порядок запуска, могут различаться.
Инструментальное средство
chkconfig
, предназначенное для управления сценариями запуска SysV, предоставляет пользователю низкоуровневый интерфейс. Вся информация, необходимая для выполнения задачи, задается в одной командной строке. Утилита
chkconfig
вызывается следующим образом:
chkconfig <--list|--add|--del> [ имя ]
Управление уровнями выполнения
В предыдущих разделах постоянно упоминались уровни выполнения, но из сказанного вряд ли стало ясно, что же они собой представляют. Говорилось лишь о том, что уровни выполнения и сценарии запуска SysV тесно связаны между собой. При загрузке компьютер переходит на некоторый уровень выполнения. Этому уровню соответствует каталог ссылок SysV; содержащиеся в нем ссылки указывают на сценарии запуска. Если ссылка начинается с символа "
S
" Linux при вызове сценария передает ему параметр
start
, а если имя ссылки начинается с "
K
", сценарию передается параметр
stop
.
Но как Linux узнает, на какой уровень следует перейти после загрузки? Информация об этом хранится в файле
/etc/inittab
, который выполняет роль конфигурационного файла для
init
— первого процесса, выполняющегося в системе. Процесс
init
является родительским для всех остальных процессов в системе. В файле
/etc/inittab
содержатся записи наподобие приведенной ниже.
id:5:initdefault:
Ключевое слово
id
, расположенное в начале, идентифицирует данную строку, а число, следующее за ним (в данном случае 5), устанавливает постоянный уровень выполнения. Если вы измените это значение и перезагрузите компьютер, система будет работать на другом уровне. Уровни 0, 1 и 6 имеют специальное назначение. Уровень 0 соответствует завершению работы системы, уровень 1 — однопользовательскому режиму, а уровень 6 — перезагрузке системы. Уровни 2–5 задают нормальные режимы работы; назначение каждого из уровней может изменяться в зависимости от версии системы. В Caldera, Red Hat Mandrake SuSE7.3 и TurboLinux уровень 3 соответствует обычному текстовому режиму (система X Window не запускается), а уровень 5 поддерживает графический пользовательский интерфейс (система X Window запущена). В ранних версиях SuSE вместо уровней 3 и 5 для поддержки текстового режима и графического интерфейса используются уровни 2 и 3, а в Slackware для той же цели применяются уровни 3 и 4. По умолчанию в Debian на уровнях 2–5 набор серверов, запускаемых посредством сценариев SysV, существенно не отличается, но на уровнях выше третьего используется меньшее число инструментов с текстовым интерфейсом (детали настройки системы можно выяснить, просмотрев содержимое файла
Использование inetd
В обычных условиях программа-сервер связывается с некоторым портом (ресурсом, для идентификации которого используется тип протокола и число в интервале от 1 до 65535). В зависимости от номера порта, указанного в запросе, этот запрос направляется тому или иному серверу. Например, почтовый сервер, поддерживающий SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты), традиционно использует TCP-порт 25, a HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовой информации), как правило, связывается с портом 80.
Программа
inetd
является одним из суперсерверов, используемых в операционной системе Linux. Суперсервер выполняет функции посредника. Вместо набора серверов в системе запускается один суперсервер, который связывается со всеми портами, соответствующими серверам из набора. При установлении соединения суперсервер загружает сервер, порт которого указан в запросе, после чего этот сервер выполняет требуемые действия по передаче данных. Использование суперсервера обеспечивает два основных преимущества по сравнению с постоянным выполнением обычных серверов. Во-первых, при таком подходе уменьшается объем используемой оперативной памяти; в особенности это заметно, если на компьютере должно присутствовать большое количество программ- серверов. Во-вторых, перед тем как запрос будет передан обычном серверу, его получает суперсервер, который может выполнять необходимую фильтрацию данных; это повышает безопасность системы. Недостаток использования суперсервера состоит в том, что продолжительность обработки запроса увеличивается (как правило, на одну-две секунды). Это связано с тем, что для загрузки сервера требуется определенное время. Поэтому суперсервер лучше применять для серверов, которые вызываются достаточно редко. Если запросы к серверу приходят часто, лучше, если такой сервер постоянно присутствует в памяти компьютера.
Формат файла /etc/inetd.conf
Для настройки
inetd
используется конфигурационный файл
/etc/inetd.conf
. Если не принимать во внимание комментарии (строки, начинающиеся с символа
#
), то можно сказать, что содержимое файла
inetd.conf
представляет собой набор строк, каждая из которых определяет отдельный сервер. Пример записи, содержащейся в файле
/etc/inetd.conf
приведен ниже.
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Каждая строка файла состоит из нескольких полей, которые отделяются друг от друга с помощью пробелов или символов табуляции.
•
Имя сервера
. Первое поле в строке идентифицирует протокол, используемый сервером. Имя протокола должно соответствовать имени, указанному в файле
/etc/services
. Например, обратившись к этому файлу, можно выяснить, что имени
telnet
соответствует значение
23/tcp
, т.е. сервер, поддерживающий протокол
telnet
, должен использовать для взаимодействия порт 23. Для того чтобы программа
inetd
могла управлять сервером, для этого сервера должна существовать запись в файле
/etc/services
. Очевидно, что, планируя запуск редко встречающегося сервера посредством
inetd
, надо позаботиться о том, чтобы соответствующая запись была включена в этот файл. Подавляющее большинство серверов изначально учтено в
/etc/services
.
•
Тип гнезда
. Второе поле указывает тип гнезда, используемого при поддержке протокола. Допустимы типы
stream
,
dgram
,
raw
,
rdm
и
seqpacket
.
Использование TCP Wrappers
Как было сказано ранее, инструмент TCP Wrappers играет роль посредника между
inetd
и целевым сервером. Средства TCP Wrappers применяются для повышения безопасности системы; они позволяют задавать правила установления соединений, защищая тем самым сервер от нежелательного взаимодействия. Предположим, что вы хотите, чтобы доступ к серверу Telnet имели только пользователи, работающие в вашей локальной сети. Программу, обеспечивающую работу сервера Telnet, можно настроить так, чтобы она отвергала попытки обращения с узлов, для обслуживания которых сервер не предназначен. Однако не все серверы предоставляют такие возможности. Передача TCP Wrappers полномочий по управлению соединением повышает гибкость системы, не требуя при этом внесения изменений в программы.
Для управления работой TCP Wrappers используются два файла:
/etc/hosts.allow
и
/etc/hosts.deny
. Эти файлы имеют одинаковый формат, но выполняют противоположные действия. В файле
hosts.allow
описываются узлы сети, которым разрешено обращаться к данному компьютеру; для всех остальных узлов доступ запрещен. Файл
hosts.deny
, напротив, содержит описания узлов, доступ с которых запрещен; все остальные узлы могут устанавливать соединение с данным компьютером. Если в системе присутствуют оба файла, приоритет имеет файл
hosts.allow
. Благодаря этому вы имеете возможность задать ограничения в файле
hosts .deny
, а затем разрешить доступ для отдельных компьютеров. Если сведения о сервере не включены ни в один из файлов (сервер может быть описан либо непосредственно, либо с помощью групповой операции), TCP Wrappers разрешает доступ к нему для всех узлов сети.
Подобно другим конфигурационным файлам, символ
#
в начале строки означает, что в данной строке содержатся комментарии. Запись в файле
hosts.allow
или
hosts.deny
имеет следующий формат:
список_демонов : список_клиентов
Использование xinetd
Традиционно
inetd
был основным суперсервером, использовавшимся в системе Linux. Однако в 2000 г. наметилась тенденция перехода к альтернативному суперсерверу
xinetd
. Условно
xinetd
можно представить себе как сочетание
inetd
и TCP Wrappers. Но между этими программами существуют некоторые отличия. Не все возможности
xinetd
можно реализовать с помощью
inetd
и TCP Wrappers, но ряд действий, которые можно выполнить, используя
inetd
и TCP Wrappers, нельзя сделать посредством
xinetd
. При необходимости
xinetd
можно использовать совместно с TCP Wrappers, поэтому считается, что данный инструмент обеспечивает большую степень гибкости по сравнению с
inetd
. В начале 2002 г.
xinetd
был использован в Red Hat и Mandrake в качестве суперсервера по умолчанию; ожидается также переход других операционных систем на
xinetd
.
Формат файла /etc/xinetd.conf
Поскольку возможности нового суперсервера расширены по сравнению с
inetd
, формат конфигурационного файла также отличается от
inetd
. Настройка
xinetd
производится с помощью файла
/etc/xinetd.conf
. Следует заметить, что файл
xinetd.conf
, поставляемый в составе дистрибутивных пакетов Red Hat и Mandrake, содержит лишь минимальный набор установок. В нем задана конфигурация серверов, а также содержится строка, которая указывает суперсерверу прочитать все файлы в каталоге
/etc/xinetd.d
и интерпретировать их как дополнительные конфигурационные файлы. Конфигурация
xinetd
напоминает конфигурацию SysV; каждому серверу соответствует собственный управляющий файл, названный по имени сервера. Например, для сервера Telnet используется файл
/etc/xinetd.d/telnet
. При необходимости
xinetd
можно настроить так, что этот суперсервер будет использовать лишь основной файл
xinetd.conf
, но в дистрибутивных пакетах Red Hat и Mandrake некоторые файлы запуска уже содержатся в каталоге
/etc/xinetd.d
.
Независимо от того, содержится ли описание сервера в
/etc/xinetd.conf
или в файле, находящемся в каталоге
/etc/xinetd.d
, оно может занимать несколько строк. Базовое определение включает те же данные, что и запись в файле
inetd.conf
. Например, приведенное ниже описание почти эквивалентно рассмотренной ранее записи для Telnet-сервера, находящейся в файле
inetd.conf
.
service telnet
{
socket_type = stream
Средства управления доступом
Одно из преимуществ
xinetd
состоит в том, что эта программа объединяет в себе функции суперсервера и средства управления доступом, характерные для TCP Wrappers. Кроме того, настройка
xinetd
выполняется достаточно просто. Средства управления доступом
xinetd
не дублируют соответствующие функции TCP Wrappers; некоторые задачи лучше решаются с помощью
xinetd
, для решения других приходится применять TCP Wrappers. Настраивая
xinetd
, можно определять доступ либо одновременно для всех серверов, либо для каждого сервера в отдельности. Основные опции, предназначенные для управления доступом, описаны ниже.
•
Ограничения для различных узлов
. Для
xinetd
предусмотрены опции
only_from
и
no-access
, которые выполняют те же функции, что и содержимое файлов
/etc/hosts.allow
и
/etc/hosts.deny
TCP Wrappers. Эти опции могут присутствовать либо в главном конфигурационном файле, либо в файле, предназначенном для конкретного сервера. В качестве значения опции
only_from
задается список компьютеров, которым разрешено обращаться к серверу (для всех остальных компьютеров доступ запрещен). Аналогично, значение опции no-access представляет собой "черный список"; компьютеры, указанные в списке, не имеют права устанавливать соединение с сервером, а для остальных компьютеров доступ разрешен. Если адрес присутствует в обоих списках, приоритет имеет адрес, заданный более конкретно. Для идентификации компьютеров используются разные способы. В опциях
only_from
и
no-access
может быть указан IP-адрес узла (например, 172.23.45.67), адрес сети, оканчивающийся нулем (например, 172.23.0.0 для сети 172.23.0.0/16) или заданный с помощью маски (172.23.0.0/16), имя сети, указанное в файле
/etc/networks
, или доменное имя узла (например,
badguy.threeroomco.com
). Если в качестве значения опции указано имя узла,
xinetd
выполняет преобразование имени в адрес один раз при загрузке суперсервера. Поскольку в течение работы
xinetd
доменное имя может измениться, данный способ установления ограничений неэффективен.
•
Ограничения по времени
•
В этом и предыдущем разделе были описаны лишь наиболее часто используемые опции
Использование локальных сценариев запуска
Как правило, в системе Linux большинство стандартных серверов запускается либо с помощью сценариев SysV, либо суперсервера. Исключением является сервер X, для запуска которого в файле
/etc/inittab
предусмотрена соответствующая запись. Сервер X запускается только на конкретном уровне выполнения. В системе Slackware для запуска основных серверов используется
/etc/rc.d/rc/inet2
. Большинство дистрибутивных пакетов включает локальные сценарии запуска, редактируя которые администратор имеет возможность обеспечить работу дополнительного сервера, запустить специальную утилиту или выполнить другие подобные действия. Локальные сценарии запуска для основных дистрибутивных пакетов Linux приведены в табл. 4.1.
Как правило, локальные сценарии запуска применяются для того, чтобы включить в систему сервер, для которого отсутствуют соответствующие сценарии SysV и который по каким-либо причинам нежелательно запускать посредством суперсервера. Сценарии запуска SysV ориентированы на конкретную версию системы, поэтому для серверов, которые не включены в дистрибутивный пакет, как правило, отсутствуют и сценарии запуска. Например, если вы установите в Mandrake сервер, ориентированный на SuSE, и попытаетесь использовать для его запуска сценарии SysV, которые также предназначены для системы SuSE, сервер не будет работать. Аналогичные проблемы возникают, если автор предоставляет вам исходные коды сервера. Как правило, такие коды не настроены на конкретный дистрибутивный пакет Linux. Сервер может компилироваться без ошибок и надежно работать, но для того, чтобы обеспечить его запуск, вам придется приложить определенные усилия.
При необходимости вы можете сами написать сценарий SysV для запуска сервера. Сделать это можно, модифицируя имеющийся сценарий. Еще проще создать сценарий SysV, имея в распоряжении сценарий, выполняющий аналогичную задачу (такая ситуация может возникнуть, если вы переходите от устаревшей версии сервера к новой или если вы заменяете один из серверов, присутствующих в системе, подобным сервером независимого производителя). Однако при создании сценария SysV все же могут возникнуть проблемы. Формат сценариев запуска SysV, используемый в вашей системе, может быть незнаком для вас (обычно для написания сценариев SysV используется язык оболочки
Для внесения изменений в локальный сценарий запуска можно использовать обычный текстовый редактор. В файл надо включить строку, формат которой совпадает с форматом команды, используемой для запуска этого сервера. Например, приведенная ниже строка позволяет запускать Telnet-сервер.
usr/sbin/in.telnetd