Текст книги "UNIX: разработка сетевых приложений"

Автор книги: Уильям Ричард Стивенс

Соавторы: Эндрю М. Рудофф,Билл Феннер
сообщить о нарушении

Текущая страница: 36 (всего у книги 88 страниц) [доступный отрывок для чтения: 36 страниц]

12.5. Переносимость исходного кода

Большинство существующих сетевых приложений написаны для IPv4. Структуры sockaddr_inразмещаются в памяти и заполняются, а функция socketзадает AF_INETв качестве первого аргумента. При переходе от листинга 1.1 к листингу 1.2 мы видели, что эти приложения IPv4 можно преобразовать в приложения IPv6 без особых усилий. Многие показанные нами изменения можно выполнить автоматически, используя некоторые сценарии редактирования. Программы, более зависящие от IPv4, использующие такие свойства, как многоадресная передача, параметры IP или символьные (неструктурированные) сокеты, потребуют больших усилий при преобразовании.

Если мы преобразуем приложение для работы с IPv6 и распространим его исходный код, нам придется думать о том, поддерживает ли принимающая система протокол IPv6. Типичный способ решения этой проблемы – применять в коде #ifdef, используя по возможности IPv6 (поскольку мы видели в этой главе, что клиент IPv6 может взаимодействовать с серверами IPv4 и наоборот). Проблема такого подхода в том, что код очень быстро засоряется директивами #ifdef, и его становится сложнее отслеживать и обслуживать.

Наилучшим подходом будет рассмотрение перехода на IPv6 как возможности сделать программу не зависящей от протокола. Первым шагом здесь будет удаление вызовов функций gethostbynameи gethostbyaddrи использование функций getaddrinfoи getnameinfo, описанных в предыдущей главе. Это позволит нам обращаться со структурами адресов сокетов как с непрозрачными объектами, ссылаться на которые можно с помощью указателя и размера, что как раз и выполняют основные функции сокетов: bind, connect, recvfromи т.д. Наши функции sock_XXXиз раздела 3.8 помогут работать с ними независимо от IPv4 и IPv6. Очевидно, эти функции содержат #ifdefдля работы с IPv4 и IPv6, но если мы скроем эту зависимость от протокола в нескольких библиотечных функциях, наш код станет проще. В разделе 21.7 мы разработаем ряд функций mcast_XXX, которые помогут сделать приложения многоадресной передачи не зависящими от версии протокола IP.

Другой момент, который нужно учесть, – что произойдет, если мы откомпилируем наш исходный код в системе, поддерживающей и IPv4, и IPv6, затем распространим либо исполняемый код, либо объектные файлы (но не исходный код) и кто-то запустит наше приложение в системе, не поддерживающей IPv6. Есть вероятность, что сервер локальных имен поддерживает записи типа AAAA и возвращает как записи типа AAAA, так и записи типа А некоему собеседнику, с которым пытается соединиться наше приложение. Если наше приложение, работающее с IPv6, вызовет функцию socketдля создания сокета IPv6, она не будет работать, если узел не поддерживает IPv6. Мы решаем этот вопрос с помощью функций, описанных в следующей главе, игнорируя ошибку функции socketи пытаясь использовать следующий адрес в списке, возвращаемом сервером имен. Если предположить, что у собеседника имеется запись типа А и что сервер имен возвращает запись типа А в дополнение к любой записи типа AAAA, то сокет IPv4 успешно создастся. Этот тип функциональности имеется в библиотечной функции, но не в исходном коде каждого приложения.

Чтобы получить возможность передавать дескрипторы сокетов, программам, работающим только с одним из протоколов, в стандарте RFC 2133 [37] предлагается использовать параметр сокета IPV6_ADDRFORM, позволяющий получить или изменить семейство сокета. Однако семантика параметра не была описана полностью, да и использоваться он мог только в очень специфических ситуациях, поэтому в следующей версии интерфейса сокетов данный параметр был отменен.

12.6. Резюме

