11.3.2. Настройка суперсервера xinetd

11.3.2. Настройка суперсервера xinetd

Все настройки суперсервера xinetd сосредоточены в файле /etc/xinetd.conf. В составе дистрибутивов Red Hat и Mandrake уже имеется такой готовый файл, но в нем содержится лишь минимальный набор установок. В него включена строка, которая указывает суперсерверу прочитать все файлы в каталоге /etc/xinetd.d и воспринимать их как дополнительные конфигурационные файлы.

Все конфигурационные файлы — /etc/xinetd.conf и включаемые в него директивой includedir — состоят из записей, имеющих следующий вид:

service <имя_службы>

{

 <атрибут> <оператор_присваивания > <значение> ...

 ...

}

Имя_службы может иметь значение login, shell, telnet, ftp, pop3 и т.п.

Оператор присваивания может быть одним из следующих: «=», «+=», «-=». Большинство атрибутов может работать только с оператором «=». Назначение операторов таково:

? «=»: присвоить атрибуту значение;

? «+=»: добавить атрибуту еще одно значение;

? «-=»: удалить значение атрибута.

Атрибут может иметь несколько значений, указанных через пробел. Большинство атрибутов можно использовать в секции defaults конфигурационного файла. Эта секция размещается в начале файла, и все заданные в ней атрибуты применяются ко всем серверам (сервисам), находящимся под контролем xinetd. Для каждого сервера (сервиса) можно индивидуально переопределить установки, заданные по умолчанию: если атрибут определен и в секции defaults, и в описании сервера (сервиса), то имеет силу значение, заданное в описании данного сервера (сервиса).

Среди атрибутов xinetd можно выделить следующие группы:

Запрет вызова сервера (сервиса). Запретить вызов какого-либо сервера (сервиса), находящегося под управлением xinetd, можно с помощью значения атрибута disable=yesinetd для этого пришлось бы закомментировать все строки описания сервиса). Того же эффекта можно достичь, если в секции defaults файла /etc/xinetd.conf указать disables=список_серверов. Список серверов (сервисов) состоит из их имен, разделенных пробелами.

Перенаправление. С помощью атрибута redirect можно обращение к серверу (сервису), для которого указан этот атрибут, перенаправить на другой компьютер, Целевой компьютер указывается либо доменным именем, либо IP-адресом: redirect=целевой_компьютер. Этого же эффекта можно достичь и с помощью iptables, но, используя для этой цели xinetd, вы можете применять средства управления доступом суперсервера.

Протоколирование. Определить, какая информация должна записываться в журнал в случае успешного запуска сервера (сервиса), а какая в случае неудачи, вы можете с помощью атрибутов log_on_success и log_on_failure. Подробное описание этих атрибутов приведено в таблице 11.2.

Ограничение на установление соединений. Можно указать максимальное количество запросов от одного источника (сервиса), которое может обработать xinetd в единицу времени, а также максимальную загрузку xinetd, по достижении которой он будет отвергать все обращения, и приоритет обработки серверов (сервисов). Для этого предназначены атрибуты per_source, instances, cps, nice и max_load (таблица 11.2).

Атрибуты защиты и управления доступом. В этих атрибутах заключается основное преимущество xinetd перед его предшественником inetd. С их помощью можно установить:

 • ограничения для отдельных узлов (атрибуты only_from и no-access);

 • ограничение по времени — временной интервал, в течение которого сервер (сервис) будет доступен для клиентов (атрибут access_times);

 • ограничения на использование интерфейсов — можно связать сервер с одним конкретным сетевым интерфейсом (атрибут interface).

Атрибуты сервисов под управлением xinetd Таблица 11.2

