Глава 32. Сетевые серверы

Настройка inetd выполняется путем редактирования /etc/inetd.conf. Каждая строка этого файла конфигурации представляет приложение, которое может быть запущено inetd. По умолчанию каждая строка начинается с комментария (#), что означает, что inetd не ожидает подключений для каких-либо приложений. Чтобы настроить inetd на ожидание подключений для приложения, удалите # в начале соответствующей строки.

После сохранения изменений настройте inetd для запуска при загрузке системы, отредактировав /etc/rc.conf:

Чтобы запустить inetd сейчас, чтобы он начал прослушивать настроенную службу, введите:

После запуска inetd необходимо уведомлять его о каждом изменении в файле /etc/inetd.conf:

Обычно запись по умолчанию для приложения не требует редактирования, кроме удаления #. В некоторых ситуациях может быть целесообразно изменить запись по умолчанию.

В качестве примера, это стандартная запись для ftpd(8) по IPv4:

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

где:

Как и большинство серверных демонов, inetd имеет ряд опций, которые можно использовать для изменения его поведения. По умолчанию inetd запускается с параметрами -wW -C 60. Эти опции включают TCP wrappers для всех сервисов, включая внутренние, и предотвращают запросы любого IP-адреса к любому сервису чаще 60 раз в минуту.

Для изменения параметров по умолчанию, передаваемых inetd, добавьте запись inetd_flags в файл /etc/rc.conf. Если inetd уже запущен, перезапустите его командой service inetd restart.

Доступные варианты ограничения скорости:

Доступны дополнительные параметры. Полный список параметров смотрите в inetd(8).

Многие демоны, которыми может управлять inetd, не обладают достаточной защитой. Некоторые демоны, такие как fingerd, могут предоставлять информацию, полезную для злоумышленника. Включайте только необходимые службы и отслеживайте систему на предмет чрезмерных попыток подключения. Параметры max-connections-per-ip-per-minute, max-child и max-child-per-ip могут быть использованы для ограничения подобных атак.

По умолчанию TCP wrappers включены. Дополнительную информацию о наложении TCP-ограничений на различные демоны, запускаемые через inetd, можно найти в hosts_access(5).

Файловые системы, которые сервер NFS будет предоставлять в общий доступ, указаны в /etc/exports. Каждая строка в этом файле определяет файловую систему для экспорта, клиентов, которые имеют доступ к этой файловой системе, и любые параметры доступа. При добавлении записей в этот файл каждая экспортируемая файловая система, её свойства и разрешённые хосты должны быть указаны в одной строке. Если в записи не указаны клиенты, то любой клиент в сети может подключить эту файловую систему.

Следующие записи в /etc/exports демонстрируют, как экспортировать файловые системы. Примеры могут быть изменены в соответствии с файловыми системами и именами клиентов в сети читателя. В этом файле можно использовать множество опций, но здесь упомянуты лишь некоторые. Полный список опций смотрите в exports(5).

В этом примере показано, как экспортировать /cdrom на три хоста с именами alpha, bravo и charlie:

Флаг -ro делает файловую систему доступной только для чтения, предотвращая внесение клиентами изменений в экспортированную файловую систему. В этом примере предполагается, что имена хостов находятся либо в DNS, либо в /etc/hosts. Обратитесь к hosts(5), если в сети нет DNS-сервера.

Следующий пример экспортирует /home трём клиентам по IP-адресу. Это может быть полезно для сетей без DNS или записей в /etc/hosts. Флаг -alldirs позволяет подкаталогам быть точками монтирования. Другими словами, он не будет автоматически монтировать подкаталоги, но разрешит клиенту монтировать необходимые каталоги по мере надобности.

Следующий пример экспортирует /a, чтобы два клиента из разных доменов могли получить доступ к этой файловой системе. Параметр -maproot=root позволяет пользователю root на удалённой системе записывать данные в экспортированную файловую систему как root. Если параметр -maproot=root не указан, пользователь root на клиенте будет отображён на учётную запись nobody на сервере и будет ограничен правами доступа, определёнными для nobody.

Клиент может быть указан только один раз для каждой файловой системы. Например, если /usr представляет собой одну файловую систему, следующие записи будут недопустимыми, так как обе указывают на один и тот же узел:

Правильный формат для данной ситуации — использовать одну запись:

Ниже приведён пример корректного списка экспорта, где /usr и /exports являются локальными файловыми системами:

Чтобы включить процессы, необходимые для работы сервера NFS при загрузке, добавьте следующие параметры в /etc/rc.conf:

Сервер можно запустить, выполнив следующую команду:

Всякий раз, когда запускается сервер NFS, также автоматически запускается mountd. Однако mountd читает /etc/exports только при запуске. Чтобы последующие изменения в /etc/exports вступили в силу немедленно, заставьте mountd перечитать его:

Обратитесь к zfs-share(8) для описания экспорта наборов данных ZFS через NFS с использованием свойства ZFS sharenfs вместо файла exports(5).

Обратитесь к nfsv4(4) для описания настройки NFS версии 4.

Чтобы включить клиенты NFS, установите эту опцию в файле /etc/rc.conf каждого клиента:

Затем выполните эту команду на каждом клиенте NFS:

Клиент теперь имеет всё необходимое для монтирования удалённой файловой системы. В этих примерах имя сервера — server, а имя клиента — client. Чтобы смонтировать /home с сервера server в точку монтирования /mnt на клиенте client:

Файлы и каталоги в /home теперь будут доступны на client, в директории /mnt.

Для монтирования удаленной файловой системы при каждой загрузке клиента добавьте её в /etc/fstab:

Обратитесь к fstab(5) для описания всех доступных опций.

Некоторые приложения требуют блокировки файлов для корректной работы. Чтобы включить блокировку, выполните следующую команду как на клиенте, так и на сервере:

Затем запустите службу rpc.lockd(8):

Если блокировка не требуется на сервере, клиент NFS можно настроить для локальной блокировки, добавив параметр -L при выполнении команды mount. Дополнительные сведения см. в mount_nfs(8).

Утилита autofs(5) — это общее название для нескольких компонентов, которые вместе позволяют автоматически монтировать удалённые и локальные файловые системы при обращении к файлу или каталогу внутри этих файловых систем. Она состоит из компонента ядра autofs(5) и нескольких пользовательских приложений: automount(8), automountd(8) и autounmountd(8). Она служит альтернативой для amd(8) из предыдущих выпусков FreeBSD. amd по-прежнему предоставляется для обратной совместимости, так как эти утилиты используют разные форматы карт; формат, используемый autofs, совпадает с форматом других автомонтировщиков SVR4, таких как в Solaris, MacOS X и Linux.

Виртуальная файловая система autofs(5) монтируется на указанные точки монтирования с помощью automount(8), который обычно запускается во время загрузки.

Всякий раз, когда процесс пытается получить доступ к файлу в точке монтирования autofs(5), ядро уведомляет демон automountd(8) и приостанавливает вызвавший процесс. Демон automountd(8) обрабатывает запросы ядра, находя соответствующую карту и монтируя файловую систему в соответствии с ней, после чего сигнализирует ядру о разблокировке процесса. Демон autounmountd(8) автоматически размонтирует автомонтируемые файловые системы по истечении некоторого времени, если они больше не используются.

Основной файл конфигурации autofs — это /etc/auto_master. Он связывает отдельные карты с корневыми точками монтирования. Для объяснения синтаксиса auto_master и карт обратитесь к auto_master(5).

Существует специальная карта автомонтирования, смонтированная в /net. При обращении к файлу в этом каталоге, autofs(5) ищет соответствующую удалённую точку монтирования и автоматически монтирует её. Например, попытка доступа к файлу в /net/foobar/usr приведёт к тому, что automountd(8) смонтирует экспорт /usr с хоста foobar.

Результат выполнения showmount показывает, что /usr экспортируется. При переходе в каталог /host/foobar/usr, automountd(8) перехватывает запрос и пытается разрешить имя хоста foobar. В случае успеха automountd(8) автоматически монтирует исходный экспорт.

Чтобы включить autofs(5) при загрузке, добавьте следующую строку в /etc/rc.conf:

Затем autofs(5) может быть запущен выполнением:

Формат карты autofs(5) такой же, как и в других операционных системах. Информация об этом формате из других источников может быть полезной, например, из документации Mac OS X.

Обратитесь к справочным страницам automount(8), automountd(8), autounmountd(8) и auto_master(5) для получения дополнительной информации.

Таблица 28.1 обобщает термины и важные процессы, используемые NIS:

В среде NIS существует три типа хостов:

Информация из многих файлов может быть совместно использована с помощью NIS. Файлы master.passwd, group и hosts часто распространяются через NIS. Когда процессу на клиенте требуется информация, которая обычно находится в этих файлах локально, он отправляет запрос к связанному с ним NIS-серверу.

В этом разделе описывается пример среды NIS, состоящей из 15 машин FreeBSD без централизованной точки администрирования. На каждой машине есть свои файлы /etc/passwd и /etc/master.passwd. Эти файлы синхронизируются между собой только вручную. В настоящее время, когда в лабораторию добавляется новый пользователь, этот процесс необходимо повторять на всех 15 машинах.

Конфигурация лаборатории будет следующей:

Если это первый раз, когда разрабатывается схема NIS, её следует тщательно спланировать заранее. Независимо от размера сети, в процессе планирования необходимо принять несколько решений.

Канонические копии всех NIS-файлов хранятся на основном сервере. Базы данных, используемые для хранения информации, называются NIS-картами. В FreeBSD эти карты хранятся в /var/yp/[domainname], где [domainname] — это имя NIS-домена. Поскольку поддерживается несколько доменов, возможно наличие нескольких каталогов, по одному для каждого домена. Каждый домен будет иметь свой независимый набор карт.

Основные и подчинённые серверы NIS обрабатывают все запросы NIS через ypserv(8). Этот демон отвечает за приём входящих запросов от клиентов NIS, преобразование запрошенного домена и имени карты в путь к соответствующему файлу базы данных и передачу данных из базы обратно клиенту.

Настройка основного NIS-сервера может быть относительно простой, в зависимости от потребностей окружения. Поскольку FreeBSD предоставляет встроенную поддержку NIS, её достаточно включить, добавив следующие строки в /etc/rc.conf:

В многосерверном домене, где серверные машины также являются клиентами NIS, необходимо соблюдать осторожность. Обычно рекомендуется принудительно заставлять серверы привязываться к самим себе, а не разрешать им рассылать запросы на привязку и потенциально привязываться друг к другу. Могут возникнуть странные режимы сбоев, если один сервер выйдет из строя, а другие будут зависеть от него. В конечном итоге все клиенты превысят время ожидания и попытаются привязаться к другим серверам, но задержка может быть значительной, а режим сбоя сохранится, поскольку серверы могут снова привязаться друг к другу.

Сервер, который также является клиентом, может быть принудительно привязан к определённому серверу путём добавления следующих строк в /etc/rc.conf:

После сохранения изменений введите /etc/netstart, чтобы перезапустить сеть и применить значения, указанные в /etc/rc.conf. Перед инициализацией карт NIS запустите ypserv(8):

Для настройки подчиненного сервера NIS войдите на подчиненный сервер и отредактируйте /etc/rc.conf, как для основного сервера. Не генерируйте карты NIS, так как они уже существуют на основном сервере. При запуске ypinit на подчиненном сервере используйте -s (для подчиненного) вместо -m (для основного). Эта опция требует указания имени основного сервера NIS в дополнение к имени домена, как показано в этом примере:

Это создаст каталог на подчиненном сервере с именем /var/yp/test-domain, который содержит копии карт основного сервера NIS. Добавление этих записей в /etc/crontab на каждом подчиненном сервере заставит их синхронизировать свои карты с картами на основном сервере:

Эти записи не являются обязательными, поскольку основной сервер автоматически пытается передать любые изменения карт своим подчинённым серверам. Однако, поскольку клиенты могут зависеть от подчинённого сервера для предоставления корректной информации о паролях, рекомендуется принудительно выполнять частые обновления карт паролей. Это особенно важно в загруженных сетях, где обновления карт могут не всегда завершаться.

Для завершения настройки выполните /etc/netstart на подчинённом сервере, чтобы запустить службы NIS.

Клиент NIS связывается с сервером NIS с помощью ypbind(8). Этот демон рассылает RPC-запросы в локальной сети. Эти запросы указывают доменное имя, настроенное на клиенте. Если NIS-сервер в том же домене получает один из таких запросов, он отвечает, и ypbind записывает адрес сервера. Если доступно несколько серверов, клиент будет использовать адрес первого ответившего сервера и направлять все свои NIS-запросы к нему. Клиент автоматически отправляет ping-запросы серверу через регулярные промежутки времени, чтобы убедиться, что он всё ещё доступен. Если ответ не получен в разумные сроки, ypbind пометит домен как несвязанный и снова начнёт рассылку запросов в надежде найти другой сервер.

Для настройки машины FreeBSD в качестве клиента NIS:

Для немедленного запуска клиента NIS выполните следующие команды от имени суперпользователя:

После выполнения этих шагов, выполнение команды ypcat passwd на клиенте должно отобразить карту passwd сервера.

Поскольку RPC — это широковещательный сервис, любая система, запускающая ypbind в том же домене, может получить содержимое NIS-карт. Чтобы предотвратить несанкционированные операции, ypserv(8) поддерживает функцию под названием "securenets", которая может использоваться для ограничения доступа к определённому набору хостов. По умолчанию эта информация хранится в /var/yp/securenets, если только ypserv(8) не запущен с ключом -p и альтернативным путём. Этот файл содержит записи, состоящие из спецификации сети и сетевой маски, разделённых пробелами. Строки, начинающиеся с "#", считаются комментариями. Пример файла securenets может выглядеть так:

Если ypserv(8) получает запрос от адреса, соответствующего одному из этих правил, он обработает запрос как обычно. Если адрес не соответствует ни одному правилу, запрос будет проигнорирован и в журнал будет записано предупреждение. Если файл securenets не существует, ypserv разрешит соединения с любого хоста.

TCP Wrapper — это альтернативный механизм контроля доступа вместо securenets. Хотя оба механизма контроля доступа добавляют некоторый уровень безопасности, они оба уязвимы к атакам "подмены IP". Весь трафик, связанный с NIS, должен блокироваться на межсетевом экране.

Серверы, использующие securenets, могут не обслуживать легитимных клиентов NIS с устаревшими реализациями TCP/IP. Некоторые из этих реализаций устанавливают все биты хоста в ноль при выполнении широковещательных запросов или не учитывают маску подсети при вычислении широковещательного адреса. Хотя некоторые из этих проблем можно устранить, изменив конфигурацию клиента, другие проблемы могут потребовать вывода из эксплуатации этих клиентских систем или отказа от securenets.

Использование TCP Wrapper увеличивает задержку сервера NIS. Дополнительная задержка может быть достаточно длительной, чтобы вызвать таймауты в клиентских программах, особенно в загруженных сетях с медленными серверами NIS. Если один или несколько клиентов страдают от задержек, преобразуйте этих клиентов в подчинённые серверы NIS и заставьте их привязываться к самим себе.

Запрет указанным пользователям возможности входа в отдельные системы становится неэффективным и не масштабируемым в крупных сетях и быстро лишает NIS основного преимущества: централизованного администрирования.

Сетевые группы были разработаны для управления большими и сложными сетями с сотнями пользователей и машин. Их использование аналогично группам в UNIX®, с той основной разницей, что отсутствует числовой идентификатор и есть возможность определять сетевую группу, включая как учётные записи пользователей, так и другие сетевые группы.

Для дополнения примера, используемого в этой главе, домен NIS будет увеличен за счет пользователей и систем, показанным в таблицах 28.2 и 28.3:

При использовании сетевых групп для настройки этого сценария каждый пользователь назначается в одну или несколько сетевых групп, а затем вход разрешается или запрещается для всех членов сетевой группы. При добавлении новой машины необходимо определить ограничения входа для всех сетевых групп. Когда добавляется новый пользователь, его учётная запись должна быть добавлена в одну или несколько сетевых групп. Если настройка NIS выполнена тщательно, для предоставления или запрета доступа к машинам потребуется изменить только один центральный файл конфигурации.

Первым шагом является инициализация NIS netgroup карты. В FreeBSD эта карта не создается по умолчанию. На главном сервере NIS используйте редактор для создания карты с именем /var/yp/netgroup.

Этот пример создает четыре сетевые группы для представления сотрудников IT, стажеров IT, сотрудников и интернов:

Каждая запись настраивает сетевую группу. Первый столбец в записи — это название сетевой группы. Каждый набор скобок представляет либо группу из одного или нескольких пользователей, либо имя другой сетевой группы. При указании пользователя три поля, разделённые запятыми, внутри каждой группы означают:

Если группа содержит нескольких пользователей, разделяйте каждого пользователя пробелом. Кроме того, каждое поле может содержать символы подстановки. Подробности см. в netgroup(5).

Имена сетевых групп длиннее 8 символов не должны использоваться. Имена чувствительны к регистру, и использование заглавных букв для имён сетевых групп — это простой способ отличить имена пользователей, машин и сетевых групп.

Некоторые клиенты NIS, не относящиеся к FreeBSD, не могут обрабатывать сетевые группы, содержащие более 15 записей. Это ограничение можно обойти, создав несколько подгрупп с 15 или менее пользователями и настоящую сетевую группу, состоящую из этих подгрупп, как показано в этом примере:

Повторите этот процесс, если в одной сетевой группе существует более 225 (15 умножить на 15) пользователей.

Для активации и распространения новой NIS-карты:

Это создаст три карты NIS netgroup, netgroup.byhost и netgroup.byuser. Используйте опцию ключа карты в ypcat(1), чтобы проверить доступность новых карт NIS:

Вывод первой команды должен напоминать содержимое файла /var/yp/netgroup. Вторая команда выводит результат только в случае создания специфичных для хоста групп сетей. Третья команда используется для получения списка групп сетей для пользователя.

Для настройки клиента используйте vipw(8), чтобы указать имя сетевой группы. Например, на сервере с именем war замените эту строку:

строкой

Указывает, что только пользователи, определённые в сетевой группе IT_EMP, будут импортированы в базу данных паролей этой системы, и только этим пользователям разрешён вход в систему.

Эта конфигурация также применяется к функции ~ оболочки и всем процедурам, которые преобразуют между именами пользователей и числовыми идентификаторами пользователей. Другими словами, cd ~user не будет работать, ls -l покажет числовой ID вместо имени пользователя, а find . -user joe -print завершится с сообщением No such user. Чтобы исправить это, импортируйте все записи пользователей, не разрешая им вход на серверы. Это можно достичь, добавив дополнительную строку:

Эта строка настраивает клиент на импорт всех записей, но с заменой оболочки в этих записях на /usr/sbin/nologin.

Убедитесь, что дополнительная строка добавлена после +@IT_EMP:::::::::. В противном случае у всех пользовательских учётных записей, импортированных из NIS, будет указана оболочка входа /usr/sbin/nologin, и никто не сможет войти в систему.

Для настройки менее важных серверов замените старые +::::::::: на серверах следующими строками:

Соответствующие строки для рабочих станций будут:

NIS поддерживает создание netgroups из других netgroups, что может быть полезно при изменении политики доступа пользователей. Одна из возможностей — создание ролевых netgroups. Например, можно создать netgroup с именем BIGSRV для определения ограничений входа на важные серверы, другую netgroup SMALLSRV для менее важных серверов и третью netgroup USERBOX для рабочих станций. Каждая из этих netgroups содержит netgroups, которым разрешено входить на эти машины. Новые записи для карты NIS netgroup будут выглядеть так:

Этот метод определения ограничений входа работает достаточно хорошо, когда можно определить группы машин с одинаковыми ограничениями. К сожалению, это скорее исключение, чем правило. В большинстве случаев требуется возможность определять ограничения входа для каждой машины отдельно.

Определения машинно-зависимых сетевых групп — ещё один способ справиться с изменениями политики. В этом сценарии файл /etc/master.passwd на каждой системе содержит две строки, начинающиеся с "+". Первая строка добавляет сетевую группу с учётными записями, которым разрешён вход на эту машину, а вторая строка добавляет все остальные учётные записи с оболочкой /usr/sbin/nologin. Рекомендуется использовать имя сетевой группы в версии "ВСЕ-ЗАГЛАВНЫЕ", соответствующее имени хоста:

После выполнения этой задачи на всех машинах больше не требуется изменять локальные версии файла /etc/master.passwd. Все дальнейшие изменения можно выполнять, редактируя карту NIS. Вот пример возможной карты netgroup для данного сценария:

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

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

Чтобы проверить, какой формат использует сервер или клиент, посмотрите на этот раздел в /etc/login.conf:

В этом примере система использует формат DES для хеширования паролей. Другие возможные значения включают blf для Blowfish, md5 для MD5, sha256 и sha512 для SHA-256 и SHA-512 соответственно. Для получения дополнительной информации и актуального списка доступных вариантов на вашей системе обратитесь к crypt(3).

Если формат на хосте необходимо изменить, чтобы он соответствовал формату, используемому в домене NIS, базу данных возможностей входа необходимо перестроить после сохранения изменений:

LDAP использует несколько терминов, которые следует понять перед началом настройки. Все записи каталога состоят из группы атрибутов. Каждый из этих наборов атрибутов содержит уникальный идентификатор, известный как Отличительное имя (DN — Distinguished Name), который обычно строится из нескольких других атрибутов, таких как общее имя или Относительное отличительное имя (RDN — Relative Distinguished Name). Подобно тому, как каталоги имеют абсолютные и относительные пути, можно рассматривать DN как абсолютный путь, а RDN — как относительный путь.

Пример записи LDAP выглядит следующим образом. В этом примере выполняется поиск записи для указанной учетной записи пользователя (uid), организационного подразделения (ou) и организации (o):

Этот пример записи показывает значения атрибутов dn, mail, cn, uid и telephoneNumber. Атрибут cn является RDN.

Дополнительная информация о LDAP и его терминологии доступна по адресу http://www.openldap.org/doc/admin24/intro.html.

FreeBSD не предоставляет встроенный LDAP-сервер. Начните настройку с установки пакета net/openldap-server или порта:

В пакете включен большой набор параметров по умолчанию. Их можно просмотреть, выполнив команду pkg info openldap-server. Если их недостаточно (например, требуется поддержка SQL), рекомендуется перекомпилировать порт с использованием соответствующего фреймворка.

Установка создает каталог /var/db/openldap-data для хранения данных. Необходимо создать каталог для хранения сертификатов:

Следующий этап — настройка Центра Сертификации. Следующие команды должны быть выполнены из директории /usr/local/etc/openldap/private. Это важно, так как права доступа к файлам должны быть строгими, и пользователи не должны иметь доступ к этим файлам. Более подробную информацию о сертификатах и их параметрах можно найти в OpenSSL. Чтобы создать Центр Сертификации, начните с этой команды и следуйте инструкциям:

Записи для запросов могут быть любыми, за исключением Common Name. Эта запись должна отличаться от имени хоста системы. Если это будет самоподписанный сертификат, добавьте к имени хоста префикс CA — как Центр Сертификации.

Следующая задача — создать запрос на подпись сертификата и закрытый ключ. Введите эту команду и следуйте инструкциям:

В процессе генерации сертификата обязательно правильно укажите атрибут Common Name. Запрос на подпись сертификата (Certificate Signing Request) должен быть подписан Центром сертификации, чтобы использоваться в качестве действительного сертификата:

Заключительная часть процесса генерации сертификатов — создание и подписание клиентских сертификатов:

Помните, что нужно использовать тот же атрибут Common Name при запросе. По завершении убедитесь, что в результате выполнения команд было создано в общей сложности восемь (8) новых файлов.

Демон, запускающий сервер OpenLDAP, называется slapd. Его настройка выполняется через файл slapd.ldif: старый файл slapd.conf больше не используется в OpenLDAP.

Есть примеры конфигурации для slapd.ldif доступны, и также их можно найти в /usr/local/etc/openldap/slapd.ldif.sample. Документация параметров в slapd-config(5). Каждый раздел slapd.ldif, как и все другие наборы атрибутов LDAP, однозначно идентифицируется через DN. Убедитесь, что между строкой dn: и желаемым концом раздела нет пустых строк. В следующем примере TLS будет использоваться для настройки безопасного канала. Первый раздел представляет глобальную конфигурацию:

Здесь необходимо указать файлы Центра сертификации, сертификата сервера и закрытого ключа сервера. Рекомендуется позволить клиентам выбирать алгоритм шифрования и опустить опцию olcTLSCipherSuite (несовместимо с TLS-клиентами, кроме openssl). Опция olcTLSProtocolMin позволяет серверу требовать минимальный уровень безопасности: это рекомендуется. Хотя проверка обязательна для сервера, для клиента она не требуется: olcTLSVerifyClient: never.

Второй раздел посвящен серверным модулям и может быть настроен следующим образом:

Третий раздел посвящён загрузке необходимых схем ldif для использования базами данных: они являются важными.

Далее, раздел конфигурации фронтенда (уровня взаимодействия с клиентами):

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

Имя администратора по умолчанию — cn=config. Введите slappasswd в оболочке, выберите пароль и используйте его хеш в olcRootPW. Если этот параметр не указан сейчас, до импорта slapd.ldif, никто не сможет впоследствии изменить раздел глобальной конфигурации.

Последний раздел посвящен бэкенду базы данных (уровню хранения данных):

Эта база данных содержит фактическое содержимое каталога LDAP. Доступны типы, отличные от mdb. Суперпользователь (не путать с глобальным) настраивается здесь: (возможно, пользовательское) имя пользователя в olcRootDN и хэш пароля в olcRootPW; slappasswd можно использовать, как и раньше.

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

После завершения настройки файл slapd.ldif должен быть скопирован в пустую директорию. Рекомендуется создать её следующим образом:

Импорт базы данных конфигурации:

Запустите демон slapd:

Опция -d может использоваться для отладки, как указано в slapd(8). Чтобы проверить, что сервер запущен и работает:

Сервер по-прежнему должен быть доверенным. Если это никогда не делалось ранее, следуйте этим инструкциям. Установите пакет или порт OpenSSL:

Из каталога, где находится ca.crt (в данном примере, /usr/local/etc/openldap), выполните:

И сертификат центра сертификации, и сертификат сервера теперь правильно распознаются в своих соответствующих ролях. Чтобы проверить это, выполните следующую команду из директории, где находится server.crt:

Если slapd был запущен, перезапустите его. Как указано в /usr/local/etc/rc.d/slapd, для корректного запуска slapd при загрузке следующие строки должны быть добавлены в /etc/rc.conf:

slapd не предоставляет отладку при загрузке. Для этой цели проверьте /var/log/debug.log, dmesg -a и /var/log/messages.

Следующий пример добавляет группу team и пользователя john в базу данных LDAP domain.example, которая пока пуста. Сначала создайте файл domain.ldif:

См. документацию OpenLDAP для получения более подробной информации. Используйте slappasswd для замены пароля в открытом тексте secret на хеш в userPassword. Путь, указанный как loginShell, должен существовать во всех системах, где john имеет право входить. Наконец, используйте администратора mdb для изменения базы данных:

Изменения в разделе глобальной конфигурации могут выполняться только глобальным суперпользователем. Например, предположим, что изначально была указана опция olcTLSCipherSuite: HIGH:MEDIUM:SSLv3, которую теперь необходимо удалить. Сначала создайте файл, содержащий следующее:

Затем примените изменения:

При запросе введите пароль, выбранный в разделе бекенда конфигурации. Имя пользователя не требуется: здесь cn=config представляет DN раздела базы данных, который нужно изменить. Альтернативно, используйте ldapmodify для удаления отдельной строки базы данных или ldapdelete для удаления всей записи.

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

slapd.ldif затем можно отредактировать и снова импортировать. Пожалуйста, следуйте этой процедуре только в том случае, если нет другого доступного решения.

Это конфигурация только сервера. На той же машине также может быть размещен LDAP-клиент с собственной отдельной конфигурацией.

Поддержка DHCP-клиента включена в установщик FreeBSD, что позволяет легко настроить новую систему для автоматического получения сетевой адресации от существующего DHCP-сервера. Примеры настройки сети можно найти в разделе Учетные записи, Часовая зона, Службы и Защита.

Когда dhclient выполняется на клиентской машине, он начинает транслировать запросы на получение конфигурационной информации. По умолчанию эти запросы используют UDP-порт 68. Сервер отвечает на UDP-порту 67, предоставляя клиенту IP-адрес и другую соответствующую сетевую информацию, такую как маска подсети, шлюз по умолчанию и адреса DNS-серверов. Эта информация предоставляется в форме "аренды" DHCP и действительна в течение настраиваемого времени. Это позволяет автоматически повторно использовать устаревшие IP-адреса для клиентов, которые больше не подключены к сети. Клиенты DHCP могут получить от сервера большое количество информации. Полный список можно найти в dhcp-options(5).

По умолчанию, при загрузке системы FreeBSD её DHCP-клиент работает в фоновом режиме или асинхронно. Другие скрипты запуска продолжают выполняться, пока завершается процесс DHCP, что ускоряет загрузку системы.

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

Эта строка в /etc/rc.conf используется для настройки фонового или асинхронного режима:

Эта строка может уже существовать, если система была настроена на использование DHCP во время установки. Замените fxp0, указанный в этих примерах, на имя интерфейса, который нужно настроить динамически, как описано в Настройка сетевых интерфейсов.

Для настройки системы на использование синхронного режима с приостановкой во время запуска до завершения DHCP используйте “SYNCDHCP”:

Есть еще несколько опций клиента. Подробности смотрите в rc.conf(5), выполнив поиск по dhclient.

Клиент DHCP использует следующие файлы:

В этом разделе показано, как настроить систему FreeBSD в качестве DHCP-сервера с использованием реализации DHCP-сервера от Консорциума Интернет-систем (ISC —Internet Systems Consortium). Эту реализацию и её документацию можно установить с помощью пакета net/isc-dhcp44-server или порта.

Установка пакета net/isc-dhcp44-server включает образец файла конфигурации. Скопируйте /usr/local/etc/dhcpd.conf.example в /usr/local/etc/dhcpd.conf и внесите необходимые изменения в этот новый файл.

Файл конфигурации состоит из объявлений для подсетей и хостов, которые определяют информацию, предоставляемую клиентам DHCP. Например, следующие строки настраивают следующее:

Этот файл конфигурации поддерживает гораздо больше опций. Подробности и примеры смотрите в dhcpd.conf(5), который устанавливается вместе с сервером.

После завершения настройки dhcpd.conf включите DHCP-сервер в /etc/rc.conf:

Замените dc0 на интерфейс (или интерфейсы, разделенные пробелами), на котором DHCP-сервер должен ожидать запросы от DHCP-клиентов.

Запустите сервер, выполнив следующую команду:

Любые последующие изменения конфигурации сервера потребуют остановки и последующего запуска службы dhcpd с помощью service(8).

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

Серверы имен обычно бывают двух видов: авторитетные DNS-серверы и кэширующие DNS-серверы (также известные как резолвинг-серверы).

Авторитетный сервер имен необходим, когда:

Кэширующий сервер имен необходим, когда:

Когда кто-нибудь запрашивает информацию о www.FreeBSD.org, резолвер обычно обращается к серверу имен провайдера и получает ответ. При использовании локального кэширующего DNS-сервера запрос во внешний мир выполняется только один раз этим сервером. Дополнительные запросы не будут выходить за пределы локальной сети, так как информация сохраняется в локальном кэше.

Unbound включён в базовую систему FreeBSD. По умолчанию он предоставляет разрешение DNS только для локальной машины. Хотя пакет базовой системы можно настроить для предоставления служб разрешения за пределами локальной машины, рекомендуется удовлетворять такие требования путём установки Unbound из коллекции портов FreeBSD.

Чтобы включить Unbound, добавьте следующую строку в /etc/rc.conf:

Любые существующие серверы имен в /etc/resolv.conf будут настроены как серверы пересылки в новой конфигурации Unbound.

После подтверждения поддержки DNSSEC каждым сервером имен, запустите Unbound:

Это обеспечит обновление /etc/resolv.conf, чтобы запросы к доменам, защищённым DNSSEC, теперь работали. Например, выполните следующую команду для проверки дерева доверия DNSSEC FreeBSD.org:

FreeBSD не предоставляет программное обеспечение авторитетного сервера имен в базовой системе. Пользователям рекомендуется устанавливать сторонние приложения, такие как dns/nsd или dns/bind918 из пакетов или портов.

Одной из популярных реализаций zeroconf является Avahi. Avahi можно установить и настроить с помощью следующих команд:

В FreeBSD основной файл конфигурации сервера Apache HTTP Server устанавливается как /usr/local/etc/apache2x/httpd.conf, где x обозначает номер версии. Этот текстовый файл в формате ASCII начинается со строк комментариев, обозначенных символом #. Наиболее часто изменяемые директивы:

Всегда рекомендуется создать резервную копию конфигурационного файла Apache по умолчанию перед внесением изменений. После завершения настройки Apache сохраните файл и проверьте конфигурацию с помощью apachectl. Запуск команды apachectl configtest должен вернуть Syntax OK.

Чтобы запускать Apache при загрузке системы, добавьте следующую строку в /etc/rc.conf:

Если Apache должен запускаться с нестандартными параметрами, следующую строку можно добавить в /etc/rc.conf для указания необходимых флагов:

Если apachectl не сообщает об ошибках конфигурации, то запустите httpd:

Службу httpd можно проверить, введя http://localhost в веб-браузере, заменив localhost на полное доменное имя машины, на которой работает httpd. Отображаемая веб-страница по умолчанию находится в /usr/local/www/apache24/data/index.html.

Проверить конфигурацию Apache на наличие ошибок после внесения последующих изменений в конфигурацию во время работы httpd можно с помощью следующей команды:

Виртуальный хостинг позволяет запускать несколько веб-сайтов на одном сервере Apache. Виртуальные хосты могут быть IP-ориентированными или имя-ориентированными. IP-ориентированный виртуальный хостинг использует разные IP-адреса для каждого сайта. Имя-ориентированный виртуальный хостинг использует заголовки HTTP/1.1 клиента для определения имени хоста, что позволяет сайтам использовать один и тот же IP-адрес.

Для настройки Apache с использованием виртуального хоста на основе имен добавьте блок VirtualHost для каждого веб-сайта. Например, для веб-сервера с именем www.domain.tld и виртуальным доменом www.someotherdomain.tld добавьте следующие записи в httpd.conf:

Для каждого виртуального хоста замените значения ServerName и DocumentRoot на те, которые должны использоваться.

Для получения дополнительной информации о настройке виртуальных хостов обратитесь к официальной документации Apache по адресу: http://httpd.apache.org/docs/vhosts/.

Apache использует модули для расширения функциональности, предоставляемой базовым сервером. Обратитесь к http://httpd.apache.org/docs/current/mod/ для получения полного списка и деталей настройки доступных модулей.

В FreeBSD некоторые модули могут быть скомпилированы с портом www/apache24. Введите make config в /usr/ports/www/apache24, чтобы увидеть, какие модули доступны и какие включены по умолчанию. Если модуль не скомпилирован с портом, коллекция портов FreeBSD предоставляет простой способ установки многих модулей. В этом разделе описаны три наиболее часто используемых модуля.

В дополнение к mod_perl и mod_php, доступны другие языки для создания динамического веб-содержимого. Среди них Django и Ruby on Rails.

Самый важный этап настройки — определение учётных записей, которым будет разрешён доступ к FTP-серверу. В системе FreeBSD существует ряд системных учётных записей, которым не следует разрешать доступ по FTP. Список пользователей, которым запрещён любой доступ по FTP, можно найти в /etc/ftpusers. По умолчанию в него включены системные учётные записи. Можно добавить дополнительных пользователей, которым не следует разрешать доступ к FTP.

В некоторых случаях может быть желательно ограничить доступ некоторых пользователей, не запрещая им полностью использовать FTP. Это можно сделать, создав файл /etc/ftpchroot, как описано в ftpchroot(5). В этом файле перечислены пользователи и группы, подлежащие ограничениям доступа к FTP.

Для обеспечения анонимного доступа по FTP к серверу создайте пользователя с именем ftp в системе FreeBSD. Пользователи смогут входить на FTP-сервер под именем ftp или anonymous. При запросе пароля будет принят любой ввод, но по соглашению в качестве пароля следует использовать адрес электронной почты. FTP-сервер вызовет chroot(2) при входе анонимного пользователя, чтобы ограничить доступ только домашним каталогом пользователя ftp.

Существуют два текстовых файла, которые можно создать для отображения приветственных сообщений клиентам FTP. Содержимое файла /etc/ftpwelcome будет показано пользователям до появления запроса на вход. После успешного входа будет отображено содержимое файла /etc/ftpmotd. Обратите внимание, что путь к этому файлу указывается относительно окружения входа, поэтому для анонимных пользователей будет отображаться содержимое файла ~ftp/etc/ftpmotd.

После настройки FTP-сервера установите соответствующую переменную в /etc/rc.conf, чтобы служба запускалась при загрузке:

Чтобы запустить службу сейчас:

Протестируйте подключение к FTP-серверу, набрав:

Демон ftpd использует syslog(3) для записи сообщений. По умолчанию, демон системного журнала записывает сообщения, связанные с FTP, в /var/log/xferlog. Местоположение журнала FTP может быть изменено путём редактирования следующей строки в /etc/syslog.conf:

Samba настраивается в файле /usr/local/etc/smb4.conf. Этот файл должен быть создан до начала использования Samba.

Простой пример smb4.conf для общего доступа к каталогам и принтерам с клиентами Windows® в рабочей группе показан ниже. Для более сложных настроек, включающих LDAP или Active Directory, проще использовать samba-tool(8) для создания начального smb4.conf.

Чтобы включить Samba при загрузке, добавьте следующую строку в /etc/rc.conf:

Чтобы сейчас запустить Samba:

Samba состоит из трёх отдельных демонов. Оба демона nmbd и smbd запускаются параметром samba_enable. Если также требуется разрешение имён через winbind, укажите:

Samba можно остановить в любой момент, набрав:

Samba — это комплексный программный комплект, функциональность которого обеспечивает широкую интеграцию с сетями Microsoft® Windows®. Для получения дополнительной информации о возможностях, выходящих за рамки базовой конфигурации, описанной здесь, обратитесь к https://www.samba.org.

На FreeBSD встроенный ntpd может использоваться для синхронизации системных часов. Настройка ntpd осуществляется с помощью переменных rc.conf(5) и файла /etc/ntp.conf, как подробно описано в следующих разделах.

ntpd взаимодействует с сетевыми узлами с помощью UDP-пакетов. Любые межсетевые экраны между вашей машиной и её NTP-узлами должны быть настроены так, чтобы разрешать входящие и исходящие UDP-пакеты через порт 123.

ntpd не требует постоянного подключения к Интернету для корректной работы. Однако, если PPP-соединение настроено на дозвон по требованию, следует предотвратить инициацию дозвона или поддержание соединения из-за трафика NTP. Это можно настроить с помощью директив filter в /etc/ppp/ppp.conf. Например:

Для получения более подробной информации обратитесь к разделу ФИЛЬТРАЦИЯ ПАКЕТОВ в ppp(8) и примерам в /usr/share/examples/ppp/.

Для настройки цели iSCSI создайте конфигурационный файл /etc/ctl.conf, добавьте строку в /etc/rc.conf, чтобы убедиться, что демон ctld(8) автоматически запускается при загрузке, а затем запустите демон.

Вот пример простого файла конфигурации /etc/ctl.conf. Полное описание доступных опций этого файла можно найти в ctl.conf(5).

Первая запись определяет группу порталов pg0. Группы порталов определяют, на каких сетевых адресах будет слушать демон ctld(8). Запись discovery-auth-group no-authentication указывает, что любой инициатор может выполнять обнаружение целей iSCSI без аутентификации. Третья и четвёртая строки настраивают ctld(8) для прослушивания всех IPv4-адресов (listen 0.0.0.0) и IPv6-адресов (listen [::]) на стандартном порту 3260.

Нет необходимости определять группу порталов, так как существует встроенная группа порталов с именем default. В этом случае разница между default и pg0 заключается в том, что для default обнаружение целей всегда запрещено, а для pg0 — всегда разрешено.

Вторая запись определяет одну цель. У цели есть два возможных значения: машина, обслуживающая iSCSI, или именованная группа LUN. В этом примере используется второе значение, где iqn.2012-06.com.example:target0 — это имя цели. Это имя цели подходит для тестирования. Для реального использования замените com.example на настоящий домен, записанный в обратном порядке. 2012-06 представляет год и месяц получения контроля над этим доменом, а target0 может быть любым значением. В этом файле конфигурации можно определить любое количество целей.

Строка auth-group no-authentication разрешает всем инициаторам подключаться к указанной цели, а portal-group pg0 делает цель доступной через группу порталов pg0.

Следующий раздел определяет LUN. Для инициатора каждый LUN будет виден как отдельное дисковое устройство. Для каждой цели можно определить несколько LUN. Каждый LUN идентифицируется числом, где LUN 0 является обязательным. Строка path /data/target0-0 определяет полный путь к файлу или zvol, который используется для LUN. Этот путь должен существовать до запуска ctld(8). Вторая строка необязательна и указывает размер LUN.

Далее, чтобы убедиться, что демон ctld(8) запускается при загрузке, добавьте эту строку в /etc/rc.conf:

Чтобы запустить ctld(8) сейчас, выполните следующую команду:

Поскольку демон ctld(8) запускается, он читает файл /etc/ctl.conf. Если этот файл был изменён после запуска демона, используйте следующую команду, чтобы изменения вступили в силу немедленно:

Инициатору iSCSI требуется, чтобы демон iscsid(8) был запущен. Этот демон не использует файл конфигурации. Для его автоматического запуска при загрузке добавьте следующую строку в /etc/rc.conf:

Чтобы сейчас запустить iscsid(8), выполните следующую команду:

Подключение к цели может быть выполнено с файлом конфигурации /etc/iscsi.conf или без него. В этом разделе показаны оба типа подключений.