Книга: Сетевые средства Linux
Формат файла /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
суперсервер делает то же самое, но при этом завершает работу тех серверов, которые согласно новому конфигурационному файлу должны быть неактивны.
- Выбор правильного формата для вашего видео на YouTube
- Какую файловую систему выбрать при форматировании дисков?
- Можно ли сравнить два файла?
- Какая программа позволяет создавать документы формата PDF?
- Как склеить два MP3-файла?
- Как вырезать звуковую дорожку из AVI-файла?
- Понятие формата файла
- Формат файла
- Формат файла протокола Apache
- Разработка записной книжки в формате текстового файла
- Пример 9-11. Преобразование графических файлов из одного формата в другой, с изменением имени файла
- 2.9.2. Сведения о файлах данных Outlook (в форматах PST и OST)