Атрибут Возможные значения
id Используется, если сервисы используют разные протоколы. Обычно совпадает с именем сервиса
type Любая комбинация из следующих значений: 1. RPC — если эта сервис RPC [Remote Procedure Call). Вызов удаленной процедуры используется в серверной части приложения. Механизм RPC скрывает от программиста детали сетевых протоколов нижележащих уровней. 2. UNLISTED — если сервис не описан в файле /etc/rpc для RPC сервисов или в /etc/services для не-RPC. 3. INTERNAL — если xinetd представляет этот сервис (для echo, time, daytime, chargen и discard). Если RPC-сервисы у вас работают некорректно после установки xinetd, вы можете использовать для них старый inetd — он прекрасно уживается с xinetd. В файле /etc/inetd.conf оставьте только RPC-сервисы, а остальное закомментируйте, а в /etc/xinetd.conf — наоборот
flags Любая комбинация из следующих значений: 1. NODELAY — только для TCP-сервисов! Будет установлен флаг сокета — TCP_NODELAY. 2. DISABLE — отключить сервис. 3. KEEPALIVE — Только для TCP сервисов! Установка флага сокета SO_KEEPALIVE. 4. REUSE — установить флаг SO_REUSEADDR на сокет сервера. 5. INTERCEPT — перехватывать пакеты или принимать соединения по порядку, проверяй, что они приходят из нужных мест. 6. NORETRY — избегать повторных попыток в случае неудачи. 7. IDONLY — соединение будет приниматься только от идентифицированных пользователей. На удаленной машине должен работать сервер идентификации
disable yes (отключить сервис) или no (не отключать)
socket_type Тип сокета. Может принимать следующие значения: 1. stream — сокет stream, обычно используется службами, работающими на основе протокола TCP; 2. dgram — сокет dgram, обычно используется службами, работающими на основе протокола UDP; 3. raw — сокет raw для сервисов, требующих прямого доступа к IP; 4. seqpacket — сокет seqpacket для сервисов, требующих надежной последовательной пересылки датаграмм
protocol tcp, udp и т.п.
wait yes (ждать завершения сервиса на данном сокете) или no (не ждать). Значение yes обычно устанавливается для сокетов dgram, а значение no - для сокетов stream
user Регистрационное имя пользователя, от имени которого будет запущен сервер (по умолчанию — root)
server Абсолютный путь к запускаемому серверу
server_args Аргументы, передаваемые серверу
only_from Список хостов, IP-адресов или сетей, которым будет доступен сервис. Аналог файла hosts.allow
no_access Список хостов, которым данный сервис не будет доступен. Аналог hosts.deny. Если ни один из атрибутов (only_from и no_access) не указан, то сервис будет доступен всем
access_times Интервалы времени в форме ЧЧ:ММ-ЧЧ:ММ, на протяжении которых сервис будет доступен. Например, 9:00-18:00
log_type Способ ведения сервисом журнала. Значения: 1. SYSLOG syslog_facility [syslog_level] — сообщения будут посылаться демону syslogd; 2. FILE file [soft_limit [hard_limit]] — сообщения будут писаться в указанный файл
log_on_failure Определяет, какая информация будет протоколироваться, если сервис по каким-либо причинам не запустился: 1. HOST — записывать адрес удаленного хоста. 2. USERID — если возможно, записывать идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). 3. ATTEMPT — записывать факт неудачной попытки. 4. RECORD — записывать информацию с удаленного узла в случае невозможности запуска сервера
log_on_success Определяет, какая информация будет протоколироваться а случае удачного запуска сервиса. Можно комбинировать любые из следующих значений: 1. PID — идентификатор запущенного серверного процесса. 2. HOST — адрес удаленного хоста. 3. USERID — если возможно, идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). 4. EXIT — записывать, каким образом был произведен выход. 5. DURATION — продолжительность сессии
rpс_number Номер сервиса RPC
rpc_version Версия сервиса RPC
env Список строк типа "имя=значение". Эти переменные будут добавлены в окружение перед тем, как сервер будет запущен
passenv Список переменных окружения xinetd, которые должны быть переданы серверу
port Порт сервиса. Если порт указан в файле /etc/services, то значение данного параметра должно совпадать с ним
redirect Позволяет tcp-сервису делать перенаправление на другой хост. Значение задается в виде host:port
interface Устанавливает интерфейс, через который будет работать сервис. Значением должен быть IP-адрес
bind Синоним параметра interface
banner Определяет имя файла, который Будет показываться при соединении с сервисом
banner_success Определяет имя файла, который будет показываться при удачном соединении
banner_fail Определяет имя файла, который будет показываться при неудачном соединении
cps Атрибут имеет два аргумента. Первый устанавливает количество соединений в секунду. Если это число будет превышено, сервис будет временно недоступен. Второй — число секунд, после которых сервис снова будет доступен
max_load Определяет максимальную загрузку. При достижении максимума сервер пере стает принимать запросы на соединение. Значение параметра — вещественное число типа float
per_source Количество запросов от одного источника (сервиса), которое может обработать xinetd в единицу времени. Значением может быть либо число, либо UNLIMITED
instances Максимальное количество процессов (серверов), которое xinetd может одновременно использовать для сервиса (по умолчанию лимита нет). Значением этого атрибута может быть либо число (большее значения атрибута per_source), либо UNLIMITED
nice Устанавливает приоритет (показатель уступчивости) сервиса

Необязательно указывать для каждого сервиса все атрибуты. Можно указать только необходимые:

? socket_type

? user

? server

? wait.

Атрибут protocol указывается только для RPC-сервисов, а также для всех сервисов, которые не описаны в /etc/services. Атрибут rpc_version — только для RPC-сервисов. Атрибут rpc_number указывается только для RPC-сервисов, которые не перечислены в файле /etc/rpc. Атрибут port задается только для не-RPC сервисов, которые не описаны в /etc/services.