Сервер IPv6 на узле с двойным стеком протоколов может предоставлять сервис как клиентам IPv4, так и клиентам IPv6. Клиент IPv4 посылает серверу дейтаграммы IPv4, но стек протоколов сервера преобразует адрес клиента к виду IPv6, поскольку сервер IPv6 работает со структурами адресов сокетов IPv6.

Аналогично, клиент IPv6 на узле с двойным стеком протоколов может взаимодействовать с сервером IPv4. Распознаватель клиента возвращает адреса IPv4, преобразованные к виду IPv6, для всех записей сервера типа А, и вызов функции connect для одного из этих адресов приводит к тому, что двойной стек посылает сегмент SYN IPv4. Только отдельным специальным клиентам и серверам необходимо знать протокол, используемый собеседником (например, FTP), и чтобы определить, что собеседник использует IPv4, можно использовать макрос IN6_IS_ADDR_V4MAPPED.

Упражнения

1. Запустите FTP-клиент IPv6 на узле с двойным стеком протоколов. Соединитесь с FTP-сервером IPv4, запустите команду debug, а затем команду dir. Далее выполните те же операции, но для сервера IPv6, и сравните команды PORT, являющиеся результатом выполнения команд dir.

2. Напишите программу, требующую ввода одного аргумента командной строки, который является адресом IPv4 в точечно-десятичной записи. Создайте TCP-сокет IPv4 и свяжите этот адрес и некоторый порт, например 8888, с сокетом при помощи функции bind. Вызовите функцию listen, а затем pause. Напишите аналогичную программу, которая в качестве аргумента командной строки принимает шестнадцатеричную строку IPv6 и создает прослушиваемый TCP-сокет IPv6. Запустите программу IPv4, задав в качестве аргумента универсальный адрес. Затем перейдите в другое окно и запустите программу IPv6, задав в качестве аргумента универсальный адрес IPv6. Можете ли вы запустить программу IPv6, если программа IPv4 уже связана с этим портом? Появляется ли разница при использовании параметра сокета SO_REUSEADDR? Что будет, если вы сначала запустите программу IPv6, а затем попытаетесь запустить программу IPv4?

Глава 13
Процессы-демоны и суперсервер inetd

13.1. Введение

Демон( daemon) – это процесс, выполняющийся в фоновом режиме и не связанный с управляющим терминалом. Системы Unix обычно имеют множество процессов (от 20 до 50), которые являются демонами, работают в фоновом режиме и выполняют различные административные задачи.

Независимость от терминала обычно является побочным эффектом запуска из системного сценария инициализации (например, в процессе загрузки компьютера). Если же демон запускается командой интерпретатора, он должен самостоятельно отключиться от терминала во избежание нежелательного взаимодействия с системами управления задачами, сеансами терминалов, а также вывода на терминал при работе в фоновом режиме.

Существует несколько способов запустить демон:

1. Во время запуска системы многие демоны запускаются сценариями инициализации системы. Эти сценарии часто находятся в каталоге /etc  или в каталоге, имя которого начинается с /etc/rc, но их расположение и содержание зависят от реализации. Такие демоны запускаются с правами привилегированного пользователя.

Некоторые сетевые серверы часто запускаются из сценариев инициализации: суперсервер inetd(следующий пункт, который мы рассмотрим), веб-сервер и почтовый сервер (обычно это программа sendmail). Демон syslogd, обсуждаемый в разделе 13.2, тоже обычно запускается одним из этих сценариев.

2. Многие сетевые серверы запускаются суперсервером inetd, который мы опишем далее в этой главе. Сам inetdзапускается в одном из сценариев на этапе 1. Суперсервер inetdпрослушивает сетевые порты (Telnet, FTP и т.д.), и когда приходит запрос, активизирует требуемый сервер (сервер Telnet, сервер FTP и т.д.).

3. За периодические процессы в системе отвечает демон cron, и программы, которые он активизирует, выполняются как демоны. Сам демон cronзапускается на этапе 1 во время загрузки системы.

