Формат файла /etc/xinetd.conf

Формат файла /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

 protocol = tcp

 wait = no

 user = root

 server = /usr/sbin/in.telnetd

}

В конфигурационном файле xinetd каждое поле именуется. Несмотря на то что в данном примере поля расположены в том же порядке, что и в рассмотренной ранее записи inetd, порядок их следования может быть произвольным. Как нетрудно заметить, в данном примере не вызывается TCP Wrappers, однако при необходимости этот инструмент можно использовать (для того, чтобы Telnet-сервер запускался через TCP Wrappers, надо задать значение /usr/bin/tcpd поля server и добавить поле server_args, присвоив ему значение /usr/sbin/in.telnetd).

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

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

• Запрет вызова сервера. Для того чтобы запретить вызов сервера, управляемого суперсервером inetd, надо закомментировать соответствующую строку в конфигурационном файле. В программе xinetd для этой цели используется опция disable = yes, которая помещается в описание требуемого сервера. Тот же результат можно получить, включив в раздел defaults основного файла /etc/xinetd.conf опцию disables = список_серверов, где список серверов состоит из имен серверов, разделенных пробелами. Различные инструментальные средства настройки используют оба способа. Если в описании сервера присутствует опция disable = no, это значит, что сервер активен.

• Перенаправление. Если вам необходимо передать запрос на другой компьютер, вы можете сделать это с помощью опции redirect = целевой_компьютер, где целевой компьютер (т.е, компьютер, которому должен быть передан запрос) задается с помощью доменного имени или IP-адреса. Например, если вы включите в описание сервера, содержащееся в файле /etc/xinetd.d/telnet на узле dummy.threeroomco.com, опцию redirect = 192.168.3.78, то при попытке обращения к Telnet-серверу на компьютере dummy.threeroomco.com запрос будет перенаправлен на 192.168.3.78. Эту возможность использует NAT-маршрутизатор для того, чтобы организовать обслуживание внешних запросов компьютером, принадлежащим внутренней сети. Тот же результат достигается с помощью iptables, но применяя для этой цели xinetd, вы можете использовать средства управления доступом суперсервера.

• Протоколирование. Используя опции log_on_success и log_on_failure суперсервера xinetd, вы можете определять, какая информация должна записываться в файл протокола в случае успешного или неудачного обращения к серверу. Значениями этих опций могут быть PID (идентификатор процесса сервера), HOST (адрес клиента), USERID (идентификатор пользователя клиентской системы, которая передала запрос), EXIT (время получения запроса и статус завершения его обработки) и DURATION (длительность сеанса). При необходимости вы можете добавлять к набору, принятому по умолчанию, или исключать из него отдельные значения, используя вместо символа = пары символов += и -=.

• Ограничения на установление соединений. Ограничить число соединений, поддерживаемых xinetd, можно несколькими способами. Опция per_source определяет, сколько запросов от одного источника xinetd может обработать в единицу времени. (Значение UNLIMITED этой опции позволяет обрабатывать неограниченное число запросов.) Опция instances задает максимальное количество процессов, которые xinetd может породить (это значение должно быть больше, чем значение опции per_source). При использовании опции cps ей передаются два значения, разделенные пробелом: число соединений, которые xinetd может установить в течение одной секунды, и длительность паузы (в секундах), которая должна быть выдержана, если число соединений превысит максимально допустимое. Приоритет серверов, управляемых xinetd, задается с помощью опции nice; эта опция действует подобно программе nice. И наконец, опция max_load, значением которой является число с плавающей точкой, указывает максимальную загрузку системы, при достижении которой xinetd должен отвергать последующие запросы. При использовании этих опций снижается вероятность того, что сервер пострадает от атаки, предпринятой с целью вывода его из строя, или в результате обилия запросов, вызванных высокой популярностью сервера.

Большинство из приведенных выше опций можно использовать либо в описании сервера, либо в разделе defaults файла /etc/xinetd.conf. Помещенная в раздел defaults опция воздействует на все серверы, управляемые xinetd. Если опция присутствует и в разделе defaults, и в описании, принимается значение опции, заданное в описании сервера.

Если вы внесли изменения в файл /etc/xinetd.conf или в один из файлов, содержащихся в каталоге /etc/xinetd.d, необходимо перезапустить программу xinetd. Поскольку суперсервер xinetd чаще всего запускается посредством сценария SysV, проще всего перезапустить его с помощью команды типа /etc/rc.d/init.d/xinetd restart (в некоторых системах сценарий запуска может находиться в другом каталоге). Можно поступить и по-другому — передать xinetd сигнал SIGUSR1 или SIGUSR2, используя для этого команду kill. При получении сигнала SIGUSR1 xinetd читает содержимое нового конфигурационного файла и продолжает работу. В ответ на сигнал SIGUSR2 суперсервер делает то же самое, но при этом завершает работу тех серверов, которые согласно новому конфигурационному файлу должны быть неактивны.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

