• Ограничения для различных узлов. Для

предусмотрены опции и , которые выполняют те же функции, что и содержимое файлов и TCP Wrappers. Эти опции могут присутствовать либо в главном конфигурационном файле, либо в файле, предназначенном для конкретного сервера. В качестве значения опции задается список компьютеров, которым разрешено обращаться к серверу (для всех остальных компьютеров доступ запрещен). Аналогично, значение опции no-access представляет собой "черный список"; компьютеры, указанные в списке, не имеют права устанавливать соединение с сервером, а для остальных компьютеров доступ разрешен. Если адрес присутствует в обоих списках, приоритет имеет адрес, заданный более конкретно. Для идентификации компьютеров используются разные способы. В опциях и может быть указан IP-адрес узла (например, 172.23.45.67), адрес сети, оканчивающийся нулем (например, 172.23.0.0 для сети 172.23.0.0/16) или заданный с помощью маски (172.23.0.0/16), имя сети, указанное в файле , или доменное имя узла (например, ). Если в качестве значения опции указано имя узла, выполняет преобразование имени в адрес один раз при загрузке суперсервера. Поскольку в течение работы доменное имя может измениться, данный способ установления ограничений неэффективен.

• Ограничения по времени. Для указания временного интервала, в течение которого сервер доступен для клиентов, используется опция

. Значение этой опции задается в формате , например, 08:00-18:00 означает, что к серверу можно обращаться с 8 до часов. Значение опции влияет только на установление соединения. Например, если для Telnet-сервера задан интервал 08:00-18:00, то соединение, установленное в 17:58, может использоваться как угодно долго.

• Ограничения на использование интерфейсов. При необходимости вы можете связать сервер с одним сетевым интерфейсом. Для этого используется опция

(либо опция , которая является синонимом ). В качестве значения опции задается IP-адрес, связанный с интерфейсом. Например, если интерфейсу присвоен адрес 172.19.28.37 и для сервера задана опция , это означает, что обращаться к этому серверу можно только через интерфейс . Попытки установить соединение через окончатся неудачей; результат будет такой же, как в случае, когда сервер не установлен в системе. Эту опцию удобно использовать на маршрутизаторах или на компьютерах, подключенных одновременно к нескольким сетям. Предположим, что на компьютере, обеспечивающем связь локальной сети с Internet и использующем для соединения с сервером провайдера PPP-соединение, установлены серверы Telnet и FTP. С помощью опции вы можете настроить так, чтобы доступ к серверам Telnet и FTP имели только компьютеры, подключенные к локальной сети.

В этом и предыдущем разделе были описаны лишь наиболее часто используемые опции

. Для получения информации об остальных опциях обратитесь к справочным данным.

Как правило, в системе Linux большинство стандартных серверов запускается либо с помощью сценариев SysV, либо суперсервера. Исключением является сервер X, для запуска которого в файле

предусмотрена соответствующая запись. Сервер X запускается только на конкретном уровне выполнения. В системе Slackware для запуска основных серверов используется . Большинство дистрибутивных пакетов включает локальные сценарии запуска, редактируя которые администратор имеет возможность обеспечить работу дополнительного сервера, запустить специальную утилиту или выполнить другие подобные действия. Локальные сценарии запуска для основных дистрибутивных пакетов Linux приведены в табл. 4.1.

Как правило, локальные сценарии запуска применяются для того, чтобы включить в систему сервер, для которого отсутствуют соответствующие сценарии SysV и который по каким-либо причинам нежелательно запускать посредством суперсервера. Сценарии запуска SysV ориентированы на конкретную версию системы, поэтому для серверов, которые не включены в дистрибутивный пакет, как правило, отсутствуют и сценарии запуска. Например, если вы установите в Mandrake сервер, ориентированный на SuSE, и попытаетесь использовать для его запуска сценарии SysV, которые также предназначены для системы SuSE, сервер не будет работать. Аналогичные проблемы возникают, если автор предоставляет вам исходные коды сервера. Как правило, такие коды не настроены на конкретный дистрибутивный пакет Linux. Сервер может компилироваться без ошибок и надежно работать, но для того, чтобы обеспечить его запуск, вам придется приложить определенные усилия.

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

). Если вы не хотите тратить время на изучение формата сценариев или языка программирования, вы можете воспользоваться локальными сценариями запуска.

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

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

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

Сценарий запуска позволяет выполнять более сложные действия, чем запуск сервера посредством одной строки. Например, с помощью условных выражений языка

можно проверить, существует ли файл сервера, или запустить сервер только при выполнении определенных условий. Подобные действия часто выполняют сценарии запуска SysV.

Необходимо помнить, что локальные сценарии запуска в разных системах могут отличаться друг от друга. Например, в SuSE сценарий

запускается раньше, чем сценарий системы Red Hat, поэтому локальный сценарий запуска SuSE лучше подходит для выполнения различных действий с интерфейсами и для других задач, которые должны решаться на ранних этапах загрузки системы, а сценарий Red Hat больше пригоден для запуска сервера и других действий, которые должны выполняться тогда, когда основные средства поддержки сетевых функций уже установлены. Если задача, которую вам необходимо решить, редактируя сценарий запуска, существенно зависит от наличия в системе некоторых серверов, вам придется написать сценарий запуска SysV с номером, отражающим порядок его выполнения относительно других сценариев.