4. Если программа должна быть выполнена однократно в определенный момент времени в будущем, применяется команда at. Демон cronобычно инициирует эти программы, когда приходит время их выполнения, поэтому они выполняются как демоны.

5. Демоны можно запускать с пользовательских терминалов, как в основном, так и в фоновом режимах. Это часто осуществляется при тестировании демона или перезапуске демона, завершенного по некоей причине.

Поскольку у демона нет управляющего терминала, ему необходимы средства для вывода сообщений о некоторых событиях – это могут быть обычные информационные сообщения или экстренные сообщения об аварийных ситуациях, которые должен обрабатывать администратор. Использование функции syslog– стандартный способ вывода таких сообщений. Эта функция посылает сообщения демону syslogd.

13.2. Демон syslogd

Системы Unix обычно запускают демон syslogdв одном из сценариев инициализации системы, и он функционирует, пока система работает. Реализации syslogd, происходящие от Беркли, выполняют при запуске следующие действия:

1. Считывается файл конфигурации, обычно /etc/syslog.conf, в котором указано, что делать с каждым типом сообщений, получаемых демоном. Эти сообщения могут добавляться в файл (особой разновидностью такого файла является /dev/console, который записывает сообщение на консоль), передаваться определенному пользователю (если этот пользователь вошел в систему) или передаваться демону syslogdна другом узле.

2. Создается доменный сокет Unix и связывается с полным именем /var/run/log(в некоторых системах /dev/log).

3. Создается сокет UDP и связывается с портом 514 (служба syslog).

4. Открывается файл (устройство) /dev/klog. Любые сообщения об ошибках внутри ядра появляются как входные данные на этом устройстве.

Демон syslogdвыполняется в бесконечном цикле, в котором вызывается функция select, ожидающая, когда один из трех его дескрипторов (из п. 2, 3 и 4) станет готов для чтения. Этот демон считывает сообщение и выполняет то, что предписывает делать с этим сообщением файл конфигурации. Если демон получает сигнал SIGHUP, он заново считывает файл конфигурации.

ПРИМЕЧАНИЕ

Более новые реализации отключают возможность создания сокета UDP, если она не задана администратором, поскольку если позволить кому угодно отправлять дейтаграммы UDP на этот порт (возможно, заполняя приемный буфер его сокета), это может привести к тому, что законные сообщения не будут получены (атака типа отказ в обслуживании) или переполнится файловая система из-за неограниченного роста журналов.

Между реализациями демона syslogd существуют различия. Например, доменные сокеты Unix используются Беркли-реализациями, а реализации System V используют потоковый драйвер (streams log driver). Различные реализации, происходящие от Беркли, используют для доменных сокетов Unix различные полные имена. Мы можем игнорировать все эти тонкости, если используем функцию syslog.

Мы можем отправлять сообщения о событиях для записи в журнал (log messages) демону syslogdиз наших демонов, создав дейтаграммный доменный сокет Unix и указывая при отправке полное имя, с которым связан демон, но более простым интерфейсом является функция syslog, которую мы описываем в следующем разделе. В качестве альтернативы мы можем создать сокет UDP и отправлять наши сообщения на адрес закольцовки и порт 514.

13.3. Функция syslog

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

#include

void syslog(int priority, const char * message, ...);

Хотя эта функция изначально разрабатывалась для BSD, в настоящее время она предоставляется большинством производителей систем Unix. Описание syslogв POSIX соответствует тому, что мы пишем здесь. RFC 3164 содержит документацию, касающуюся протокола syslogBSD.

Аргумент priority– это комбинация аргументов levelи facility, которые мы показываем в табл. 13.1 и 13.2. Дополнительные сведения об этом аргументе можно найти в RFC 3164. Аргумент messageаналогичен строке формата функции printfс добавлением спецификации %m, которая заменяется сообщением об ошибке, соответствующим текущему значению переменной errno. Символ перевода строки может появиться в конце строки message, но он не является обязательным.

Сообщения для журнала имеют значение level(уровень) от 0 до 7, что мы показываем в табл. 13.1. Это упорядоченные значения. Если отправитель не задает значение level, используется значение по умолчанию LOG_NOTICE.

