Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

152 Глава 5. Базовая настройка

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

применяется, например, для протокола RIP (Routing Information Protocol) и

системы доменных имен (DNS). Сетевые службы, требующие сложных про-

цедур для запуска либо постоянно востребованные, обычно запускаются

сценариями при загрузке системы и работают в качестве демонов, пока сис-

тема не будет остановлена.

Все команды, пригодные для использования в командной строке интерпре-

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

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

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

симости от используемой модели загрузки, BSD или System V.

Модель BSD является более простой: некоторое количество стартовых сцена-

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

наиболее примитивном варианте три основных сценария, /etc/rc, /etc/reboot

и /etc/гс.local выполняются в таком порядке и обеспечивают инициализа-

цию системы, инициализацию служб, а также вносят локальные корректи-

вы. В системах BSD Unix сетевые службы, как правило, запускаются из

файла /etc/reboot или /etc/гс.local.

Если в системе используется модель загрузки BSD, размещайте дополни-

тельные команды настройки сети в сценарии rc.local. Он выполняется в кон-

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

замещают встреченные системой ранее.

Модель загрузки BSD применяется в системах BSD и SunOS. В Linux и Sola-

ris применяется модель загрузки System V, в которой участвует гораздо бо-

лее сложный набор стартовых файлов.

Здесь присутствуют целые каталоги

сценариев, выполняемых процессом

init,

причем в зависимости от заданно-

го уровня исполнения выполняются сценарии из различных каталогов.

Уровни исполнения

Чтобы понять загрузку по модели System V, необходимо сначала разобрать-

ся с уровнями исполнения, которые используются для определения состоя-

ния системы после завершения процесса init. Уровни исполнения никоим

образом не связаны с аппаратным обеспечением системы, это исключитель-

но программное понятие, init и /etc/inittab - файл, используемый для на-

стройки init - вот два элемента, реализующих влияние уровней исполнения

на систему. Применение уровней исполнения мы продемонстрируем на при-

мере системы Red Hat Linux.

Linux определяет ряд уровней исполнения, охватывающих полный спектр

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

гопользовательского режима:

Хорошее описание лабиринта файлов инициализации System V приводится в

книге Элин Фриш (Л£1ееп Frisch) «Essential System Administration» (Основы сис-

темного администрирования), O'Reilly.

Загрузочные файлы

153

• Уровень исполнения 0 останавливает работу всех процессов, а затем и

систему.

• Уровень 1 переводит систему в однопользовательский режим. Однопользо-

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

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

в системе пользователей. Этот уровень может обозначаться буквой S, а не

цифрой 1. В Solaris однопользовательский режим обозначается буквой S.

• Уровень 2 - специальный многопользовательский режим, в котором не

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

• Уровень 3 - полноценная многопользовательская среда с поддержкой

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

Это режим по умолчанию для систем Solaris.

• Уровень 4 не используется. Таким образом, существует возможность соз-

дать собственное состояние системы и реализовать его посредством уров-

ня 4.

• Уровень 5 инициализирует систему в качестве выделенного терминала

X Window. В системах Linux на этом уровне доступен вход в систему с

консоли X Window. Когда система Linux загружается по уровню 3, она

предоставляет пользователям для регистрации текстовую консоль. В So-

laris этот уровень работы не используется. Переход на уровень 5 в Solaris

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

• Уровень 6 останавливает работу всех процессов и перезагружает систему.

Теперь, когда ситуация с уровнями немного прояснилась, отметим, что в

различных системах уровни исполнения трактуются по-разному. Это проис-

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

менты загрузочных команд, предписывающие процессу init вызов опреде-

ленных сценариев. Сценарии могут содержать любые допустимые команды.

Отображение уровней init в загрузочные файлы происходит при помощи

файла inittab.

Разбираемся с /etc/inittab

