Xinetd что это
xinetd выполняет такие же функции как и inetd : запускает программы, которые предоставляют службы Интенрет. Вместо того, чтобы запускать серверы этих служб при начальной загрузке системы, ожидается поступление запроса на соединение, xinetd слушает порты всех служб, которые перечислены в его файле настройки и просто производит запуск соответствующего сервера при поступлении запроса. Поскольку xinetd предоставляет способ управления серверами, его (как и inetd ) также называют суперсервером.
Службы, перечисленные в файле с настройками xinetd могут быть разделены на две группы. Службы в первой группе называются multi-threaded (многопоточными) и они требуют разветвления (forking) нового серверного процесса для каждого нового запроса на соединение. Далее соединением управляет новый сервер. Для таких служб, xinetd продолжает слушать порты для приема новых запросов, чтобы вызвать новые серверы. В противолоположность первой, вторая группа включает службы, у которых демон службы отвечает за управление всеми запросами на соединение. Такие службы называются single-threaded (однопоточными) и для них xinetd не будет управлять новыми запросами пока сервер не завершит свою работу. Службы в этой группе обычно основаны на передаче данных через датаграммы (UDP).
Таким образом, единственная причина, по которой был создан расширенный суперсервер состоит в том, чтобы сохранить системные ресурсы через недопущение разветвления огромного числа процессов, которые могут бездействовать в течении большей части времени своей работы. В то же время выполненяя эту функцию, xinetd работает согласно идее суперсервера, предоставляя такие особенности, как управление доступом и протоколирование. Кроме того, xinetd не ограничивается обслуживанием служб, перечисленных в /etc/services. Поэтому, любой может использовать xinetd для запуска серверов специального назначения.
ОПЦИИ
-d Разрешает режим отладки. Указание этой опции приводит к большому количеству отладочных сообщений, которые делают возможным использование отладчика на
xinetd . -syslog syslog_facility Данная опция разрешает протоколирование создаваемых xinetd сообщений через syslog с заданным syslog facility. Поддерживаются следующие имена facility: daemon, auth, user, local[0-7] (посмотрите syslog.conf(5) для того, чтобы понять их назначение). Данная опция неэффективна в режиме отладки, так как все необходимые сообщения отправляются на терминал. -filelog файл_журнала Сообщения создаваемые xinetd будут помещаться в указанный файл. Сообщения вседя добавляются к уже существующему файлу. Если файл не существует, то он будет создан. Данная опция неэффективна в режиме отладки, так как все необходимые сообщения отправляются на терминал. -f файл_настроек Задает файл, который xinetd использует для настройки. По умолчанию это /etc/xinetd.conf . -pidfile pid_файл
В этот файл записывается идентификатор процесса. Данная опция неэффективна в режиме отладки. -stayalive Говорит xinetd оставаться запущенным, даже если не задано никаких служб. -loop rate Данная опция устанавливает верхнюю величну цикла, по которой определяется, что служба работает с ошибками и по которой она отключается. Величина цикла задается в терминах количества серверов в секунду, которое может быть запущено в обработку (fork). Для этой опции, корректное значние определяется скоростью вашей машины. По умолчанию оно равно 10. -reuse Если используется эта опция, xinetd будет устанавливать опцию сокета SO_REUSEADDR перед привязкой сокета службы к какому-либо Интернет адресу. Это позволяет привязать адрес, даже если есть программа, которая уже использует его, например в том случае, если некоторые серверы были запущены во время предыдущего запуска xinetd и еще не завершили свою работу. Данная опция не оказывает влияния на службы RPC. -limit proc_limit Данная опция устанавливает ограничение на количество одновременно запущенных процессов, которые может запустить xinetd. Ее назначение предотвращать переполнение таблицы процессов. -logprocs limit Данная опция устанавливает ограничение на количество одновременно запущенных серверов на один идентификатор удаленного пользователя. -shutdownprocs limit Данная опция устанавливает ограничение на количество одновременно запущенных серверов для завершения работы службы (разветвление, когда используется опция RECORD ). -cc interval Данная опция говорит xinetd выполнять периодеческие проверки своего внутреннего состояния каждые interval секунд.
Опции syslog и filelog являются взаимно исключающими. Если ни одна из них не задана, то по умолчанию используется syslog с daemon facility. Вы не должны путать сообщения xinetd с сообщениями, которые создаются службами. Последние протоколируются только если это задано в файле с настройками.
УПРАВЛЕНИЕ XINETD
Когда xinetd получает определенные сигналы, он выполняет определенные действия. Эти действия зависят от заданных сигналов и могут быть переопределены путем правки файла config.h и перекомпиляции. SIGUSR2 Заставляет выполнить жесткую перенастройку, которая означает, что xinetd перечитает файл с настройками и завершит работу серверов для тех служб, которые больше не доступны. Управление доступом выыполняется снова на уже запущенные сервера через проверку удаленных подключений, времени доступа и копий сереров. Если количество копий серверов уменьшается, то некоторые произвольно выбранные сервера будут убиты, чтобы соблюсти ограничение; это случится после завершения работы тех серверов, которые попадают под ограничение доступа с удаленных адресов или ограничение времни доступа. Также, если флаг INTERCEPT был сброшен и происходит его установка, то будет завершена работа любых запущенных серверов для служб с этим флагом. цель такого поведения — убедиться, что после жесткой перенастройки не будет запущено северов, которые могут принимать пакеты с тех адресов, которые не соответвуют криетриями управления доступом . SIGQUIT Приводит к завершению работы. SIGTERM Завершает работу всех запущенных серверов перед завершением работы xinetd . SIGHUP Приводит к снятию дампа внутреннего состояния (по умолчанию файл дампа это /var/run/xinetd.dump ; чтобы изменить данное имя файла нужна правка config.h и перекопиляция). SIGIOT Производит внутреннюю проверку того, что структуры данных, используемые программой не повреждены. Когда проверка завершится xinetd сгенерирует сообщение, которое скажет успешно прошла проверка или нет.
При перенастройке файлы журналов закрываются и переоткрываются. Это позволяет удалить старые файлы журналов.
ФАЙЛЫ
/etc/xinetd.conf файл с настройками /var/run/xinetd.dump файл дампа
xinetd + netcat → подводные камни
Если на удалённом сервере нужно делать какие-то действия, но лень возиться с написанием сетевого сервиса, на помощь приходит xinetd.
Лёгкость написания серверов для xinetd привлекательна, это действительно просто: пишем на любом языке простой скрипт, который работает с stdin и stdout (в простейшем случае это обычный REPL) и получаем одновременно консольную утилиту и сетевой сервер в одном флаконе.
После одной минуты на правку конфига xinetd получаем работающий сервер, к которому можно подключаться telnet-ом или netcat-ом и видеть результат на консоли.
Всё легко и прекрасно. Но раз уж есть (удалённая) консольная утилита, хочется пойти дальше — автоматизировать работу с ней. Не вбивать же сотни запросов руками и не искать же в выдаче на экране, как оно отработало. То есть, говоря сетевым языком, нужна клиентская часть.
Тут естественным образом хочется использовать netcat (nc): пишем простой скрипт, который выдёт команды на stdout и интерпретирует ответы, поступающие ему с stdin и подключаем его к netcat, таким образом превращая в сетевого клиента (хотя сам скрипт об этом и не узнает).
Имея такие «серверный» и «клиентский» скрипты, мы бонусом получаем возможность запускать их локально. Не говоря уже о том, что при кодировании мы не написали ни одной строчки, касающейся работы с сетью.
В большинстве случаев этого достаточно чтобы работать долго и счастливо.
Но бывают и нюансы.
Написав на радостях несколько таких удалённых утилит, я обнаружил, что иногда процесс общения написанных таким образом клиента и сервера зависает.
Нагуглить на эту тему не удалось вообще ничего, пришлось разбираться самому, результаты представляю вам.
Кто виноват?
Как работает xinetd: открывает сокет, прицепляет его на стандартные потоки ввода/вывода и запускает внешнюю программулинку.
Как работает netcat (-e, например): открывает сокет, прицепляет его на стандартные потоки ввода/вывода и запускает внешнюю программулинку.
То есть, одинаково.
Соответственно, если обе программулинки заточены на работу с терминалом, никто не проверяет возможность записи или чтения. Если надо читать, просто читают; надо писать — просто пишут.
Только вместо терминала там уже сетевой сокет, а с сетью так никто не работает.
При достаточной интенсивности трафика может возникнуть ситуация драконов, пожирающих друг друга с хвоста: буфера на чтение с обеих сторон заполнены, но по логике циклов работы обе стороны, как раз, хотят друг другу что-то сказать.
В итоге оба процесса повисают во write() навсегда.
Попытки дёшево решить проблему путём вычитывания максимального количества данных проблему не лечат, а только откладывают.
Но больше всего в этой истории меня огорчил netcat.
Не найдя в strace nc никаких вызовов для установки неблокирующего режима сокетов, я заглянул в apt-get source и… действительно не обнаружил ничего подобного.
Netcat работает с сокетами в синхронном режиме, провоцируя возможность зависания, даже без наличия всякой «внешней программы, написанной для консоли».
Печали добавляет то, что netcat по факту является стандартом, хотя, фактически, непригоден для использования в общем случае.
Что делать?
1. Писать сервер для xinetd с учётом того, что это — сеть (fcntl O_NONBLOCK, select на stdin и stdout и всё такое), но тогда теряется смысл xinetd как простой обёртки для простых вещей. Можно уже писать полноценный сервер.
2. Писать синхронного клиента, который будет дожидаться ответа сервера и не допускать переполнения буферов на чтение и запись — тут теряется простота netcat и надо что-то делать с производительностью чтобы можно было посылать по нескольку запросов одновременно, не переполняя буфер и уметь обрабатывать одновременно несколько ответов.
В моём случае я выбрал полу-второй синхронный вариант:
• послать 10 запросов
• пока есть что слать < послать один запрос; прочитать один ответ >
• прочитать 10 ответов
… что в моём конкретном случае сработало, но как общее решение, конечно, не годится.
Inetd (xinetd)
Inetd (xinetd) — служба, работающая в фоновом режиме на многих системах, основанных на Unix, и управляет сетевыми соединениями. По запросу от клиентов Inetd запускает другие программы, которые подключаются к определенным портам. Например, если кто-то хочет получить доступ к FTP-серверу, то Inetd запускает FTP-программу и передает ей соединение. Inetd читает файл конфигурации (inetd.conf), где указано, какие программы запускать для определенных портов и протоколов
Xinetd — это расширенная версия Inetd, которая имеет больше возможностей и высокий уровень безопасности. Xinetd может ограничивать количество одновременных соединений, фильтровать входящий трафик по IP-адресам или времени суток, протоколировать активность и детектить сканеры портов. Xinetd также имеет простой и гибкий формат конфигурации (xinetd.conf), который позволяет задавать параметры для каждой программы отдельно.
Цифровые следы — ваша слабость, и хакеры это знают. Подпишитесь и узнайте, как их замести!
XINETD
xinetd выполняет те же функции что и inetd : он запускает процессы которые предоставляют различные сервисы интернет. В отличие от сервисов которые стартуют во время инициализации системы и пребывают в бездействии в ожидании запросов, xinetd представляет собой только один процесс слушающий на всех портах сервисов перечисленных в файле конфигурации xinetd.conf. Когда приходит запрос xinetd запускает соответствующий сервер. По причине такой работы xinetd (так же как и inetd ) называют еще супер-сервером.
Сервисы перечисленные в конфигурационном файле xinetd можно разделить на две группы. Сервисы из первой группы называются multi-threaded см. примечание и на каждый новый запрос запускается новый серверный процесс. Для таких сервисов xinetd продолжает слушать сеть на соответствующем порту ожидая новых запросов и готовай породить новый процесс. В другую группу включаются сервисы демоны которых в состоянии обрабатывать новые соединения. Такие сервисы называются single-threaded см. примечание и xinetd прекращает обработку новых запросов до тех пор пока серверный процесс не завершит свою работу. Сервисы в этой группе обычно datagram-based.
Итак, причиной существования супер-сервера является факт сохранения системных ресурсов за счет не запуска множества серверных процессов которые возможно будут бездействовать большую часть своей жизни. Полностью соответствуя назначению запускать требуемые сервисы, xinetd осуществляет так же функции контроля доступа и регистрации событий. Кроме того xinetd не ограничен сервисами перечисленными в файле /etc/services. Можно использовать xinetd для запуска сервисов специального назначения.
ПАРАМЕТРЫ
-d Активирует режим отладки. Этот параметр выводит много отладочной информации и позволяет отладить работу xinetd . -syslog syslog_facility Этот параметр разрешает регистрацию событий используя syslog. Сообщения производимые демоном xinetd регистрируются используя одну из syslog facility. Следующие facility поддерживаются: daemon, auth, user, local[0-7] Эта опция не действует если активирован режим отладки, так как при отладке все сообщения посылаются на консоль. -filelog logfile Производимые xinetd сообщения помещаются в указанный файл. Новые сообщения всегда добавляются к существующим. Если файл не существует, то он создается. Опция не действует в режиме отладки. -f config_file Определяет положение файла конфигурации xinetd . По умолчанию это — /etc/xinetd.conf . -pid
Идентификатор процесса (PID) выводится на устройство стандартной ошибки. Не действует в режиме отладки. -loop rate Этот параметр устанавливает ограничение скорости запускания серверов, указывается число запускаемых серверов в секунду. При превышении указанного значения запуск новых процессов блокируется и сервис становится временно недоступным. Значение этого параметра определяется производительностью компьютера. По умолчанию — 10. -reuse Если указан этот параметр то, xinetd устанавливает SO_REUSEADDR для сокета используемого сервисом. Это позволяет использовать адрес даже если активны программы которые уже его используют, это может случиться когда предыдущая копия xinetd пытается запустить сервер который уже выполняется. Параметр не эффективен с RPC сервисами. -limit proc_limit Этот параметр устанавливает предел на число одновременно выполняющихся процессов запущенных демоном xinetd. Использование параметра позволяет предотвратить переполнение таблицы процессов. -logprocs limit Параметр устанавливает максимальное значение одновременно выполняемых процессов запущенных по запросу удаленного userid. -shutdownprocs limit Параметр устанавливает предельное число одновременно выполняющихся серверов сервиса shutdown (concurrently running servers for service shutdown) -cc interval Параметр задает промежуток времени в секундах через который xinetd производит периодическую проверку внутренней целостности.
Параметры syslog и filelog взаимно исключающие. Если ничего не указано, то по умолчанию используется syslog daemon facility. Не путайте сообщения xinetd с сообщениями относящимися к функциям регистрации событий. Последние журналируются только если это указано в файле конфигурации.
УПРАВЛЕНИЕ XINETD
xinetd выполняет определенные действия при получении определенных сигналов. Действия ассоциированные с соответствующими сигналами могут быть переопределены путем редактирования config.h и последующей компиляции. SIGUSR1 вызывает мягкую переконфигурацию, это означает что xinetd перечитывает файл конфигурации и подстраивается под изменения. SIGUSR2 вызывает жесткую переконфигурацию, это значит то же самое что и мягкая переконфигурация за исключением того что все серверы для сервисов которые стали недоступны принудительно завершаются. Контроль доступа заново выполняется для выполняющихся серверных процессов, путем проверки удаленного хоста, времени доступа и количества выполняющихся серверов. Если число выполняющихся процессов превышает заданное, произвольным образом выбранные процессы убиваются что бы число оставшихся удовлетворяло поставленному условию. Так же если флаг INTERCEPT был сброшен или установлен, все серверы обеспечивающие этот сервис завершаются. Все это выполняется для того что бы после жесткой реконфигурации не осталось не одного работающего процесса обрабатывающего запросы с адресов не соответствующих критериям контроля доступа. . SIGQUIT приводит к завершению программы. SIGTERM завершает все выполняющиеся серверы перед завершением xinetd . SIGHUP приводит к генерации дампа внутреннего состояния (по умолчанию файл дампа /tmp/xinetd.dump ; что бы сменить отредактируйте config.h и перекомпилируйте). SIGIOT вызывает проверку внутренней целостности что бы проверить что структуры данных используемые программой не повреждены. После завершения проверки xinetd генерирует сообщение о результате проверки.
При реконфигурации лог-файлы закрываются и вновь открываются. Это позволяет удалять старые логи.
ФАЙЛЫ
/etc/xinetd.conf стандартный конфигурационный файл /var/run/xinetd.dump стандартный файл дампа
СМОТРИТЕ ДОПОЛНИТЕЛЬНО
АВТОР
Panos Tsirigotis, CS Dept, University of Colorado, Boulder
ПРОИЗНОШЕНИЕ
zy-net-d
зи-нет-ди
ПРИМЕЧАНИЕ
Я несколько не согласен с терминологией авторов относительно «multi-threaded» и «single-threaded», в текстах прочитанных мною ранее например объяснения разницы архитектуры Apache и M$ IIS или Oracle и M$ SQL а также различных реализаций InterBase V6 то что авторы называют «multi-threaded» принято называть «классической архитектурой» (Classic) — на каждый запрос свой процесс, а для того что здесь названо «single-threaded» используется термин «многопоточный» (multi-threaded — вот оно, в точности наоборот 🙂 или «суперсерверная архитектура», то есть в рамках одного процесса несколько потоков(нитей). В данном документе я решил при переводе оставить терминологию оригинального текста.