--- description: 'Эта глава рассказывает о некоторых из наиболее часто используемых сетевых служб в системах UNIX' next: books/handbook/firewalls params: path: /books/handbook/network-servers/ part: 'IV. Сетевое взаимодействие' prev: books/handbook/mail showBookMenu: 'true' tags: ["network", "servers", "inetd", "NFS", "NIS", "LDAP", "DHCP", "DNS", "Apache HTTP", "FTP", "Samba", "NTP", "iSCSI"] title: 'Глава 32. Сетевые серверы' weight: 37 --- [[network-servers]] = Сетевые серверы :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 32 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/network-servers/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[network-servers-synopsis]] == Обзор В этой главе рассматриваются некоторые из наиболее часто используемых сетевых служб в системах UNIX(R). Сюда входит установка, настройка, тестирование и поддержка различных типов сетевых служб. В этой главе приведены примеры конфигурационных файлов для справки. К концу этой главы читатели будут знать: * Как управлять демоном inetd. * Как настроить Network File System (NFS). * Как настроить сервер сетевой информации (NIS) для централизации и совместного использования учётных записей пользователей. * Как настроить FreeBSD в качестве сервера или клиента LDAP * Как настроить автоматические параметры сети с использованием DHCP. * Как настроить сервер доменных имён (DNS). * Как настроить веб-сервер Apache HTTP. * Как настроить сервер протокола передачи файлов (FTP). * Как настроить файловый и печатный сервер для клиентов Windows(R) с использованием Samba. * Как синхронизировать время и дату, а также настроить сервер времени с использованием протокола Network Time Protocol (NTP). * Как настроить iSCSI. Эта глава предполагает базовые знания о: * Скриптах [.filename]#/etc/rc#. * Сетевой терминологии. * Установке дополнительного стороннего программного обеспечения (crossref:ports[ports,Установка приложений: Пакеты и Порты]). [[network-inetd]] == Суперсервер inetd Демон man:inetd[8] иногда называют суперсервером, потому что он управляет соединениями для многих служб. Вместо запуска множества приложений, достаточно запустить только службу inetd. Когда поступает соединение для службы, управляемой inetd, он определяет, какому программе предназначено соединение, создает процесс для этой программы и делегирует программе сокет. Использование inetd для служб, которые не используются интенсивно, может снизить нагрузку на систему по сравнению с запуском каждого демона отдельно в автономном режиме. Прежде всего, inetd используется для запуска других демонов, но несколько простых протоколов обрабатываются внутри него, таких как chargen, auth, time, echo, discard и daytime. Этот раздел охватывает основы настройки inetd. [[network-inetd-conf]] === Файл конфигурации Настройка inetd выполняется путем редактирования [.filename]#/etc/inetd.conf#. Каждая строка этого файла конфигурации представляет приложение, которое может быть запущено inetd. По умолчанию каждая строка начинается с комментария (`+#+`), что означает, что inetd не ожидает подключений для каких-либо приложений. Чтобы настроить inetd на ожидание подключений для приложения, удалите `+#+` в начале соответствующей строки. После сохранения изменений настройте inetd для запуска при загрузке системы, отредактировав [.filename]#/etc/rc.conf#: [.programlisting] .... inetd_enable="YES" .... Чтобы запустить inetd сейчас, чтобы он начал прослушивать настроенную службу, введите: [source, shell] .... # service inetd start .... После запуска inetd необходимо уведомлять его о каждом изменении в файле [.filename]#/etc/inetd.conf#: [[network-inetd-reread]] .Перезагрузка конфигурационного файла inetd [example] ==== [source, shell] .... # service inetd reload .... ==== Обычно запись по умолчанию для приложения не требует редактирования, кроме удаления `+#+`. В некоторых ситуациях может быть целесообразно изменить запись по умолчанию. В качестве примера, это стандартная запись для man:ftpd[8] по IPv4: [.programlisting] .... ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l .... Семь столбцов в записи следующие: [.programlisting] .... service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments .... где: service-name:: Имя службы демона для запуска. Оно должно соответствовать службе, указанной в [.filename]#/etc/services#. Это определяет, на каком порту inetd ожидает входящие соединения для этой службы. При использовании пользовательской службы она сначала должна быть добавлена в [.filename]#/etc/services#. socket-type:: Либо `stream`, `dgram`, `raw`, или `seqpacket`. Используйте `stream` для TCP-соединений и `dgram` для UDP-сервисов. protocol:: Используйте одно из следующих названий протоколов: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Имя протокола | Объяснение |tcp или tcp4 |TCP IPv4 |udp или udp4 |UDP IPv4 |tcp6 |TCP IPv6 |udp6 |UDP IPv6 |tcp46 |Как TCP IPv4, так и IPv6 |udp46 |Как UDP IPv4, так и IPv6 |=== {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]:: В этом поле необходимо указать `wait` или `nowait`. Параметры `max-child`, `max-connections-per-ip-per-minute` и `max-child-per-ip` являются необязательными. + `wait|nowait` указывает, способна ли служба обрабатывать свой собственный сокет. Типы сокетов `dgram` должны использовать `wait`, в то время как для демонов `stream`, которые обычно многопоточные, следует использовать `nowait`. `wait` обычно передаёт несколько сокетов одному демону, тогда как `nowait` создаёт дочерний демон для каждого нового сокета. + Максимальное количество дочерних демонов, которые может породить inetd, задается параметром `max-child`. Например, чтобы ограничить десять экземпляров демона, укажите `/10` после `nowait`. Указание `/0` позволяет создавать неограниченное количество дочерних процессов. + `max-connections-per-ip-per-minute` ограничивает количество соединений с любого конкретного IP-адреса в минуту. Как только лимит достигнут, последующие соединения с этого IP-адреса будут отбрасываться до конца минуты. Например, значение `/10` ограничивает любой конкретный IP-адрес десятью попытками соединения в минуту. `max-child-per-ip` ограничивает количество дочерних процессов, которые могут быть запущены от имени любого отдельного IP-адреса в любой момент времени. Эти опции позволяют ограничить чрезмерное потребление ресурсов и помогают предотвратить атаки типа "Отказ в обслуживании". + Пример можно увидеть в настройках по умолчанию для man:fingerd[8]: + [.programlisting] .... finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -k -s .... user:: Имя пользователя, от имени которого будет работать демон. Демоны обычно работают от имени `root`, `daemon` или `nobody`. server-program:: Полный путь к демону. Если демон является службой, предоставляемой inetd внутренне, используйте `internal`. server-program-arguments:: Используется для указания любых аргументов командной строки, передаваемых демону при его запуске. Если демон является внутренней службой, используйте `internal`. [[network-inetd-cmdline]] === Параметры командной строки Как и большинство серверных демонов, inetd имеет ряд опций, которые можно использовать для изменения его поведения. По умолчанию inetd запускается с параметрами `-wW -C 60`. Эти опции включают TCP wrappers для всех сервисов, включая внутренние, и предотвращают запросы любого IP-адреса к любому сервису чаще 60 раз в минуту. Для изменения параметров по умолчанию, передаваемых inetd, добавьте запись `inetd_flags` в файл [.filename]#/etc/rc.conf#. Если inetd уже запущен, перезапустите его командой `service inetd restart`. Доступные варианты ограничения скорости: -c maximum:: Укажите максимальное количество одновременных вызовов каждой службы по умолчанию, где по умолчанию значение не ограничено. Может быть переопределено для каждой службы отдельно с помощью параметра `max-child` в [.filename]#/etc/inetd.conf#. -C rate:: Укажите максимальное количество вызовов службы с одного IP-адреса в минуту по умолчанию. Это значение может быть переопределено для отдельной службы с помощью параметра `max-connections-per-ip-per-minute` в файле [.filename]#/etc/inetd.conf#. -R rate:: Укажите максимальное количество вызовов службы в течение одной минуты, где значение по умолчанию — `256`. Значение `0` позволяет неограниченное количество. -s maximum:: Укажите максимальное количество раз, которое служба может быть вызвана с одного IP-адреса одновременно, по умолчанию значение не ограничено. Может быть переопределено для каждой службы отдельно с помощью параметра `max-child-per-ip` в [.filename]#/etc/inetd.conf#. Доступны дополнительные параметры. Полный список параметров смотрите в man:inetd[8]. [[network-inetd-security]] === Безопасность Многие демоны, которыми может управлять inetd, не обладают достаточной защитой. Некоторые демоны, такие как fingerd, могут предоставлять информацию, полезную для злоумышленника. Включайте только необходимые службы и отслеживайте систему на предмет чрезмерных попыток подключения. Параметры `max-connections-per-ip-per-minute`, `max-child` и `max-child-per-ip` могут быть использованы для ограничения подобных атак. По умолчанию TCP wrappers включены. Дополнительную информацию о наложении TCP-ограничений на различные демоны, запускаемые через inetd, можно найти в man:hosts_access[5]. [[network-nfs]] == Сетевая файловая система (NFS — Network File System) FreeBSD поддерживает Network File System (NFS), что позволяет серверу делиться каталогами и файлами с клиентами по сети. С помощью NFS пользователи и программы могут обращаться к файлам на удалённых системах так, как если бы они хранились локально. NFS имеет множество практических применений. Некоторые из наиболее распространённых вариантов использования включают: * Данные, которые в противном случае дублировались бы на каждом клиенте, могут храниться в одном месте и быть доступными для клиентов в сети. * Несколько клиентов могут нуждаться в доступе к каталогу [.filename]#/usr/ports/distfiles#. Общий доступ к этому каталогу позволяет быстро получить исходные файлы без необходимости загрузки их на каждый клиент. * На крупных сетях часто удобнее настроить центральный NFS-сервер, на котором хранятся все домашние каталоги пользователей. Пользователи могут входить в систему с любого клиента в сети и получать доступ к своим домашним каталогам. * Управление экспортом NFS упрощено. Например, существует только одна файловая система, в которой необходимо настраивать политики безопасности или резервного копирования. * Съемные устройства хранения данных могут использоваться другими компьютерами в сети. Это уменьшает количество устройств в сети и обеспечивает централизованное управление их безопасностью. Часто бывает удобнее устанавливать программное обеспечение на несколько компьютеров с централизованного носителя для установки. NFS состоит из сервера и одного или нескольких клиентов. Клиент удалённо получает доступ к данным, хранящимся на машине сервера. Для корректной работы необходимо настроить и запустить несколько процессов. Эти демоны должны быть запущены на сервере: [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Демон | Описание |nfsd |Демон NFS, обслуживающий запросы от клиентов NFS. |mountd |Демон монтирования NFS, который выполняет запросы, полученные от nfsd. |rpcbind | Этот демон позволяет клиентам NFS определять, какой порт использует сервер NFS. |=== Запуск man:nfsiod[8] на клиенте может повысить производительность, но не является обязательным. [[network-configuring-nfs]] === Настройка сервера Файловые системы, которые сервер NFS будет предоставлять в общий доступ, указаны в [.filename]#/etc/exports#. Каждая строка в этом файле определяет файловую систему для экспорта, клиентов, которые имеют доступ к этой файловой системе, и любые параметры доступа. При добавлении записей в этот файл каждая экспортируемая файловая система, её свойства и разрешённые хосты должны быть указаны в одной строке. Если в записи не указаны клиенты, то любой клиент в сети может подключить эту файловую систему. Следующие записи в [.filename]#/etc/exports# демонстрируют, как экспортировать файловые системы. Примеры могут быть изменены в соответствии с файловыми системами и именами клиентов в сети читателя. В этом файле можно использовать множество опций, но здесь упомянуты лишь некоторые. Полный список опций смотрите в man:exports[5]. В этом примере показано, как экспортировать [.filename]#/media# на три хоста с именами _alpha_, _bravo_ и _charlie_: [.programlisting] .... /media -ro alpha bravo charlie .... Флаг `-ro` делает файловую систему доступной только для чтения, предотвращая внесение клиентами изменений в экспортированную файловую систему. В этом примере предполагается, что имена хостов находятся либо в DNS, либо в [.filename]#/etc/hosts#. Обратитесь к man:hosts[5], если в сети нет DNS-сервера. Следующий пример экспортирует [.filename]#/home# трём клиентам по IP-адресу. Это может быть полезно для сетей без DNS или записей в [.filename]#/etc/hosts#. Флаг `-alldirs` позволяет подкаталогам быть точками монтирования. Другими словами, он не будет автоматически монтировать подкаталоги, но разрешит клиенту монтировать необходимые каталоги по мере надобности. [.programlisting] .... /usr/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 .... Следующий пример экспортирует [.filename]#/a#, чтобы два клиента из разных доменов могли получить доступ к этой файловой системе. Параметр `-maproot=root` позволяет пользователю `root` на удалённой системе записывать данные в экспортированную файловую систему как `root`. Если параметр `-maproot=root` не указан, пользователь `root` на клиенте будет отображён на учётную запись `nobody` на сервере и будет ограничен правами доступа, определёнными для `nobody`. [.programlisting] .... /a -maproot=root host.example.com box.example.org .... Клиент может быть указан только один раз для каждой файловой системы. Например, если [.filename]#/usr# представляет собой одну файловую систему, следующие записи будут недопустимыми, так как обе указывают на один и тот же узел: [.programlisting] .... # Invalid when /usr is one file system /usr/src client /usr/ports client .... Правильный формат для данной ситуации — использовать одну запись: [.programlisting] .... /usr/src /usr/ports client .... Ниже приведён пример корректного списка экспорта, где [.filename]#/usr# и [.filename]#/exports# являются локальными файловыми системами: [.programlisting] .... # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro .... Чтобы включить процессы, необходимые для работы сервера NFS при загрузке, добавьте следующие параметры в [.filename]#/etc/rc.conf#: [.programlisting] .... rpcbind_enable="YES" nfs_server_enable="YES" mountd_enable="YES" .... Сервер можно запустить, выполнив следующую команду: [source, shell] .... # service nfsd start .... Всякий раз, когда запускается сервер NFS, также автоматически запускается mountd. Однако mountd читает [.filename]#/etc/exports# только при запуске. Чтобы последующие изменения в [.filename]#/etc/exports# вступили в силу немедленно, заставьте mountd перечитать его: [source, shell] .... # service mountd reload .... Обратитесь к man:zfs-share[8] для описания экспорта наборов данных ZFS через NFS с использованием свойства ZFS `sharenfs` вместо файла man:exports[5]. Обратитесь к man:nfsv4[4] для описания настройки NFS версии 4. === Настройка клиента Чтобы включить клиенты NFS, установите эту опцию в файле [.filename]#/etc/rc.conf# каждого клиента: [.programlisting] .... nfs_client_enable="YES" .... Затем выполните эту команду на каждом клиенте NFS: [source, shell] .... # service nfsclient start .... Клиент теперь имеет всё необходимое для монтирования удалённой файловой системы. В этих примерах имя сервера — `server`, а имя клиента — `client`. Чтобы смонтировать [.filename]#/home# с сервера `server` в точку монтирования [.filename]#/mnt# на клиенте `client`: [source, shell] .... # mount server:/home /mnt .... Файлы и каталоги в [.filename]#/home# теперь будут доступны на `client`, в каталоге [.filename]#/mnt#. Для монтирования удаленной файловой системы при каждой загрузке клиента добавьте её в [.filename]#/etc/fstab#: [.programlisting] .... server:/home /mnt nfs rw 0 0 .... Обратитесь к man:fstab[5] для описания всех доступных опций. === Блокировка Некоторые приложения требуют блокировки файлов для корректной работы. Чтобы включить блокировку, выполните следующую команду как на клиенте, так и на сервере: [source, shell] .... # sysrc rpc_lockd_enable="YES" .... Затем запустите службу man:rpc.lockd[8]: [source, shell] .... # service lockd start .... Если блокировка не требуется на сервере, клиент NFS можно настроить для локальной блокировки, добавив параметр `-L` при выполнении команды mount. Дополнительные сведения см. в man:mount_nfs[8]. [[network-autofs]] === Автоматизация монтирования с помощью man:autofs[5] [NOTE] ==== Автомонтирование man:autofs[5] поддерживается начиная с FreeBSD 10.1-RELEASE. Для использования функциональности автомонтирования в более старых версиях FreeBSD используйте man:amd[8]. В этой главе описывается только автомонтирование man:autofs[5]. ==== Утилита man:autofs[5] — это общее название для нескольких компонентов, которые вместе позволяют автоматически монтировать удалённые и локальные файловые системы при обращении к файлу или каталогу внутри этих файловых систем. Она состоит из компонента ядра man:autofs[5] и нескольких пользовательских приложений: man:automount[8], man:automountd[8] и man:autounmountd[8]. Она служит альтернативой для man:amd[8] из предыдущих выпусков FreeBSD. amd по-прежнему предоставляется для обратной совместимости, так как эти утилиты используют разные форматы карт; формат, используемый autofs, совпадает с форматом других автомонтировщиков SVR4, таких как в Solaris, MacOS X и Linux. Виртуальная файловая система man:autofs[5] монтируется на указанные точки монтирования с помощью man:automount[8], который обычно запускается во время загрузки. Всякий раз, когда процесс пытается получить доступ к файлу в точке монтирования man:autofs[5], ядро уведомляет демон man:automountd[8] и приостанавливает вызвавший процесс. Демон man:automountd[8] обрабатывает запросы ядра, находя соответствующую карту и монтируя файловую систему в соответствии с ней, после чего сигнализирует ядру о разблокировке процесса. Демон man:autounmountd[8] автоматически размонтирует автомонтируемые файловые системы по истечении некоторого времени, если они больше не используются. Основной файл конфигурации autofs — это [.filename]#/etc/auto_master#. Он связывает отдельные карты с корневыми точками монтирования. Для объяснения синтаксиса [.filename]#auto_master# и карт обратитесь к man:auto_master[5]. Существует специальная карта автомонтирования, смонтированная в [.filename]#/net#. При обращении к файлу в этом каталоге, man:autofs[5] ищет соответствующую удалённую точку монтирования и автоматически монтирует её. Например, попытка доступа к файлу в [.filename]#/net/foobar/usr# приведёт к тому, что man:automountd[8] смонтирует экспорт [.filename]#/usr# с хоста `foobar`. .Подключение экспорта с помощью man:autofs[5] [example] ==== В этом примере `showmount -e` показывает экспортированные файловые системы, которые могут быть подключены с NFS-сервера `foobar`: [source, shell] .... % showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 % cd /net/foobar/usr .... ==== Результат выполнения `showmount` показывает, что [.filename]#/usr# экспортируется. При переходе в каталог [.filename]#/host/foobar/usr#, man:automountd[8] перехватывает запрос и пытается разрешить имя хоста `foobar`. В случае успеха man:automountd[8] автоматически монтирует исходный экспорт. Чтобы включить man:autofs[5] при загрузке, добавьте следующую строку в [.filename]#/etc/rc.conf#: [.programlisting] .... autofs_enable="YES" .... Затем man:autofs[5] может быть запущен выполнением: [source, shell] .... # service automount start # service automountd start # service autounmountd start .... Формат карты man:autofs[5] такой же, как и в других операционных системах. Информация об этом формате из других источников может быть полезной, например, из http://web.archive.org/web/20160813071113/http://images.apple.com/business/docs/Autofs.pdf[документации Mac OS X]. Обратитесь к справочным страницам man:automount[8], man:automountd[8], man:autounmountd[8] и man:auto_master[5] для получения дополнительной информации. [[network-nis]] == Сетевая информационная система (NIS) Сетевая информационная система (NIS — Network Information System) предназначена для централизованного администрирования UNIX(R)-подобных систем, таких как Solaris(TM), HP-UX, AIX(R), Linux, NetBSD, OpenBSD и FreeBSD. Изначально NIS была известна как Yellow Pages, но название было изменено из-за проблем с товарными знаками. Именно поэтому команды NIS начинаются с `yp`. NIS — это клиент-серверная система на основе удалённых вызовов процедур (RPC), которая позволяет группе машин в домене NIS использовать общий набор конфигурационных файлов. Это позволяет системному администратору настраивать клиентские системы NIS с минимальным объёмом конфигурационных данных, а также добавлять, удалять или изменять конфигурационные данные из единого места. FreeBSD использует вторую версию протокола NIS. === Термины и процессы NIS Таблица 28.1 обобщает термины и важные процессы, используемые NIS: .Терминология NIS [cols="1,1", frame="none", options="header"] |=== | Термин | Описание |Имя домена NIS |Серверы и клиенты NIS используют общее имя домена NIS. Как правило, это имя не связано с DNS. |man:rpcbind[8] |Эта служба включает RPC и должна работать для запуска сервера NIS или работы в качестве клиента NIS. |man:ypbind[8] |Эта служба связывает клиент NIS с его сервером NIS. Она принимает имя домена NIS и использует RPC для подключения к серверу. Это основа клиент-серверного взаимодействия в среде NIS. Если эта служба не запущена на клиентской машине, она не сможет получить доступ к серверу NIS. |man:ypserv[8] |Это процесс для сервера NIS. Если эта служба перестанет работать, сервер больше не сможет отвечать на запросы NIS, поэтому, надеюсь, есть подчиненный сервер, который возьмет на себя управление. Некоторые клиенты, не относящиеся к FreeBSD, не будут пытаться переподключиться с использованием подчиненного сервера, и процесс ypbind, возможно, потребуется перезапустить на этих клиентах. |man:rpc.yppasswdd[8] |Этот процесс работает только на основных серверах NIS. Этот демон позволяет клиентам NIS изменять свои пароли в NIS. Если этот демон не запущен, пользователям придется входить на главный сервер NIS и изменять пароли там. |=== === Типы машин В среде NIS существует три типа хостов: * Основной сервер NIS + Этот сервер выступает в роли центрального хранилища информации о конфигурации хостов и содержит авторитетные копии файлов, используемых всеми клиентами NIS. Файлы [.filename]#passwd#, [.filename]#group# и другие, используемые клиентами NIS, хранятся на главном сервере. Хотя возможно, чтобы одна машина была основным сервером NIS для нескольких доменов NIS, такая конфигурация не рассматривается в этой главе, так как предполагается относительно небольшая среда NIS. * Подчиненные серверы NIS + Подчинённые серверы NIS хранят копии файлов данных NIS главного сервера для обеспечения избыточности. Подчинённые серверы также помогают распределить нагрузку основного сервера, так как клиенты NIS всегда подключаются к NIS серверу, который отвечает первым. * Клиенты NIS + Клиенты NIS проходят аутентификацию на сервере NIS при входе в систему. Информация из многих файлов может быть совместно использована с помощью NIS. Файлы [.filename]#master.passwd#, [.filename]#group# и [.filename]#hosts# часто распространяются через NIS. Когда процессу на клиенте требуется информация, которая обычно находится в этих файлах локально, он отправляет запрос к связанному с ним NIS-серверу. === Планирование и подготовка В этом разделе описывается пример среды NIS, состоящей из 15 машин FreeBSD без централизованной точки администрирования. На каждой машине есть свои файлы [.filename]#/etc/passwd# и [.filename]#/etc/master.passwd#. Эти файлы синхронизируются между собой только вручную. В настоящее время, когда в лабораторию добавляется новый пользователь, этот процесс необходимо повторять на всех 15 машинах. Конфигурация лаборатории будет следующей: [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | Имя машины | IP-адрес | Роль машины |`ellington` |`10.0.0.2` |Основной сервер NIS |`coltrane` |`10.0.0.3` |Подчиненный сервер NIS |`basie` |`10.0.0.4` |Факультетская рабочая станция |`bird` |`10.0.0.5` |Клиентская машина |`cli[1-11]` |`10.0.0.[6-17]` |Другие клиентские машины |=== Если это первый раз, когда разрабатывается схема NIS, её следует тщательно спланировать заранее. Независимо от размера сети, в процессе планирования необходимо принять несколько решений. ==== Выбор имени домена NIS Когда клиент рассылает широковещательные запросы на получение информации, он включает имя домена NIS, к которому принадлежит. Таким образом, несколько серверов в одной сети могут определить, какой сервер должен отвечать на конкретный запрос. Думайте о доменном имени NIS как об имени для группы хостов. Некоторые организации предпочитают использовать своё доменное имя интернета в качестве имени домена NIS. Это не рекомендуется, так как может вызвать путаницу при попытках отладки сетевых проблем. Имя домена NIS должно быть уникальным в пределах сети, и полезно, если оно описывает группу машин, которую представляет. Например, художественный отдел компании Acme Inc. может находиться в домене NIS "acme-art". В этом примере будет использоваться имя домена `test-domain`. Однако некоторые операционные системы, отличные от FreeBSD, требуют, чтобы имя домена NIS совпадало с именем интернет-домена. Если одна или несколько машин в сети имеют это ограничение, _необходимо_ использовать имя интернет-домена в качестве имени домена NIS. ==== Требования к физическому серверу Есть несколько моментов, которые следует учитывать при выборе машины для использования в качестве сервера NIS. Поскольку клиенты NIS зависят от доступности сервера, следует выбрать машину, которая не перезагружается часто. Идеально, чтобы сервер NIS был отдельной машиной, единственной целью которой является быть сервером NIS. Если сеть не сильно загружена, допустимо разместить сервер NIS на машине, где выполняются другие службы. Однако, если сервер NIS станет недоступен, это негативно скажется на всех клиентах NIS. === Настройка основного сервера NIS Канонические копии всех NIS-файлов хранятся на основном сервере. Базы данных, используемые для хранения информации, называются NIS-картами. В FreeBSD эти карты хранятся в [.filename]#/var/yp/[domainname]#, где [.filename]#[domainname]# — это имя NIS-домена. Поскольку поддерживается несколько доменов, возможно наличие нескольких каталогов, по одному для каждого домена. Каждый домен будет иметь свой независимый набор карт. Основные и подчинённые серверы NIS обрабатывают все запросы NIS через man:ypserv[8]. Этот демон отвечает за приём входящих запросов от клиентов NIS, преобразование запрошенного домена и имени карты в путь к соответствующему файлу базы данных и передачу данных из базы обратно клиенту. Настройка основного NIS-сервера может быть относительно простой, в зависимости от потребностей окружения. Поскольку FreeBSD предоставляет встроенную поддержку NIS, её достаточно включить, добавив следующие строки в [.filename]#/etc/rc.conf#: [.programlisting] .... nisdomainname="test-domain" <.> nis_server_enable="YES" <.> nis_yppasswdd_enable="YES" <.> .... <.> Эта строка устанавливает имя домена NIS в `test-domain`. <.> Это автоматизирует запуск процессов сервера NIS при загрузке системы. <.> Это включает демон man:rpc.yppasswdd[8], позволяющий пользователям изменять свой NIS-пароль с клиентской машины. В многосерверном домене, где серверные машины также являются клиентами NIS, необходимо соблюдать осторожность. Обычно рекомендуется принудительно заставлять серверы привязываться к самим себе, а не разрешать им рассылать запросы на привязку и потенциально привязываться друг к другу. Могут возникнуть странные режимы сбоев, если один сервер выйдет из строя, а другие будут зависеть от него. В конечном итоге все клиенты превысят время ожидания и попытаются привязаться к другим серверам, но задержка может быть значительной, а режим сбоя сохранится, поскольку серверы могут снова привязаться друг к другу. Сервер, который также является клиентом, может быть принудительно привязан к определённому серверу путём добавления следующих строк в [.filename]#/etc/rc.conf#: [.programlisting] .... nis_client_enable="YES" <.> nis_client_flags="-S test-domain,server" <.> .... <.> Это позволяет также запускать клиентские приложения. <.> Эта строка устанавливает имя домена NIS в `test-domain` и привязывает к себе. После сохранения изменений введите `/etc/netstart`, чтобы перезапустить сеть и применить значения, указанные в [.filename]#/etc/rc.conf#. Перед инициализацией карт NIS запустите man:ypserv[8]: [source, shell] .... # service ypserv start .... ==== Инициализация карт NIS NIS-карты создаются из конфигурационных файлов в [.filename]#/etc# на NIS-мастере, за исключением одного: [.filename]#/etc/master.passwd#. Это сделано для предотвращения распространения паролей на все серверы в NIS-домене. Поэтому перед инициализацией NIS-карт необходимо настроить основные файлы паролей: [source, shell] .... # cp /etc/master.passwd /var/yp/master.passwd # cd /var/yp # vi master.passwd .... Рекомендуется удалить все записи системных учётных записей, а также любые пользовательские учётные записи, которые не нужно распространять на клиенты NIS, такие как `root` и другие административные учётные записи. [NOTE] ==== Убедитесь, что файл [.filename]#/var/yp/master.passwd# не доступен для чтения группе или всем, установив его права доступа на `600`. ==== После завершения этой задачи инициализируйте карты NIS. FreeBSD включает скрипт man:ypinit[8] для этого. При создании карт для главного сервера укажите `-m` и задайте имя домена NIS: [source, shell] .... ellington# ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If not, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a . master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. .... Это создаст файл [.filename]#/var/yp/Makefile# на основе [.filename]#/var/yp/Makefile.dist#. По умолчанию этот файл предполагает, что в окружении есть единственный NIS-сервер только с клиентами FreeBSD. Поскольку у `test-domain` есть подчиненный сервер, отредактируйте эту строку в [.filename]#/var/yp/Makefile#, чтобы она начиналась с комментария (`+#+`): [.programlisting] .... NOPUSH = "True" .... ==== Добавление новых пользователей Каждый раз при создании нового пользователя учётная запись должна быть добавлена на основной NIS-сервер, а NIS-карты должны быть перестроены. До этого новый пользователь не сможет войти в систему нигде, кроме главного NIS-сервера. Например, чтобы добавить нового пользователя `jsmith` в домен `test-domain`, выполните следующие команды на основном сервере: [source, shell] .... # pw useradd jsmith # cd /var/yp # make test-domain .... Пользователь также может быть добавлен с помощью `adduser jsmith` вместо `pw useradd smith`. === Настройка подчиненного сервера NIS Для настройки подчиненного сервера NIS войдите на подчиненный сервер и отредактируйте [.filename]#/etc/rc.conf#, как для основного сервера. Не генерируйте карты NIS, так как они уже существуют на основном сервере. При запуске `ypinit` на подчиненном сервере используйте `-s` (для подчиненного) вместо `-m` (для основного). Эта опция требует указания имени основного сервера NIS в дополнение к имени домена, как показано в этом примере: [source, shell] .... coltrane# ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If not, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Remember to update map ypservers on ellington. .... Это создаст каталог на подчиненном сервере с именем [.filename]#/var/yp/test-domain#, который содержит копии карт основного сервера NIS. Добавление этих записей в [.filename]#/etc/crontab# на каждом подчиненном сервере заставит их синхронизировать свои карты с картами на основном сервере: [.programlisting] .... 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid .... Эти записи не являются обязательными, поскольку основной сервер автоматически пытается передать любые изменения карт своим подчинённым серверам. Однако, поскольку клиенты могут зависеть от подчинённого сервера для предоставления корректной информации о паролях, рекомендуется принудительно выполнять частые обновления карт паролей. Это особенно важно в загруженных сетях, где обновления карт могут не всегда завершаться. Для завершения настройки выполните `/etc/netstart` на подчинённом сервере, чтобы запустить службы NIS. === Настройка клиента NIS Клиент NIS связывается с сервером NIS с помощью man:ypbind[8]. Этот демон рассылает RPC-запросы в локальной сети. Эти запросы указывают доменное имя, настроенное на клиенте. Если NIS-сервер в том же домене получает один из таких запросов, он отвечает, и ypbind записывает адрес сервера. Если доступно несколько серверов, клиент будет использовать адрес первого ответившего сервера и направлять все свои NIS-запросы к нему. Клиент автоматически отправляет ping-запросы серверу через регулярные промежутки времени, чтобы убедиться, что он всё ещё доступен. Если ответ не получен в разумные сроки, ypbind пометит домен как несвязанный и снова начнёт рассылку запросов в надежде найти другой сервер. Для настройки машины FreeBSD в качестве клиента NIS: [.procedure] ==== . Отредактируйте файл [.filename]#/etc/rc.conf# и добавьте следующие строки, чтобы установить имя домена NIS и запустить man:ypbind[8] при старте сети: + [.programlisting] .... nisdomainname="test-domain" nis_client_enable="YES" .... . Для импорта всех возможных записей паролей с сервера NIS, используйте `vipw`, чтобы удалить все учётные записи пользователей, кроме одной, из [.filename]#/etc/master.passwd#. При удалении учётных записей учитывайте, что хотя бы одна локальная учётная запись должна остаться, и эта учётная запись должна быть членом группы `wheel`. Если возникнут проблемы с NIS, эту локальную учётную запись можно использовать для удаленного входа, получения прав суперпользователя и устранения проблемы. Перед сохранением изменений добавьте следующую строку в конец файла: + [.programlisting] .... +::::::::: .... + Эта строка настраивает клиент для предоставления любому пользователю с действительной учётной записью в картах паролей NIS-сервера учётной записи на клиенте. Существует множество способов настройки NIS-клиента путём изменения этой строки. Один из методов описан в crossref:network-servers[network-netgroups, Использование групп сети]. Для более подробного ознакомления обратитесь к книге `Managing NFS and NIS`, опубликованной O'Reilly Media. . Для импорта всех возможных записей групп с сервера NIS добавьте следующую строку в [.filename]#/etc/group#: + [.programlisting] .... +:*:: .... ==== Для немедленного запуска клиента NIS выполните следующие команды от имени суперпользователя: [source, shell] .... # /etc/netstart # service ypbind start .... После выполнения этих шагов, выполнение команды `ypcat passwd` на клиенте должно отобразить карту [.filename]#passwd# сервера. === Безопасность NIS Поскольку RPC — это широковещательный сервис, любая система, запускающая ypbind в том же домене, может получить содержимое NIS-карт. Чтобы предотвратить несанкционированные операции, man:ypserv[8] поддерживает функцию под названием "securenets", которая может использоваться для ограничения доступа к определённому набору хостов. По умолчанию эта информация хранится в [.filename]#/var/yp/securenets#, если только man:ypserv[8] не запущен с ключом `-p` и альтернативным путём. Этот файл содержит записи, состоящие из спецификации сети и сетевой маски, разделённых пробелами. Строки, начинающиеся с `+"#"+`, считаются комментариями. Пример файла [.filename]#securenets# может выглядеть так: [.programlisting] .... # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 .... Если man:ypserv[8] получает запрос от адреса, соответствующего одному из этих правил, он обработает запрос как обычно. Если адрес не соответствует ни одному правилу, запрос будет проигнорирован и в журнал будет записано предупреждение. Если файл [.filename]#securenets# не существует, `ypserv` разрешит соединения с любого хоста. crossref:security[tcpwrappers,"TCP Wrapper"] — это альтернативный механизм контроля доступа вместо [.filename]#securenets#. Хотя оба механизма контроля доступа добавляют некоторый уровень безопасности, они оба уязвимы к атакам "подмены IP". Весь трафик, связанный с NIS, должен блокироваться на межсетевом экране. Серверы, использующие [.filename]#securenets#, могут не обслуживать легитимных клиентов NIS с устаревшими реализациями TCP/IP. Некоторые из этих реализаций устанавливают все биты хоста в ноль при выполнении широковещательных запросов или не учитывают маску подсети при вычислении широковещательного адреса. Хотя некоторые из этих проблем можно устранить, изменив конфигурацию клиента, другие проблемы могут потребовать вывода из эксплуатации этих клиентских систем или отказа от [.filename]#securenets#. Использование TCP Wrapper увеличивает задержку сервера NIS. Дополнительная задержка может быть достаточно длительной, чтобы вызвать таймауты в клиентских программах, особенно в загруженных сетях с медленными серверами NIS. Если один или несколько клиентов страдают от задержек, преобразуйте этих клиентов в подчинённые серверы NIS и заставьте их привязываться к самим себе. ==== Запрет доступа некоторым пользователям В этом примере система `basie` является рабочей станцией преподавателя в домене NIS. Файл [.filename]#passwd# на главном сервере NIS содержит учётные записи как преподавателей, так и студентов. В этом разделе показано, как разрешить вход преподавателей в эту систему, запретив вход студентам. Чтобы предотвратить вход определённых пользователей в систему, даже если они присутствуют в базе данных NIS, используйте `vipw` для добавления `-_имя_пользователя_` с правильным количеством двоеточий в конце файла [.filename]#/etc/master.passwd# на клиенте, где _имя_пользователя_ — это имя пользователя, которому запрещен вход. Строка с заблокированным пользователем должна находиться перед строкой `+`, которая разрешает вход пользователям NIS. В этом примере пользователю `bill` запрещен вход на `basie`: [source, shell] .... basie# cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin operator:*:2:5::0:0:System &:/:/usr/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/usr/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/usr/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin -bill::::::::: +::::::::: basie# .... [[network-netgroups]] === Использование сетевых групп Запрет указанным пользователям возможности входа в отдельные системы становится неэффективным и не масштабируемым в крупных сетях и быстро лишает NIS основного преимущества: _централизованного_ администрирования. Сетевые группы были разработаны для управления большими и сложными сетями с сотнями пользователей и машин. Их использование аналогично группам в UNIX(R), с той основной разницей, что отсутствует числовой идентификатор и есть возможность определять сетевую группу, включая как учётные записи пользователей, так и другие сетевые группы. Для дополнения примера, используемого в этой главе, домен NIS будет увеличен за счет пользователей и систем, показанным в таблицах 28.2 и 28.3: .Дополнительные пользователи [cols="1,1", frame="none", options="header"] |=== | Имена пользователей | Описание |`alpha`, `beta` |Сотрудники IT-отдела |`charlie`, `delta` |Стажеры IT-отдела |`echo`, `foxtrott`, `golf`, ... |Сотрудники |`able`, `baker`, ... |Интерны |=== .Дополнительные Системы [cols="1,1", frame="none", options="header"] |=== | Имена машин | Описание |`war`, `death`, `famine`, `pollution` |Только сотрудники IT имеют право входить на эти серверы. |`pride`, `greed`, `envy`, `wrath`, `lust`, `sloth` |Все сотрудники IT-отдела имеют право входить на эти серверы. |`one`, `two`, `three`, `four`, ... |Обычные рабочие станции, используемые сотрудниками. |`trashcan` |Очень старая машина без каких-либо важных данных. Даже интернам разрешено использовать эту систему. |=== При использовании сетевых групп для настройки этого сценария каждый пользователь назначается в одну или несколько сетевых групп, а затем вход разрешается или запрещается для всех членов сетевой группы. При добавлении новой машины необходимо определить ограничения входа для всех сетевых групп. Когда добавляется новый пользователь, его учётная запись должна быть добавлена в одну или несколько сетевых групп. Если настройка NIS выполнена тщательно, для предоставления или запрета доступа к машинам потребуется изменить только один центральный файл конфигурации. Первым шагом является инициализация NIS `netgroup` карты. В FreeBSD эта карта не создается по умолчанию. На главном сервере NIS используйте редактор для создания карты с именем [.filename]#/var/yp/netgroup#. Этот пример создает четыре сетевые группы для представления сотрудников IT, стажеров IT, сотрудников и интернов: [.programlisting] .... IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) .... Каждая запись настраивает сетевую группу. Первый столбец в записи — это название сетевой группы. Каждый набор скобок представляет либо группу из одного или нескольких пользователей, либо имя другой сетевой группы. При указании пользователя три поля, разделённые запятыми, внутри каждой группы означают: . Имя хоста(ов), на котором другие поля, представляющие пользователя, действительны. Если имя хоста не указано, запись действительна на всех хостах. . Имя учётной записи, принадлежащей этой сетевой группе. . NIS-домен для учётной записи. Учётные записи могут быть импортированы из других NIS-доменов в сетевую группу. Если группа содержит нескольких пользователей, разделяйте каждого пользователя пробелом. Кроме того, каждое поле может содержать символы подстановки. Подробности см. в man:netgroup[5]. Имена сетевых групп длиннее 8 символов не должны использоваться. Имена чувствительны к регистру, и использование заглавных букв для имён сетевых групп — это простой способ отличить имена пользователей, машин и сетевых групп. Некоторые клиенты NIS, не относящиеся к FreeBSD, не могут обрабатывать сетевые группы, содержащие более 15 записей. Это ограничение можно обойти, создав несколько подгрупп с 15 или менее пользователями и настоящую сетевую группу, состоящую из этих подгрупп, как показано в этом примере: [.programlisting] .... BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 .... Повторите этот процесс, если в одной сетевой группе существует более 225 (15 умножить на 15) пользователей. Для активации и распространения новой NIS-карты: [source, shell] .... ellington# cd /var/yp ellington# make .... Это создаст три карты NIS [.filename]#netgroup#, [.filename]#netgroup.byhost# и [.filename]#netgroup.byuser#. Используйте опцию ключа карты в man:ypcat[1], чтобы проверить доступность новых карт NIS: [source, shell] .... ellington% ypcat -k netgroup ellington% ypcat -k netgroup.byhost ellington% ypcat -k netgroup.byuser .... Вывод первой команды должен напоминать содержимое файла [.filename]#/var/yp/netgroup#. Вторая команда выводит результат только в случае создания специфичных для хоста групп сетей. Третья команда используется для получения списка групп сетей для пользователя. Для настройки клиента используйте man:vipw[8], чтобы указать имя сетевой группы. Например, на сервере с именем `war` замените эту строку: [.programlisting] .... +::::::::: .... строкой [.programlisting] .... +@IT_EMP::::::::: .... Указывает, что только пользователи, определённые в сетевой группе `IT_EMP`, будут импортированы в базу данных паролей этой системы, и только этим пользователям разрешён вход в систему. Эта конфигурация также применяется к функции `~` оболочки и всем процедурам, которые преобразуют между именами пользователей и числовыми идентификаторами пользователей. Другими словами, `cd ~_user_` не будет работать, `ls -l` покажет числовой ID вместо имени пользователя, а `find . -user joe -print` завершится с сообщением `No such user`. Чтобы исправить это, импортируйте все записи пользователей, не разрешая им вход на серверы. Это можно достичь, добавив дополнительную строку: [.programlisting] .... +:::::::::/usr/sbin/nologin .... Эта строка настраивает клиент на импорт всех записей, но с заменой оболочки в этих записях на [.filename]#/usr/sbin/nologin#. Убедитесь, что дополнительная строка добавлена _после_ `+@IT_EMP:::::::::`. В противном случае у всех пользовательских учётных записей, импортированных из NIS, будет указана оболочка входа [.filename]#/usr/sbin/nologin#, и никто не сможет войти в систему. Для настройки менее важных серверов замените старые `+:::::::::` на серверах следующими строками: [.programlisting] .... +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/usr/sbin/nologin .... Соответствующие строки для рабочих станций будут: [.programlisting] .... +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/usr/sbin/nologin .... NIS поддерживает создание netgroups из других netgroups, что может быть полезно при изменении политики доступа пользователей. Одна из возможностей — создание ролевых netgroups. Например, можно создать netgroup с именем `BIGSRV` для определения ограничений входа на важные серверы, другую netgroup `SMALLSRV` для менее важных серверов и третью netgroup `USERBOX` для рабочих станций. Каждая из этих netgroups содержит netgroups, которым разрешено входить на эти машины. Новые записи для карты NIS `netgroup` будут выглядеть так: [.programlisting] .... BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS .... Этот метод определения ограничений входа работает достаточно хорошо, когда можно определить группы машин с одинаковыми ограничениями. К сожалению, это скорее исключение, чем правило. В большинстве случаев требуется возможность определять ограничения входа для каждой машины отдельно. Определения машинозависимых сетевых групп — ещё один способ справиться с изменениями политики. В этом сценарии файл [.filename]#/etc/master.passwd# на каждой системе содержит две строки, начинающиеся с "+". Первая строка добавляет сетевую группу с учётными записями, которым разрешён вход на эту машину, а вторая строка добавляет все остальные учётные записи с оболочкой [.filename]#/usr/sbin/nologin#. Рекомендуется использовать имя сетевой группы в версии "ВСЕ-ЗАГЛАВНЫЕ", соответствующее имени хоста: [.programlisting] .... +@BOXNAME::::::::: +:::::::::/usr/sbin/nologin .... После выполнения этой задачи на всех машинах больше не требуется изменять локальные версии файла [.filename]#/etc/master.passwd#. Все дальнейшие изменения можно выполнять, редактируя карту NIS. Вот пример возможной карты `netgroup` для данного сценария: [.programlisting] .... # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] .... Не всегда целесообразно использовать сетевые группы, привязанные к машинам. При развертывании нескольких десятков или сотен систем можно использовать ролевые сетевые группы вместо машинных, чтобы размер карты NIS оставался в разумных пределах. === Форматы паролей NIS требует, чтобы все хосты в домене NIS использовали одинаковый формат шифрования паролей. Если у пользователей возникают проблемы с аутентификацией на клиенте NIS, это может быть связано с разным форматом паролей. В гетерогенной сети формат должен поддерживаться всеми операционными системами, где DES является минимальным общим стандартом. Чтобы проверить, какой формат использует сервер или клиент, посмотрите на этот раздел в [.filename]#/etc/login.conf#: [.programlisting] .... default:\ :passwd_format=des:\ [Further entries elided] .... В этом примере система использует формат DES для хеширования паролей. Другие возможные значения включают `blf` для Blowfish, `md5` для MD5, `sha256` и `sha512` для SHA-256 и SHA-512 соответственно. Для получения дополнительной информации и актуального списка доступных вариантов на вашей системе обратитесь к man:crypt[3]. Если формат на хосте необходимо изменить, чтобы он соответствовал формату, используемому в домене NIS, базу данных возможностей входа необходимо перестроить после сохранения изменений: [source, shell] .... # cap_mkdb /etc/login.conf .... [NOTE] ==== Формат паролей для существующих учётных записей не будет обновлён, пока каждый пользователь не изменит свой пароль _после_ перестроения базы данных возможностей входа. ==== [[network-ldap]] == Протокол LDAP Протокол LDAP (Lightweight Directory Access Protocol) — это протокол уровня приложений, используемый для доступа, изменения и аутентификации объектов с помощью распределённой службы каталогов. Его можно сравнить с телефонной книгой или архивом, который хранит несколько уровней иерархической однородной информации. Он применяется в сетях Active Directory и OpenLDAP, позволяя пользователям получать доступ к различным уровням внутренней информации с использованием одной учётной записи. Например, аутентификация электронной почты, получение контактных данных сотрудников и аутентификация на внутренних веб-сайтах могут осуществляться с помощью одной учётной записи в базе данных LDAP-сервера. В этом разделе представлено краткое руководство по настройке сервера LDAP в системе FreeBSD. Предполагается, что администратор уже имеет продуманный план, включающий тип хранимой информации, её назначение, перечень пользователей с доступом к этой информации и способы защиты от несанкционированного доступа. === Терминология и структура LDAP LDAP использует несколько терминов, которые следует понять перед началом настройки. Все записи каталога состоят из группы _атрибутов_. Каждый из этих наборов атрибутов содержит уникальный идентификатор, известный как _Отличительное имя_ (DN — Distinguished Name), который обычно строится из нескольких других атрибутов, таких как общее имя или _Относительное отличительное имя_ (RDN — Relative Distinguished Name). Подобно тому, как каталоги имеют абсолютные и относительные пути, можно рассматривать DN как абсолютный путь, а RDN — как относительный путь. Пример записи LDAP выглядит следующим образом. В этом примере выполняется поиск записи для указанной учётной записи пользователя (`uid`), организационного подразделения (`ou`) и организации (`o`): [source, shell] .... % ldapsearch -xb "uid=trhodes,ou=users,o=example.com" # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # trhodes, users, example.com dn: uid=trhodes,ou=users,o=example.com mail: trhodes@example.com cn: Tom Rhodes uid: trhodes telephoneNumber: (123) 456-7890 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 .... Этот пример записи показывает значения атрибутов `dn`, `mail`, `cn`, `uid` и `telephoneNumber`. Атрибут `cn` является RDN. Дополнительная информация о LDAP и его терминологии доступна по адресу http://www.openldap.org/doc/admin24/intro.html[http://www.openldap.org/doc/admin24/intro.html]. [[ldap-config]] === Настройка сервера LDAP FreeBSD не предоставляет встроенный LDAP-сервер. Начните настройку с установки пакета package:net/openldap-server[] или порта: [source, shell] .... # pkg install openldap-server .... В extref:{linux-users}[пакете, software] включен большой набор параметров по умолчанию. Их можно просмотреть, выполнив команду `pkg info openldap-server`. Если их недостаточно (например, требуется поддержка SQL), рекомендуется перекомпилировать порт с использованием соответствующего crossref:ports[ports-using,фреймворка]. Установка создает каталог [.filename]#/var/db/openldap-data# для хранения данных. Необходимо создать каталог для хранения сертификатов: [source, shell] .... # mkdir /usr/local/etc/openldap/private .... Следующий этап — настройка Центра Сертификации. Следующие команды должны быть выполнены из каталога [.filename]#/usr/local/etc/openldap/private#. Это важно, так как права доступа к файлам должны быть строгими, и пользователи не должны иметь доступ к этим файлам. Более подробную информацию о сертификатах и их параметрах можно найти в crossref:security[openssl,"OpenSSL"]. Чтобы создать Центр Сертификации, начните с этой команды и следуйте инструкциям: [source, shell] .... # openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt .... Записи для запросов могут быть любыми, _за исключением_ `Common Name`. Эта запись должна _отличаться_ от имени хоста системы. Если это будет самоподписанный сертификат, добавьте к имени хоста префикс `CA` — как Центр Сертификации. Следующая задача — создать запрос на подпись сертификата и закрытый ключ. Введите эту команду и следуйте инструкциям: [source, shell] .... # openssl req -days 365 -nodes -new -keyout server.key -out server.csr .... В процессе генерации сертификата обязательно правильно укажите атрибут `Common Name`. Запрос на подпись сертификата (Certificate Signing Request) должен быть подписан Центром сертификации, чтобы использоваться в качестве действительного сертификата: [source, shell] .... # openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial .... Заключительная часть процесса генерации сертификатов — создание и подписание клиентских сертификатов: [source, shell] .... # openssl req -days 365 -nodes -new -keyout client.key -out client.csr # openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key .... Помните, что нужно использовать тот же атрибут `Common Name` при запросе. По завершении убедитесь, что в результате выполнения команд было создано в общей сложности восемь (8) новых файлов. Демон, запускающий сервер OpenLDAP, называется [.filename]#slapd#. Его настройка выполняется через файл [.filename]#slapd.ldif#: старый файл [.filename]#slapd.conf# больше не используется в OpenLDAP. Есть http://www.openldap.org/doc/admin24/slapdconf2.html[примеры конфигурации] для [.filename]#slapd.ldif# доступны, и также их можно найти в [.filename]#/usr/local/etc/openldap/slapd.ldif.sample#. Документация параметров в slapd-config(5). Каждый раздел [.filename]#slapd.ldif#, как и все другие наборы атрибутов LDAP, однозначно идентифицируется через DN. Убедитесь, что между строкой `dn:` и желаемым концом раздела нет пустых строк. В следующем примере TLS будет использоваться для настройки безопасного канала. Первый раздел представляет глобальную конфигурацию: [.programlisting] .... # # See slapd-config(5) for details on configuration options. # This file should NOT be world readable. # dn: cn=config objectClass: olcGlobal cn: config # # # Define global ACLs to disable default read access. # olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCertificateFile: /usr/local/etc/openldap/server.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/private/server.key olcTLSCACertificateFile: /usr/local/etc/openldap/ca.crt #olcTLSCipherSuite: HIGH olcTLSProtocolMin: 3.1 olcTLSVerifyClient: never .... Здесь необходимо указать файлы Центра сертификации, сертификата сервера и закрытого ключа сервера. Рекомендуется позволить клиентам выбирать алгоритм шифрования и опустить опцию `olcTLSCipherSuite` (несовместимо с TLS-клиентами, кроме [.filename]#openssl#). Опция `olcTLSProtocolMin` позволяет серверу требовать минимальный уровень безопасности: это рекомендуется. Хотя проверка обязательна для сервера, для клиента она не требуется: `olcTLSVerifyClient: never`. Второй раздел посвящен серверным модулям и может быть настроен следующим образом: [.programlisting] .... # # Load dynamic backend modules: # dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_mdb.la #olcModuleload: back_bdb.la #olcModuleload: back_hdb.la #olcModuleload: back_ldap.la #olcModuleload: back_passwd.la #olcModuleload: back_shell.la .... Третий раздел посвящён загрузке необходимых схем `ldif` для использования базами данных: они являются важными. [.programlisting] .... dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif include: file:///usr/local/etc/openldap/schema/nis.ldif .... Далее, раздел конфигурации фронтенда (уровня взаимодействия с клиентами): [.programlisting] .... # Frontend settings # dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to * by * read # # Sample global access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # #olcAccess: to dn.base="" by * read #olcAccess: to dn.base="cn=Subschema" by * read #olcAccess: to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # olcPasswordHash: {SSHA} # {SSHA} is already the default for olcPasswordHash .... Еще один раздел посвящен _бэкенду конфигурации_ — единственному способу последующего доступа к конфигурации сервера OpenLDAP, который доступен только глобальному суперпользователю. [.programlisting] .... dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: to * by * none olcRootPW: {SSHA}iae+lrQZILpiUdf16Z9KmDmSwT77Dj4U .... Имя администратора по умолчанию — `cn=config`. Введите [.filename]#slappasswd# в оболочке, выберите пароль и используйте его хеш в `olcRootPW`. Если этот параметр не указан сейчас, до импорта [.filename]#slapd.ldif#, никто не сможет впоследствии изменить раздел _глобальной конфигурации_. Последний раздел посвящен бэкенду базы данных (уровню хранения данных): [.programlisting] .... ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=domain,dc=example olcRootDN: cn=mdbadmin,dc=domain,dc=example # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd-config(5) for details. # Use of strong authentication encouraged. olcRootPW: {SSHA}X2wHvIWDk6G76CQyCMS1vDCvtICWgn0+ # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. olcDbDirectory: /var/db/openldap-data # Indices to maintain olcDbIndex: objectClass eq .... Эта база данных содержит _фактическое содержимое_ каталога LDAP. Доступны типы, отличные от `mdb`. Суперпользователь (не путать с глобальным) настраивается здесь: (возможно, пользовательское) имя пользователя в `olcRootDN` и хэш пароля в `olcRootPW`; [.filename]#slappasswd# можно использовать, как и раньше. Этот http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=tests/data/regressions/its8444;h=8a5e808e63b0de3d2bdaf2cf34fecca8577ca7fd;hb=HEAD[репозиторий] содержит четыре примера файла [.filename]#slapd.ldif#. Для преобразования существующего [.filename]#slapd.conf# в [.filename]#slapd.ldif# обратитесь к http://www.openldap.org/doc/admin24/slapdconf2.html[этой странице] (обратите внимание, что это может добавить некоторые бесполезные опции). После завершения настройки файл [.filename]#slapd.ldif# должен быть скопирован в пустой каталог. Рекомендуется создать его следующим образом: [source, shell] .... # mkdir /usr/local/etc/openldap/slapd.d/ .... Импорт базы данных конфигурации: [source, shell] .... # /usr/local/sbin/slapadd -n0 -F /usr/local/etc/openldap/slapd.d/ -l /usr/local/etc/openldap/slapd.ldif .... Запустите демон [.filename]#slapd#: [source, shell] .... # /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d/ .... Опция `-d` может использоваться для отладки, как указано в slapd(8). Чтобы проверить, что сервер запущен и работает: [source, shell] .... # ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=example # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 .... Сервер по-прежнему должен быть доверенным. Если это никогда не делалось ранее, следуйте этим инструкциям. Установите пакет или порт OpenSSL: [source, shell] .... # pkg install openssl .... Из каталога, где находится [.filename]#ca.crt# (в данном примере, [.filename]#/usr/local/etc/openldap#), выполните: [source, shell] .... # c_rehash . .... И сертификат центра сертификации, и сертификат сервера теперь правильно распознаются в своих соответствующих ролях. Чтобы проверить это, выполните следующую команду из каталога, где находится [.filename]#server.crt#: [source, shell] .... # openssl verify -verbose -CApath . server.crt .... Если [.filename]#slapd# был запущен, перезапустите его. Как указано в [.filename]#/usr/local/etc/rc.d/slapd#, для корректного запуска [.filename]#slapd# при загрузке следующие строки должны быть добавлены в [.filename]#/etc/rc.conf#: [.programlisting] .... slapd_enable="YES" slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap://0.0.0.0/"' slapd_sockets="/var/run/openldap/ldapi" slapd_cn_config="YES" .... [.filename]#slapd# не предоставляет отладку при загрузке. Для этой цели проверьте [.filename]#/var/log/debug.log#, [.filename]#dmesg -a# и [.filename]#/var/log/messages#. Следующий пример добавляет группу `team` и пользователя `john` в базу данных LDAP `domain.example`, которая пока пуста. Сначала создайте файл [.filename]#domain.ldif#: [source, shell] .... # cat domain.ldif dn: dc=domain,dc=example objectClass: dcObject objectClass: organization o: domain.example dc: domain dn: ou=groups,dc=domain,dc=example objectClass: top objectClass: organizationalunit ou: groups dn: ou=users,dc=domain,dc=example objectClass: top objectClass: organizationalunit ou: users dn: cn=team,ou=groups,dc=domain,dc=example objectClass: top objectClass: posixGroup cn: team gidNumber: 10001 dn: uid=john,ou=users,dc=domain,dc=example objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: John McUser uid: john uidNumber: 10001 gidNumber: 10001 homeDirectory: /home/john/ loginShell: /usr/bin/bash userPassword: secret .... См. документацию OpenLDAP для получения более подробной информации. Используйте [.filename]#slappasswd# для замены пароля в открытом тексте `secret` на хеш в `userPassword`. Путь, указанный как `loginShell`, должен существовать во всех системах, где `john` имеет право входить. Наконец, используйте администратора `mdb` для изменения базы данных: [source, shell] .... # ldapadd -W -D "cn=mdbadmin,dc=domain,dc=example" -f domain.ldif .... Изменения в разделе _глобальной конфигурации_ могут выполняться только глобальным суперпользователем. Например, предположим, что изначально была указана опция `olcTLSCipherSuite: HIGH:MEDIUM:SSLv3`, которую теперь необходимо удалить. Сначала создайте файл, содержащий следующее: [source, shell] .... # cat global_mod dn: cn=config changetype: modify delete: olcTLSCipherSuite .... Затем примените изменения: [source, shell] .... # ldapmodify -f global_mod -x -D "cn=config" -W .... При запросе введите пароль, выбранный в разделе _бэкенда конфигурации_. Имя пользователя не требуется: здесь `cn=config` представляет DN раздела базы данных, который нужно изменить. Или используйте `ldapmodify` для удаления отдельной строки базы данных или `ldapdelete` для удаления всей записи. Если что-то пойдет не так или если глобальный суперпользователь не сможет получить доступ к бэкенду конфигурации, можно удалить и перезаписать всю конфигурацию: [source, shell] .... # rm -rf /usr/local/etc/openldap/slapd.d/ .... [.filename]#slapd.ldif# затем можно отредактировать и снова импортировать. Пожалуйста, следуйте этой процедуре только в том случае, если нет другого доступного решения. Это конфигурация только сервера. На той же машине также может быть размещен LDAP-клиент с собственной отдельной конфигурацией. [[network-dhcp]] == Протокол динамической конфигурации узла (DHCP) Протокол динамической конфигурации узла (DHCP —Dynamic Host Configuration Protocol) позволяет системе подключаться к сети для получения необходимой адресной информации для общения в этой сети. FreeBSD включает версию `dhclient` от OpenBSD, которая используется клиентом для получения адресной информации. FreeBSD не устанавливает сервер DHCP, но несколько серверов доступны в коллекции портов FreeBSD. Протокол DHCP полностью описан в http://www.freesoft.org/CIE/RFC/2131/[RFC 2131]. Информационные ресурсы также доступны на http://www.isc.org/downloads/dhcp/[isc.org/downloads/dhcp/]. Этот раздел описывает, как использовать встроенный DHCP-клиент. Затем он описывает, как установить и настроить DHCP-сервер. [NOTE] ==== В FreeBSD устройство man:bpf[4] необходимо как для сервера DHCP, так и для клиента DHCP. Это устройство включено в ядро [.filename]#GENERIC#, которое устанавливается с FreeBSD. Пользователям, предпочитающим создавать собственное ядро, необходимо оставить это устройство, если используется DHCP. Следует отметить, что [.filename]#bpf# также позволяет привилегированным пользователям запускать анализаторы сетевых пакетов в этой системе. ==== === Настройка клиента DHCP Поддержка DHCP-клиента включена в установщик FreeBSD, что позволяет легко настроить новую систему для автоматического получения сетевой адресации от существующего DHCP-сервера. Примеры настройки сети можно найти в разделе crossref:bsdinstall[bsdinstall-post,"Учётные записи, Часовая зона, Службы и Защита"]. Когда `dhclient` выполняется на клиентской машине, он начинает транслировать запросы на получение конфигурационной информации. По умолчанию эти запросы используют UDP-порт 68. Сервер отвечает на UDP-порту 67, предоставляя клиенту IP-адрес и другую соответствующую сетевую информацию, такую как маска подсети, шлюз по умолчанию и адреса DNS-серверов. Эта информация предоставляется в форме "аренды" DHCP и действительна в течение настраиваемого времени. Это позволяет автоматически повторно использовать устаревшие IP-адреса для клиентов, которые больше не подключены к сети. Клиенты DHCP могут получить от сервера большое количество информации. Полный список можно найти в man:dhcp-options[5]. По умолчанию, при загрузке системы FreeBSD её DHCP-клиент работает в фоновом режиме или _асинхронно_. Другие скрипты запуска продолжают выполняться, пока завершается процесс DHCP, что ускоряет загрузку системы. DHCP в фоновом режиме работает хорошо, когда сервер DHCP быстро отвечает на запросы клиента. Однако на некоторых системах выполнение DHCP может занять много времени. Если сетевые службы пытаются запуститься до того, как DHCP назначит информацию о сетевой адресации, они завершатся с ошибкой. Использование DHCP в _синхронном_ режиме предотвращает эту проблему, приостанавливая запуск до завершения настройки DHCP. Эта строка в [.filename]#/etc/rc.conf# используется для настройки фонового или асинхронного режима: [.programlisting] .... ifconfig_fxp0="DHCP" .... Эта строка может уже существовать, если система была настроена на использование DHCP во время установки. Замените `_fxp0_`, указанный в этих примерах, на имя интерфейса, который нужно настроить динамически, как описано в crossref:config[config-network-setup,"Настройка сетевых интерфейсов"]. Для настройки системы на использование синхронного режима с приостановкой во время запуска до завершения DHCP используйте "`SYNCDHCP`": [.programlisting] .... ifconfig_fxp0="SYNCDHCP" .... Есть ещё несколько опций клиента. Подробности смотрите в man:rc.conf[5], выполнив поиск по `dhclient`. Клиент DHCP использует следующие файлы: * [.filename]#/etc/dhclient.conf# + Файл конфигурации, используемый `dhclient`. Обычно этот файл содержит только комментарии, так как значения по умолчанию подходят для большинства клиентов. Этот конфигурационный файл описан в man:dhclient.conf[5]. * [.filename]#/sbin/dhclient# + Дополнительную информацию о самой команде можно найти в man:dhclient[8]. * [.filename]#/sbin/dhclient-script# + Специфичный для FreeBSD скрипт конфигурации DHCP-клиента. Он описан в man:dhclient-script[8], но для правильной работы не требует изменений со стороны пользователя. * [.filename]#/var/db/dhclient.leases.interface# + Клиент DHCP сохраняет базу данных действительных аренд в этом файле, который записывается как журнал и описывается в man:dhclient.leases[5]. [[network-dhcp-server]] === Установка и настройка сервера DHCP В этом разделе показано, как настроить систему FreeBSD в качестве DHCP-сервера с использованием реализации DHCP-сервера от Консорциума Интернет-систем (ISC —Internet Systems Consortium). Эту реализацию и её документацию можно установить с помощью пакета package:net/isc-dhcp44-server[] или порта. Установка пакета package:net/isc-dhcp44-server[] включает образец файла конфигурации. Скопируйте [.filename]#/usr/local/etc/dhcpd.conf.example# в [.filename]#/usr/local/etc/dhcpd.conf# и внесите необходимые изменения в этот новый файл. Файл конфигурации состоит из объявлений для подсетей и хостов, которые определяют информацию, предоставляемую клиентам DHCP. Например, следующие строки настраивают следующее: [.programlisting] .... option domain-name "example.org";<.> option domain-name-servers ns1.example.org;<.> option subnet-mask 255.255.255.0;<.> default-lease-time 600;<.> max-lease-time 72400;<.> ddns-update-style none;<.> subnet 10.254.239.0 netmask 255.255.255.224 { range 10.254.239.10 10.254.239.20;<.> option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;<.> } host fantasia { hardware ethernet 08:00:07:26:c0:a5;<.> fixed-address fantasia.fugue.com;<.> } .... <.> Этот параметр задаёт домен поиска по умолчанию, который будет предоставляться клиентам. Дополнительную информацию можно найти в man:resolv.conf[5]. <.> Эта опция определяет разделённый запятыми список DNS-серверов, которые должен использовать клиент. Они могут быть указаны по их Полным Доменным Именам (FQDN), как показано в примере, или по их IP-адресам. <.> Маска подсети, которая будет предоставлена клиентам. <.> Время истечения аренды по умолчанию в секундах. Клиент может быть настроен для переопределения этого значения. <.> Максимально допустимая продолжительность аренды в секундах. Если клиент запросит аренду на более длительный срок, аренда всё равно будет выдана, но будет действительна только в течение `max-lease-time`. <.> Значение по умолчанию `none` отключает динамические обновления DNS. Изменение этого параметра на `interim` настраивает DHCP-сервер на обновление DNS-сервера при каждой выдаче аренды, чтобы DNS-сервер знал, какие IP-адреса связаны с какими компьютерами в сети. Не изменяйте значение по умолчанию, если DNS-сервер не настроен для поддержки динамического DNS. <.> Эта строка создает пул доступных IP-адресов, зарезервированных для выделения клиентам DHCP. Диапазон адресов должен быть действительным для сети или подсети, указанной в предыдущей строке. <.> Объявляет шлюз по умолчанию, действительный для сети или подсети, указанной перед открывающей скобкой `{`. <.> Указывает аппаратный MAC-адрес клиента, чтобы DHCP-сервер мог распознать клиента при его запросе. <.> Указывает, что данный узел всегда должен получать один и тот же IP-адрес. Использование имени узла корректно, так как DHCP-сервер разрешит имя узла перед возвратом информации об аренде. Этот файл конфигурации поддерживает гораздо больше опций. Подробности и примеры смотрите в dhcpd.conf(5), который устанавливается вместе с сервером. После завершения настройки [.filename]#dhcpd.conf# включите DHCP-сервер в [.filename]#/etc/rc.conf#: [.programlisting] .... dhcpd_enable="YES" dhcpd_ifaces="dc0" .... Замените `dc0` на интерфейс (или интерфейсы, разделенные пробелами), на котором DHCP-сервер должен ожидать запросы от DHCP-клиентов. Запустите сервер, выполнив следующую команду: [source, shell] .... # service isc-dhcpd start .... Любые последующие изменения конфигурации сервера потребуют остановки и последующего запуска службы dhcpd с помощью man:service[8]. Сервер DHCP использует следующие файлы. Обратите внимание, что страницы руководства устанавливаются вместе с серверным программным обеспечением. * [.filename]#/usr/local/sbin/dhcpd# + Дополнительную информацию о сервере dhcpd можно найти в dhcpd(8). * [.filename]#/usr/local/etc/dhcpd.conf# + Файл конфигурации сервера должен содержать всю информацию, которую необходимо предоставить клиентам, а также сведения о работе сервера. Этот конфигурационный файл описан в dhcpd.conf(5). * [.filename]#/var/db/dhcpd.leases# + Сервер DHCP ведёт базу данных выданных аренд в этом файле, который записывается в виде журнала. Обратитесь к dhcpd.leases(5), где приводится несколько более подробное описание. * [.filename]#/usr/local/sbin/dhcrelay# + Этот демон используется в сложных средах, где один DHCP-сервер перенаправляет запрос от клиента другому DHCP-серверу в отдельной сети. Если требуется такая функциональность, установите пакет package:net/isc-dhcp44-relay[] или соответствующий порт. Установка включает dhcrelay(8), где приведены более подробные сведения. [[network-dns]] == Система доменных имён (DNS) Система доменных имён (DNS) — это протокол, который сопоставляет доменные имена с IP-адресами и наоборот. DNS координируется в масштабах Интернета через довольно сложную систему авторитетных корневых серверов, серверов доменов верхнего уровня (TLD — Top Level Domain) и других менее масштабных серверов имен, которые хранят и кэшируют информацию об отдельных доменах. Для выполнения DNS-запросов в системе не обязательно запускать сервер имен. Следующая таблица описывает некоторые термины, связанные с DNS: .Терминология DNS [cols="1,1", frame="none", options="header"] |=== | Термин | Определение |Прямая запись DNS (Forward DNS) |Сопоставление имён хостов с IP-адресами. |Зона ответственности (Origin) |Относится к домену, охватываемому определённым файлом зоны. |Резолвер (Resolver) |Системный процесс, с помощью которого машина запрашивает у сервера имён информацию о зоне. |Обратная запись DNS (Reverse DNS) |Сопоставление IP-адресов с именами хостов. |Корневая зона (Root zone) |Начало иерархии зон Интернета. Все зоны находятся под корневой зоной, аналогично тому, как все файлы в файловой системе находятся под корневым каталогом. |Зона (Zone) |Отдельный домен, поддомен или часть DNS, управляемые одной организацией. |=== Примеры зон: * `.` — так обычно обозначается корневая зона в документации. * `org.` — это домен верхнего уровня (TLD) в корневой зоне. * `example.org.` — это зона под доменом `org.`. * `1.168.192.in-addr.arpa` — это зона, содержащая ссылки на все IP-адреса, входящие в адресное пространство `192.168.1.*`. Как видно, более специфичная часть имени хоста расположена слева. Например, `example.org.` более специфично, чем `org.`, а `org.` более специфично, чем корневая зона. Структура каждой части имени хоста во многом напоминает файловую систему: каталог [.filename]#/dev# находится в корне и так далее. === Причины для запуска сервера имен Серверы имён обычно бывают двух видов: авторитетные DNS-серверы и кэширующие DNS-серверы (также известные как резолвинг-серверы). Авторитетный сервер имён необходим, когда: * Хочется предоставлять DNS-информацию для всего мира, отвечая на запросы авторитетно. * Домен, например `example.org`, зарегистрирован, и IP-адреса должны быть назначены именам хостов в нём. * Блок IP-адресов требует обратных DNS-записей (IP к имени хоста). * Резервный или вторичный сервер имен, называемый подчиненным (slave), будет отвечать на запросы. Кэширующий сервер имён необходим, когда: * Локальный DNS-сервер может кэшировать и отвечать быстрее, чем запрос к внешнему серверу имен. Когда кто-нибудь запрашивает информацию о `www.FreeBSD.org`, резолвер обычно обращается к серверу имён провайдера и получает ответ. При использовании локального кэширующего DNS-сервера запрос во внешний мир выполняется только один раз этим сервером. Дополнительные запросы не будут выходить за пределы локальной сети, так как информация сохраняется в локальном кэше. === Конфигурация DNS-сервера Unbound включён в базовую систему FreeBSD. По умолчанию он предоставляет разрешение DNS только для локальной машины. Хотя пакет базовой системы можно настроить для предоставления служб разрешения за пределами локальной машины, рекомендуется удовлетворять такие требования путём установки Unbound из коллекции портов FreeBSD. Чтобы включить Unbound, добавьте следующую строку в [.filename]#/etc/rc.conf#: [.programlisting] .... local_unbound_enable="YES" .... Любые существующие серверы имён в [.filename]#/etc/resolv.conf# будут настроены как серверы пересылки в новой конфигурации Unbound. [NOTE] ==== Если какой-либо из перечисленных серверов имён не поддерживает DNSSEC, локальное разрешение DNS завершится неудачей. Обязательно протестируйте каждый сервер имён и удалите те, которые не прошли проверку. Следующая команда покажет дерево доверия или ошибку для сервера имен, работающего на `192.168.1.1`: [source, shell] .... % drill -S FreeBSD.org @192.168.1.1 .... ==== После подтверждения поддержки DNSSEC каждым сервером имен, запустите Unbound: [source, shell] .... # service local_unbound onestart .... Это обеспечит обновление [.filename]#/etc/resolv.conf#, чтобы запросы к доменам, защищённым DNSSEC, теперь работали. Например, выполните следующую команду для проверки дерева доверия DNSSEC FreeBSD.org: [source, shell] .... % drill -S FreeBSD.org ;; Number of trusted keys: 1 ;; Chasing: freebsd.org. A DNSSEC Trust tree: freebsd.org. (A) |---freebsd.org. (DNSKEY keytag: 36786 alg: 8 flags: 256) |---freebsd.org. (DNSKEY keytag: 32659 alg: 8 flags: 257) |---freebsd.org. (DS keytag: 32659 digest type: 2) |---org. (DNSKEY keytag: 49587 alg: 7 flags: 256) |---org. (DNSKEY keytag: 9795 alg: 7 flags: 257) |---org. (DNSKEY keytag: 21366 alg: 7 flags: 257) |---org. (DS keytag: 21366 digest type: 1) | |---. (DNSKEY keytag: 40926 alg: 8 flags: 256) | |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) |---org. (DS keytag: 21366 digest type: 2) |---. (DNSKEY keytag: 40926 alg: 8 flags: 256) |---. (DNSKEY keytag: 19036 alg: 8 flags: 257) ;; Chase successful .... === Конфигурация авторитетного сервера имен FreeBSD не предоставляет программное обеспечение авторитетного сервера имён в базовой системе. Пользователям рекомендуется устанавливать сторонние приложения, такие как package:dns/nsd[] или package:dns/bind918[] из пакетов или портов. [[network-zeroconf]] == Сетевое взаимодействие без настройки (mDNS/DNS-SD) https://en.wikipedia.org/wiki/Zero-configuration_networking[Сетевое взаимодействие без настройки] (иногда называемое _Zeroconf_) — это набор технологий, упрощающих настройку сети. Главные составные части Zeroconf: - Линк-локальная адресация, предоставляющая автоматическое назначение числовых сетевых адресов. - Мультикаст DNS (_mDNS_), обеспечивающий автоматическое распространение и разрешение имён хостов. - DNS-Based Service Discovery (_DNS-SD_), обеспечивающий автоматическое обнаружение экземпляров сервисов. === Настройка и запуск Avahi Одной из популярных реализаций zeroconf является https://avahi.org/[Avahi]. Avahi можно установить и настроить с помощью следующих команд: [source, shell] .... # pkg install avahi-app nss_mdns # grep -q '^hosts:.*\' /etc/nsswitch.conf || sed -i "" 's/^hosts: .*/& mdns/' /etc/nsswitch.conf # service dbus enable # service avahi-daemon enable # service dbus start # service avahi-daemon start .... [[network-apache]] == HTTP сервер Apache Веб-сервер с открытым исходным кодом Apache является наиболее широко используемым веб-сервером. FreeBSD не устанавливает этот веб-сервер по умолчанию, но его можно установить из пакета package:www/apache24[] или порта. В этом разделе приведена сводка по настройке и запуску версии 2._x_ HTTP-сервера Apache на FreeBSD. Более подробная информация о Apache 2.X и его директивах конфигурации доступна по ссылке http://httpd.apache.org/[httpd.apache.org]. === Настройка и запуск Apache В FreeBSD основной файл конфигурации сервера Apache HTTP Server устанавливается как [.filename]#/usr/local/etc/apache2x/httpd.conf#, где _x_ обозначает номер версии. Этот текстовый файл в формате ASCII начинается со строк комментариев, обозначенных символом `+#+`. Наиболее часто изменяемые директивы: `ServerRoot "/usr/local"`:: Указывает иерархию каталогов по умолчанию для установки Apache. Исполняемые файлы хранятся в подкаталогах [.filename]#bin# и [.filename]#sbin# корня сервера, а конфигурационные файлы — в подкаталоге [.filename]#etc/apache2x#. `ServerAdmin \you@example.com`:: Замените это на адрес электронной почты для получения сообщений о проблемах с сервером. Этот адрес также появляется на некоторых страницах, сгенерированных сервером, таких как документы об ошибках. `ServerName www.example.com:80`:: Позволяет администратору установить имя хоста, которое отправляется клиентам сервера. Например, можно использовать `www` вместо фактического имени хоста. Если у системы нет зарегистрированного DNS-имени, введите её IP-адрес. Если сервер будет прослушивать альтернативный порт, замените `80` на номер альтернативного порта. `DocumentRoot "/usr/local/www/apache2_x_/data"`:: Каталог, из которого будут обслуживаться документы. По умолчанию все запросы обрабатываются из этого каталога, но символические ссылки и псевдонимы могут использоваться для указания на другие расположения. Всегда рекомендуется создать резервную копию конфигурационного файла Apache по умолчанию перед внесением изменений. После завершения настройки Apache сохраните файл и проверьте конфигурацию с помощью `apachectl`. Запуск команды `apachectl configtest` должен вернуть `Syntax OK`. Чтобы запускать Apache при загрузке системы, добавьте следующую строку в [.filename]#/etc/rc.conf#: [.programlisting] .... apache24_enable="YES" .... Если Apache должен запускаться с нестандартными параметрами, следующую строку можно добавить в [.filename]#/etc/rc.conf# для указания необходимых флагов: [.programlisting] .... apache24_flags="" .... Если apachectl не сообщает об ошибках конфигурации, то запустите `httpd`: [source, shell] .... # service apache24 start .... Службу `httpd` можно проверить, введя `http://_localhost_` в веб-браузере, заменив _localhost_ на полное доменное имя машины, на которой работает `httpd`. Отображаемая веб-страница по умолчанию находится в [.filename]#/usr/local/www/apache24/data/index.html#. Проверить конфигурацию Apache на наличие ошибок после внесения последующих изменений в конфигурацию во время работы `httpd` можно с помощью следующей команды: [source, shell] .... # service apache24 configtest .... [NOTE] ==== Важно отметить, что `configtest` не является стандартом man:rc[8], и не следует ожидать, что он будет работать для всех стартовых скриптов. ==== === Виртуальный хостинг Виртуальный хостинг позволяет запускать несколько веб-сайтов на одном сервере Apache. Виртуальные хосты могут быть _IP-ориентированными_ или _имя-ориентированными_. IP-ориентированный виртуальный хостинг использует разные IP-адреса для каждого сайта. Имя-ориентированный виртуальный хостинг использует заголовки HTTP/1.1 клиента для определения имени хоста, что позволяет сайтам использовать один и тот же IP-адрес. Для настройки Apache с использованием виртуального хоста на основе имён добавьте блок `VirtualHost` для каждого веб-сайта. Например, для веб-сервера с именем `www.domain.tld` и виртуальным доменом `www.someotherdomain.tld` добавьте следующие записи в [.filename]#httpd.conf#: [.programlisting] .... ServerName www.domain.tld DocumentRoot /www/domain.tld ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld .... Для каждого виртуального хоста замените значения `ServerName` и `DocumentRoot` на те, которые должны использоваться. Для получения дополнительной информации о настройке виртуальных хостов обратитесь к официальной документации Apache по адресу: http://httpd.apache.org/docs/vhosts/[http://httpd.apache.org/docs/vhosts/]. === Модули Apache Apache использует модули для расширения функциональности, предоставляемой базовым сервером. Обратитесь к http://httpd.apache.org/docs/current/mod/[http://httpd.apache.org/docs/current/mod/] для получения полного списка и деталей настройки доступных модулей. В FreeBSD некоторые модули могут быть скомпилированы с портом package:www/apache24[]. Введите `make config` в [.filename]#/usr/ports/www/apache24#, чтобы увидеть, какие модули доступны и какие включены по умолчанию. Если модуль не скомпилирован с портом, коллекция портов FreeBSD предоставляет простой способ установки многих модулей. В этом разделе описаны три наиболее часто используемых модуля. ==== Поддержка SSL В прошлом поддержка SSL в Apache требовала дополнительного модуля под названием [.filename]#mod_ssl#. Сейчас это не так, и стандартная установка Apache включает SSL в веб-сервер. Пример настройки поддержки SSL-сайтов доступен в установленном файле [.filename]#httpd-ssl.conf# внутри каталога [.filename]#/usr/local/etc/apache24/extra#. В этом же каталоге также находится пример файла с именем [.filename]#ssl.conf-sample#. Рекомендуется изучить оба файла для правильной настройки защищённых сайтов в веб-сервере Apache. После настройки SSL необходимо раскомментировать следующую строку в основном файле [.filename]#http.conf#, чтобы активировать изменения при следующей перезагрузке или обновлении Apache: [.programlisting] .... #Include etc/apache24/extra/httpd-ssl.conf .... [WARNING] ==== Версии SSL два и три имеют известные уязвимости. Настоятельно рекомендуется использовать версии TLS 1.2 и 1.3 вместо старых вариантов SSL. Это можно сделать, установив следующие параметры в [.filename]#ssl.conf#: ==== [.programlisting] .... SSLProtocol all -SSLv3 -SSLv2 +TLSv1.2 +TLSv1.3 SSLProxyProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 .... Для завершения настройки SSL в веб-сервере раскомментируйте следующую строку, чтобы убедиться, что конфигурация будет загружена в Apache при перезапуске или обновлении: [.programlisting] .... # Secure (SSL/TLS) connections Include etc/apache24/extra/httpd-ssl.conf .... Следующие строки также должны быть раскомментированы в файле [.filename]#httpd.conf# для полной поддержки SSL в Apache: [.programlisting] .... LoadModule authn_socache_module libexec/apache24/mod_authn_socache.so LoadModule socache_shmcb_module libexec/apache24/mod_socache_shmcb.so LoadModule ssl_module libexec/apache24/mod_ssl.so .... Следующий шаг — работа с центром сертификации для установки соответствующих сертификатов в системе. Это создаст цепочку доверия для сайта и предотвратит появление предупреждений о самоподписанных сертификатах. ==== [.filename]#mod_perl# Модуль [.filename]#mod_perl# позволяет писать модули Apache на Perl. Кроме того, встроенный в сервер постоянный интерпретатор избегает накладных расходов на запуск внешнего интерпретатора и задержек при старте Perl. [.filename]#mod_perl# можно установить с помощью пакета package:www/mod_perl2[] или порта. Документация по использованию этого модуля доступна по адресу http://perl.apache.org/docs/2.0/index.html[http://perl.apache.org/docs/2.0/index.html]. ==== [.filename]#mod_php# _PHP: Препроцессор Гипертекста_ (PHP) — это язык программирования общего назначения, который особенно хорошо подходит для веб-разработки. Способный встраиваться в HTML, его синтаксис основан на C, Java(TM) и Perl, что позволяет веб-разработчикам быстро создавать динамически генерируемые веб-страницы. Поддержка PHP для Apache и любых других функций, написанных на этом языке, может быть добавлена путем установки соответствующего порта. Для всех поддерживаемых версий выполните поиск в базе данных пакетов с помощью `pkg`: [source, shell] .... # pkg search php .... Будет отображен список, включающий версии и дополнительные возможности, которые они предоставляют. Компоненты полностью модульные, что означает, что функции включаются путем установки соответствующего порта. Чтобы установить PHP версии 7.4 для Apache, выполните следующую команду: [source, shell] .... # pkg install mod_php74 .... Если необходимо установить какие-либо зависимости, они также будут установлены. По умолчанию PHP не будет включен. Следующие строки необходимо добавить в конфигурационный файл Apache, расположенный в [.filename]#/usr/local/etc/apache24#, чтобы активировать его: [.programlisting] .... SetHandler application/x-httpd-php SetHandler application/x-httpd-php-source .... В дополнение, параметр `DirectoryIndex` в конфигурационном файле также потребуется обновить, и Apache нужно будет перезапустить или перезагрузить, чтобы изменения вступили в силу. Поддержка многих функций PHP также может быть установлена с помощью `pkg`. Например, для установки поддержки XML или SSL установите соответствующие порты: [source, shell] .... # pkg install php74-xml php74-openssl .... Как и ранее, для вступления изменений в силу необходимо перезагрузить конфигурацию Apache, даже в случаях, когда была просто установка модуля. Для выполнения плавного перезапуска с целью перезагрузки конфигурации выполните следующую команду: [source, shell] .... # apachectl graceful .... После завершения установки есть два способа получить установленные модули поддержки PHP и информацию о среде сборки. Первый — установить полный бинарный файл PHP и выполнить команду для получения информации: [source, shell] .... # pkg install php74 .... [source, shell] .... # php -i | less .... Необходимо передать вывод в постраничный просмотрщик, например, `more` или `less`, чтобы упростить восприятие большого объёма вывода. Наконец, для внесения изменений в глобальную конфигурацию PHP существует хорошо документированный файл, установленный в [.filename]#/usr/local/etc/php.ini#. На момент установки этот файл не будет существовать, так как есть две версии на выбор: [.filename]#php.ini-development# и [.filename]#php.ini-production#. Они представляют собой отправные точки, помогающие администраторам в развертывании. ==== Поддержка HTTP2 Поддержка протокола HTTP2 в Apache включена по умолчанию при установке порта с помощью `pkg`. Новая версия HTTP содержит множество улучшений по сравнению с предыдущей версией, включая использование одного соединения с веб-сайтом, что сокращает общее количество циклов TCP-соединений. Кроме того, данные заголовков пакетов сжимаются, а HTTP2 по умолчанию требует шифрования. Когда Apache настроен на использование только HTTP2, веб-браузеры будут требовать безопасное, зашифрованное HTTPS-соединение. Если Apache настроен на использование обеих версий, HTTP1.1 будет считаться резервным вариантом при возникновении проблем с соединением. Хотя это изменение требует от администраторов внесения изменений, они положительные и способствуют более безопасному Интернету для всех. Изменения требуются только для сайтов, которые в настоящее время не используют SSL и TLS. [NOTE] ==== Эта конфигурация зависит от предыдущих разделов, включая поддержку TLS. Рекомендуется выполнить эти инструкции перед продолжением с данной конфигурацией. ==== Начните процесс, включив модуль http2, раскомментировав строку в [.filename]#/usr/local/etc/apache24/httpd.conf#, и замените модуль mpm_prefork на mpm_event, так как первый не поддерживает HTTP2. [.programlisting] .... LoadModule http2_module libexec/apache24/mod_http2.so LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so .... [NOTE] ==== Существует отдельный порт [.filename]#mod_http2#, который доступен. Он предназначен для более быстрого получения исправлений безопасности и ошибок по сравнению с модулем, установленным через встроенный порт [.filename]#apache24#. Он не обязателен для поддержки HTTP2, но доступен. При установке следует использовать [.filename]#mod_h2.so# вместо [.filename]#mod_http2.so# в конфигурации Apache. ==== Существует два метода реализации HTTP2 в Apache; один способ — глобально для всех сайтов и каждого VirtualHost, работающего в системе. Чтобы включить HTTP2 глобально, добавьте следующую строку под директивой ServerName: [.programlisting] .... Protocols h2 http/1.1 .... [NOTE] ==== Для включения HTTP2 в незашифрованном виде используйте h2h2chttp/1.1 в файле [.filename]#httpd.conf#. ==== Наличие здесь h2c позволит передавать незашифрованные данные HTTP2 в системе, но это не рекомендуется. Кроме того, использование здесь http/1.1 позволит системе вернуться к версии протокола HTTP1.1, если это потребуется. Для включения HTTP2 для отдельных VirtualHosts добавьте ту же строку в директиву VirtualHost в файле [.filename]#httpd.conf# или [.filename]#httpd-ssl.conf#. Перезагрузите конфигурацию с помощью команды `apachectl`[parameter]#reload# и проверьте конфигурацию каким-либо из следующих способов после посещения одной из страниц на сервере: [source, shell] .... # grep "HTTP/2.0" /var/log/httpd-access.log .... Это должно вернуть что-то похожее на следующее: [.programlisting] .... 192.168.1.205 - - [18/Oct/2020:18:34:36 -0400] "GET / HTTP/2.0" 304 - 192.0.2.205 - - [18/Oct/2020:19:19:57 -0400] "GET / HTTP/2.0" 304 - 192.0.0.205 - - [18/Oct/2020:19:20:52 -0400] "GET / HTTP/2.0" 304 - 192.0.2.205 - - [18/Oct/2020:19:23:10 -0400] "GET / HTTP/2.0" 304 - .... Другой способ — использование встроенного в веб-браузер отладчика сайтов или `tcpdump`; однако использование любого из этих методов выходит за рамки данного документа. Поддержка обратных прокси-соединений HTTP2 с использованием модуля [.filename]#mod_proxy_http2.so#. При настройке директив ProxyPass или RewriteRules с флагом [P] следует использовать h2:// для соединения. === Динамические веб-сайты В дополнение к mod_perl и mod_php, доступны другие языки для создания динамического веб-содержимого. Среди них Django и Ruby on Rails. ==== Django Django — это фреймворк под лицензией BSD, разработанный для того, чтобы позволить разработчикам быстро создавать высокопроизводительные и элегантные веб-приложения. Он предоставляет объектно-реляционный преобразователь (ORM), позволяющий разрабатывать типы данных как объекты Python. Для этих объектов предоставляется богатый динамический API доступа к базе данных, без необходимости написания разработчиком кода на SQL. Также имеется расширяемая система шаблонов, чтобы логика приложения была отделена от HTML-представления. Django зависит от [.filename]#mod_python# и движка SQL-базы данных. В FreeBSD порт package:www/py-django[] автоматически устанавливает [.filename]#mod_python# и поддерживает базы данных PostgreSQL, MySQL или SQLite, по умолчанию используется SQLite. Чтобы изменить движок базы данных, введите `make config` в [.filename]#/usr/ports/www/py-django#, затем установите порт. После установки Django приложению понадобится каталог проекта вместе с конфигурацией Apache для использования встроенного интерпретатора Python. Этот интерпретатор используется для вызова приложения при обращении к определённым URL на сайте. Для настройки Apache для передачи запросов определённых URL веб-приложению добавьте следующее в [.filename]#httpd.conf#, указав полный путь к каталогу проекта: [.programlisting] .... SetHandler python-program PythonPath "['/dir/to/the/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonAutoReload On PythonDebug On .... Обратитесь к https://docs.djangoproject.com[https://docs.djangoproject.com] для получения дополнительной информации о том, как использовать Django. ==== Ruby on Rails Ruby on Rails — это ещё один фреймворк с открытым исходным кодом для веб-разработки, предоставляющий полный стек разработки. Он оптимизирован для повышения продуктивности веб-разработчиков и позволяет быстро создавать мощные приложения. В FreeBSD его можно установить с помощью пакета package:www/rubygem-rails[] или порта. Обратитесь к http://guides.rubyonrails.org[http://guides.rubyonrails.org] для получения дополнительной информации о том, как использовать Ruby on Rails. [[network-ftp]] == Протокол передачи файлов (FTP) Протокол передачи файлов (FTP — File Transfer Protocol) предоставляет пользователям простой способ передачи файлов на FTP-сервер и с него. В базовую систему FreeBSD включено программное обеспечение FTP-сервера — ftpd. В FreeBSD предусмотрено несколько файлов конфигурации для управления доступом к FTP-серверу. В этом разделе приводится их краткое описание. Подробнее о встроенном FTP-сервере можно узнать в man:ftpd[8]. === Конфигурация Самый важный этап настройки — определение учётных записей, которым будет разрешён доступ к FTP-серверу. В системе FreeBSD существует ряд системных учётных записей, которым не следует разрешать доступ по FTP. Список пользователей, которым запрещён любой доступ по FTP, можно найти в [.filename]#/etc/ftpusers#. По умолчанию в него включены системные учётные записи. Можно добавить дополнительных пользователей, которым не следует разрешать доступ к FTP. В некоторых случаях может быть желательно ограничить доступ некоторых пользователей, не запрещая им полностью использовать FTP. Это можно сделать, создав файл [.filename]#/etc/ftpchroot#, как описано в man:ftpchroot[5]. В этом файле перечислены пользователи и группы, подлежащие ограничениям доступа к FTP. Для обеспечения анонимного доступа по FTP к серверу создайте пользователя с именем `ftp` в системе FreeBSD. Пользователи смогут входить на FTP-сервер под именем `ftp` или `anonymous`. При запросе пароля будет принят любой ввод, но по соглашению в качестве пароля следует использовать адрес электронной почты. FTP-сервер вызовет man:chroot[2] при входе анонимного пользователя, чтобы ограничить доступ только домашним каталогом пользователя `ftp`. Существуют два текстовых файла, которые можно создать для отображения приветственных сообщений клиентам FTP. Содержимое файла [.filename]#/etc/ftpwelcome# будет показано пользователям до появления запроса на вход. После успешного входа будет отображено содержимое файла [.filename]#/etc/ftpmotd#. Обратите внимание, что путь к этому файлу указывается относительно окружения входа, поэтому для анонимных пользователей будет отображаться содержимое файла [.filename]#~ftp/etc/ftpmotd#. После настройки FTP-сервера установите соответствующую переменную в [.filename]#/etc/rc.conf#, чтобы служба запускалась при загрузке: [.programlisting] .... ftpd_enable="YES" .... Чтобы запустить службу сейчас: [source, shell] .... # service ftpd start .... Протестируйте подключение к FTP-серверу, набрав: [source, shell] .... % ftp localhost .... Демон ftpd использует man:syslog[3] для записи сообщений. По умолчанию, демон системного журнала записывает сообщения, связанные с FTP, в [.filename]#/var/log/xferlog#. Местоположение журнала FTP может быть изменено путём редактирования следующей строки в [.filename]#/etc/syslog.conf#: [.programlisting] .... ftp.info /var/log/xferlog .... [NOTE] ==== Имейте в виду потенциальные проблемы, связанные с запуском анонимного FTP-сервера. В частности, хорошо подумайте, прежде чем разрешать анонимным пользователям загружать файлы. Может оказаться, что FTP-сайт станет площадкой для обмена нелицензионным коммерческим программным обеспечением или даже чем-то хуже. Если загрузка файлов анонимными пользователями необходима, убедитесь в правильности настроек прав доступа, чтобы эти файлы не могли быть прочитаны другими анонимными пользователями до тех пор, пока их не проверит администратор. ==== [[network-samba]] == Услуги файлов и печати для клиентов Microsoft(R) Windows(R) (Samba) Samba — это популярный пакет открытого программного обеспечения, предоставляющий файловые и печатные услуги с использованием протокола SMB/CIFS. Этот протокол встроен в системы Microsoft(R) Windows(R). Он может быть добавлен в системы, отличные от Microsoft(R) Windows(R), путем установки клиентских библиотек Samba. Протокол позволяет клиентам получать доступ к общим данным и принтерам. Эти ресурсы могут быть отображены как локальный диск, а общие принтеры могут использоваться так, как если бы они были локальными. На FreeBSD клиентские библиотеки Samba могут быть установлены с помощью порта или пакета package:net/samba416[]. Клиент предоставляет возможность системе FreeBSD получать доступ к общим ресурсам SMB/CIFS в сети Microsoft(R) Windows(R). Система FreeBSD также может быть настроена в качестве сервера Samba путем установки порта или пакета package:net/samba416[]. Это позволяет администратору создавать общие ресурсы SMB/CIFS на системе FreeBSD, к которым могут обращаться клиенты под управлением Microsoft(R) Windows(R) или использующие клиентские библиотеки Samba. === Конфигурация сервера Samba настраивается в файле [.filename]#/usr/local/etc/smb4.conf#. Этот файл должен быть создан до начала использования Samba. Простой пример [.filename]#smb4.conf# для общего доступа к каталогам и принтерам с клиентами Windows(R) в рабочей группе показан ниже. Для более сложных настроек, включающих LDAP или Active Directory, проще использовать man:samba-tool[8] для создания начального [.filename]#smb4.conf#. [.programlisting] .... [global] workgroup = WORKGROUP server string = Samba Server Version %v netbios name = ExampleMachine wins support = Yes security = user passdb backend = tdbsam # Example: share /usr/src accessible only to 'developer' user [src] path = /usr/src valid users = developer writable = yes browsable = yes read only = no guest ok = no public = no create mask = 0666 directory mask = 0755 .... ==== Глобальные настройки Настройки, описывающие сеть, добавляются в [.filename]#/usr/local/etc/smb4.conf#: `workgroup`:: Имя рабочей группы, которая будет обслуживаться. `netbios name`:: Имя NetBIOS, под которым известен сервер Samba. По умолчанию оно совпадает с первой частью DNS-имени хоста. `server string`:: Строка, которая будет отображаться в выводе команды `net view` и некоторых других сетевых инструментов, предназначенных для отображения описательного текста о сервере. `wins support`:: Будет ли Samba выступать в качестве сервера WINS. Не следует включать поддержку WINS более чем на одном сервере в сети. ==== Настройки безопасности Важнейшие настройки в [.filename]#/usr/local/etc/smb4.conf# — это модель безопасности и формат хранения паролей. Эти параметры управляются следующими директивами: `security`:: Если клиенты используют имена пользователей, совпадающие с их именами на машине FreeBSD, следует использовать уровень безопасности пользователя. `security = user` — это политика безопасности по умолчанию, которая требует от клиентов сначала войти в систему, прежде чем они смогут получить доступ к общим ресурсам. + Обратитесь к man:smb.conf[5], чтобы узнать о других поддерживаемых настройках для опции `security`. `passdb backend`:: Samba поддерживает несколько различных моделей аутентификации на стороне сервера. Клиенты могут быть аутентифицированы с помощью LDAP, NIS+, SQL-базы данных или модифицированного файла паролей. Рекомендуемый метод аутентификации `tdbsam` идеально подходит для простых сетей, и мы его рассмотрим здесь. Для более крупных или сложных сетей рекомендуется `ldapsam`. `smbpasswd` был прежним методом по умолчанию и теперь устарел. ==== Пользователи Samba Пользовательские учётные записи FreeBSD должны быть сопоставлены с базой данных `SambaSAMAccount` для доступа клиентов Windows(R) к общему ресурсу. Сопоставьте существующие учётные записи FreeBSD с помощью man:pdbedit[8]: [source, shell] .... # pdbedit -a -u username .... В этом разделе упомянуты только наиболее часто используемые настройки. Дополнительную информацию о доступных параметрах конфигурации можно найти на https://wiki.samba.org[Официальном вики Samba]. === Начало работы с Samba Чтобы включить Samba при загрузке, добавьте следующую строку в [.filename]#/etc/rc.conf#: [.programlisting] .... samba_server_enable="YES" .... Чтобы сейчас запустить Samba: [source, shell] .... # service samba_server start Performing sanity check on Samba configuration: OK Starting nmbd. Starting smbd. .... Samba состоит из трёх отдельных демонов. Оба демона nmbd и smbd запускаются параметром `samba_enable`. Если также требуется разрешение имён через winbind, укажите: [.programlisting] .... winbindd_enable="YES" .... Samba можно остановить в любой момент, набрав: [source, shell] .... # service samba_server stop .... Samba — это комплексный программный комплект, функциональность которого обеспечивает широкую интеграцию с сетями Microsoft(R) Windows(R). Для получения дополнительной информации о возможностях, выходящих за рамки базовой конфигурации, описанной здесь, обратитесь к https://www.samba.org[https://www.samba.org]. [[network-ntp]] == Синхронизация времени с помощью NTP Со временем часы компьютера могут отставать или спешить. Это создаёт проблемы, так как многие сетевые службы требуют, чтобы компьютеры в сети использовали одинаковое точное время. Точное время также необходимо для обеспечения согласованности временных меток файлов. Протокол сетевого времени (NTP — Network Time Protocol) — это один из способов обеспечить точность часов в сети. FreeBSD включает man:ntpd[8], который можно настроить для запроса к другим серверам NTP с целью синхронизации часов на этом компьютере или для предоставления сервиса времени другим компьютерам в сети. В этом разделе описывается, как настроить ntpd в FreeBSD. Дополнительная документация доступна в [.filename]#/usr/share/doc/ntp/# в формате HTML. === Конфигурация NTP На FreeBSD встроенный ntpd может использоваться для синхронизации системных часов. Настройка ntpd осуществляется с помощью переменных man:rc.conf[5] и файла [.filename]#/etc/ntp.conf#, как подробно описано в следующих разделах. ntpd взаимодействует с сетевыми узлами с помощью UDP-пакетов. Любые межсетевые экраны между вашей машиной и её NTP-узлами должны быть настроены так, чтобы разрешать входящие и исходящие UDP-пакеты через порт 123. ==== Файл [.filename]#/etc/ntp.conf# ntpd читает файл [.filename]#/etc/ntp.conf#, чтобы определить, к каким серверам NTP обращаться. Рекомендуется выбирать несколько серверов NTP на случай, если один из серверов станет недоступен или его часы окажутся ненадёжными. По мере получения ответов ntpd отдаёт предпочтение более надёжным серверам перед менее надёжными. Запрашиваемые серверы могут быть локальными в сети, предоставляться ISP или выбираться из http://support.ntp.org/bin/view/Servers/WebHome[онлайн-списка общедоступных серверов NTP]. При выборе общедоступного сервера NTP следует выбирать сервер, географически близкий к вам, и ознакомиться с его политикой использования. Ключевое слово `pool` в конфигурации выбирает один или несколько серверов из пула серверов. Доступен http://support.ntp.org/bin/view/Servers/NTPPoolServers[онлайн-список общедоступных пулов NTP], организованный по географическим регионам. Кроме того, FreeBSD предоставляет спонсируемый проектом пул `0.freebsd.pool.ntp.org`. .Пример [.filename]#/etc/ntp.conf# [example] ==== Вот простой пример файла [.filename]#ntp.conf#. Его можно безопасно использовать в таком виде; он содержит рекомендуемые параметры `restrict` для работы в общедоступном сетевом подключении. [.programlisting] .... # Disallow ntpq control/query access. Allow peers to be added only # based on pool and server statements in this file. restrict default limited kod nomodify notrap noquery nopeer restrict source limited kod nomodify notrap noquery # Allow unrestricted access from localhost for queries and control. restrict 127.0.0.1 restrict ::1 # Add a specific server. server ntplocal.example.com iburst # Add FreeBSD pool servers until 3-6 good servers are available. tos minclock 3 maxclock 6 pool 0.freebsd.pool.ntp.org iburst # Use a local leap-seconds file. leapfile "/var/db/ntpd.leap-seconds.list" .... ==== Формат этого файла описан в man:ntp.conf[5]. Приведённые ниже описания дают краткий обзор только ключевых слов, использованных в примере файла выше. По умолчанию сервер NTP доступен для любого узла сети. Ключевое слово `restrict` управляет тем, какие системы могут обращаться к серверу. Поддерживается несколько записей `restrict`, каждая из которых уточняет ограничения, заданные в предыдущих утверждениях. Значения, указанные в примере, предоставляют локальной системе полный доступ для запросов и управления, в то время как удалённые системы могут только запрашивать время. Для получения дополнительной информации обратитесь к подразделу `Access Control Support` в man:ntp.conf[5]. Ключевое слово `server` указывает отдельный сервер для запросов. Файл может содержать несколько ключевых слов `server`, по одному серверу на каждой строке. Ключевое слово `pool` определяет пул серверов. ntpd добавит один или несколько серверов из этого пула по мере необходимости, чтобы достичь количества узлов, указанного с помощью значения `tos minclock`. Ключевое слово `iburst` предписывает ntpd выполнить серию из восьми быстрых обменов пакетами с сервером при первом установлении соединения, чтобы быстро синхронизировать системное время. Ключевое слово `leapfile` указывает расположение файла, содержащего информацию о високосных секундах. Этот файл автоматически обновляется с помощью man:periodic[8]. Указанное расположение файла должно соответствовать значению переменной `ntp_db_leapfile` в файле [.filename]#/etc/rc.conf#. ==== Записи NTP в [.filename]#/etc/rc.conf# Установите `ntpd_enable=YES` для запуска ntpd при загрузке. После добавления `ntpd_enable=YES` в [.filename]#/etc/rc.conf#, ntpd можно немедленно запустить без перезагрузки системы, введя: [source, shell] .... # service ntpd start .... Для использования ntpd необходимо установить только `ntpd_enable`. При необходимости также могут быть заданы перечисленные ниже переменные [.filename]#rc.conf#. Установите `ntpd_sync_on_start=YES`, чтобы разрешить ntpd однократно корректировать время при запуске на любую величину. Обычно ntpd записывает сообщение об ошибке и завершает работу, если расхождение времени превышает 1000 секунд. Эта опция особенно полезна для систем без аккумуляторного резервного питания часов реального времени. Установите `ntpd_oomprotect=YES`, чтобы защитить демон ntpd от завершения системой при попытке восстановиться после состояния нехватки памяти (OOM). Установите в значении`ntpd_config=` расположение альтернативного файла [.filename]#ntp.conf#. Установите `ntpd_flags=` с любыми другими флагами ntpd по необходимости, но избегайте использования тех флагов, которые устанавливаются внутри файла [.filename]#/etc/rc.d/ntpd#: * `-p` (расположение pid-файла) * `-c` (вместо этого установите `ntpd_config=` ) ==== ntpd и непривилегированный пользователь `ntpd` ntpd в FreeBSD может запускаться и работать как непривилегированный пользователь. Для этого требуется модуль политики man:mac_ntpd[4]. Скрипт запуска [.filename]#/etc/rc.d/ntpd# сначала проверяет конфигурацию NTP. Если возможно, он загружает модуль `mac_ntpd`, а затем запускает ntpd как непривилегированный пользователь `ntpd` (идентификатор пользователя 123). Чтобы избежать проблем с доступом к файлам и каталогам, скрипт запуска не будет автоматически запускать ntpd как `ntpd`, если конфигурация содержит любые файлозависимые параметры. Присутствие любого из следующих параметров в `ntpd_flags` требует ручной настройки, как описано ниже, для запуска от пользователя `ntpd`: * -f or --driftfile * -i or --jaildir * -k or --keyfile * -l or --logfile * -s or --statsdir Наличие любого из следующих ключевых слов в [.filename]#ntp.conf# требует ручной настройки, как описано ниже, для запуска от пользователя `ntpd`: * crypto * driftfile * key * logdir * statsdir Для ручной настройки ntpd для запуска от пользователя `ntpd` необходимо: * Убедитесь, что пользователь `ntpd` имеет доступ ко всем файлам и каталогам, указанным в конфигурации. * Обеспечьте загрузку или компиляцию модуля `mac_ntpd` в ядро. Подробности см. в man:mac_ntpd[4]. * Установите `ntpd_user="ntpd"` в [.filename]#/etc/rc.conf# === Использование NTP с PPP-подключением ntpd не требует постоянного подключения к Интернету для корректной работы. Однако, если PPP-соединение настроено на дозвон по требованию, следует предотвратить инициацию дозвона или поддержание соединения из-за трафика NTP. Это можно настроить с помощью директив `filter` в [.filename]#/etc/ppp/ppp.conf#. Например: [.programlisting] .... set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 .... Для получения более подробной информации обратитесь к разделу `ФИЛЬТРАЦИЯ ПАКЕТОВ` в man:ppp[8] и примерам в [.filename]#/usr/share/examples/ppp/#. [NOTE] ==== Некоторые интернет-провайдеры блокируют порты с низкими номерами, что мешает работе NTP, так как ответы никогда не достигают машины. ==== [[network-iscsi]] == Настройка инициатора и цели iSCSI iSCSI — это способ совместного использования хранилища по сети. В отличие от NFS, который работает на уровне файловой системы, iSCSI работает на уровне блочного устройства. В терминологии iSCSI система, предоставляющая хранилище, называется _целью_. Хранилище может быть физическим диском, областью, представляющей несколько дисков, или частью физического диска. Например, если диск(и) отформатированы с использованием ZFS, можно создать zvol для использования в качестве хранилища iSCSI. Клиенты, которые обращаются к хранилищу iSCSI, называются _инициаторами_. Для инициаторов хранилище, доступное через iSCSI, отображается как неформатированный диск, известный как LUN (логический номер устройства). Узлы устройств для диска появляются в [.filename]#/dev/#, и устройство должно быть отдельно отформатировано и смонтировано. FreeBSD предоставляет встроенную поддержку iSCSI целевой системы и инициатора на уровне ядра. В этом разделе описывается, как настроить систему FreeBSD в качестве целевой системы или инициатора. [[network-iscsi-target]] === Настройка цели iSCSI Для настройки цели iSCSI создайте конфигурационный файл [.filename]#/etc/ctl.conf#, добавьте строку в [.filename]#/etc/rc.conf#, чтобы убедиться, что демон man:ctld[8] автоматически запускается при загрузке, а затем запустите демон. Вот пример простого файла конфигурации [.filename]#/etc/ctl.conf#. Полное описание доступных опций этого файла можно найти в man:ctl.conf[5]. [.programlisting] .... portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group no-authentication portal-group pg0 lun 0 { path /data/target0-0 size 4G } } .... Первая запись определяет группу порталов `pg0`. Группы порталов определяют, на каких сетевых адресах будет слушать демон man:ctld[8]. Запись `discovery-auth-group no-authentication` указывает, что любой инициатор может выполнять обнаружение целей iSCSI без аутентификации. Третья и четвёртая строки настраивают man: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. Этот путь должен существовать до запуска man:ctld[8]. Вторая строка необязательна и указывает размер LUN. Далее, чтобы убедиться, что демон man:ctld[8] запускается при загрузке, добавьте эту строку в [.filename]#/etc/rc.conf#: [.programlisting] .... ctld_enable="YES" .... Чтобы запустить man:ctld[8] сейчас, выполните следующую команду: [source, shell] .... # service ctld start .... Поскольку демон man:ctld[8] запускается, он читает файл [.filename]#/etc/ctl.conf#. Если этот файл был изменён после запуска демона, используйте следующую команду, чтобы изменения вступили в силу немедленно: [source, shell] .... # service ctld reload .... ==== Аутентификация Предыдущий пример изначально небезопасен, так как не использует аутентификацию, предоставляя любому полный доступ ко всем целям. Чтобы потребовать имя пользователя и пароль для доступа к целям, измените конфигурацию следующим образом: [.programlisting] .... auth-group ag0 { chap username1 secretsecret chap username2 anothersecret } portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group ag0 portal-group pg0 lun 0 { path /data/target0-0 size 4G } } .... Раздел `auth-group` определяет пары имени пользователя и пароля. Инициатор, пытающийся подключиться к `iqn.2012-06.com.example:target0`, должен сначала указать определённое имя пользователя и секрет. Однако обнаружение цели по-прежнему разрешено без аутентификации. Чтобы потребовать аутентификацию при обнаружении цели, установите `discovery-auth-group` в определённое имя `auth-group` вместо `no-authentication`. Обычно определяют один экспортируемый объект для каждого инициатора. В качестве сокращения для синтаксиса выше, имя пользователя и пароль могут быть указаны непосредственно в записи объекта: [.programlisting] .... target iqn.2012-06.com.example:target0 { portal-group pg0 chap username1 secretsecret lun 0 { path /data/target0-0 size 4G } } .... [[network-iscsi-initiator]] === Настройка инициатора iSCSI [NOTE] ==== Описанный в этом разделе инициатор iSCSI поддерживается начиная с FreeBSD 10.0-RELEASE. Для использования инициатора iSCSI, доступного в более старых версиях, обратитесь к man:iscontrol[8]. ==== Инициатору iSCSI требуется, чтобы демон man:iscsid[8] был запущен. Этот демон не использует файл конфигурации. Для его автоматического запуска при загрузке добавьте следующую строку в [.filename]#/etc/rc.conf#: [.programlisting] .... iscsid_enable="YES" .... Чтобы сейчас запустить man:iscsid[8], выполните следующую команду: [source, shell] .... # service iscsid start .... Подключение к цели может быть выполнено с файлом конфигурации [.filename]#/etc/iscsi.conf# или без него. В этом разделе показаны оба типа подключений. ==== Подключение к цели без файла конфигурации Для подключения инициатора к одному целевому устройству укажите IP-адрес портала и имя целевого устройства: [source, shell] .... # iscsictl -A -p 10.10.10.10 -t iqn.2012-06.com.example:target0 .... Для проверки успешности соединения выполните команду `iscsictl` без аргументов. Вывод должен выглядеть примерно так: [.programlisting] .... Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Connected: da0 .... В этом примере сеанс iSCSI был успешно установлен, где [.filename]#/dev/da0# представляет подключённый LUN. Если цель `iqn.2012-06.com.example:target0` экспортирует более одного LUN, в соответствующем разделе вывода будет показано несколько устройств: [source, shell] .... Connected: da0 da1 da2. .... Любые ошибки будут отображены в выводе, а также в системных журналах. Например, это сообщение обычно означает, что демон man:iscsid[8] не запущен: [.programlisting] .... Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Waiting for iscsid(8) .... Следующее сообщение указывает на проблему с сетью, например, неверный IP-адрес или порт: [.programlisting] .... Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.11 Connection refused .... Это сообщение означает, что указано неправильное имя цели: [.programlisting] .... Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Not found .... Это сообщение означает, что цель требует аутентификации: [.programlisting] .... Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Authentication failed .... Чтобы указать имя пользователя CHAP и секрет, используйте следующий синтаксис: [source, shell] .... # iscsictl -A -p 10.10.10.10 -t iqn.2012-06.com.example:target0 -u user -s secretsecret .... ==== Подключение к цели с использованием файла конфигурации Для подключения с использованием файла конфигурации создайте файл [.filename]#/etc/iscsi.conf# с содержимым, подобным этому: [.programlisting] .... t0 { TargetAddress = 10.10.10.10 TargetName = iqn.2012-06.com.example:target0 AuthMethod = CHAP chapIName = user chapSecret = secretsecret } .... `t0` задаёт псевдоним для раздела конфигурационного файла. Он будет использоваться инициатором для указания, какую конфигурацию применять. Остальные строки определяют параметры, используемые при подключении. `TargetAddress` и `TargetName` являются обязательными, тогда как остальные параметры — опциональными. В этом примере показаны имя пользователя CHAP и секретный ключ. Для подключения к указанной цели укажите псевдоним: [source, shell] .... # iscsictl -An t0 .... Или для подключения ко всем целям, определённым в файле конфигурации, используйте: [source, shell] .... # iscsictl -Aa .... Чтобы инициатор автоматически подключался ко всем целям в [.filename]#/etc/iscsi.conf#, добавьте следующее в [.filename]#/etc/rc.conf#: [.programlisting] .... iscsictl_enable="YES" iscsictl_flags="-Aa" ....