5.4.3. Недостатки xinetd

Из книги автора

5.4.3. Недостатки xinetd У любой технологии есть недостатки, и inetd/xinetd не являются исключением. При подключении пользователя к одному из портов вашего сервера программа inetd (или xinetd) просматривает таблицу портов, чтобы найти сервис, который необходимо запустить, и передать ему


Формат файла /etc/inetd.conf

Из книги автора

Формат файла /etc/inetd.conf Для настройки inetd используется конфигурационный файл /etc/inetd.conf. Если не принимать во внимание комментарии (строки, начинающиеся с символа #), то можно сказать, что содержимое файла inetd.conf представляет собой набор строк, каждая из которых определяет


Редактирование файла /etc/cups/cupsd.conf

Из книги автора

Редактирование файла /etc/cups/cupsd.conf Работой сервера CUPS управляет файл /etc/cups/cupsd.conf. Поскольку система CUPS позаимствовала многие средства сервера HTTP, структура ее конфигурационного файла напоминает соответствующий файл Apache (он будет рассмотрен в главе 20). При работе CUPS также


Структура конфигурационного файла ntp.conf

Из книги автора

Структура конфигурационного файла ntp.conf Для настройки средств NTP используется файл ntp.conf, который обычно размещается в каталоге /etc. Как и во многих других конфигурационных файлах, строки, содержащие комментарии, начинаются с символа #, а в остальных строках задаются


Формат файла протокола Apache

Из книги автора

Формат файла протокола Apache Данные могут записываться в файл протокола Apache в различных форматах; конкретный формат задается с помощью директивы CustomLog. В данном разделе описывается формат combined, который объединяет в одном файле различные данные. Запись в формате combined


8.1.7. Пример файла конфигурации /etc/xinetd

Из книги автора

8.1.7. Пример файла конфигурации /etc/xinetd Теперь, как и обещал, привожу пример файла конфигурации (см. листинг 8.5). В этом листинге перечислены наиболее часто используемые сервисы с оптимальными параметрами (атрибутами). Конечно же, вам предстоит решить: какие сервисы вы будете


12.6. Пример файла httpd.conf

Из книги автора

12.6. Пример файла httpd.conf В этом разделе приведен пример стандартной конфигурации сервера Apache (см. листинг 12.13). К каждому блоку листинга сопутствуют комментарии на русском языке, которые помогут вам разобраться с различными опциями сервера. Листинг 12.13. Пример файла httpd.conf####


15.5. Формат файла squid.conf

Из книги автора

15.5. Формат файла squid.conf В файле squid.conf задаются всевозможные параметры конфигурации прокси-сервера. Давайте рассмотрим их все по


11.3.3.1. Защита xinetd

Из книги автора

11.3.3.1. Защита xinetd Суперсервер xinetd достаточно защищен, но его конфигурационный файл придется защитить вам самим. Естественно, нужно установить ему права доступа, разрешив только чтение в только суперпользователю:# chmod 400 /etc/xinetd.confЧтобы никто не смог изменить, удалить,


11.3.3.2. Пример файла конфигурации /etc/xinetd

Из книги автора

11.3.3.2. Пример файла конфигурации /etc/xinetd Теперь, как и обещал, привожу пример файла конфигурации. В этом листинге перечислены чаще всего используемые сервисы с оптимальными атрибутами. Конечно же, вам предстоит решить, какие сервисы вы будете использовать, а какие нет.


16.3. Основные настройки. Файл httpd.conf (httpd2.conf)

Из книги автора

16.3. Основные настройки. Файл httpd.conf (httpd2.conf) Как уже отмечалось ранее, этот файл содержит практически все директивы, необходимые для работы сервера. Директивы конфигурационного файла сервера Apache можно условно разделить на такие группы:1. Общие. К общим директивам относятся


16.11. Пример файла httpd.conf

Из книги автора

16.11. Пример файла httpd.conf В этом параграфе приведен пример стандартной конфигурации сервера Apache. Каждому блоку листинга 16.15 сопутствуют комментарии, которые помогут вам разобраться с различными настройками сервера.Листинг 16.15. Пример файла httpd.conf#### httpd.conf -- файл


5.2.1.10. Полный листинг конфигурационного файла xorg.conf

Из книги автора

5.2.1.10. Полный листинг конфигурационного файла xorg.conf В листинге 5.12 представлен полный вариант главного конфигурационного файла /etc/X11/xorg.conf.Листинг 5.12. Файл xorg.conf# Xorg configuration created by livna-cоnfig-display Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mousel"


Формат выходного файла

Из книги автора

Формат выходного файла Ранее было сказано, что Studio может создавать видеофайлы в нескольких форматах. Рассмотрим форматы, поддерживаемые Pinnacle Studio.• AVI – широко распространенный формат. Видео– и аудиоданные файла AVI обрабатываются разными программами (кодеками), которые