Таблица 13.1. Аргумент level журнальных сообщений

LOG_EMERG	0	Система не может функционировать, экстренная ситуация (наивысший приоритет)
LOG_ALERT	1	Следует немедленно принять меры, срочная ситуация
LOG_CRIT	2	Критическая ситуация
LOG_ERR	3	Состояние ошибки
LOG_WARNING	4	Предупреждение
LOG_NOTICE	5	Необычное, хотя и не ошибочное состояние (значение аргумента level по умолчанию)
LOG_INFO	6	Информационное сообщение
LOG_DEBUG	7	Отладочные сообщения (низший приоритет)

Сообщения также содержат аргумент facilityдля идентификации типа процесса, посылающего сообщение. Мы показываем его различные значения в табл. 13.2. Если не задано значение аргумента facility, используется его значение по умолчанию – LOG_USER.

Таблица 13.2. Аргумент facility журнальных сообщений

LOG_AUTH	Сообщения no безопасности/авторизации
LOG_AUTHPRIV	Сообщения по безопасности/авторизации (частные)
LOG_CRON	Демон cron
LOG_DAEMON	Системные демоны
LOG_FTP	Демон FTP
LOG_KERN	Сообщения ядра
LOG_LOCAL0	Локальное использование
LOG_LOCAL1	Локальное использование
LOG_LOCAL2	Локальное использование
LOG_LOCAL3	Локальное использование
LOG_LOCAL4	Локальное использование
LOG_LOCAL5	Локальное использование
LOG_LOCAL6	Локальное использование
LOG_LOCAL7	Локальное использование
LOG_LPR	Демон принтера
LOG_MAIL	Почтовая система
LOG_NEWS	Система телеконференций
LOG_SYSLOG	Внутренние сообщения системы syslog
LOG_USER	Сообщения пользовательского уровня (значение аргумента facility по умолчанию)
LOG_UUCP	Система UUCP

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

syslog(LOG_INFO|LOG_LOCAL2, "rename(%s, %s): %m", file1, file2);

Назначение аргументов facilityи levelв том, чтобы все сообщения, которые посылаются процессами определенного типа (то есть с одним значением аргумента facility), могли обрабатываться одинаково в файле /etc/syslog.confили чтобы все сообщения одного уровня (с одинаковым значением аргумента level) обрабатывались одинаково. Например, файл конфигурации может содержать строки

kern.* /dev/console

local7.debug /var/log/cisco.log

для указания, что все сообщения ядра направляются на консоль, а сообщения относительно отладки со значением аргумента facility, равным local7, добавляются в файл /var/log/cisco.log.

Когда приложение впервые вызывает функцию syslog, она создает дейтаграммный доменный сокет Unix и затем вызывает функцию connectдля сокета с заранее известным полным именем, которое создано демоном syslogd(например, /var/run/log). Этот сокет остается открытым, пока процесс не завершится. Другим вариантом является вызов процессом функций openlogи closelog.

#include

void openlog(const char * ident, int options, int facility);

void closelog(void);

Функция openlogможет быть вызвана перед первым вызовом функции syslog, а функция closelog– когда приложение закончит отправлять сообщения в журнал.

Аргумент ident– это строка, которая будет добавлена в начало каждого журнального сообщения функцией syslog. Часто это имя программы.

Обычно аргумент optionsформируется путем применения операции логического ИЛИ к константам из табл. 13.3.

Таблица 13.3. Аргумент options (параметр) для функции openlog

LOG_CONS	Выводить журнал на консоль, если невозможно послать сообщение демону syslogd
LOG_NDELAY	Не откладывать создание сокета, открыть его сейчас
LOG_PERROR	Записывать сообщение в stderr, а также посылать его демону syslogd
LOG_PID	Включать идентификатор процесса (PID) в каждую запись журнала

Обычно доменный сокет Unix не создается при вызове функции openlog. Вместо этого сокет открывается при первом вызове функции syslog. Параметр LOG_NDELAYуказывает, что сокет должен создаваться при вызове функции openlog.