Следующие атрибуты поддерживают все операторы присваивания:

? only_from

? no_access

? log_on_success

? log_on_failure

? passenv

? env (кроме оператора «-=»).

В секции defaults, в которой описаны атрибуты по умолчанию, обычно указываются следующие атрибуты:

? log_type

? log_on_success

? log_on_failure

? only_from

? no_access

? passenv

? instances

? disabled

? enabled.

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

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

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

8.1. Суперсерверы inetd и xinetd

Из книги Linux-сервер своими руками автора Колисниченко Денис Николаевич

8.1. Суперсерверы inetd и xinetd В данной главе пойдет речь об общей настройке Интернет-суперсерверов inetd и xinetd, а также о настройке сервера xinetd для работы с протоколом IPv6.Для начала все же определимся, почему inetd(xinetd) называется суперсервером? Да потому, что он отвечает за


8.1.5. Настройка xinetd

Из книги Сетевые средства Linux автора Смит Родерик В.

8.1.5. Настройка xinetd Синтаксис файла xinetd.conf такой: service < service_name> { <атрибут> <оператор_присваивания> <значение> <значение> … <атрибут> <оператор_присваивания> <значение> <значение> … … <атрибут> <оператор_присваивания> <значение>


8.1.6. Параметры запуска xinetd

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

8.1.6. Параметры запуска xinetd Я надеюсь, что с настройкой более-менее все понятно. Если же мои надежды не оправдались, то в разделе 8.1.7 вы найдете пример файла /etc/xinetd.conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его


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

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

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


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

Из книги Linux глазами хакера автора Флёнов Михаил Евгеньевич

Использование xinetd Традиционно inetd был основным суперсервером, использовавшимся в системе Linux. Однако в 2000 г. наметилась тенденция перехода к альтернативному суперсерверу xinetd. Условно xinetd можно представить себе как сочетание inetd и TCP Wrappers. Но между этими программами


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

Из книги Социальные сети. ВКонтакте, Facebook и другие… автора Леонтьев Виталий Петрович

Формат файла /etc/xinetd.conf Поскольку возможности нового суперсервера расширены по сравнению с inetd, формат конфигурационного файла также отличается от inetd. Настройка xinetd производится с помощью файла /etc/xinetd.conf. Следует заметить, что файл xinetd.conf, поставляемый в составе


11.3. Суперсервер xinetd

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

11.3. Суперсервер xinetd 11.3.1. Установка суперсервера xinetd Суперсервер xinetd появился в дистрибутивах давно (например, в Red Hat начиная еще с 7 версии) и стал достойной заменой inetd, использовавшемуся до него. Суперсервер xinetd обычно устанавливается по умолчанию во время установки


11.3.1. Установка суперсервера xinetd

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

11.3.1. Установка суперсервера xinetd Суперсервер xinetd появился в дистрибутивах давно (например, в Red Hat начиная еще с 7 версии) и стал достойной заменой inetd, использовавшемуся до него. Суперсервер xinetd обычно устанавливается по умолчанию во время установки системы. Одним из


11.3.3. Запуск xinetd

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

11.3.3. Запуск xinetd Я надеюсь, что с настройкой все более-менее понятно. Если нет, то немного ниже вы найдете пример файла /etc/xinetd.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 Теперь, как и обещал, привожу пример файла конфигурации. В этом листинге перечислены чаще всего используемые сервисы с оптимальными атрибутами. Конечно же, вам предстоит решить, какие сервисы вы будете использовать, а какие нет.


Сравнение архитектуры Суперсервера и Классического сервера

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

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


5.4. Демон inetd/xinetd

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

5.4. Демон inetd/xinetd Для того чтобы сервер смог обрабатывать запросы клиентов, программа должна быть постоянно загружена и связана с определенным портом. В этом нет ничего сложного, но зачем постоянно держать программу в памяти, особенно если она слишком большая, а работает


5.4.1. Конфигурирование xinetd

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

5.4.1. Конфигурирование xinetd Основной конфигурационный файл для xinetd — это /etc/xinetd.conf. В нем описываются настройки по умолчанию для запускаемых сервисов и директория, в которой будут находиться конфигурационные файлы, влияющие на работу конкретных сервисов. Рассмотрим по


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

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

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


Настройка QIP

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

Настройка QIP Да, программа работает… Но пока что лишь в собственной сети. А ей мы, как вы понимаете, ограничиваться не собираемся. Поэтому первое, что нам нужно сделать, – это внести в настройки QIP всю необходимую информацию для доступа к другим сетям. Сделать это можно в