Любая строка файла inittab, которая начинается символом решетки (#), яв-

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

ку синтаксис строк файла inittab весьма насыщенный и загадочный. Запись

inittab имеет следующий формат:

метка:уровень:действие:процесс

Моле метка имеет длину от одного до четырех символов и идентифицирует

(•троку. Отдельные системы поддерживают только двухсимвольные метки,

поэтому в большинстве случаев их длина ограничена двумя символами. Мет-

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

Поле уровень определяет уровни исполнения, для которых действует эта за-

пись. Если поле содержит цифру 3, процесс, на который указывает запись,

должен быть запущен при инициализации системы по уровню исполнения 3.

154

Глава 5. Базовая настройка

Можно указывать несколько уровней одновременно. Записи с пустым полем

уровня не участвуют в инициализации конкретных уровней. Например, в

системах Linux существует запись inittab, связанная с обработкой комбина-

ции из трех пальцев (<Ctrl>+<Alt>+<Del>); она имеет пустое поле уровня.

Поле действие определяет условия, при которых выполняется процесс.

В табл. 5.1 перечислены значения действий, существующие в системах Red

Hat, Mandrake и Caldera Linux.

Таблица 5.1. Значения действий для inittab в Linux

Действие

Значение

Boot Выполняется при загрузке системы. Уровни не используются

Bootwait

Выполняется при загрузке системы; init ожидает завершения процес-

са. Уровни не используются

Ctrlaltdel

Выполняется по сочетанию клавиш <Ctrl>+<Alt>+<Del>, init полу-

чает сигнал SIGINT. Уровни не используются

Initdefault

Отсутствует выполняемый процесс. Действие устанавливает уровень

исполнения по умолчанию

Kbrequest Выполняется, когда init получает сигнал с клавиатуры. Сочетание

клавиш должно быть связано с клавиатурным сигналом (KeyBoard-

Signal)

Off

Отключает запись, блокирует выполнение процесса

Once

Выполняется единожды для каждого уровня исполнения

Ondemand

Выполняется, когда система переходит на один из специальных уров-

ней, А, В или С

Powerfail Выполняется, когда init получает сигнал SIGPWR

Powerokwait

Выполняется, когда init получает сигнал SIGPWR и файл /etc/power-

status содержит слово ОК

Powerwait

Выполняется, когда init получает сигнал SIGPWR; init ожидает за-

вершения процесса

Respawn Перезапускает процесс после завершения

sysinit Выполняется до всех процессов boot и bootwait

wait

Выполняет процесс при переходе в рабочий режим, init ожидает за-

вершения процесса

И последнее поле записи - процесс. Оно указывает процесс, запускаемый

init.

Процесс имеет формат команды, выполняемой в командной строке. Та-

ким образом, поле процесса начинается с имени программы, которую следу-

ет выполнить. За именем следуют аргументы, передаваемые процессу. На-

пример, /sbin/shutdown -t3 -

г now,

процесс, выполняемый отдельными систе-

мами Linux по сочетанию клавиш <Ctrl>+<Alt>+<Del>, - это команда, ко-

торую можно набрать в командной строке интерпретатора с целью

перезагрузки системы. В большинстве записей inittab поле процесса содер-

Загрузочные файлы 155

Эти семь строк - сердцевина файла inittab, они вызывают загрузочные сце-

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

/ etc / rc.d / rc.sysinit для инициализации системы. В этой записи отсутствует

значение уровня исполнения. Сценарий выполняется при каждой загрузке

системы. Сценарий инициализации системы выполняет ряд важных задач.

Так, сценарий rc.sysinit системы Red Hat:

• инициализирует пространство подкачки;

• выполняет проверку файловой системы;

• монтирует файловую систему /ргос;

• монтирует корневую файловую систему в режиме чтения-записи после

завершения работы fsck;

• загружает модули ядра.

Сценарии инициализации других систем могут выглядеть иначе, чем в Red

Hat, но они решают очень похожие задачи. Например, процесс инициализа-

ции в системе Caldera начинается с загрузки модулей ядра. Затем происхо-

дит активизация пространства подкачки, проверка файловой системы и пе-

ремонтирование корневой файловой системы в режиме чтения-записи. По-

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

Выполнив сценарий инициализации системы, init вызывает сценарий для

конкретного уровня исполнения. Остальные шесть строк примера использу-

ются для вызова загрузочных сценариев отдельных уровней. За исключени-

ем поля уровня исполнения, все эти строки идентичны.

Для примера рассмотрим строку с меткой 13. Данная строка запускает все

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

го режима. Уровень исполнения системы-3. Действие wait предписывает

программе init ожидать завершения загрузочного сценария, прежде чем пе-

реходить к прочим записям файла inittab, относящимся к уровню 3. init вы-

полняет сценарий /etc/rc.d/rc и передает ему аргумент командной строки - 3.

Управляющий сценарий, /etc/rc.d/rc, в свою очередь вызывает все сцена-

рии, соответствующие уровню исполнения, то есть все сценарии из катало-

жит имя стартового сценария. Существует два главных типа загрузочных

сценариев: сценарии инициализации системы и сценарии инициализации

уровней исполнения. В приведенном ниже фрагменте файла inittab системы

Red Hat Linux отражены оба типа:

156

Глава 5. Базовая настройка

га /etc/rcn.d, где п - указанный уровень. В нашем примере управляющий

сценарий гс получает значение 3, а потому выполняет сценарии из каталога

/etc/rc.d/rc3.d. Просмотр каталога системы Red Hat показывает, что сцена-

риев много:

КОЗ rhnsd K35smb

K74ntpd S05kudzu

S25netfs S85httpd

K16rarpd K45arpwatch K74ypserv

S06reconfig

S26apmd

S90crond

K20nfs K45named K74ypxfrd

S08ipchains

S28autofs S90xfs

K20rstatd

K50snmpd

K75gated

S09isdn

S40atd

S95anacron

K20rusersd

K50tux

K84bgpd

SlOnetwork

S55sshd

S991inuxconf

K20rwalld

K55routed K84ospf6d

S12syslog S56rawdevices S991ocal

K20rwhod

K61ldap

K84ospfd S13portmap

S56xinetd

K28amd

K65identd K84ripd

S14nfslock

S601pd

K34yppasswdd K73ypbind K84ripngd

S17keytable S80sendmail

K35dhcpd K74nscd

K85zebra

S20random S85gpm

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

шения процессов при завершении определенного уровня исполнения. В при-

веденном примере К-сценарии будут использованы в процессе завершения

работы на уровне 3. Сценарии, имена которых начинаются с буквы S, ис-

пользуются при переходе на уровень 3. Однако ни один из файлов, храни-

мых в rc3.d, не является в действительности сценарием. Это логические

ссылки на настоящие сценарии, расположенные в каталоге /etc/гсЛ/init.d.

Так, S80sendma.il - ссылка на файл init.d/sendmail. Сразу возникает вопрос -

зачем выполнять сценарии из каталога rc3.d, когда можно вызвать их на-

прямую из init.d, где они на самом деле хранятся? Причины очень просты.

Одни и те же сценарии используются в работе нескольких уровней. Логичес-

кие ссылки позволяют хранить сценарии в одном месте и использовать их из

каталога каждого конкретного уровня исполнения.

Сценарии исполняются в алфавитном порядке. SlOnetwork исполняется

раньше, чем S80sendmail. Таким образом, можно контролировать порядок

выполнения сценариев, изменяя их имена. Порядок вызова сценариев мо-

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

действительные сценарии в каталоге init.d будут по-прежнему иметь прос-

тые, осмысленные имена. Что и доказывает содержимое каталога init.d:

$ Is /etc/rc.d/init.d

amd functions

kdcrotate

network

rarpd

rwalld

xfs

anacron gated

keytable nfs

rawdevices rwhod

xinetd

apmd

9 pro

killall

nfslock reconfig

sendmail

ypbind

arpwatch

halt

kudzu

nscd rhnsd

single

yppasswdd

atd httpd ldap

ntpd

ripd smb

ypserv

autofs

identd linuxconf

ospf6d

ripngd snmpd

ypxfrd

bgpd

ipchains

lpd

ospfd routed sshd

zebra

crond

iptables

named portmap

rstatd syslog

dhcpd

isdn

netfs

random

rusersd tux

Загрузочные файлы

157

Можно разместить специальную команду настройки прямо в соответствую-

щем сценарии из каталога init.d. Более приемлемый вариант для системы

Red Hat - размещать все подобные команды в сценарии гс .local.

Подобно системам BSD, системы Linux для внесения локальных изменений

предоставляют файл rc.local. Общее правило: не вносите поправки в загру-

зочные сценарии. Исключением из этого правила является файл rc.local,

расположенный в каталоге /etc/rc.d. Это единственный стартовый файл,

подлежащий правке, он зарезервирован для этой цели и может иметь любое

содержание. После выполнения сценария инициализации системы сцена-

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

является S99local, ссылка на rc.local. Поскольку сценарий rc.local вызывает-

ся в последнюю очередь, определенные в нем значения замещают встречен-

ные системой ранее.

В системе Solaris также применяется модель загрузки System V, но дела об-

стоят несколько сложнее, чем в Linux. Во-первых, отсутствует сценарий

rc.local. Чтобы воспользоваться таким сценарием, следует создать соответст-

вующие файлы в каталогах уровней исполнения. Во-вторых, в системе Sola-

ris не так много логических ссылок в каталогах уровней. Как следствие, от-

сутствует возможность централизованно изменять сценарии, задействован-

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

ветствует отдельный управляющий сценарий, что может вносить различия в

стартовый процесс уровней. Например, сценарий /sbin/rc2 управляет уров-

нем работы 2, а /sbin/гсЗ - управляющий сценарий для уровня 3. Все эти от-

личия делают процесс загрузки Solaris более сложным для анализа.

В системе Solaris 8 уровень исполнения 3 является уровнем по умолчанию

для многопользовательской среды с доступом к сетевым службам. Управля-

ющий сценарий /sbin/гсЗ выполняет сценарии из каталога /etc/rc2.d, а за-

тем сценарии из каталога /etc/rc3.d. Базовая настройка сети происходит в

/etc/rc2.d и реализована сценариями S69inet и S72inetsvc. Запуск сетевых

служб выполняется рядом других сценариев, расположенных в каталогах

/etc/rc2.d и /etc/rc3.d.

В целях диагностирования и отладки очень важно понимать, что и каким об-

разом происходит в процессе загрузки системы. Если возникли проблемы

ири инициализации сети, полезно знать, с чего начинать поиск. Однако в на-

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

ментов и методов данной конкретной системы. Прямое изменение загрузоч-

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

ка запутает других людей, ассистирующих вам в сопровождении сети.

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

Большинство служб начинают работу по требованию. Наиболее распростра-

ненным инструментом для вызова сетевых служб по требованию является

inetd, демон Интернета.

158 Глава 5. Базовая настройка

Демон Internet

Демон inetd (произносится «ай-нет-ди») запускается в процессе загрузки из

файла инициализации, такого как /etc/rc2.d/S72inetsvc. При запуске inetd

обращается к своему файлу настройки, /etc/inetd.conf. Файл настройки со-

держит имена служб, которые inetd слушает и запускает. Службы можно до-

бавлять или удалять, внося изменения в файл inetd.conf.

Пример записи из такого файла для системы Solaris 8:

ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd

Поля записи файла inetd.conf, слева направо:

имя

Имя службы в том виде, в каком оно приводится в файле /etc/services.

В приведенном примере это поле имеет значение ftp.

тип

Тип службы доставки данных, или тип сокета. Распространенные типы

сокетов:

stream

Служба потоковой доставки, предоставляемая TCP, то есть байтовый

поток TCP.

dgram

Служба доставки пакетов (дейтаграмм), предоставляемая UDP.

raw

Служба прямых дейтаграмм IP.

В примере используется потоковый сокет.

протокол

Имя протокола в том виде, в каком оно приводится в файле /etc/protocols.

Обычно принимает значение «tcp» или «udp». Значения «tcp6» и «udp6»

в Solaris позволяют отразить тот факт, что служба способна работать как

по протоколу IPv4, так и по протоколу IPv6. Протоколом транспортного

уровня для FTP является TCP, поэтому наш пример содержит в поле про-

токола значение tcp6.

wait-status

Поле может иметь значение «wait» либо «nowait.» Обычно, но не всегда,

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

буют значения «wait», а потоковые серверы требуют значения «nowait».

Состояние «wait» предписывает inetd ожидать освобождения сокета сер-

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

Состояние «nowait» позволяет inetd немедленно начать принимать до-

Речь идет о сокетах TCP/IP и потоках TCP, не о потоковом вводе-выводе AT&T

или вводе-выводе через сокеты BSD.

Демон Internet

159

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

состоянием «nowait» задействуют для работы сокеты, отличные от тех,

по которым получен запрос соединений, то есть используют динамически

выделяемые сокеты.

uid

Значение uid - это имя пользователя, с полномочиями которого работает

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

это имя root. Есть и ряд исключений. Например, в стандартном варианте

настройки Solaris 8 служба finger и сервер шрифтов fs (Sun Font Server)

работают с полномочиями пользователя nobody, из соображений безопас-

ности.

сервер

Абсолютное имя программы сервера, исполняемой демоном inetd. По-

скольку наш пример относится к системе Solaris, использовано имя /usr/

sbin/in.ftpd. Имена и пути могут варьироваться в различных системах.

Демон inetd способен самостоятельно обслуживать запросы к отдельным

нетребовательным к ресурсам службам. Это более эффективно, чем запус-

кать самостоятельные внешние серверы. Чтобы задействовать внутрен-

нюю службу inetd, достаточно указать ключевое слово «internal» в поле

имени сервера.

аргументы.

Произвольные аргументы командной строки, передаваемые при вызове

программе сервера. Перечень всегда начинается с argv[0] (то есть с имени

вызываемой программы). Руководство по каждой конкретной программе

документирует допустимые аргументы командной строки. В приведен-

ном примере передается только имя программы,

in.

ftpd.

Существует ряд ситуаций, требующих правки файла inetd.conf. Например,

возникла необходимость заблокировать существующую службу. Настройки

по умолчанию содержат информацию о полном наборе серверов. Далеко не

нее эти серверы требуются на средней системе, а из соображений безопасности

имеет смысл отключать невостребованные службы на некоторых машинах.

Чтобы заблокировать службу, добавьте символ # в начало соответствующей

записи (строка становится комментарием) и передайте сигнал принудитель-

ного завершения серверу inetd. Получив сигнал, демон inetd повторно про-

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

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

торые примеры этого мы еще встретим в последующих главах. Рассмотрим в

подробностях процесс восстановления работы службы, которая была забло-

кирована. Начнем с некоторых записей и комментариев из файла Solaris

/ etc/inetd.conf:

160

Глава 5. Базовая настройка

В этой части файла отражены две службы TCP/IP. Одна из них,

tftp,

заком-

ментирована. Протокол TFTP - это специальный вариант протокола FTP,

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

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

безопасности системы и часто блокируется в файле inetd.conf. Вторая служ-

ба -

finger,

комментарии для которой предполагают, что ее имеет смысл за-

блокировать.

В качестве примера изменения файла inetd.conf мы перенастроим систему

на предоставление службы

tftp,

которая бывает необходима для поддержки

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

tftp при помощи любимого текстового редактора. (В этом примере использу-

ется sed, любимый редактор всех пользователей!) Затем определим иденти-

фикатор процесса inetd и передадим ему сигнал SIGHUP. Следующие коман-

ды решают поставленную задачу:

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

сервера или аргументов его вызова. Для примера снова обратимся к записи

tftp.

Строка содержит аргументы командной строки, передаваемые tftp-cep-

веру при вызове. Ключ -s /tftpboot закрывает самую очевидную прореху в

безопасности tftp: запрещает пользователям получать файлы, расположен-

ные за пределами каталога, указанного в качестве аргумента ключа -s. Для

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

inetd.conf. Серверам, вызываемым inetd, передаются только те аргументы

командной строки, которые указаны в файле inetd.conf.

Расширенный демон Internet

Альтернативой inetd является расширенный демон Интернета - xinetd (Ex-

tended Internet Daemon). Настройки xinetd хранятся в файле /etc/xinetd.conf,

который для xinetd имеет такое же значение, как inetd.conf для

inetd.

Одна-

ко вместо позиционных параметров, значение которых определяется поряд-

ком следования в записи, в xinetd.conf применяются пары атрибутов и зна-

чений. Имя атрибута четко определяет смысл каждого параметра. Значение

выполняет настройку параметра. Например, третье поле записи файла in-

Расширенный демон Internet

161

etd.conf содержит название транспортного протокола. В файле xinetd.conf

имя транспортного протокола определяется при помощи атрибута protocol.

Например, protocol =

tcp.

Вот пример записи tftp в файле xinetd.conf:

Символ # отмечает строки-комментарии. Непосредственно запись начинает-

ся командой

service.

Атрибуты внутри фигурных скобок ({}) определяют ха-

рактеристики конкретной службы.

Значения service, socket_type, protocol, wait, user, server и server_args соот-

петствуют значениям, описанным в примере для файла inetd.conf системы

Solaris. Их назначение в xinetd полностью соответствует назначению пози-

ционных параметров inetd.

Одна из строк, disable =

yes,

требует некоторых объяснений, disable = yes за-

прещает xinetd запускать tftp по требованию, disable = yes является эквива-

лентом блокировки tftp в файле inetd.conf посредством комментария. Чтобы

включить

tftp,

отредактируйте файл, изменив строку на disable =

по.

В Red Hat 7 применяется xinetd. Однако в файле /etc/xinetd.conf системы

Red Hat вы не увидите перечисления сетевых служб. В системе Red Hat на-

стройка xinetd выполнена таким образом, что файл xinetd.conf включает

ссылки на все файлы каталога /etc/xinetd.d. Приведенный выше фрагмент

на самом деле отражает содержимое файла /etc/xinetd.d/tftp системы Red

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

отдельный файл настройки.

Применение xinetd диктуется более совершенными механизмами обеспече-

ния безопасности. Безопасность - одна из наиболее важных причин, по ко-

торым следует разобраться со строением файлов inetd.conf и xinetd.conf. Ис-

пользование возможностей управления доступом демонов xinetd и inetd опи-

сано в главе 12.