Аргумент facilityфункции openlogзадает значение facility, используемое по умолчанию для любого последующего вызова функции syslog, при котором не задается аргумент facility. Некоторые демоны вызывают функцию openlogи задают значение аргумента facility(которое обычно не изменяется для данного демона) и затем в каждом вызове функции syslogзадают только аргумент level(поскольку levelможет изменяться в зависимости от ошибки).

Сообщения для записи в журнал могут также генерироваться командой logger. Это может использоваться в сценариях интерпретатора команд, например для отправки сообщений демону syslogd.

13.4. Функция daemon_init

В листинге 13.1 [1]1
  Все исходные коды программ, опубликованные в этой книге, вы можете найти по адресу http://www.piter.com.


[Закрыть]показана функция, называемая daemon_init, которую мы можем вызвать (обычно с сервера), чтобы придать процессу свойства демона.

Листинг 13.1. Функция daemon_init: придание процессу свойств демона

//daemon _init.с

 1 #include "unp.h"

 2 #include

 3 #define MAXFD 64

 4 extern int daemon_proc; /* определен в error.с */

 5 int

 6 daemon_init(const char *pname, int facility)

 7 {

 8  int i;

 9  pid_t pid;

10  if ((pid = Fork()) < 0)

11   return (-1);

12  else if (pid)

13   _exit(0); /* родитель завершается */

14  /* 1-й дочерний процесс продолжает работу... */

15  if (setsid() < 0) /* становится главным процессом сеанса */

16   return (-1);

17  Signal(SIGHUP, SIG_IGN);

18  if ((pid = Fork()) < 0)

19   return (-1);

20  else if (pid)

21   _exit(0); /* 1-й дочерний процесс завершается */

22  /* 2-й дочерний процесс продолжает работу */

23  daemon_proc = 1; /* для функций err_XXX() */

24  chdir("/"); /* смена текущего каталога */

25  /* закрытие дескрипторов файлов*/

26  for (i = 0; i < MAXFD; i++)

27   close(i);

28  /* перенаправление stdin, stdout и stderr в /dev/null */

29  open("/dev/null", O_RDONLY);

30  open("/dev/null", O_RDWR);

31  open("/dev/null", O_RDWR);

32  openlog(pname, LOG_PID, facility);

33  return (0); /* успешное завершение */

34 }

Вызов функции fork

10-13 Сначала мы вызываем функцию fork, после чего родительский процесс завершается, а дочерний продолжается. Если процесс был запущен из интерпретатора команд в фоновом режиме, то, когда родительский процесс завершается, оболочка считает, что команда выполнена. Это автоматически запускает дочерний процесс в фоновом режиме. Дочерний процесс наследует идентификатор группы процессов от родительского процесса, но получает свой собственный идентификатор процесса. Это гарантирует, что дочерний процесс не является главным в группе процессов, что требуется для следующего вызова функции setsid.

Вызов функции setsid

15-16 Функция setsid– это функция POSIX, создающая новый сеанс. (В главе 9 [110] подробно рассказывается о взаимоотношениях процессов.) Процесс становится главным в новом сеансе, становится главным в новой группе процессов и не имеет управляющего терминала.

Игнорирование сигнала SIGHUP и новый вызов функции fork

17-21 Мы игнорируем сигнал SIGHUPи снова вызываем функцию fork. Когда эта функция завершается, родительский процесс на самом деле является первым дочерним процессом, и он завершается, оставляя выполняться второй дочерний процесс. Назначение второй функции fork– гарантировать, что демон не сможет автоматически получить управляющий терминал, если потом он откроет устройство терминала. В SVR4, когда главный процесс сеанса без управляющего терминала открывает устройство терминала (которое в этот момент не является управляющим терминалом для другого сеанса), терминал становится управляющим терминалом главного процесса сеанса. Но вызывая второй раз функцию fork, мы гарантируем, что второй дочерний процесс больше не является главным в сеансе, поэтому он не может получить управляющий терминал. Сигнал SIGHUPприходится игнорировать, поскольку, когда главный процесс сеанса завершает работу (первый дочерний процесс), всем процессам в сеансе (нашему второму дочернему процессу) посылается сигнал SIGHUP.

Установка флага для функций ошибок

23 Мы присваиваем глобальной переменной daemon_procненулевое значение. Эта внешняя переменная задается нашими функциями err_ XXX(см. раздел Г.4), и ее ненулевое значение сообщает этим функциям, что нужно вызвать функцию syslogвместо функции fprintf(которая выводит сообщение об ошибке в стандартный поток сообщений об ошибках). Это спасает нас от необходимости проходить через весь наш код и вызывать одну из наших функций ошибок, если сервер не работает как демон (то есть когда мы проверяем сервер), а при работе в режиме демона заменять все вызовы на вызовы syslog.

Изменение рабочего каталога и сброс всех битов в маске режима создания файла

24 Мы изменяем рабочий каталог на корневой каталог, хотя у некоторых демонов могут быть причины изменить рабочий каталог на какой-либо другой. Например, демон печати может изменить его на каталог, в котором накапливается содержимое заданий для принтера и происходит вся работа по выводу данных на печать. Если демоном сбрасывается дамп (файл core), он появляется в текущем рабочем каталоге. Другой причиной для изменения рабочего каталога является то, что демон мог быть запущен в любой файловой системе, и если он там останется, эту систему нельзя будет размонтировать, во всяком случае, без жестких мер.

Закрытие всех открытых дескрипторов

25-27 Мы закрываем все открытые дескрипторы, которые наследуются от процесса, запустившего демон (обычно этим процессом бывает интерпретатор команд). Проблема состоит в определении наибольшего используемого дескриптора: в Unix нет ни одной функции, предоставляющей это значение. Есть способы определения максимального числа дескрипторов, которое может открыть процесс, но даже это достаточно сложно [110, с. 43], поскольку предел может быть бесконечным. Наше решение – закрыть первые 64 дескриптора, даже если большинство из них, возможно, не было открыто.

ПРИМЕЧАНИЕ

Solaris предоставляет функцию closefrom, позволяющую демонам решать эту проблему.

Перенаправление stdin, stdout и stderr в /dev/null

29-31 Некоторые демоны открывают /dev/nullдля чтения и записи и подключают к нему дескрипторы стандартных потоков ввода, вывода и сообщений об ошибках. Это гарантирует, что наиболее типичные дескрипторы открыты и операция чтения из любого из них возвращает 0 (конец файла), а ядро игнорирует все, что записано в любой из этих трех дескрипторов. Причина, по которой требуется открыть эти дескрипторы, заключается в том, что любая библиотечная функция, вызываемая демоном и считающая, что она может читать из стандартного потока ввода или записывать либо в стандартный поток вывода, либо в стандартный поток сообщений об ошибках, не должна завершиться с ошибкой. Отказ был бы потенциально опасен: если демон открывает сокет для связи с клиентом, дескриптор сокета воспринимается как стандартный поток вывода, поэтому ошибочный вызов какой-нибудь функции типа perrorможет привести к отправке клиенту нежелательных данных.

Использование демона syslogd для вывода сообщений об ошибках

32 Вызывается функция openlog. Первый ее аргумент берется из вызывающего процесса и обычно является именем программы (например, argv[0]). Мы указываем, что идентификатор процесса должен добавляться к каждому сообщению. Аргумент facilityтакже задается вызывающим процессом, и его значением может быть константа из табл. 13.2 либо, если приемлемо значение по умолчанию LOG_USER, нулевое значение.

Отметим, что поскольку демон выполняется без управляющего терминала, он никогда не должен получать сигнал SIGHUPот ядра. Следовательно, многие демоны используют этот сигнал в качестве уведомления от администратора, что файл конфигурации демона изменился и демон должен еще раз считать файл. Два других сигнала, которые демон никогда не должен получать, – это сигналы SIGINTи SIGWINCH, и они также могут использоваться для уведомления демона о некоторых изменениях.