diff --git a/ru_RU.KOI8-R/books/handbook/config/chapter.sgml b/ru_RU.KOI8-R/books/handbook/config/chapter.sgml index 341e52951b..02f21574d8 100644 --- a/ru_RU.KOI8-R/books/handbook/config/chapter.sgml +++ b/ru_RU.KOI8-R/books/handbook/config/chapter.sgml @@ -1,3152 +1,3189 @@ Chern Lee Написал Mike Smith Основывается на учебнике, написанном Matt Dillon и на tuning(7), написанном Андрей Мельник Перевод на русский язык: Денис Пеплин Валерий Кравчук Настройка и оптимизация Введение настройка системы оптимизация системы Один из важных аспектов &os; это настройка системы. Правильная настройка системы поможет избежать головной боли при последующих обновлениях. Эта глава описывает большую часть процесса настройки &os;, включая некоторые параметры, которые можно установить для оптимизации системы &os;. После прочтения этой главы вы узнаете: Как эффективно работать с файловыми системами и разделами подкачки. Основы настройки rc.conf и системы запуска приложений /usr/local/etc/rc.d. Как настроить и протестировать сетевую карту. Как настроить виртуальные хосты на сетевых устройствах. Как использовать различные файлы конфигурации в /etc. Как оптимизировать &os;, используя переменные sysctl. Как увеличить скорость работы дисков и изменить ограничения, накладываемые ядром. Перед прочтением этой главы вам следует: Понять основы &unix; и &os; (). Ознакомиться с основами конфигурации/компиляции ядра (). Начальное конфигурирование Разделы диска разделы диска /etc /var /usr Основы построения разделов Во время разметки жёсткого диска с помощью &man.disklabel.8; или &man.sysinstall.8;, важно помнить, что скорость чтения и записи данных уменьшается от внешних к внутренним трекам диска. Самые маленькие и самые часто используемые файловые системы (корневая и раздел подкачки) должны быть расположены в начале диска, в то время как самые большие, такие, как /usr, в конце. Самым оптимальным считается следующий порядок расположения файловых систем: root, swap, /var, /usr. Размер файловой системы /var определяется предназначением машины. /var используется для хранения почтовых ящиков, очередей печати и лог файлов. Размер почтовых ящиков и лог файлов может расти неограниченно в зависимости от количества пользователей системы и от того, как долго хранятся лог-файлы. Большинству пользователей никогда не потребуется гигабайт, но помните, что /var/tmp должен быть достаточно большим для пакетов. В разделе /usr содержит большинство файлов, необходимых для поддержки системы, порты (&man.ports.7;, рекомендуется) и исходные тексты (опционально). Оба эти каталога опциональны при установке. Для этого раздела рекомендуется как минимум 2 гигабайта. При установке размера разделов, не забудьте принять во внимание рост размера требуемого системе дискового пространства. Переполнение одного раздела даже при наличии свободного места на другом может вызвать затруднения. Многие пользователи обнаружили, что размер разделов, предлагаемый &man.sysinstall.8;'ом по умолчанию, иногда меньше подходящего для разделов /var и /. Тщательно планируйте размер разделов и не жалейте места. Раздел подкачки размер раздела подкачки раздел подкачки Как правило, размер раздела подкачки должен быть равен удвоенному размеру оперативной памяти. Например, если на машине установлено 128 мегабайт памяти, раздел подкачки должен быть 256 мегабайт. Системы с меньшим количеством памяти могут работать лучше с большим объёмом раздела подкачки. Не рекомендуется устанавливать размер раздела подкачки меньше 256 мегабайт, необходимо также принять во внимание возможное наращивание объема установленной на машине памяти. Алгоритмы кэширования VM настроены на максимальное быстродействие, когда размер раздела подкачки равен как минимум удвоенному размеру памяти. Заниженный размер раздела подкачки может привести к неэффективной работе постраничного сканирования VM и вызвать проблемы при увеличении объёма памяти. На больших системах с несколькими SCSI дисками (или несколькими IDE дисками, находящимися на разных контроллерах), рекомендуется создавать раздел подкачки на каждом диске (до четырёх дисков). Разделы подкачки должны быть примерно одного размера. Ядро не накладывает ограничений на размер раздела подкачки, но внутренние структуры позволяют иметь общий размер разделов подкачки, равный наибольшему, умноженному на четыре. Выделение под разделы подкачки примерно одинакового места позволить ядру оптимально расположить разделы подкачки. Установка размера подкачки больше требуемого нормальна, даже если этот объем не используется. В этих условиях может быть проще восстановиться после зависания программы перед тем, как возникнет необходимость перезагрузки. Зачем нужны разделы? Некоторые пользователи считают, что лучше использовать один большой раздел, но есть несколько причин, по которым этого лучше не делать. Во-первых, у каждого раздела свои характеристики, и отделяя их, можно выполнить соответствующие настройки. Например, корневая и файловая система и /usr в основном предназначены для чтения, без большого объема записи. В то же время множество операций чтения и записи выполняется в /var и /var/tmp. При правильном размещении и выборе размера разделов системы, фрагментация в более маленьких разделах, куда часто записываются данные, не перенесётся на остальные разделы. Размещение самых часто используемых разделов ближе к началу диска увеличит скорость ввода/вывода там, где она нужна больше всего. Хотя производительность важна и для больших дисков, передвижение их ближе к концу диска не повлечёт значительного уменьшения быстродействия по сравнению с перемещением ближе к концу диска /var. И, наконец, разделы существуют и из соображений безопасности. Наличие маленького аккуратного корневого раздела, доступного только для чтения даёт значительные шансы на "выживание" после краха системы. Основные настройки rc файлы rc.conf Основные настройки системы располагаются в /etc/rc.conf. Этот файл вмещает широкий спектр конфигурационной информации, используемой при загрузке системы. Имя этого файла прямо отражает его назначение, это файл настройки для файлов rc*. Администратор должен сделать записи в rc.conf, чтобы переопределить строки по умолчанию из /etc/defaults/rc.conf. Файлы по умолчанию нельзя копировать в /etc — они вмещают значения по умолчанию, а не примеры значений. Все специфичные для данной системы изменения должны быть сделаны в файле rc.conf. Существует несколько методов для отделения общей конфигурации для группы систем от конкретной для данной системы в целях уменьшения объема работы администратора. Рекомендуемый метод — прописать общую конфигурацию в отдельный файл, например, в /etc/rc.conf.site, и включить его название в /etc/rc.conf, который вмещает только специфичную для данной системы информацию. Поскольку rc.conf читается &man.sh.1;, есть тривиальный способ сделать это. Например: rc.conf: . /etc/rc.conf.site hostname="node15.example.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" Файл rc.conf.site может быть распространён на все системы, используя rsync или подобную ей программу, в то время, как rc.conf должен остаться только на одной машине. Обновление системы с помощью &man.sysinstall.8; или make world не повлекут за собой перезапись rc.conf. Вся информация в этом файле сохранится. Настройка приложений Обычно, установленные приложения имеют свои конфигурационные файлы, со своим собственным синтаксисом. Важно хранить эти файлы отдельно от файлов основной системы, чтобы их можно было легко администрировать с помощью средств управления пакетами. /usr/local/etc Обычно эти файлы устанавливаются в /usr/local/etc. В случае, если приложению нужно большое количество конфигурационных файлов, для их хранения будет создан подкаталог. Обычно, вместе с установкой портов и пакетов, устанавливаются и примеры конфигурационных файлов. Обычно они имеют расширение .default. Если не существует конфигурационных файлов для этого приложения, они будут созданы путём копирования .default файлов. Например, /usr/local/etc/apache: -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default Размеры файлов показывают, что только файл srm.conf был изменён. При следующем обновлении Apache этот файл уже не будет перезаписан. Tom Rhodes Предоставил Запуск сервисов сервисы Многие пользователи предпочитают устанавливать программы сторонних производителей в &os; из набора портов. В подобных случаях может потребоваться сконфигурировать программы так, чтобы они запускались при инициализации системы. Сервисы, такие как mail/postfix или www/apache13, — это лишь два примера множества программных пакетов, которые можно запускать при инициализации системы. В этом разделе описывается процедура, предназначенная для запуска программ сторонних разработчиков. Большинство входящих в &os; сервисов, таких как &man.cron.8;, запускается с помощью стартовых скриптов системы. Эти скрипты могут различаться в зависимости от версии &os; или ее производителя; однако важнее всего учитывать, что их начальную конфигурацию можно задать с помощью простых стартовых скриптов. До появления rcNG приложения должны были помещать простой стартовый скрипт в каталог /usr/local/etc/rc.d, который затем читался скриптами инициализации системы. Эти скрипты затем выполнялись в ходе последующих стадий запуска системы. Хотя много разработчиков потратили часы на попытки внедрить старый стиль конфигурирования в новую систему, остаётся фактом, что для некоторых утилит сторонних производителей по-прежнему необходим скрипт, помещённый в указанный выше каталог. Незначительные различия в скриптах зависят от того, используется ли rcNG. До версии &os; 5.1 использовались скрипты в старом стиле, и почти во всех случаях скрипты в новом стиле должны подойти так же хорошо. Хотя каждый скрипт должен соответствовать некоторым минимальным требованиям, в большинстве случаев эти требования не зависят от версии &os;. Каждый скрипт должен иметь в конце расширение .sh и каждый скрипт должен быть выполняемым. Последнее требование может быть выполнено путем установки командой chmod уникальных прав доступа 755. Также, как минимум, должна быть опция start для запуска приложения и опция stop для его остановки. Простейший стартовый скрипт, пожалуй, будет похож на следующий: #!/bin/sh echo -n ' utility' case "$1" in start) /usr/local/bin/utility ;; stop) kill -9 `cat /var/run/utility.pid` ;; *) - echo "Usage: `basename $0` {start|stop}" >&2 + echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Этот скрипт поддерживает опции stop и start для приложения, которое мы здесь называем просто — utility. А можно запускать его и вручную, с помощью команды: &prompt.root; /usr/local/etc/rc.d/utility.sh start Хотя и не все программы сторонних производителей требуют добавления строки в файл rc.conf, практически каждый день очередной новый порт меняется так, чтобы поддерживать подобную конфигурацию. Поищите в результатах, выдаваемых после установки более детальную информацию по конкретному приложению. Некоторые программы сторонних производителей будут включать стартовые скрипты, позволяющие использовать приложение с rcNG; но это мы еще обсудим в следующем разделе. Расширенное конфигурирование приложения Теперь, когда &os; включает rcNG, конфигурирование запуска приложений стало более оптимальным; фактически, оно стало более тщательным. С помощью ключевых слов, рассмотренных в разделе rcNG, приложения теперь можно настроить для запуска после других заданных сервисов, например, DNS; можно разрешить передачу дополнительных флагов через rc.conf вместо жесткого задания флагов в стартовых скриптах, и т.д. Простой скрипт может иметь следующий вид: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: FreeBSD shutdown # # НЕ МЕНЯЙТЕ ЗДЕСЬ ЭТИ СТАНДАРТНЫЕ ЗНАЧЕНИЯ # ЗАДАВАЙТЕ ИХ В ФАЙЛЕ /etc/rc.conf # utility_enable=${utility_enable-"NO"} utility_flags=${utility_flags-""} utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name pidfile="${utility_pidfile}" start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" run_rc_command "$1" Этот скрипт будет гарантировать, что указанное приложение utility будет запущено перед сервисом login, но после сервиса daemon. Он также предоставляет метод для создания и отслеживания файла идентификатора процесса, PID. Для этого приложения затем можно поместить следующую строку в файл /etc/rc.conf: utility_enable="YES" Этот новый метод также позволяет легко работать с аргументами командной строки, включать стандартные функции из файла /etc/rc.subr, обеспечивает совместимость с утилитой &man.rcorder.8; и упрощает конфигурирование с помощью файла rc.conf. По сути, этот сценарий можно даже поместить в каталог /etc/rc.d. Это, однако, потенциально может сбить с толку утилиту &man.mergemaster.8; при обновлениях программного обеспечения. Использование сервисов для запуска сервисов Другие сервисы, такие как даемоны сервера POP3, IMAP, и т.п. могут быть запущены с помощью &man.inetd.8;. Для этого необходимо установить сервисную утилиту из набора портов и добавить соответствующую строчку конфигурации в файл /etc/inetd.conf или раскомментировать подходящую строку конфигурации из уже имеющихся. Работа с даемоном inetd и его конфигурирование подробно описаны в разделе inetd. В некоторых случаях использование для запуска системных служб даемона &man.cron.8; может оказаться более приемлемым. Этот подход имеет несколько преимуществ, поскольку даемон cron запускает эти процессы от имени владельца файла crontab. Это позволяет обычным пользователям запускать и поддерживать некоторые приложения. Утилита cron поддерживает уникальную возможность, @reboot, — это значение можно использовать вместо спецификации времени. В результате, задание будет выполнено при запуске &man.cron.8;, обычно — в ходе инициализации системы. Tom Rhodes Предоставил Настройка утилиты <command>cron</command> cron настройка Одна из наиболее полезных утилит &os; это &man.cron.8;. Утилита cron работает в фоновом режиме и постоянно проверяет файл /etc/crontab. Утилита cron проверяет также каталог /var/cron/tabs в поиске новых файлов crontab. Файлы crontab содержат информацию об определенных функциях, которые cron выполняет в указанное время. Утилита cron использует два разных типа конфигурационных файлов, системный и пользовательский. Все различие между этими двумя форматами заключается в шестом поле. В системном файле шестое поля это имя пользователя, с правами которого будет запущена команда. Это позволяет запускать команды из системного crontab от любого пользователя. В пользовательском файле шестое поле указывает запускаемую команду, и все команды запускаются от пользователя, который создал crontab; это важно для безопасности. Пользовательские crontab позволяют индивидуальным пользователям планировать задачи без привилегий суперпользователя (root). Команды из crontab пользователя запускаются с привилегиями этого пользователя. Пользователь root может использовать собственный crontab, как и любой другой пользователь. Он будет отличаться от системного crontab /etc/crontab. Поскольку существует системный crontab, обычно не требуется создавать пользовательский crontab для root. Давайте заглянем в файл /etc/crontab (системный crontab): # /etc/crontab - root's crontab for &os; # # $&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log # # #minute hour mday month wday who command # # */5 * * * * root /usr/libexec/atrun Как и в большинстве файлов настройки FreeBSD, символы # означают комментарии. Комментарии нужны для напоминания о том, что означает строка и зачем она добавлена. Комментарии не могут находиться на той же строке, что и команда, или они будут восприняты как часть команды; располагайте их на новой строке. Пустые строки игнорируются. Сначала должны быть заданы переменные окружения. Знак равно (=) используется для задания переменных окружения, в этом примере SHELL, PATH, и HOME. Если переменная для оболочки не задана, cron использует оболочку по умолчанию, sh. Если не задана переменная PATH, значение по умолчанию не устанавливается и пути к файлам должны быть полными. Если не задана переменная HOME, cron будет использовать домашний каталог соответствующего пользователя. В строке всего семь полей. Их значения minute, hour, mday, month, wday, who (кто), и command. Значение полей почти очевидно. minute это время в минутах, когда будет запущена команда. hour означает то же самое для часов. mday означает день месяца. month, это то же самое, что час и минута, но для месяцев. Параметр wday это день недели. Все эти поля должны быть в числовом формате, время в двадцатичетырехчасовом исчислении. Поле who имеет специальное значение, и присутствует только в файле /etc/crontab. Это поле определяет пользователя, с правами которого должна быть запущена команда. Когда пользователь устанавливает собственный файл crontab, он не указывает этот параметр. Последний параметр command. Он указывает команду, которая должна быть запущена. Последняя строка определяет параметры, описанные выше. Здесь задано значение */5, и несколько символов *. Эти символы * означают первый-последний, и могут быть интерпретированы как каждый. Таким образом, для этой строки соответствующая команда atrun вызывается под пользователем root каждые пять минут независимо от дня или месяца. За дополнительной информацией по команде atrun обращайтесь к странице справочника &man.atrun.8;. Команды могут принимать любое количество параметров; однако команды, состоящие из нескольких строк, должны быть объединены символом \. Этот формат одинаков для каждого файла crontab, за исключением одной детали. Шестое поле, где указано имя пользователя, присутствует только в файле /etc/crontab. Это поле должно быть исключено из crontab файлов пользователей. Установка crontab Вы не должны использовать процедуру, описанную здесь, для установки системного crontab. Просто используйте свой любимый текстовый редактор: утилита cron узнает о том, что файл изменился и сразу начнет использовать обновленную версию. Обратитесь к этой части FAQ за дальнейшей информацией. Для установки готового crontab пользователя, сначала создайте в вашем любимом редакторе файл соответствующего формата, а затем воспользуйтесь утилитой crontab. Обычно она запускается так: &prompt.user; crontab crontab-file В этом примере, crontab-file это имя файла crontab, который только что был создан. Существует также параметр для просмотра установленных файлов crontab: задайте crontab параметр . Для пользователей, составляющих crontab вручную, без временного файла, существует параметр crontab -e. Она вызовет редактор с пустым файлом. Когда файл будет сохранен, crontab автоматически установит его. Если позднее вы захотите полностью удалить свой crontab, используйте crontab с параметром . Tom Rhodes Предоставил - Использование rc в FreeBSD 5.X + Использование rc во &os; 5.X и последующих версиях - rcNG - - В &os; недавно была интегрирована из NetBSD система + Во &os; недавно была интегрирована из NetBSD система rc.d, используемая для старта системы. Многие из файлов в каталоге /etc/rc.d предназначены для основных сервисов, они могут управляться параметрами , , и . Например, &man.sshd.8; может быть перезапущен следующей командой: &prompt.root; /etc/rc.d/sshd restart Эта процедура похожа для других сервисов. Конечно, сервисы обычно запускаются автоматически, как указано в &man.rc.conf.5;. Например, включение даемона Network Address Translation при запуске выполняется простым добавлением следующей строки в /etc/rc.conf: natd_enable="YES" Если уже присутствует, просто измените на . Скрипты rc автоматически загрузят все другие зависимые сервисы, как описано ниже. Поскольку система rc.d в основном предназначена для запуска/отключения сервисов во время запуска/отключения системы, стандартные параметры , и будут работать только если установлена соответствующая переменная в /etc/rc.conf. Например, команда выше sshd restart будет работать только если переменная sshd_enable в файле /etc/rc.conf установлена в . Для выполнения скриптов независимо от установок в /etc/rc.conf, параметры , или необходимо задавать с префиксом force. Например, для перезапуска sshd независимо от установок в /etc/rc.conf, выполните следующую команду: &prompt.root; /etc/rc.d/sshd forcerestart Проверить состояние переменной в файле /etc/rc.conf легко: запустите соответствующий скрипт из rc.d с параметром . Проверка переменной для sshd выполняется следующей командой: &prompt.root; /etc/rc.d/sshd rcvar # sshd $sshd_enable=YES Вторая строка (# sshd) это вывод команды sshd, а не консоль root. Чтобы определить, запущен ли сервис, существует параметр . Например для проверки того, запущен ли sshd, выполните: &prompt.root; /etc/rc.d/sshd status sshd is running as pid 433. Возможна также перегрузка () сервиса. Скрипт, запущенный с этим параметром, попытается отправить сервису сигнал, вызывающий перезагрузку файлов настройки. В большинстве случаев это означает отправку сервису сигнала SIGHUP. - Структура rcNG используется не только для + Система rc.d используется не только для сетевых серверов, она отвечает также за большую часть инициализации системы. Рассмотрим, к примеру, файл bgfsck. Во время выполнения этот скрипт выводит следующее сообщение: Starting background file system checks in 60 seconds. Следовательно, этот файл используется для фоновой проверки файловых систем, которая выполняется только в процессе инициализации системы. Функционирование многих сервисов системы зависит от корректной работы других сервисов. Например, NIS и другие основанные на RPC сервисы могут не запуститься, пока не загрузится rpcbind (portmapper). Для разрешения этой проблемы, в начале каждого скрипта в комментарии включаются информация о зависимостях и другие метаданные. Программа &man.rcorder.8; используется для разбора этих комментариев во время старта системы для определения порядка, в котором должны вызываться системные сервисы в соответствии с зависимостями. В начало каждого стартового файла должны быть включены следующие строки: PROVIDE: Задает имя сервиса, предоставляемого этим файлом. REQUIRE: Список сервисов, необходимых этому сервису. Этот файл будет запущен после указанных сервисов. BEFORE: Список сервисов, зависящих от этого сервиса. Этот файл будет запущен до указанных сервисов. KEYWORD: &os; или NetBSD. Используется для функций, зависящих от версии *BSD. Используя этот метод, администратор может легко контролировать системные сервисы без использования уровней запуска, как в некоторых других операционных системах &unix;. Дополнительную информацию о системе rc.d - &os; 5.X можно найти на страницах справочника &man.rc.8; и + можно найти на страницах справочника &man.rc.8; и &man.rc.subr.8;. Marc Fonvieille Предоставил Настройка карт сетевых интерфейсов сетевые карты настройка В наши дни мы не представляем себе компьютера без сетевого подключения. Добавление и настройка сетевой карты это обычная задача любого администратора &os;. Поиск подходящего драйвера сетевые карты драйвер В первую очередь определите тип используемой карты (PCI или ISA), модель карты и используемый в ней чип. &os; поддерживает многие PCI и ISA карты. Обратитесь к Списку поддерживаемого оборудования вашего релиза чтобы узнать, поддерживается ли карта. Как только вы убедились, что карта поддерживается, потребуется определить подходящий драйвер. В файлах /usr/src/sys/conf/NOTES и /usr/src/sys/arch/conf/NOTES находится список драйверов сетевых интерфейсов с информацией о поддерживаемых чипсетах/картах. Если вы сомневаетесь в том, какой драйвер подойдет, прочтите страницу справочника к драйверу. Страница справочника содержит больше информации о поддерживаемом оборудовании и даже о проблемах, которые могут возникнуть. NOTES не существует в &os; 4.X. Вместо него, проверьте файл LINT на предмет информации о различных сетевых интерфейсах. В находится более подробная информация о различиях NOTES и LINT. Если ваша карта широко распространена, вам скорее всего не потребуется долго искать драйвер. Драйверы для широко распространенных карт представлены в ядре GENERIC, так что ваша карта должна определиться при загрузке, примерно так: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 dc0: Ethernet address: 00:a0:cc:da:da:da miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 dc1: Ethernet address: 00:a0:cc:da:da:db miibus1: <MII bus> on dc1 ukphy1: <Generic IEEE 802.3u media interface> on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto В этом примере две карты используют имеющийся в системе драйвер &man.dc.4;. Если драйвер вашей сетевой карты отсутствует в GENERIC, для ее использования потребуется загрузить подходящий драйвер. Это может быть сделано одним из двух способов: Простейший способ — просто загрузить модуль ядра сетевой карты с помощью &man.kldload.8;. Не все драйверы доступны в виде модулей; например, модули отсутствуют для ISA карт. Вместо этого, вы можете статически включить поддержку карты, скомпилировав собственное ядро. Информацию о том, какие параметры нужно включать в ядро, можно получить из /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES и страницы справочника драйвера сетевой карты. За более подробной информацией о сборке собственного ядра обращайтесь к . Если карта была обнаружена вашим ядром (GENERIC) во время загрузки, собирать ядро не потребуется. Настройка сетевой карты сетевые карты настройка Как только для сетевой карты загружен подходящий драйвер, ее потребуется настроить. Как и многое другое, сетевая карта может быть настроена во время установки с помощью sysinstall. Для вывода информации о настройке сетевых интерфейсов системы, введите следующую команду: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:a0:cc:da:da:db media: Ethernet 10baseT/UTP status: no carrier lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 Старые версии &os; могут потребовать запуска &man.ifconfig.8; с параметром , за более подробным описанием синтаксиса &man.ifconfig.8; обращайтесь к странице справочника. Учтите также, что строки, относящиеся к IPv6 (inet6 и т.п.) убраны из этого примера. В этом примере были показаны следующие устройства: dc0: первый Ethernet интерфейс dc1: второй Ethernet интерфейс lp0: интерфейс параллельного порта lo0: устройство loopback tun0: туннельное устройство, используемое ppp Для присвоения имени сетевой карте &os; использует имя драйвера и порядковый номер, в котором карта обнаруживается при инициализации устройств. Например, sis2 это третья сетевая карта, использующая драйвер &man.sis.4;. В этом примере, устройство dc0 включено и работает. Ключевые признаки таковы: UP означает, что карта настроена и готова. У карты есть интернет (inet) адрес (в данном случае 192.168.1.3). Установлена маска подсети (netmask; 0xffffff00, то же, что и 255.255.255.0). Широковещательный адрес (в данном случае, 192.168.1.255). Значение MAC адреса карты (ether) 00:a0:cc:da:da:da Выбор физической среды передачи данных в режиме автовыбора (media: Ethernet autoselect (100baseTX <full-duplex>)). Мы видим, что dc1 была настроена для работы с 10baseT/UTP. За более подробной информацией о доступных драйверу типах среды обращайтесь к странице справочника. Статус соединения (status) active, т.е. несущая обнаружена. Для dc1, мы видим status: no carrier. Это нормально, когда Ethernet кабель не подключен к карте. Если &man.ifconfig.8; показывает примерно следующее: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:a0:cc:da:da:da это означает, что карта не была настроена. Для настройки карты вам потребуются привилегии пользователя root. Настройка сетевой карты может быть выполнена из командной строки с помощью &man.ifconfig.8;, но вам потребуется делать это после каждой перезагрузки системы. Подходящее место для настройки сетевых карт это файл /etc/rc.conf. Откройте /etc/rc.conf в текстовом редакторе. Вам потребуется добавить строку для каждой сетевой карты, имеющейся в системе, например, в нашем случае, было добавлено две строки: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" Замените dc0, dc1, и так далее на соответствующие имена ваших карт, подставьте соответствующие адреса. Обратитесь к страницам справочника сетевой карты и &man.ifconfig.8;, за подробной информацией о доступных опциях и к странице справочника &man.rc.conf.5; за дополнительной информацией о синтаксисе /etc/rc.conf. Если вы настроили сетевую карту в процессе установки системы, некоторые строки, касающиеся сетевой карты, могут уже присутствовать. Внимательно проверьте /etc/rc.conf перед добавлением каких-либо строк. Отредактируйте также файл /etc/hosts для добавления имен и IP адресов различных компьютеров сети, если их еще там нет. За дополнительной информацией обращайтесь к man.hosts.5; и к /usr/share/examples/etc/hosts. Тестирование и решение проблем Как только вы внесете необходимые изменения в /etc/rc.conf, перегрузите компьютер. Изменения настроек интерфейсов будут применены, кроме того будет проверена правильность настроек. Как только система перезагрузится, проверьте сетевые интерфейсы. Проверка Ethernet карты сетевые карты тестирование Для проверки правильности настройки сетевой карты, попробуйте выполнить ping для самого интерфейса, а затем для другой машины в локальной сети. Сначала проверьте локальный интерфейс: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms Затем проверьте другую машину в локальной сети: &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms Вы можете также использовать имя машины вместо 192.168.1.2, если настроен файл /etc/hosts. Решение проблем сетевые карты решение проблем Решение проблем с аппаратным и программным обеспечением всегда вызывает сложности, которые можно уменьшить, проверив сначала самые простые варианты. Подключен ли сетевой кабель? Правильно ли настроены сетевые сервисы? Правильно ли настроен брандмауэр? Поддерживается ли используемая карта в &os;? Всегда проверяйте информацию об оборудовании перед отправкой сообщения об ошибке. Обновите &os; до последней версии STABLE. Просмотрите архивы списков рассылки, или поищите информацию в интернет. Если карта работает, но производительность низка, может помочь чтение страницы справочника &man.tuning.7;. Проверьте также настройки сети, поскольку неправильные настройки могут стать причиной низкой скорости соединения. Некоторые пользователи встречаются с несколькими device timeouts, что нормально для некоторых сетевых карт. Если это продолжается и надоедает, убедитесь, что устройство не конфликтует с другим устройством. Внимательно проверьте подключение кабеля. Возможно также, что вам просто надо установить другую карту. Время от времени, пользователи видят несколько ошибок watchdog timeout. Первое, что требуется сделать, это проверить сетевой кабель. Многие карты требуют поддержки Bus Mastering слотом PCI. На некоторых старых материнских платах, только один PCI слот имеет такую поддержку (обычно слот 0). Сверьтесь с документацией на сетевую карту и материнскую плату, чтобы определить, может ли это быть проблемой. Сообщение No route to host появляются, если система не в состоянии доставить пакеты к хосту назначения. Это может случиться, если не определен маршрут по умолчанию, или кабель не подключен. Проверьте вывод команды netstat -rn и убедитесь, что к соответствующему хосту есть работающий маршрут. Если это не так, прочтите . Сообщения ping: sendto: Permission denied зачастую появляются при неправильно настроенном брандмауэре. Если ipfw включен в ядре, но правила не определены, правило по умолчанию блокирует весь трафик, даже запросы ping! Прочтите с более подробной информацией. Иногда скорость карты недостаточна, или ниже среднего. В этих случаях лучше всего изменить режим выбора типа подключения с autoselect на правильный тип. Обычно это работает для большинства оборудования, но не может решить проблему во всех случаях. Проверьте еще раз настройки сети и прочтите страницу справочника &man.tuning.7;. Настройка виртуальных серверов виртуальные сервера синонимы ip Очень часто &os; используется для размещения сайтов, когда один сервер работает в сети как несколько серверов. Это достигается присвоением нескольких сетевых адресов одному интерфейсу. У сетевого интерфейса всегда есть один настоящий адрес, хотя он может иметь любое количество синонимов (alias). Эти синонимы обычно добавляются путём помещения соответствующих записей в /etc/rc.conf. Синоним для интерфейса fxp0 выглядит следующим образом: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" Заметьте, что записи синонимов должны начинаться с alias0 и идти далее в определенном порядке (например, _alias1, _alias2, и т.д.). Конфигурационный процесс остановится на первом по порядку отсутствующем числе. Определение маски подсети для синонима очень важно, но к счастью, так же просто. Для каждого интерфейса должен быть один адрес с истинной маской подсети. Любой другой адрес в сети должен иметь маску подсети, состоящую из всех единичек (что выражается как 255.255.255.255 или как 0xffffffff). Например, рассмотрим случай, когда интерфейс fxp0 подключён к двум сетям, к сети 10.1.1.0 с маской подсети 255.255.255.0 и к сети 202.0.75.16 с маской 255.255.255.240. Мы хотим, чтобы система была видна по IP, начиная с 10.1.1.1 по 10.1.1.5 и с 202.0.75.17 по 202.0.75.20. Как было сказано выше, только первый адрес в заданном диапазоне (в данном случае, 10.0.1.1 и 202.0.75.17) должен иметь реальную маску сети; все остальные (с 10.1.1.2 по 10.1.1.5 и с 202.0.75.18 по 202.0.75.20) должны быть сконфигурированы с маской сети 255.255.255.255. Для этого в файл /etc/rc.conf должны быть внесены следующие записи: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Файлы настройки Каталог <filename>/etc</filename> Во FreeBSD определён ряд каталогов, предназначенных для хранения конфигурационных файлов. Это: /etc Основные файлы конфигурации системы. Тут размещены системно–зависимые данные. /etc/defaults Версии системных конфигурационных файлов по умолчанию. /etc/mail Дополнительные конфигурационные файлы &man.sendmail.8;, другие конфигурационные файлы MTA. /etc/ppp Настройка для user- и kernel-ppp программ. /etc/namedb Основное место расположения данных &man.named.8;. Обычно named.conf и файлы зон расположены здесь. /usr/local/etc Конфигурационные файлы установленных приложений. Могут содержать подкаталоги приложений. /usr/local/etc/rc.d Скрипты запуска/остановки установленных приложений. /var/db Автоматически генерируемые системно-специфичные файлы баз данных, такие как база данных пакетов, и так далее Имена хостов hostname DNS <filename>/etc/resolv.conf</filename> resolv.conf /etc/resolv.conf определяет, как - ресолвер (resolver) &os; получает доступ к Системе Доменных + резолвер (resolver) &os; получает доступ к Системе Доменных Имён (DNS). Основные записи resolv.conf: nameserver IP адрес сервера имён. Сервера опрашиваются в порядке описания. Максимальное количество адресов — три. search Список доменов для поиска с помощью hostname lookup. Обычно определяется доменом, в котором находится компьютер. domain Домен, в котором находится компьютер. Типичный вид resolv.conf: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Опции search и domain нельзя использовать совместно. Если вы используете DHCP, &man.dhclient.8; обычно перезаписывает resolv.conf информацией, полученной от серверов DHCP. <filename>/etc/hosts</filename> hosts /etc/hosts — простая текстовая база данных, напоминающая старый Интернет. Она работает совместно с DNS и NIS, сопоставляя доменные имена IP адресу. Отдельные компьютеры, соединённые с помощью локальной сети, могут быть записаны тут вместо &man.named.8; сервера с целью упрощения. Кроме того, /etc/hosts используется для записи IP адресов и соответствующих им доменов, избавляя от внешнего трафика, используемого для запросов к DNS серверам. # $&os;$ # # Host Database # This file should contain the addresses and aliases # for local hosts that share this file. # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain myname.my.domain 127.0.0.1 localhost localhost.my.domain myname.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. PLEASE PLEASE PLEASE do not try # to invent your own network numbers but instead get one from your # network provider (if any) or from the Internet Registry (ftp to # rs.internic.net, directory `/templates'). # Формат /etc/hosts: [IP адрес в Интернете] [имя компьютера] [alias1] [alias2] ... Например: 10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2 За дополнительной информацией обращайтесь к &man.hosts.5;. Настройка лог файлов лог файлы <filename>syslog.conf</filename> syslog.conf syslog.conf is является файлом конфигурации для &man.syslogd.8;. В нём указываются, типы сообщений генерируемые syslog, и лог файлы, в которые они записываются. # $&os;$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manual page. *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log #*.* /var/log/all.log # uncomment this to enable logging to a remote log host named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log За более полной информацией обратитесь к &man.syslog.conf.5;. <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf — конфигурационный файл &man.newsyslog.8;, программы, обычно контролируемой &man.cron.8;. &man.newsyslog.8; определяет, когда лог-файлы нуждаются в архивировании и перегруппировке. logfile перемещается в logfile.0, logfile.0 перемещается в logfile.1, и так далее. Другое именование получится при архивировании с помощью &man.gzip.1;: logfile.0.gz, logfile.1.gz, и т.д. newsyslog.conf показывает, какие лог файлы должны быть проинспектированы, сколько их должно быть сохранено, и когда они должны быть пересмотрены. Лог файлы могут быть перегруппированы и/или заархивированы, когда они либо достигнут определённого размера, либо при достижении определённых даты/времени. # configuration file for newsyslog # $&os;$ # # filename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z За дополнительной информацией обращайтесь к &man.newsyslog.8;. <filename>sysctl.conf</filename> sysctl.conf sysctl sysctl.conf очень похож на rc.conf. Значения устанавливаются в виде variable=value. Указанные значения устанавливаются после перевода системы в многопользовательский режим. Однако не все переменные могут быть установлены в этом режиме. Пример sysctl.conf, настроенного для выключения протоколирования фатальных ошибок программ и разрешения Linux-программам определять, что они запускаются под &os;: kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11) compat.linux.osname=&os; compat.linux.osrelease=4.3-STABLE Настройка с помощью sysctl sysctl настройка с помощью sysctl &man.sysctl.8; — это интерфейс, позволяющий вам вносить изменения в работающую систему &os;. Эти изменения касаются многих опций стека TCP/IP и виртуальной памяти; опытный системный администратор может использовать их для существенного увеличения производительности. Более пяти тысяч системных переменных могут быть прочитаны и записаны с помощью &man.sysctl.8;. По своей сути, &man.sysctl.8; выполняет две функции: чтение и изменение настроек системы. Для просмотра всех доступных для чтения переменных: &prompt.user; sysctl -a Чтобы прочитать определённую переменную, например, kern.maxproc, введите: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Для присвоения значения переменной, используйте выражение вида переменная=значение: &prompt.root; sysctl kern.maxfiles=5000 -kern.maxfiles: 2088 -> 5000 +kern.maxfiles: 2088 -> 5000 Изменяемые с помощью sysctl переменные обычно принимают значения либо строкового, либо целого, либо булевого типа. Переменные булевого типа могут принимать два значения (1 (истина) и 0 (ложь)). Если вы хотите устанавливать некоторые переменные автоматически при каждой загрузке компьютера, добавьте их в файл /etc/sysctl.conf. За дополнительной информацией обращайтесь к странице справочника &man.sysctl.conf.5; и к . Tom Rhodes Предоставил Переменные &man.sysctl.8; только для чтения В некоторых случаях желательно изменить переменные &man.sysctl.8; только для чтения. Иногда другого способа решить - проблему нет; при этоме, результат может быть достигнут только на этапе + проблему нет; при этом, результат может быть достигнут только на этапе начальной загрузки. Например, на некоторых моделях лэптопов диапазон памяти устройства &man.cardbus.4; не определяется и выдается приблизительно такая ошибка: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 Ситуации, похожие на эту, требуют изменения некоторых значений &man.sysctl.8;, модификация которых запрещена. Для разрешения этой ситуации пользователь может поместить &man.sysctl.8; OID в файл /boot/loader.conf. Значения по умолчанию хранятся в файле /boot/defaults/loader.conf. Решение проблемы, приведенной выше, потребует помещения строки в вышеупомянутый файл. Теперь &man.cardbus.4; будет работать нормально. Оптимизация дисков Переменные Sysctl <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable Значением переменной vfs.vmiodirenable может быть установлено в 0 (выключено) или 1 (включено); по умолчанию 1. Эта переменная отвечает за метод кэширования каталогов. Размер большинства каталогов невелик. Они могут поместиться в одном фрагменте (обычно 1K), и могут занимать ещё меньше места (обычно 512 байт) в кэше буфера. При отключении этой переменной (при установке значения 0) буфер прокэширует только заданное число каталогов даже если у вас много памяти. При включении (при установке значения 1) эта переменная sysctl позволит использовать страничное кэширование VM, делая доступным для кэширования каталогов весь объём памяти. Однако, минимальный объём памяти, используемой для кэширования каталогов стал равен объёму страницы (обычно 4 K) вместо 512 байт. Мы рекомендуем оставлять эту опцию включенной, если ваш компьютер исполняет программы, манипулирующие значительным количеством файлов. Примером таких программ могут быть кэширующие прокси-серверы, большие почтовые серверы и серверы новостей. Обычно включение этой опции не понижает производительности, однако лучше поэкспериментировать, чтобы узнать оптимальное значение для вашей машины. <varname>vfs.write_behind</varname> vfs.write_behind Переменная sysctl vfs.write_behind по умолчанию установлена в 1 (включено). Она указывает системе выполнять запись на носитель по кластерам, что обычно делается для больших файлов. Идея в том, чтобы избежать заполнения кэша неполными буферами, когда это не увеличивает производительность. Однако, это может заблокировать процессы и в некоторых случаях вам может понадобиться отключить этот параметр. <varname>vfs.hirunningspace</varname> vfs.hirunningspace Переменная sysctl vfs.hirunningspace определяет число запросов записи на диск, которые могут быть поставлены в очередь. Значение по умолчанию обычно подходит, но на компьютерах с большим количеством дисков вы можете увеличить его до четырех или пяти мегабайт. Учтите, что установка слишком большого значения (превышающего размер буфера записи) может привести к очень значительному падению общей производительности. Не делайте это значение произвольно большим! Большие значения могут привести к задержкам чтения, выполняемого в то же время Есть много других переменных sysctl, относящихся к кэшированию в буфер и страничному кэшированию VM. Мы не рекомендуем изменять эти значения. Начиная &os; 4.3, система VM делает отличную работу по автоматической самонастройке. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled Переменная sysctl vm.swap_idle_enabled полезна в больших многопользовательских системах, где есть много пользователей, входящих и выходящих из системы, и множество ожидающих процессов. Такие системы обычно генерируют большое количество запросов на выделение памяти. Включение этой переменной и настройка задержки выгрузки (swapout hysteresis, в секундах) установкой переменных vm.swap_idle_threshold1 и vm.swap_idle_threshold2 позволит освобождать страницы памяти, занятые ожидающими процессами, более быстро, чем при нормальном алгоритме выгрузки. Это помогает даемону выгрузки страниц. Не включайте этот параметр, пока он на самом деле вам не понадобится, поскольку его действие в сущности заключается в более ранней выгрузке страниц из памяти; это повышает нагрузку на подкачку и диск. В малых системах эффект от включения этого параметра предсказуем, но в больших системах нагруженной на подкачкой этот параметр позволяет системе VM проще загружать и выгружать процессы из памяти. <varname>hw.ata.wc</varname> hw.ata.wc Во &os; 4.3 кэширование записи на IDE диски было отключено. Это понижало производительность IDE дисков в тестах, но было необходимо для лучшей сохранности данных. Проблема состоит в том, что IDE диски неправильно указывают время завершения записи на диск. При включенном кэшировании IDE диски могут не только записать данные в неправильном порядке — при большой нагрузке на диск некоторые блоки могут задержаться до бесконечности. Сбой, или отключение питания могут могут стать причиной серьёзных повреждений в файловой системе. Поэтому для безопасности системы значение по умолчанию этого параметра было изменено. К сожалению, результатом этого стало столь значительная потеря производительности, что после выхода релиза значение этого параметра было возвращено в первоначальное состояние. Вам следует проверить значение переменной sysctl hw.ata.wc на вашей машине. Если кэширование выключено — вы можете включить его, установив значение переменной ядра, равное 1. Это должно быть сделано при помощи загрузчика при загрузке. Если вы сделаете это позже — изменения не будут иметь силы. За более подробной информацией обращайтесь к &man.ata.4;. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay опции ядра SCSI_DELAY Параметр настройки ядра SCSI_DELAY может использоваться для уменьшения времени загрузки системы. Значение по умолчанию велико и может составлять более 15 секунд в процессе загрузки. Уменьшение его до 5 секунд обычно работает (особенно с современными дисками). В новых версиях &os; (5.0 и выше) должен использоваться параметр kern.cam.scsi_delay, настраиваемый во время загрузки. Этот параметр и параметр настройки ядра принимают значения в миллисекундах, а не в секундах. Soft Updates Soft Updates tunefs Программа &man.tunefs.8; используется для настройки файловой системы. Эта программа может принимать большое количество параметров, но мы рассмотрим лишь один из них — включение и выключение Soft Updates, что может быть достигнуто следующим образом: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem Нельзя изменять файловую систему с помощью &man.tunefs.8; когда она смонтирована. Самое подходящее время для включения "Soft Updates" - перед монтированием разделов, в однопользовательском режиме. Начиная с &os; 4.5, можно включить Soft Updates во время создания файловой системы, используя &man.newfs.8; с параметром -U. Soft Updates существенно увеличивают скорость создания и удаления файлов путём использования кэширования. Мы рекомендуем использовать Soft Updates на всех ваших файловых системах. Однако у Soft Updates есть и обратные стороны: во-первых, Soft Updates гарантирует целостность файловой системы в случае сбоя, но может наблюдаться задержка в несколько секунд (или даже минуту!) перед записью на жесткий диск. Если система зависнет — вы можете потерять больше, чем, если бы вы не включили Soft Updates. Во-вторых, Soft Updates задерживает освобождение блоков файловой системы. Если ваша файловая система заполнена, выполнение значительного обновления, например, make installworld, может вызвать переполнение. Дополнительная информация о Soft Updates Soft Updates детали Есть два традиционных способа записи метаданных файловых систем на диск (пример метаданных: индексные дескрипторы и каталоги). Исторически, поведение по умолчанию заключается в синхронном обновлении метаданных. Если каталог был изменен, система ждет, пока изменение не будет физически записано на диск. Содержимое файлов проходит через кэш и записывается на диск асинхронно. Преимущество этого способа в его надежности. При сбое во время обновления метаданные остаются в нормальном состоянии. Файл либо создается целиком, либо вообще не создается. Если блоки данных не были записаны в файл из буфера во время сбоя, &man.fsck.8; сможет определить это и восстановить файловую систему, установив длину файла в 0. Кроме того, реализация этого способа проста и понятна. Недостаток в том, что обновление метаданных занимает много времени. Команда rm -r, например, последовательно удаляет все файлы в каталоге, и каждое изменение в каталоге (удаление файла) будет синхронно записано на диск. Сюда включаются обновления самого каталога, таблицы индексных дескрипторов, и возможно блоков, занятых файлом. Те же соглашения работают при распаковке больших иерархий (tar -x). Другой вариант это асинхронное обновление метаданных. Это поведение по умолчанию для Linux/ext2fs и *BSD ufs с параметром mount -o async. Все обновления метаданных просто пропускаются через кэш буфера, как и содержимое файлов. Преимущество этой реализации в том, что нет необходимости ждать каждый раз, пока метаданные будут записаны на диск, поэтому все операции с большим объемом обновления метаданных будут происходить гораздо быстрее, чем при синхронном обновлении. Кроме того, реализация все еще проста и понятна, поэтому риск появления ошибок в коде невелик. Недостаток в том, что нет никаких гарантий исправности файловой системы. Если во время обновления большого объема метаданных произойдет сбой (например, отключение питания, или нажатие кнопки reset), файловая система останется в непредсказуемом состоянии. Нет возможности определить состояние файловой системы после такого сбоя; блоки данных файла могут быть уже записаны на диск, а обновления таблицы индексных дескрипторов нет. Невозможно реализовать fsck, которая могла бы исправить получившийся хаос (поскольку необходимой информации нет на диске). Если файловая система была уничтожена во время восстановления, единственный способ восстановления — запустить &man.newfs.8; и воспользоваться резервной копией. Обычное решение этой проблемы состояло в реализации протоколировании проблемной области (dirty region logging), известном как журналирование, хотя этот термин использовался неправильно и порой также применялся к другим формам протоколирования транзакций. Обновление метаданных как и прежде происходит синхронно, но в отдельную область диска. Позже они перемещаются туда, где должны быть. Поскольку область протоколирования это небольшая, последовательная область диска, головкам жесткого диска не приходится перемещаться на большие расстояния даже во время значительных обновлений, поэтому такой способ быстрее, чем синхронные обновления. Кроме того, сложность реализации довольно ограничена, поэтому риск внесения ошибок невелик. Недостаток в том, что все обновления метаданных записываются дважды (один раз в область протоколирования и один раз окончательно), поэтому при обычной работе производительность может понизиться. С другой стороны, в случае сбоя все незаконченные действия с метаданными могут быть быстро отменены, или завершены после загрузки системы, поэтому система после сбоя загружается быстрее. Kirk McKusick, разработчик Berkeley FFS, решил эту проблему с помощью Soft Updates: все незавершенные обновления метаданных находятся в памяти и записываются на диск в упорядоченном виде (упорядоченное обновления метаданных). При значительных обновлениях метаданных более поздние обновления присоединяются к предыдущим, если они все еще находятся в памяти и еще не записаны на диск. Поэтому все операции, скажем, над каталогом, обычно выполняются в памяти перед записью обновления на диск (блоки данных сортируются в соответствии с их положением, так что они не будут записаны на диск до метаданных. При крахе операционной системы выполняется откат: считается, что все операции, не записанные на диск, никогда не происходили. Файловая система находится в том состоянии, в котором она была за 30–60 секунд до сбоя. Используемый алгоритм гарантирует, что все используемые ресурсы маркированы соответствующим образом в своих областях: блоки и индексные дескрипторы. После сбоя могут остаться только ошибки выделения ресурсов, они помечаются как используемые, хотя на самом деле свободны. &man.fsck.8; разбирается в ситуации и освобождает более не используемые ресурсы. После сбоя система может быть безопасно смонтирована с опцией mount -f. Для освобождения ресурсов, которые могут не использоваться, в дальнейшем потребуется запустить &man.fsck.8;. Эта идея лежит в основе background (фоновая) fsck: во время запуска системы записывается только снимок файловой системы. Все системы могут быть смонтированы в грязном состоянии, и система загружается в многопользовательский режим. Затем, фоновые fsck ставятся в очередь для всех систем, где это требуется, чтобы освободить неиспользуемые ресурсы. (Файловые системы, где не используются Soft Updates, все еще требуют запуска fsck в обычном режиме). Преимущество этого способа в том, что обновления метаданных происходят почти так же быстро, как при асинхронных обновлениях (т.е. быстрее, чем при журналировании, когда метаданные записываются дважды). Недостаток в сложности кода (подразумевающим больший риск появления ошибок в области, где вероятность потери данных пользователя особенно высока) и в более высоких требованиях к объему памяти. К тому же могут возникнуть некоторые странные на первый взгляд ситуации. После сбоя состояние файловой системы несколько более старое. В ситуации, когда стандартный способ синхронизации оставит несколько файлов нулевой длины после выполнения fsck, в файловой системе с Soft Updates их не останется вовсе, поскольку ни метаданные, ни содержимое файлов не были записаны на диск. Дисковое пространство не будет освобождено пока обновления не будут записаны на диск, что может занять некоторое время после выполнения rm. Это может повлечь проблемы при установке большого количества файлов на файловую систему, где не хватает места для помещения всех файлов дважды. Изменение ограничений, накладываемых ядром оптимизация параметры ядра Ограничения на Файлы/Процессы <varname>kern.maxfiles</varname> kern.maxfiles Значение kern.maxfiles может быть увеличено или уменьшено в зависимости от потребностей вашей системы. Эта переменная определяет максимальное число дескрипторов файлов. Когда таблица дескрипторов файлов полна, в очереди системных сообщений появится сообщение file: table is full. Это сообщение может быть прочитано с помощью команды dmesg. Каждый открытый файл, сокет или буфер использует дескриптор файла. Широкомасштабному серверу может понадобиться много тысяч дескрипторов файлов, в зависимости от количества программ, одновременно выполняемых на сервере. Стандартное значение kern.maxfile определяется - переменной в вашем файле конфигурации + переменной в вашем файле конфигурации ядра. Значение kern.maxfiles увеличивается - пропорционально значению . При + пропорционально значению . При компилировании ядра, нужно установить эту переменную согласно потребностям вашей системы. Исходя из значения этой переменной, ядро устанавливает значения большинства предопределённых переменных. Даже если предполагается, что к компьютеру не будут одновременно подсоединяться 256 пользователей, требуемые ресурсы могут быть такими же, как у крупномасштабного сервера. - Начиная с &os; 4.5, установка значения - в - 0 в файле конфигурации ядра выберет подходящее - значение по умолчанию, основанное на объеме оперативной памяти - системы. + Начиная с &os; 4.5 система автоматически настроит + maxusers, если вы явно установите его в + 0 + Алгоритм автоматической настройки установит + maxusers равным количеству памяти в системе, + где минимум 32, а максимум 384. + . Во &os; 5.X и выше, maxusers + по умолчанию равно 0, если не указано другое. + Если вы используйте версию &os; младше 4.5 или желаете выставить + значение самостоятельно, то задайте maxusers по + меньшей мере равным 4, особенно если вы используйте X Window System или + компилируйте программное обеспечение. Причина в том, что самая + значимая таблица, устанавливаемая maxusers - + это максимальное количество процессов, которая устанавливается + равным 20 + 16 * maxusers, и поэтому, если + вы установите maxusers в 1, то вы сможете + иметь только 36 одновременных процессов, включая 18 или около того, + что система запустит во время загрузки и 15 или около того, что + вы создадите при запуске X Window System. Даже простая задача, как + чтение страницы справочника породит 9 процессов для фильтрации, + декомпрессии и её просмотра. Установка maxusers + в 64 позволит иметь вам до 1044 одновременных процессов, чего + должно быть достаточно примерно для всех использований. Если, + тем не менее, вы увидите пугающую ошибку proc table + full при попытке запуска другой программы, или + вы используйте сервер с большим количеством одновременных пользователей + (как ftp.FreeBSD.org), то вы всегда + можете увеличить значение и пересобрать систему. + + + maxusers не + ограничивает количество пользователей, которые могут заходить на + вашу машину. Оно просто устанавливает различные размеры таблиц + в разумные значения, учитывая максимальное количество пользователей, + вы вероятно будете иметь на вашей системе и как много процессов + каждый из них сможет запускать. Ключевое слово, которое ограничивает + количество одновременных удаленных входов и терминальных X окон - + это pseudo-device pty + 16. С &os; 5.X вам не надо беспокоиться + об этом значении, так как &man.pty.4; драйвер является + автоматически клонирующим; вы просто используйте + device pty в вашем конфигурационном файле. + + <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn Переменная sysctl kern.ipc.somaxconn ограничивает размер очереди для приема новых TCP соединений. Значение по умолчанию 128 слишком мало для надежной обработки новых соединений для нагруженного web сервера. Для такого сервера рекомендуется увеличить это значение до 1024 или выше. Даемон сервиса может сам ограничивать очередь приема новых соединений (например, &man.sendmail.8;, или Apache), но обычно в файле настройки даемона есть директива для настройки длины очереди. Более длинная очередь также помогает избежать атак Denial of Service (DoS). Сетевые Ограничения Опция ядра NMBCLUSTERS обуславливает количество Mbuf, доступных на машине. На сервере с большим трафиком и маленьким Mbuf производительность будет пониженной. Каждый кластер представлен двумя килобайтами памяти, поэтому значение 1024 означает 2 мегабайта памяти ядра, зарезервированной для сетевых буферов. Для определения оптимального значения необходимо провести простые вычисления. Если у вас веб сервер, который может обслуживать 1000 одновременных соединений, и каждое соединение съедает 16 K буфера приема и 16 K буфера отправки, вам потребуется 32 MB памяти под буферы. Хорошее правило — умножение этого значения на 2, 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Мы рекомендуем значения между 4096 и 32768 для машин с большим объемом памяти. Не указывайте произвольно большое значение параметра, это может привести к падению системы при загрузке. Используйте &man.netstat.1; с опцией для определения количества используемых сетевых кластеров. Для настройки в процессе загрузки используйте в loader переменную kern.ipc.nmbclusters. Только в старых версиях &os; потребуется пересобрать ядро (&man.config.8;) с измененным параметром NMBCLUSTERS. Для нагруженных серверов, интенсивно использующих системный вызов &man.sendfile.2;, может потребоваться увеличения буферов &man.sendfile.2; с помощью параметра конфигурации ядра NSFBUFS, или изменения значения путем установки переменной в /boot/loader.conf (обратитесь к &man.loader.8; за подробностями). Общий признак того, что параметр требуется изменить — состояние процессов sfbufa. Переменная sysctl kern.ipc.nsfbufs установлена только для чтения. Этот параметр увеличивается вместе с kern.maxusers, хотя может потребоваться увеличить его отдельно. Даже если сокет помечен как неблокирующий, вызов &man.sendfile.2; на неблокирующем сокете может вызвать блокирование &man.sendfile.2;, пока не станет доступным достаточное количество struct sf_buf. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* Переменные sysctl net.inet.ip.portrange.* контролируют диапазоны номеров портов, автоматически привязываемых к TCP и UDP сокетам. Есть три диапазона: нижний диапазон, диапазон по умолчанию и верхний диапазон. Большинство сетевых программ используют диапазон по умолчанию, контролируемый net.inet.ip.portrange.first и net.inet.ip.portrange.last, установленными соответственно в 1024 и 5000. Диапазоны портов привязки используются для исходящих соединений и при некоторых условиях портов может не хватить. Это чаще всего происходит на сильно загруженном прокси сервере. Диапазон портов не становится проблемой при работе серверов, которые обрабатывают в основном входящие соединения, или с небольшим количеством исходящих соединений, например mail relay. Для ситуаций, когда возможен недостаток портов, рекомендуется немного увеличить net.inet.ip.portrange.last. Может подойти значение 10000, 20000, или 30000. Учтите также возможное влияние брандмауэра при изменении диапазона портов. Некоторые могут блокировать большие диапазоны портов (обычно с небольшими номерами) и вынуждают использовать более высокие диапазоны для - исходящих соединений. По этой причине рекомендуется - настроить значение + исходящих соединений. По этой причине не рекомендуется + уменьшать значение net.inet.ip.portrange.first. TCP Bandwidth Delay Product TCP Bandwidth Delay Product Limiting net.inet.tcp.inflight.enable TCP Bandwidth Delay Product Limiting похоже на TCP/Vegas в NetBSD. Оно может быть включено установкой переменной sysctl net.inet.tcp.inflight.enable в 1. Система попытается вычислить задержку пакетов для каждого соединения и ограничить объем данных в очереди сети до значения, требуемого для поддержания оптимальной пропускной способности. Эта возможность полезна при передаче данных через модемы, Gigabit Ethernet, или даже через высокоскоростные WAN соединения (или любые другие соединения с большой задержкой передачи), особенно если вы также используете изменение размера окна или настроили большое окно передачи. Если вы включили этот параметр, убедитесь также, что переменная net.inet.tcp.inflight.debug установлена в 0 (отладка выключена), а для использования в реальных задачах может понадобиться установка переменной net.inet.tcp.inflight.min к значению как минимум 6144. Но учтите, что установка большого значения этой переменной может фактически отключить ограничение в зависимости от вида соединения. Ограничение уменьшает количество данных на определенном маршруте и управляет очередью пакетов, как и уменьшает общее количество данных в очереди локального интерфейса хоста. С меньшим количеством пакетов в очереди двусторонние интерактивные соединения, особенно на медленных линиях, могут проходить быстрее. Но имейте ввиду, что эта функция работает только при передаче данных (передача данных / сторона сервера). Она не работает при получении данных (загрузке). Изменение значения переменной net.inet.tcp.inflight.stab не рекомендуется. Этот параметр по умолчанию равен 20, что означает добавление 2 пакетов к вычислению задержки передачи. Дополнительное окно требуется для стабилизации алгоритма и улучшения ответной реакции на изменение условий, но также приводит к большему времени ping на медленных соединениях (задержка все же гораздо меньше, чем без алгоритма inflight). Вы можете попробовать уменьшить этот параметр до 15, 10 или 5; а также уменьшить net.inet.tcp.inflight.min (например, до 3500) для получения желаемого эффекта. Уменьшение значений этих параметров может использоваться только как крайняя мера. В &os; версий 4.X и ранее системные переменные группы inflight расположены непосредственно в ветви net.inet.tcp. Их наименования (в алфавитном порядке): net.inet.tcp.inflight_debug, net.inet.tcp.inflight_enable, net.inet.tcp.inflight_max, net.inet.tcp.inflight_min, net.inet.tcp.inflight_stab. Виртуальная память <varname>kern.maxvnodes</varname> Файлы и каталоги в ядре представлены при помощи vnode (виртуальных узлов). Увеличение их числа может помочь уменьшить нагрузку на дисковую подсистему. Как правило, специальной настройки это значение не требует, однако, в некоторых случаях дисковая активность является узким местом, и система исчерпывает таблицу vnode, значение этой переменной следует увеличить. При этом необходимо оценить объем неактивной и свободной памяти. Текущее количество использованных vnode можно посмотреть при помощи команды: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 Максимальное количество vnode, доступных системе: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 Если количество использованных vnode близко к максимуму, значение переменной kern.maxvnodes следует увеличить на 1000. Следите за динамикой изменения vfs.numvnodes. Если оно увеличивается, приближаясь к вновь установленному максимуму, процесс следует повторить. Изменение в распределении памяти должно быть видно в выводе утилиты &man.top.1;: больше памяти перейдет в разряд активной. Увеличение объема подкачки Вне зависимости от того, что вы планировали, иногда система ведет себя неожиданно. Если вам потребовался дополнительный объем подкачки, его довольно просто добавить. Есть три способа увеличения объема подкачки: добавить новый жесткий диск, включить подкачку по NFS, или создать файл подкачки на существующем разделе. Подкачка на новом жестком диске Лучший способ добавить подкачку, конечно, использовать еще один жесткий диск. Вы можете сделать это в любой момент. Если такой способ подходит, прочтите еще раз информацию по пространству подкачки в Руководства, где рассказывается о наилучшем способе организации раздела подкачки. Подкачка через NFS Подкачка через NFS рекомендуется только в том случае, если в системе отсутствует жесткий диск. Подкачка через NFS медленна и неэффективна в версиях &os; до 4.X. Она довольно быстра и эффективна в 4.0-RELEASE и выше. Но даже в новых версиях &os;, подкачка через NFS ограничена скоростью сетевого подключения и к тому же дополнительно нагружает NFS сервер. Файлы подкачки Вы можете создать файл определенного размера и использовать его как файл подкачки. В нашем примере будет использован файл /usr/swap0 размером 64MB. Конечно, вы можете использовать любое имя. Создание файла подкачки в &os; 4.X Убедитесь, что ядре включен драйвер vnode. Он не включен в последних версиях GENERIC. pseudo-device vn 1 #Vnode driver (turns a file into a device) Создайте устройство vn: &prompt.root; cd /dev &prompt.root; sh MAKEDEV vn0 Создайте файл подкачки (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Установите подходящие права на (/usr/swap0): &prompt.root; chmod 0600 /usr/swap0 Включите файл подкачки в /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Перегрузите компьютер, или для включения подкачки прямо сейчас выполните: &prompt.root; vnconfig -e /dev/vn0b /usr/swap0 swap Создание файла подкачки в &os; 5.X Убедитесь, что в файле настройки ядра присутствует драйвер виртуального диска (&man.md.4;). Он есть в ядре GENERIC. device md # Memory "disks" Создайте файл подкачки (/usr/swap0): &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Установите подходящие права на (/usr/swap0): &prompt.root; chmod 0600 /usr/swap0 Включите файл подкачки в /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Перегрузите компьютер или для включения подкачки прямо сейчас введите: - &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 + &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Написал Tom Rhodes Управление питанием и ресурсами Очень важно использовать аппаратные ресурсы эффективно. До того, как появился ACPI, управление потреблением питания и температурными характеристиками системы было очень сложной для операционной системы задачей. Аппаратное обеспечение контролировалось одним из видов встроенного интерфейса BIOS, таким как: Plug and Play BIOS (PNPBIOS), Advanced Power Management (APM) и так далее. Управление питанием и ресурсами это один из ключевых компонентов современной операционной системы. Например, вам может потребоваться, чтобы операционная система следила за температурными ограничениями и возможно, предупреждала при неожиданном росте температуры. В этом разделе Руководства &os;, мы предоставим исчерпывающую информацию о ACPI. В конце раздела есть ссылки для дальнейшего чтения. Учтите, что ACPI есть только в &os; 5.X и выше в качестве стандартного модуля ядра. В &os; 4.9 ACPI можно включить добавлением строки device acpica к файлу настройки ядра и его пересборкой. Что такое ACPI? ACPI APM Advanced Configuration and Power Interface (ACPI) это стандарт, написанный объединением поставщиков в целях предоставления стандартного интерфейса для аппаратных ресурсов и управления питанием (отсюда и название). Это ключевой элемент Operating System-directed configuration and Power Management, т.е.: он предоставляет операционной системе (OS) больше контроля и более универсален. Современные системы вышли за пределы ограничений существующих Plug and Play интерфейсов (таких как APM, использовавшийся в &os; 4.X), до появления ACPI. ACPI это прямой наследник APM (Advanced Power Management). Недостатки Advanced Power Management (APM) Средства Advanced Power Management (APM) управляют энергопотреблением системы в зависимости от нагрузки. APM BIOS предоставляется поставщиком системы и специфичен для данной аппаратной платформы. Драйвер APM в OS обеспечивает доступ к APM Software Interface, который позволяет управлять уровнями потребления питания. В APM имеется четыре основных проблемы. Во-первых, управление энергопотреблением осуществляется через зависимый от поставщика BIOS, и OS ничего не знает нем. Один пример: когда пользователь устанавливает время ожидания для жесткого диска в APM BIOS, и это время истекает, BIOS останавливает жесткий диск без согласования с OS. Во-вторых, алгоритм APM встроен в BIOS, и все действия происходят вне контроля OS. Это означает, что пользователи могут решить проблемы с APM BIOS только путем перепрошивки его ROM; это очень опасная процедура, и если она завершится неудачно, система может оказаться в невосстановимом состоянии. В-третьих, реализация технологии APM зависит от поставщика, что означает дублирование усилий и если в BIOS одного из поставщиков будет найдена и исправлена ошибка, ее могли не исправить другие поставщики. Наконец, объем APM BIOS недостаточно велик для реализации сложной политики управления питанием, или такой политики, которая может хорошо адаптироваться к потребностям компьютера. Plug and Play BIOS (PNPBIOS) был неудобен во многих ситуациях. PNPBIOS это 16-битная технология, поэтому OS требовалось использовать 16-битную эмуляцию для взаимодействия с методами PNPBIOS. &os; драйвер APM документирован в странице справочника &man.apm.4;. Настройка <acronym>ACPI</acronym> &man.loader.8; загружает драйвер acpi.ko по умолчанию, его не надо встраивать в ядро. Причина в том, что с модулями проще работать, например переключиться на другой acpi.ko без пересборки ядра. Преимущество в упрощении тестирования. Другая причина в том, что запуск ACPI после старта системы не очень полезен и при некоторых условиях может приводить к краху. Если вы сомневаетесь, отключите ACPI совсем. Драйвер не должен и не может быть выгружен, поскольку системная шина используется для различных взаимодействий оборудования. ACPI может быть выключен с помощью утилиты &man.acpiconf.8;. Фактически большинство взаимодействий с ACPI может быть выполнено через &man.acpiconf.8;. В основном это означает, что если в выводе &man.dmesg.8; есть что-то об ACPI, он скорее всего работает. ACPI и APM не могут сосуществовать и должны использоваться раздельно. Каждый из них прервет загрузку, если обнаружит загруженный драйвер другого. В простейшей форме, ACPI может использоваться для перевода системы в спящий режим с помощью &man.acpiconf.8;, с флагом и параметром 1-5. Большинству пользователей нужен только параметр 1. Параметр 5 сделает мягкое завершение работы, так же как и: &prompt.root; halt -p Доступны и другие параметры. Обратитесь к странице справочника &man.acpiconf.8; за дополнительной информацией. Nate Lawson Написал Peter Schultz При помощи Tom Rhodes Использование и отладка &os; <acronym>ACPI</acronym> ACPI это фундаментально новый способ обнаружения устройств, управления энергопотреблением и предоставления стандартизированного доступа к различному оборудованию, ранее управлявшемуся BIOS. Был достигнут определенный прогресс в приспособлении ACPI к работе со всеми системами, но все еще встречаются ошибки в байткоде ACPI Machine Language (AML) некоторых материнских плат, незавершенные участки кода в подсистемах ядра &os; и ошибки в интерпретаторе &intel; ACPI-CA. Этот раздел предназначен для того, чтобы упростить ваше содействие разработчикам &os; ACPI в определении причин наблюдаемых вами проблем, выполнении отладки и выработке решения. Спасибо за помощь и надеемся, что мы сможем помочь в решении проблем вашей системы. Отправка отладочной информации Перед отправкой сообщения об ошибке убедитесь, что у вас последняя версия BIOS, и, если доступна, последняя версия firmware встроенного контроллера. Те из вас, кто желает составить сообщение о проблеме прямо сейчас, могут воспользоваться адресом freebsd-acpi@FreeBSD.org, отправив на него следующую информацию: Описание неправильного поведения, включая тип системы, модель и все, что приводит к появлению ошибки. Кроме того, сообщите настолько точно, насколько возможно, когда появилась ошибка, если ранее вы ее не видели. Вывод &man.dmesg.8; после boot -v, включая все сообщения, появившиеся при изучении ошибки. Вывод &man.dmesg.8; после boot -v с выключенным ACPI, если его отключение помогает решить проблему. Вывод sysctl hw.acpi. Это также хороший способ получения списка возможностей системы. URL где можно найти ваш ACPI Source Language (ASL). Не отправляйте ASL непосредственно в список рассылки, поскольку он может быть очень большим. Копия ASL может быть создана командой: &prompt.root; acpidump -t -d > name-system.asl (Замените вашим логином name и производителем/моделью system. Пример: njl-FooCo6000.asl) Большинство разработчиков читают &a.current;, но для уверенности, что проблему увидят, отправьте ее в &a.acpi.name;. Будьте терпеливы, все мы заняты полный рабочий день где-то еще. Если ваше сообщение не заметили сразу, мы возможно попросим вас отправить PR (сообщение о проблеме) через &man.send-pr.1;. При вводе PR, включайте ту же информацию, что запрошена выше. Это поможет нам отследить проблему и решить ее. Не отправляйте PR без предварительной отправки письма в &a.acpi.name;, поскольку мы используем PR в качестве напоминаний о существующих проблемах, а не как механизм сообщений об ошибках. Вероятно, о вашей проблеме кто-то уже сообщал ранее. Общие сведения ACPI ACPI представлен во всех современных компьютерах, соответствующих архитектурам ia32 (x86), ia64 (Itanium) и amd64 (AMD). Полный стандарт включает множество возможностей, в том числе управление производительностью CPU, уровнем питания, температурой, различными системами аккумуляторов, встроенными контроллерами и опросом шины. В большинстве систем стандарт реализован не полностью. Например, настольные системы обычно реализуют только опрос шины, а портативные компьютеры кроме того могут поддерживать управление охлаждением и энергопотреблением. Они также поддерживают приостановку и последующий запуск системы различного уровня сложности. ACPI-совместимые системы состоят из различных компонентов. Производители BIOS и чипсетов предоставляют различные жестко заданные таблицы, (например, FADT), которые определяют функции вроде карты APIC (используется для SMP), регистры настройки и простые значения параметров. Кроме того, предоставляется таблица байткода (Differentiated System Description Table, DSDT), определяющая древоподобное пространство имен устройств и методов. Драйвер ACPI должен прочесть заданные таблицы, реализовать интерпретатор для байткода, модифицировать драйвера устройств и ядро для приема информации от подсистемы ACPI. Для &os; &intel; предоставила интерпретатор (ACPI-CA), тот же что для Linux и NetBSD. Исходный код ACPI-CA находится в каталоге src/sys/contrib/dev/acpica. Код для приспособления ACPI-CA к работе в &os;, находится в src/sys/dev/acpica/Osd. Наконец, драйвера, реализующие различные ACPI устройства, находятся в src/sys/dev/acpica. Часто встречающиеся проблемы ACPI проблемы Для правильной работы ACPI все ее части должны работать правильно. Вот некоторые часто встречающиеся проблемы, в порядке частоты появления, и некоторые обходные пути или исправления. Проблемы с мышью В некоторых случаях при возобновлении работы после приостановки перестает работать мышь. Известным решением проблемы является добавление строки hint.psm.0.flags="0x3000" в файл /boot/loader.conf. Если это не помогло, стоит сообщить о проблеме, как описано выше. Приостановка/возобновление работы ACPI поддерживает три состояния приостановки в RAM (STR), S1-S3, и одно состояние приостановки на диск (STD), называемое S4. S5 это мягкое выключение и это нормальное состояние системы, когда она подключена к сети, но не включена. S4 может быть реализован двумя различными путями. S4BIOS это BIOS-поддерживаемая приостановка на диск. S4OS реализуется полностью операционной системой. Начните с проверки переменных sysctl hw.acpi, относящихся к приостановке (suspend). Вот результат для Thinkpad: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Это означает, что мы можем использовать acpiconf -s для тестирования S3, S4OS, и S5. Если был единицей (1), это означает поддержку S4BIOS вместо S4OS. При тестировании приостановки/возобновления работы, начните с S1, если этот режим поддерживается. Это состояние скорее всего поддерживается, поскольку не требует слишком серьезной поддержки со стороны драйвера. Никто не реализовал S2, который похож на S1. Следующий режим для тестирования это S3. Это наиболее глубокое STR состояние, оно требует существенной поддержки со стороны драйвера, чтобы правильно реинициализировать оборудование. Если у вас возникли проблемы при выходе из этого состояния, отправьте письмо в рассылку &a.acpi.name;, но не ждите, что проблема будет обязательно решена, поскольку существует множество драйверов/оборудования, нуждающихся в дальнейшем тестировании и разработке. Для изоляции проблемы удалите из ядра столько драйверов, сколько возможно. Если это работает, вы можете выяснить, какой драйвер вызывает проблему путем загрузки драйверов до тех пор, пока опять не произойдет сбой. Обычно бинарные драйвера, такие как nvidia.ko, драйвера дисплея X11 и USB вызывают большинство проблем, а драйвера Ethernet интерфейсов как правило работают отлично. Если вы можете нормально загрузить/выгрузить драйвера, автоматизируйте этот процесс, поместив соответствующие команды в /etc/rc.suspend и /etc/rc.resume. Это закомментированные примеры выгрузки и загрузки драйверов. Попробуйте установить параметр в нуль (0), если ваш дисплей не включается после возобновления работы. Попробуйте установить большие или меньшие значения для , чтобы проверить, поможет ли это. Другой способ, который можно попробовать, это запуск последнего дистрибутива Linux с поддержкой ACPI и тестирование поддержки остановки/возобновления работы на том же оборудовании. Если она работает на Linux, проблема скорее всего в драйверах &os; и поиск драйвера, вызывающего проблему, поможет разрешить ситуацию. Имейте ввиду, что разработчики ACPI обычно не поддерживают другие драйверы (звук, ATA, и т.п.), так что все результаты работы по поиску проблемы возможно необходимо отправить в список рассылки &a.current.name; и человеку, поддерживающему драйвер. Если вы решитесь заняться отладкой, поместите соответствующий код (&man.printf.3;) в вызывающий проблему драйвер для обнаружения места, где прерывается функция восстановления. Наконец, попробуйте отключить ACPI и включить APM. Если приостановка/возобновление работает с APM, вам возможно лучше подойдет APM, особенно на старом оборудовании (до 2000). Включение корректной поддержки ACPI поставщиками оборудования требует времени и вероятно в старом оборудовании поддержка ACPI в BIOS была некорректна. Система останавливается (временно или постоянно) Большинство систем останавливаются в результате потери прерываний или шторма прерываний. В чипсетах существует много проблем, связанных с тем, как BIOS настраивает прерывания перед загрузкой, правильностью таблицы APIC (MADT), и маршрутизации System Control Interrupt (SCI). шторм прерываний Шторм прерываний может быть обнаружен по потерянным прерываниям путем проверки вывода строки с acpi0 команды vmstat -i. Если счетчик увеличивается более, чем несколько раз в секунду, это шторм прерываний. Если система останавливается, попробуйте войти в DDB (CTRL ALTESC на консоли) и ввести show interrupts. APIC отключение Наиболее надежный способ избавиться от проблемы с прерываниями, это отключение поддержки APIC с помощью параметра loader.conf hint.apic.0.disabled="1". Паника Паника, связанная с ACPI, случается довольно редко и имеет наибольший приоритет исправления. Первый шаг это изоляция действий, приводящих к панике (если это возможно) и получение отладки. Следуйте инструкции по включению options DDB и настройке последовательной консоли (смотрите ) или настройке раздела &man.dump.8;. Вы можете получить отладочную информацию DDB с помощью tr. Если вы записываете отладку вручную, убедитесь, что переписали как минимум пять (5) строк снизу и пять (5) строк сверху. Затем попробуйте изолировать проблему, загрузившись с выключенным ACPI. Если это работает, вы можете изолировать подсистему ACPI, используя различные параметры . Обратитесь к странице справочника &man.acpi.4; за примерами. Система включается после приостановки или завершения работы Во-первых, попробуйте установить в &man.loader.conf.5; параметр hw.acpi.disable_on_poweroff="0". Это предотвращает отключение различных событий в ACPI во время завершения работы. В некоторых системах этот параметр необходимо установить в 1 (по умолчанию) по тем же причинам. Обычно это решает проблему, если система неожиданно включается после приостановки или отключения питания. Другие проблемы Если вы наблюдаете другие проблемы с ACPI (работа с внешним оборудованием, проблемы с обнаружением устройств, и т.д.), отправьте описание проблемы в список рассылки; однако, некоторые из этих проблем могут относиться к незавершенным частям подсистемы ACPI, поэтому может потребоваться время на их реализацию. Будьте терпеливы, и подготовьтесь к тестированию исправлений, которые мы можем вам выслать. <acronym>ASL</acronym>, <command>acpidump</command>, и <acronym>IASL</acronym> ACPI ASL Наиболее часто встречается проблема, связанная с предоставлением поставщиками BIOS некорректного (или полностью ошибочного!) байткода. Это обычно проявляется появлением консольных сообщений ядра, подобных этому: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Зачастую вы можете разрешить эти проблемы путем обновления BIOS до последней ревизии. Большинство консольных сообщений безвредны, но если существуют другие проблемы, такие как не работающий статус батареи, возможно существуют проблемы в AML. Байткод, известный как AML, компилируется из исходного текста на языке ASL. AML находится в таблице, известной как DSDT. Для получения копии ASL, используйте &man.acpidump.8;. Вы можете использовать оба параметра (показывать содержимое постоянных таблиц) и (дизассемблировать AML в ASL). Обратитесь к разделу Отправка отладочной информации за примером синтаксиса. Простейшая первая проверка, которую вы можете провести, это перекомпиляция ASL для поиска ошибок. Предупреждения обычно могут быть проигнорированы, но ошибки обычно не позволяют ACPI работать правильно. Для перекомпиляции ASL, выполните следующую команду: &prompt.root; iasl your.asl Исправление <acronym>ASL</acronym> ACPI ASL В дальней перспективе, наша задача состоит в том, чтобы обеспечить поддержку ACPI практически для каждой системы без вмешательства пользователя. Однако, на данный момент мы все еще разрабатываем обходные пути для ошибок, которые часто делают поставщики BIOS. Интерпретатор µsoft; (acpi.sys и acpiec.sys) не занимается проверкой четкости соблюдения стандартов, поэтому многие поставщики BIOS, проверяющие ACPI только под &windows;, никогда не исправляют ASL. Мы надеемся продолжать обнаружение и документацию нестандартных поведений, позволяемых интерпретатором µsoft;, и воспроизводить их, чтобы &os; могла работать без необходимости исправления ASL пользователями. В качестве обходного пути для обнаружения неправильного поведения, вы можете исправить ASL вручную. Если исправления будут работать, пожалуйста отправьте &man.diff.1; между старым и новым ASL, чтобы мы могли реализовать обходной путь для неправильного поведения ACPI-CA, чтобы исправление вручную больше не требовалось. ACPI сообщения об ошибках Вот список наиболее часто встречающихся проблем, их причин и способы исправления: OS зависимости Некоторые AML предполагают, что мир состоит из различных версий &windows;. Вы можете настроить &os;, чтобы она сообщала любое другое имя OS и посмотреть, исправит ли это имеющуюся проблему. Простой способ указания другого имени системы это установка переменной /boot/loader.conf hw.acpi.osname="Windows 2001" или в другое подобное значение, имеющееся в ASL. Отсутствие возврата значения Некоторые методы не возвращают значение явно, как того требует стандарт. Хотя ACPI-CA не обрабатывает эту ситуацию, в &os; существует обходной путь, позволяющей ей явно возвращать значение. Вы можете также добавить явные операторы Return (возврат) там, где требуется, если знаете, что значение должно быть возвращено. Для принудительного компилирования ASL командой iasl, используйте флаг . Перезапись <acronym>AML</acronym> по умолчанию После настройки your.asl для компиляции запустите: &prompt.root; iasl your.asl Вы можете добавить флаг для создания AML даже при наличии ошибок компиляции. Помните, что некоторые ошибки (например, отсутствующие операторы Return), автоматически обходятся интерпретатором. Файл DSDT.aml используется iasl по умолчанию. Вы можете загрузить его вместо ошибочной копии BIOS (которая остается в постоянной памяти) путем редактирования /boot/loader.conf: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Убедитесь, что скопировали DSDT.aml в каталог /boot. Получение отладочной информации <acronym>ACPI</acronym> ACPI проблемы ACPI отладка Возможности отладки драйвера ACPI очень гибкие. Они позволяют вам указывать набор подсистем, а также уровень отладки. Подсистемы, которые вы хотите отлаживать, указываются как слои, и подразделяются на компоненты ACPI-CA (ACPI_ALL_COMPONENTS) и поддержку оборудования ACPI (ACPI_ALL_DRIVERS). Уровень отладки варьируется от ACPI_LV_ERROR (только сообщать об ошибках) до ACPI_LV_VERBOSE (все сообщения). Уровень отладки представляет собой битовую маску, поэтому возможна одновременная установка нескольких параметров, разделенных пробелами. На практике, при использовании для получения отладочной информации последовательной консоли, слишком большое количество информации может переполнить буфер консоли. Полный список отдельных слоев и уровней можно найти на странице справочника &man.acpi.4;. Вывод отладочной информации по умолчанию не включен. Для его включения добавьте параметр options ACPI_DEBUG к файлу настройки ядра, если ACPI встроен в ядро. Вы можете добавить параметр ACPI_DEBUG=1 в файл /etc/make.conf для глобального включения этого параметра. Если вы используете модуль acpi.ko , его можно пересобрать индивидуально: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 Установите acpi.ko в /boot/kernel и добавьте предпочитаемый уровень и слой к loader.conf. Этот пример включает отладочные сообщения для всех компонентов ACPI-CA и всех драйверов оборудования ACPI (CPU, LID и т.д.). Будут выводиться только сообщения об ошибках, наименьший уровень отладки. debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" Если требуемая информация получается в результате определенного события (скажем, приостановка и восстановление), вы можете не изменять loader.conf и использовать для указания слоя и уровня sysctl после загрузки и подготовки системы к определенному событию. Имена переменных sysctl те же, что и имена параметров настройки в loader.conf. Ссылки Дальнейшую информацию о ACPI можно найти по следующим ссылкам: &a.acpi; Архивы списка рассылки ACPI Старые архивы списка рассылки ACPI Спецификация ACPI 2.0 Страницы справочника &os;: &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, &man.acpidb.8; Ресурс по отладке DSDT. (Использует в качестве примера Compaq, но обычно полезен.) diff --git a/ru_RU.KOI8-R/books/handbook/network-servers/chapter.sgml b/ru_RU.KOI8-R/books/handbook/network-servers/chapter.sgml index 81a0827c8b..1cc3f0f607 100644 --- a/ru_RU.KOI8-R/books/handbook/network-servers/chapter.sgml +++ b/ru_RU.KOI8-R/books/handbook/network-servers/chapter.sgml @@ -1,5271 +1,5263 @@ Murray Stokely Реорганизовал Андрей Захватов Перевод на русский язык: Сетевые серверы Краткий обзор Эта глава посвящена некоторым наиболее часто используемым сетевым службам систем &unix;. Мы опишем, как установить, настроить, протестировать и поддерживать многие различные типы сетевых сервисов. Для облегчения вашей работы в главу включены примеры конфигурационных файлов. После чтения этой главы вы будете знать: Как управлять даемоном inetd. Как настроить сетевую файловую систему. Как настроить сетевой сервер информации для совместного использования учётных записей пользователей. Как настроить автоматическое конфигурирование сетевых параметров при помощи DHCP. Как настроить сервер имён. Как настроить Apache HTTP сервер. - Как настроить файловый и принт сервер для &windows; + Как настроить файловый и сервер печати для &windows; клиентов с использованием Samba. Как синхронизировать дату и время, а также настроить сервер времени с протоколом NTP. Перед чтением этой главы вы должны: Понимать основы работы скриптов /etc/rc. Свободно владеть основными сетевыми терминами. Знать как устанавливать дополнительные программы сторонних разработчиков (). Chern Lee Текст предоставил <quote>Супер-сервер</quote> <application>inetd</application> Обзор &man.inetd.8; называют также супер-сервером Интернет, потому что он управляет соединениями к многим сервисам. Когда inetd принимает соединение, он определяет, для какой программы предназначено соединение, запускает соответствующий процесс и предоставляет ему сокет, ссылка на который передается процессу в качестве стандартных устройств ввода, вывода и сообщения об ошибках. Запуск одного экземпляра inetd уменьшает общую нагрузку на систему по сравнению с запуском каждого даемона индивидуально в выделенном режиме. В первую очередь inetd используется для вызова других даемонов, но несколько простых протоколов, таких, как chargen, auth и daytime, обслуживаются непосредственно. Этот раздел посвящен основам настройки inetd посредством его параметров командной строки и его конфигурационного файла, /etc/inetd.conf. Настройки inetd инициализируется посредством системы /etc/rc.conf. Параметр inetd_enable по умолчанию установлен в NO, однако часто включается утилитой sysinstall при выборе профиля среднего уровня безопасности. Указание inetd_enable="YES" или inetd_enable="NO" в файле /etc/rc.conf может задать или запретить запуск inetd во время загрузки. Кроме того, через inetd_flags даемону inetd могут быть переданы различные параметры командной строки. Параметры командной строки Формат вызова inetd: -d Включение отладочной информации. -l Включение регистрации успешных соединений. -w Включение механизма TCP Wrapping для внешних служб (по умолчанию включено). -W Включение механизма TCP Wrapping для внутренних служб, которые встроены в inetd (по умолчанию включено). -c maximum Определение максимального числа одновременных запусков каждой службы; по умолчание не ограничено. Может быть переопределено индивидуально для каждой службы при помощи параметра . -C rate Определение по умолчанию максимального количества раз, которое служба может быть вызвана с одного IP-адреса в минуту; по умолчанию не ограничено. Может быть переопределено для каждой службы параметром . -R rate Определяет максимальное количество раз, которое служба может быть вызвана в минуту; по умолчанию 256. Частота, равная 0, не ограничивает число вызовов. -a Задает один IP-адрес, к которому делается привязка. Альтернативно может быть указано имя хоста, и в этом случае используется соответствующий этому имени хоста адрес IPv4 или IPv6. Обычно имя хоста задается, когда inetd запускается в окружении &man.jail.8;, и в этом случае имя хоста соответствует этому &man.jail.8;-окружению. Если используется формат с именем хоста и требуется привязка как для IPv4, так и для IPv6, то для каждой привязки требуется запись с соответствующим типом протокола для каждой службы в файле /etc/inetd.conf. К примеру, службе на основе TCP потребуется две записи, в одной для протокола используется tcp4, а в другой используется tcp6. -p Задает альтернативный файл для хранения ID процесса. Эти параметры могут быть переданы в inetd при помощи inetd_flags в файле /etc/rc.conf. По умолчанию значение inetd_flags установлено в -wW, что включает механизм TCP wrapping для внутренних и внешних служб inetd. Новичкам эти параметры изменять и даже задавать их в файле /etc/rc.conf не нужно. Внешняя служба является даемоном вне inetd, который запускается при получении соединения к нему. С другой стороны, внутренней службой является услуга, которую inetd предоставляет сам. <filename>inetd.conf</filename> Настройка inetd управляется через файл /etc/inetd.conf. Если в файле /etc/inetd.conf делались изменения, то inetd можно заставить считать его конфигурационный файл повторно, послав сигнал HangUP процессу inetd, как показано здесь: Посылка сигнала HangUP процессу <application>inetd</application> &prompt.root; kill -HUP `cat /var/run/inetd.pid` В каждой строке конфигурационного файла описывается отдельный даемон. Комментариям в файле предшествует знак #. Файл /etc/inetd.conf имеет такой формат: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] user[:group][/login-class] server-program server-program-arguments Пример записи для даемона ftpd, использующего IPv4: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Это имя сервиса, предоставляемого конкретным даемоном. Оно должно соответствовать сервису, указанному в файле /etc/services. Здесь определяется, какой порт должен обслуживать inetd. При создании нового сервиса он должен помещаться сначала в файл /etc/services. socket-type stream, dgram, raw либо seqpacket. stream должен использоваться для ориентированных на соединение даемонов TCP, когда как dgram используется для даемонов, использующих транспортный протокол UDP. protocol Одно из следующих: Протокол Описание tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP как для IPv4, так и для v6 udp46 UDP как для IPv4, так и для v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] определяет, может ли даемон, вызванный из inetd, работать с собственным сокетом, или нет. Сокеты типа должны использовать параметр , когда как даемоны с потоковыми сокетами, которые обычно многопоточны, должны использовать . обычно передает много сокетов одному даемону, когда как порождает даемон для каждого нового сокета. Максимальное число порожденных даемонов, которых может создать inetd, может быть задано параметром . Если нужно ограничение в десять экземпляров некоторого даемона, то после параметра нужно задать /10. Кроме , может быть задействован другой параметр, ограничивающий максимальное число соединений от одного источника. служит именно для этого. Здесь значение, равное десяти, будет ограничивать любой заданный IP-адрес на выполнение десяти попыток подключения к некоторому сервису в минуту. Это полезно для предотвращения намеренного или ненамеренного расходования ресурсов и атак типа Denial of Service (DoS) на машину. В этом поле или обязательны. и опциональны. Многопоточный даемон типа stream без ограничений или будет определен просто вот так: nowait. Тот же самый даемон с ограничением в максимум десять даемонов будет определен так: nowait/10. Наконец, та же конфигурация с ограничением в двадцать соединений на IP-адрес в минуту и общим ограничением в максимум десять порожденных даемонов выглядит так: nowait/10/20. Эти параметры, используемые все со значениями по умолчанию даемоном fingerd, имеют такой вид: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s user Это имя пользователя, под которым должен работать соответствующий даемон. Чаще всего даемоны работают как пользователь root. Для обеспечения безопасности некоторые серверы запускаются как пользователь daemon или как пользователь с минимальными правами nobody. server-program Полный маршрут к даемону, который будет выполняться при установлении соединения. Если даемон является сервисом, предоставляемым самим inetd, то нужно задать ключевое слово . server-program-arguments Этот параметр работает вместе с параметром , задавая параметры, начиная с argv[0], передаваемые даемону при запуске. Если в командной строке задано mydaemon -d, то mydaemon -d будет являться значением для . И снова, если даемон является внутренней службой, то здесь нужно использовать . Безопасность В зависимости от схемы безопасности, выбранной при установке, многие из даемонов inetd могут оказаться по умолчанию включенными. Если нет особой нужды в некотором даемоне, то выключите его! Поместите знак # перед ненужным даемоном в /etc/inetd.conf и пошлите сигнал для inetd. Некоторые даемоны, такие, как fingerd, вообще нежелательны, потому что они дают атакующему слишком много информации. Некоторые даемоны не заботятся о безопасности и имеют большие - таймауты для соединений или вообще их не имеют. Это позволяет + тайм-ауты для соединений или вообще их не имеют. Это позволяет атакующему неспешно устанавливать соединения к конкретному даемону, истощая имеющиеся ресурсы. Может оказаться полезным задать для некоторых даемонов ограничения и . По умолчанию механизм TCP wrapping включен. Обратитесь к справочной странице по &man.hosts.access.5; для получения более подробной информации о задании ограничений TCP для различных даемонов, запускаемых посредством inetd. Разное daytime, time, echo, discard, chargen и auth все являются услугами, предоставляемыми самим inetd. Сервис auth предоставляет идентификационные сетевые услуги (ident, identd) и поддается настройке. Обратитесь к справочной странице по &man.inetd.8; для получения более подробной информации. Tom Rhodes Реорганизация и улучшения Bill Swingle Текст создал Network File System (NFS) NFS Кроме поддержки многих прочих типов файловых систем, во FreeBSD встроена поддержка сетевой файловой системы (Network File System), известной как NFS. NFS позволяет системе использовать каталоги и файлы совместно с другими машинами, посредством сети. Посредством NFS пользователи и программы могут получать доступ к файлам на удалённых системах точно так же, как если бы это были файлы на собственных дисках. Вот некоторые из наиболее заметных преимуществ, которые даёт использование NFS: Отдельно взятые рабочие станции используют меньше собственного дискового пространства, так как совместно используемые данные могут храниться на одной отдельной машине и быть доступными для других машин в сети. Пользователям не нужно иметь домашние каталоги, отдельные для каждой машины в вашей сети. Домашние каталоги могут располагаться на сервере NFS и их можно сделать доступными отовсюду в сети. Устройства хранения информации, такие, как дискеты, приводы CD-ROM и устройства &iomegazip;, могут использоваться другими машинами в сети. Это может привести к уменьшению переносимых устройств хранения информации в сети. Как работает <acronym>NFS</acronym> NFS строится по крайней мере из двух основных частей: сервера и одного или большего количества клиентов. Клиент обращается к данным, находящимся на сервере, в режиме удалённого доступа. Для того, чтобы это нормально функционировало, нужно настроить и запустить несколько процессов. В &os; 4.X, вместо утилиты rpcbind использовалась утилита portmap. Таким образом, при использовании &os; 4.X пользователю необходимо заменить в последующих примерах все команды rpcbind на portmap. На сервере работают следующие даемоны: NFS сервер файл сервер UNIX клиенты rpcbind portmap mountd nfsd Даемон Описание nfsd Даемон NFS, обслуживающий запросы от клиентов NFS. mountd Даемон монтирования NFS, который выполняет запросы, передаваемые ему от &man.nfsd.8;. rpcbind Этот даемон позволяет клиентам NFS определить порт, используемый сервером NFS. Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. Для получения дополнительной информации обратитесь к разделу справочной системы о &man.nfsiod.8;. Настройка <acronym>NFS</acronym> NFS настройка Настройка NFS является достаточно незамысловатым процессом. Все процессы, которые должны быть запущены, могут быть запущены во время загрузки посредством нескольких модификаций в вашем файле /etc/rc.conf. Проверьте, что на NFS-сервере в файле /etc/rc.conf имеются такие строки: rpcbind_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd запускается автоматически, если включена функция сервера NFS. На клиенте убедитесь, что в файле /etc/rc.conf присутствует такой параметр: nfs_client_enable="YES" Файл /etc/exports определяет, какие файловые системы на вашем сервере NFS будут экспортироваться (иногда их называют совместно используемыми). Каждая строка в /etc/exports задаёт файловую систему, которая будет экспортироваться и какие машины будут иметь к ней доступ. Кроме машин, имеющих доступ, могут задаваться другие параметры, влияющие на характеристики доступа. Имеется полный набор параметров, которые можно использовать, но здесь пойдёт речь лишь о некоторых из них. Описания остальных параметров можно найти на страницах справочной системы по &man.exports.5;. Вот несколько примерных строк из файла /etc/exports: NFS примеры экспортирования В следующих примерах даётся общая идея того, как экспортировать файловые системы, хотя конкретные параметры могут отличаться в зависимости от ваших условий и конфигурации сети. К примеру, чтобы экспортировать каталог /cdrom для трёх машин, находящихся в том же самом домене, что и сервер (поэтому отсутствует доменное имя для каждой машины) или для которых имеются записи в файле /etc/hosts. Флаг указывает на использование экспортируемой файловой системы в режиме только чтения. С этим флагом удалённая система не сможет никоим образом изменить экспортируемую файловую систему. /cdrom -ro host1 host2 host3 В следующей строке экспортируется файловая система /home, которая становится доступной трем хостам, указанным по их IP-адресам. Это полезно, если у вас есть собственная сеть без настроенного сервера DNS. Как вариант, файл /etc/hosts может содержать внутренние имена хостов; пожалуйста, обратитесь к справочную систему по &man.hosts.5; для получения дополнительной информации. Флаг позволяет рассматривать подкаталоги в качестве точек монтирования. Другими словами, это не монтирование подкаталогов, но разрешение клиентам монтировать только каталоги, которые им требуются или нужны. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 В строке, приведённой ниже, файловая система /a экспортируется таким образом, что она доступна двум клиентам из других доменов. Параметр позволяет пользователю root удалённой системы осуществлять запись на экспортируемую файловую систему как пользователь root. Если параметр -maproot=root не задан, то даже если пользователь имеет права доступа root на удалённой системе, он не сможет модифицировать файлы на экспортированной файловой системе. /a -maproot=root host.example.com box.example.org Для того, чтобы клиент смог обратиться к экспортированной файловой системе, он должен иметь права сделать это. Проверьте, что клиент указан в вашем файле /etc/exports. В файле /etc/exports каждая строка содержит информацию об экспортировании для отдельной файловой системы для отдельно взятого хоста. Удалённый хост может быть задан только один раз для каждой файловой системы, и может иметь только одну запись, используемую по умолчанию, для каждой локальной файловой системы. К примеру, предположим, что /usr является отдельной файловой системой. Следующий /etc/exports будет некорректен: # Invalid when /usr is one file system /usr/src client /usr/ports client Одна файловая система, /usr, имеет две строки, задающие экспортирование для одного и того же хоста, client. Правильный формат в этом случае таков: /usr/src /usr/ports client Свойства отдельной файловой системы, экспортируемой некоторому хосту, должны задаваться в одной строке. Строки без указания клиента воспринимаются как отдельный хост. Это ограничивает то, как вы можете экспортировать файловые системы, но для большинства это не проблема. Ниже приведён пример правильного списка экспортирования, где /usr и /exports являются локальными файловыми системами: # Экспортируем src и ports для client01 и client02, но # только client01 имеет права пользователя root на них /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # Клиентские машины имеют пользователя root и могут монтировать всё в # каталоге /exports. Кто угодно может монтировать /exports/obj в режиме чтения /exports -alldirs -maproot=root client01 client02 /exports/obj -ro Вы должны перезапустить mountd после того, как изменили /etc/exports, чтобы изменения вступили в силу. Это может быть достигнуто посылкой сигнала HUP процессу mountd: &prompt.root; kill -HUP `cat /var/run/mountd.pid` Как вариант, при перезагрузке FreeBSD всё настроится правильно. Хотя выполнять перезагрузку вовсе не обязательно. Выполнение следующих команд пользователем root запустит всё, что нужно. На сервере NFS: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r На клиенте NFS: &prompt.root; nfsiod -n 4 Теперь всё должно быть готово к реальному монтированию удалённой файловой системы. В приводимых примерах сервер будет носить имя server, а клиент будет носить имя client. Если вы только хотите временно смонтировать удалённую файловую систему, или всего лишь протестировать ваши настройки, то просто запустите команды, подобные приводимым здесь, работая как пользователь root на клиентской машине: NFS монтирование &prompt.root; mount server:/home /mnt По этой команде файловая система /home на сервере будет смонтирована в каталог /mnt на клиенте. Если всё настроено правильно, вы сможете войти в каталог /mnt на клиенте и увидеть файлы, находящиеся на сервере. Если вы хотите автоматически монтировать удалённую файловую систему при каждой загрузке компьютера, добавьте файловую систему в /etc/fstab. Вот пример: server:/home /mnt nfs rw 0 0 На страницах справочной системы по &man.fstab.5; перечислены все доступные параметры. Практическое использование У NFS есть много вариантов практического применения. Ниже приводится несколько наиболее широко распространённых способов её использования: NFS использование Настройка несколько машин для совместного использования CDROM или других носителей. Это более дешёвый и зачастую более удобный способ установки программного обеспечения на несколько машин. В больших сетях может оказаться более удобным настроить центральный сервер NFS, на котором размещаются все домашние каталоги пользователей. Эти домашние каталоги могут затем экспортироваться в сеть так, что пользователи всегда будут иметь один и тот же домашний каталог вне зависимости от того, на какой рабочей станции они работают. Несколько машин могут иметь общий каталог /usr/ports/distfiles. Таким образом, когда вам нужно будет установить порт на несколько машин, вы сможете быстро получить доступ к исходным текстам без их загрузки на каждой машине. Wylie Stilwell Текст предоставил Chern Lee Текст переписал Автоматическое монтирование с <application>amd</application> amd даемон автоматического монтирования &man.amd.8; (даемон автоматического монтирования) автоматически монтирует удалённую файловую систему, как только происходит обращение к файлу или каталогу в этой файловой системе. Кроме того, файловые системы, которые были неактивны некоторое время, будут автоматически размонтированы даемоном amd. Использование amd является простой альтернативой статическому монтированию, так как в последнем случае обычно всё должно быть описано в файле /etc/fstab. amd работает, сам выступая как сервер NFS для каталогов /host и /net. Когда происходит обращение к файлу в одном из этих каталогов, amd ищет соответствующий удаленный ресурс для монтирования и автоматически его монтирует. /net используется для монтирования экспортируемой файловой системы по адресу IP, когда как каталог /host используется для монтирования ресурса по удаленному имени хоста. Обращение к файлу в каталоге /host/foobar/usr укажет amd на выполнение попытки монтирования ресурса /usr, который находится на хосте foobar. Монтирование ресурса при помощи <application>amd</application> Вы можете посмотреть доступные для монтирования ресурсы отдалённого хоста командой showmount. К примеру, чтобы посмотреть ресурсы хоста с именем foobar, вы можете использовать: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Как видно из примера, showmount показывает /usr как экспортируемый ресурс. При переходе в каталог /host/foobar/usr даемон amd пытается разрешить имя хоста foobar и автоматически смонтировать требуемый ресурс. amd может быть запущен из скриптов начальной загрузки, если поместить такую строку в файл /etc/rc.conf: amd_enable="YES" Кроме того, даемону amd могут быть переданы настроечные флаги через параметр amd_flags. По умолчанию amd_flags настроен следующим образом: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Файл /etc/amd.map задает опции, используемые по умолчанию при монтировании экспортируемых ресурсов. В файле /etc/amd.conf заданы настройки некоторых более сложных возможностей amd. Обратитесь к справочным страницам по &man.amd.8; и &man.amd.conf.5; для получения более полной информации. John Lind Текст предоставил Проблемы взаимодействия с другими системами Некоторые сетевые адаптеры для систем PC с шиной ISA имеют ограничения, которые могут привести к серьезным проблемам в сети, в частности, с NFS. Эти проблемы не специфичны для FreeBSD, однако эту систему они затрагивают. Проблема, которая возникает практически всегда при работе по сети систем PC (FreeBSD) с высокопроизводительными рабочими станциями, выпущенными такими производителями, как Silicon Graphics, Inc. и Sun Microsystems, Inc. Монтирование по протоколу NFS будет работать нормально, и некоторые операции также будут выполняться успешно, но неожиданно сервер окажется недоступным для клиент, хотя запросы к и от других систем будут продолжаться обрабатываться. Такое встречается с клиентскими системами, не зависимо от того, является ли клиент машиной с FreeBSD или рабочей станцией. Во многих системах при возникновении этой проблемы нет способа корректно завершить работу клиента. Единственным выходом зачастую является холодная перезагрузка клиента, потому что ситуация с NFS не может быть разрешена. Хотя правильным решением является установка более производительного и скоростного сетевого адаптера на систему FreeBSD, имеется простое решение, приводящее к удовлетворительным результатам. Если система FreeBSD является сервером, укажите параметр на клиенте при монтировании. Если система FreeBSD является клиентом, то смонтируйте файловую систему NFS с параметром . Эти параметры могут быть заданы в четвертом поле записи в файле fstab клиента при автоматическом монтировании, или при помощи параметра в команде &man.mount.8; при монтировании вручную. Нужно отметить, что имеется также другая проблема, ошибочно принимаемая за приведенную выше, когда серверы и клиенты NFS находятся в разных сетях. Если это тот самый случай, проверьте, что ваши маршрутизаторы пропускают нужную информацию UDP, в противном случае вы ничего не получите, что бы вы ни предпринимали. В следующих примерах fastws является именем хоста (интерфейса) высокопроизводительной рабочей станции, а freebox является именем хоста (интерфейса) системы FreeBSD со слабым сетевым адаптером. Кроме того, /sharedfs будет являться экспортируемой через NFS файловой системой (обратитесь к страницам справочной системы по команде &man.exports.5;), а /project будет точкой монтирования экспортируемой файловой системы на клиенте. В любом случае, отметьте, что для вашего приложения могут понадобиться дополнительные параметры, такие, как , или . Пример системы FreeBSD (freebox) как клиента в файле /etc/fstab на машине freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 Команда, выдаваемая вручную на машине freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Пример системы FreeBSD в качестве сервера в файле /etc/fstab на машине fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 Команда, выдаваемая вручную на машине fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Практически все 16-разрядные сетевые адаптеры позволят работать без указанных выше ограничений на размер блоков при чтении и записи. Для тех, кто интересуется, ниже описывается, что же происходит в при появлении этой ошибки, и объясняется, почему ее невозможно устранить. Как правило, NFS работает с блоками размером 8 килобайт (хотя отдельные фрагменты могут иметь меньшие размеры). Так, пакет Ethernet имеет максимальный размер около 1500 байт, то блок NFS разбивается на несколько пакетов Ethernet, хотя на более высоком уровне это все тот же единый блок, который должен быть принят, собран и подтвержден как один блок. Высокопроизводительные рабочие станции могут посылать пакеты, которые соответствуют одному блоку NFS, сразу друг за другом, насколько это позволяет делать стандарт. На слабых, низкопроизводительных адаптерах пакеты, пришедшие позже, накладываются поверх ранее пришедших пакетов того же самого блока до того, как они могут быть переданы хосту и блок как единое целое не может быть собран или подтвержден. В - результате рабочая станция входит в ситуацию таймаута и пытается + результате рабочая станция входит в ситуацию тайм-аута и пытается повторить передачу, но уже с полным блоком в 8 КБ, и процесс будет повторяться снова, до бесконечности. Задав размер блока меньше размера пакета Ethernet, мы достигаем того, что любой полностью полученный пакет Ethernet может быть подтвержден индивидуально, и избежим тупиковую ситуацию. Наложение пакетов может все еще проявляться, когда высокопроизводительные рабочие станции сбрасывают данные на PC-систему, однако повторение этой ситуации не обязательно с более скоростными адаптерами с блоками NFS. Когда происходит наложение, затронутые блоки будут переданы снова, и скорее всего, они будут получены, собраны и подтверждены. Bill Swingle Текст создал Eric Ogren Внёс добавления Udo Erdelhoff Network Information System (NIS/YP) Что это такое? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, что является сокращением от Network Information Services (Сетевые Информационные Службы), которые были разработаны компанией Sun Microsystems для централизованного администрирования систем &unix; (изначально &sunos;). В настоящее время эти службы практически стали промышленным стандартом; все основные &unix;-подобные системы (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD и так далее) поддерживают NIS. yellow pages NIS NIS первоначально назывались Yellow Pages (или yp), но из-за проблем с торговым знаком Sun изменила это название. Старое название (и yp) всё ещё часто употребляется. NIS домены Это система клиент/сервер на основе вызовов RPC, которая позволяет группе машин в одном домене NIS совместно использовать общий набор конфигурационных файлов. Системный администратор может настроить клиентскую систему NIS только с минимальной настроечной информацией, а затем добавлять, удалять и модифицировать настроечную информацию из одного места. Windows NT Это похоже на систему доменов &windowsnt;; хотя их внутренние реализации не так уж и похожи, основные функции сравнимы. Термины/программы, о которых вы должны знать Существует несколько терминов и некоторое количество пользовательских программ, которые будут нужны, когда вы будете пытаться сделать NIS во FreeBSD, и в случае создания сервера, и в случае работы в качестве клиента NIS: rpcbind portmap Термин Описание Имя домена NIS Главный сервер NIS и все его клиенты (включая вторичные серверы), имеют доменное имя NIS. Как и в случае с именем домена &windowsnt;, имя домена NIS не имеет ничего общего с DNS. rpcbind Для обеспечения работы RPC (Remote Procedure Call, Удалённого Вызова Процедур, сетевого протокола, используемого NIS), должен быть запущен даемон rpcbind. Если даемон rpcbind не запущен, невозможно будет запустить сервер NIS, или работать как NIS-клиент (в &os; 4.X вместо rpcbind используется portmap). ypbind Связывает NIS-клиента с его NIS-сервером. Он определяет имя NIS-домена системы, и при помощи RPC подключается к серверу. ypbind является основой клиент-серверного взаимодействия в среде NIS; если на клиентской машине программа ypbind перестанет работать, то эта машина не сможет получить доступ к серверу NIS. ypserv Программа ypserv, которая должна запускаться только на серверах NIS: это и есть сервер NIS. Если &man.ypserv.8; перестанет работать, то сервер не сможет отвечать на запросы NIS (к счастью, на этот случай предусмотрен вторичный сервер). Есть несколько реализаций NIS (к FreeBSD это не относится), в которых не производится попыток подключиться к другому серверу, если ранее используемый сервер перестал работать. Зачастую единственным средством, помогающим в этой ситуации, является перезапуск серверного процесса (или сервера полностью) или процесса ypbind на клиентской машине. rpc.yppasswdd Программа rpc.yppasswdd, другой процесс, который запускается только на главных NIS-серверах: это даемон, позволяющий клиентам NIS изменять свои пароли NIS. Если этот даемон не запущен, то пользователи должны будут входить на основной сервер NIS и там менять свои пароли. Как это работает? В системе NIS существует три типа хостов: основные (master) серверы, вторичные (slave) серверы и клиентские машины. Серверы выполняют роль централизованного хранилища информации о конфигурации хостов. Основные серверы хранят оригиналы этой информации, когда как вторичные серверы хранят ее копию для обеспечения избыточности. Клиенты связываются с серверами, чтобы предоставить им эту информацию. Информация во многих файлах может совместно использоваться следующим образом. Файлы master.passwd, group и hosts используются совместно через NIS. Когда процессу, работающему на клиентской машине, требуется информация, как правило, находящаяся в этих файлах локально, то он делает запрос к серверу NIS, с которым связан. Типы машин NIS главный сервер Основной сервер NIS. Такой сервер, по аналогии с первичным контроллером домена &windowsnt;, хранит файлы, используемые всеми клиентами NIS. Файлы passwd, group и различные другие файлы, используемые клиентами NIS, находятся на основном сервере. Возможно использование одной машины в качестве сервера для более чем одного домена NIS. Однако, в этом введении такая ситуация не рассматривается, и предполагается менее масштабное использование NIS. NIS вторичный сервер Вторичные серверы NIS. Похожие на вторичные контроллеры доменов &windowsnt;, вторичные серверы NIS содержат копии оригинальных файлов данных NIS. Вторичные серверы NIS обеспечивают избыточность, что нужно в критичных приложениях. Они также помогают распределять нагрузку на основной сервер: клиенты NIS всегда подключаются к тому серверу NIS, который ответил первым, в том числе и к вторичным серверам. NIS клиент Клиенты NIS. Клиенты NIS, как и большинство рабочих станций &windowsnt;, аутентифицируются на сервере NIS (или на контроллере домена &windowsnt; для рабочих станций &windowsnt;) во время входа в систему. Использование NIS/YP В этом разделе приводится пример настройки NIS. В этом разделе предполагается, что вы работаете с FreeBSD 3.3 или выше. Указания, приводимые здесь, скорее всего, будут работать с любой версией FreeBSD, выше, чем 3.0, однако нет гарантий, что это на самом деле так. Планирование Давайте предположим, что вы являетесь администратором в маленькой университетской лаборатории. В настоящий момент в этой лаборатории с 15 машинами отсутствует единая точка администрирования; на каждой машине имеются собственные файлы /etc/passwd и /etc/master.passwd. Эти файлы синхронизируются друг с другом только вручную; сейчас, когда вы добавляете пользователя в лаборатории, вы должны выполнить команду adduser на всех 15 машинах. Понятно, что такое положение вещей нужно исправлять, так что вы решили перевести сеть на использование NIS, используя две машины в качестве серверов. Итак, конфигурация лаборатории сейчас выглядит примерно так: Имя машины 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 как об имени группы хостов, которые каким-то образом связаны. Некоторые организации в качестве имени домена NIS используют свой домен Интернет. Это не рекомендуется, так как может вызвать проблемы в процессе решения сетевых проблем. Имя домена NIS должно быть уникальным в пределах вашей сети и хорошо, если оно будет описывать группу машин, которые представляет. Например, художественный отдел в компании Acme Inc. может находиться в домене NIS с именем acme-art. В нашем примере положим, что мы выбрали имя test-domain. SunOS Несмотря на это, некоторые операционные системы (в частности, &sunos;) используют свое имя домена NIS в качестве имени домена Интернет. Если одна или более машин в вашей сети имеют такие ограничения, вы обязаны использовать имя домена Интернет в качестве имени домена NIS. Требования к серверу Есть несколько вещей, которые нужно иметь в виду при выборе машины для использования в качестве сервера NIS. Одной из обескураживающей вещью, касающейся NIS, является уровень зависимости клиентов от серверов. Если клиент не может подключиться к серверу своего домена NIS, зачастую машину просто становится нельзя использовать. Отсутствие информации о пользователях и группах приводит к временной остановке работы большинства систем. Зная это, вы должны выбрать машину, которая не должна подвергаться частым перезагрузкам и не используется для разработки. Сервер NIS в идеале должен быть отдельно стоящей машиной, единственным целью в жизни которой является быть сервером NIS. Если вы работаете в сети, которая не так уж сильно загружена, то можно поместить сервер NIS на машине, на которой запущены и другие сервисы, просто имейте в виду, что если сервер NIS становится недоступным, то это негативно отражается на всех клиентах NIS. Серверы NIS Оригинальные копии всей информации NIS хранится на единственной машине, которая называется главным сервером NIS. Базы данных, которые используются для хранения информации, называются картами NIS. Во FreeBSD эти карты хранятся в /var/yp/[domainname], где [domainname] является именем обслуживаемого домена NIS. Один сервер NIS может поддерживать одновременно несколько доменов, так что есть возможность иметь несколько таких каталогов, по одному на каждый обслуживаемый домен. Каждый домен будет иметь свой собственный независимый от других набор карт. Основной и вторичный серверы обслуживают все запросы NIS с помощью даемона ypserv. ypserv отвечает за получение входящих запросов от клиентов NIS, распознавание запрашиваемого домена и отображение имени в путь к соответствующему файлы базы данных, а также передаче информации из базы данных обратно клиенту. Настройка основного сервера NIS NIS настройка сервера Настройка основного сервера NIS может оказаться сравнительно простой, в зависимости от ваших потребностей. В поставку FreeBSD сразу включена поддержка NIS. Все, что вам нужно, это добавить следующие строки в файл /etc/rc.conf, а FreeBSD сделает за вас всё остальное.. nisdomainname="test-domain" В этой строке задается имя домена NIS, которое будет test-domain, еще до настройки сети (например, после перезагрузки). nis_server_enable="YES" Здесь указывается FreeBSD на запуск процессов серверов NIS, когда дело доходит до сетевых настроек. nis_yppasswdd_enable="YES" Здесь указывается на запуск даемона rpc.yppasswdd, который, как это отмечено выше, позволит пользователям менять свой пароль NIS с клиентской машины. В зависимости от ваших настроек NIS, вам могут понадобиться дополнительные строки. Обратитесь к разделу о серверах NIS, которые являются и клиентами NIS ниже для получения подробной информации. А теперь всё, что вам нужно сделать, это запустить команду /etc/netstart, работая как администратор. По ней произойдет настройка всего, при этом будут использоваться значения, заданные в файле /etc/rc.conf. Инициализация карт NIS NIS карты Карты NIS являются файлами баз данных, которые хранятся в каталоге /var/yp. Они генерируются из конфигурационных файлов, находящихся в каталоге /etc основного сервера NIS, за одним исключением: файл /etc/master.passwd. На это есть весомая причина, вам не нужно распространять пароли пользователя root и других административных пользователей на все серверы в домене NIS. По этой причине, прежде чем инициализировать карты NIS, вы должны сделать вот что: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Вы должны удалить все записи, касающиеся системных пользователей (bin, tty, kmem, games и так далее), а также записи, которые вы не хотите распространять клиентам NIS (например, root и другие пользователи с UID, равным 0 (администраторы)). Проверьте, чтобы файл /var/yp/master.passwd был недоступен для записи ни для группы, ни для остальных пользователей (режим доступа 600)! Воспользуйтесь командой chmod, если это нужно. Tru64 UNIX Когда с этим будет покончено, самое время инициализировать карты NIS! В поставку FreeBSD включен скрипт с именем ypinit, который делает это (обратитесь к его справочной странице за дополнительной информацией). Отметьте, что этот скрипт имеется в большинстве операционных систем &unix;, но не во всех. В системе Digital Unix/Compaq Tru64 UNIX он называется ypsetup. Так как мы генерируем карты для главного сервера NIS, то при вызове программы ypinit мы передаем ей параметр . Для генерации карт NIS в предположении, что вы уже сделали шаги, описанные выше, выполните следующее: ellington&prompt.root; 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 you don't, 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 <control D>. 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 [..вывод при генерации карт..] NIS Map update completed. ellington has been setup as an YP master server without any errors. Программа ypinit должна была создать файл /var/yp/Makefile из /var/yp/Makefile.dist. При создании этого файла предполагается, что вы работаете в окружении с единственным сервером NIS и только с машинами FreeBSD. Так как в домене test-domain имеется также и вторичный сервер, то вы должны отредактировать файл /var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile Вы должны закомментировать строку, в которой указано NOPUSH = "True" (она уже не раскомментирована). Настройка вторичного сервера NIS NIS вторичный сервер Настройка вторичного сервера NIS осуществляется ещё проще, чем настройка главного сервера. Войдите на вторичный сервер и отредактируйте файл /etc/rc.conf точно также, как вы делали это ранее. Единственным отличием является то, что при запуске программы ypinit мы теперь должны использовать опцию . Применение опции требует также указание имени главного сервера NIS, так что наша команда должна выглядеть так: coltrane&prompt.root; 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 you don't, 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. Don't forget to update map ypservers on ellington. Теперь у вас должен быть каталог с именем /var/yp/test-domain. Копии карт главного сервера NIS должны быть в этом каталоге. Вы должны удостовериться, что этот каталог обновляется. Следующие строки в /etc/crontab вашего вторичного сервера должны это делать: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Эти две строки заставляют вторичный сервер синхронизировать свои карты с картами главного сервера. Хотя эти строчки не обязательны, так как главный сервер делает попытки передать все изменения в своих картах NIS на свои вторичные серверы, но из-за того, что информация для входа в систему настолько жизненно важна для систем, зависящих от сервера, что выполнение регулярных обновлений является совсем не плохой идеей. Это ещё более важно в загруженных сетях, в которых обновления карт могут не всегда завершаться успешно. А теперь точно также запустите команду /etc/netstart на вторичном сервере, по которой снова выполнится запуск сервера NIS. Клиенты NIS Клиент NIS выполняет так называемую привязку к конкретному серверу NIS при помощи даемона ypbind. ypbind определяет домен, используемый в системе по умолчанию (тот, который устанавливается по команде domainname), и начинает широковещательную рассылку запросов RPC в локальной сети. В этих запросах указано имя домена, к серверу которого ypbind пытается осуществить привязку. Если сервер, который был настроен для обслуживания запрашиваемого домена, получит широковещательный запрос, он ответит ypbind, который, в свою очередь запомнит адрес сервера. Если имеется несколько серверов (например, главный и несколько вторичных), то ypbind будет использовать адрес первого ответившего. С этого момента клиентская система будет направлять все свои запросы NIS на этот сервер. Время от времени ypbind будет пинать сервер для проверки его работоспособности. Если на один из тестовых пакетов не удастся получить ответа за разумное время, то ypbind пометит этот домен как домен, с которым связка разорвана, и снова начнет процесс посылки широковещательных запросов в надежде найти другой сервер. Настройка клиента NIS NIS настройка клиента Настройка машины с FreeBSD в качестве клиента NIS достаточно проста. Отредактируйте файл /etc/rc.conf, добавив туда следующие строки для того, чтобы задать имя домена NIS и запустить ypbind во время запуска сетевых служб: nisdomainname="test-domain" nis_client_enable="YES" Для импортирования всех возможных учётных записей от сервера NIS, удалите все записи пользователей из вашего файла /etc/master.passwd и воспользуйтесь командой vipw для добавления следующей строки в конец файла: +::::::::: Эта строчка даст всем пользователям с корректной учетной записью в картах учетных баз пользователей доступ к этой системе. Есть множество способов настроить ваш клиент NIS, изменив эту строку. Посмотрите ниже текст, касающийся сетевых групп, чтобы получить более подробную информацию. Дополнительная информация для изучения находится в книге издательства O'Reilly под названием Managing NFS and NIS. Вы должны оставить хотя бы одну локальную запись (то есть не импортировать ее через NIS) в вашем /etc/master.passwd и эта запись должна быть также членом группы wheel. Если с NIS что-то случится, эта запись может использоваться для удаленного входа в систему, перехода в режим администратора и исправления неисправностей. Для импортирования всех возможных записей о группах с сервера NIS, добавьте в ваш файл /etc/group такую строчку: +:*:: После завершения выполнения этих шагов у вас должно получиться запустить команду ypcat passwd и увидеть карту учетных записей сервера NIS. Безопасность NIS В общем-то любой пользователь, зная имя вашего домена, может выполнить запрос RPC к &man.ypserv.8; и получить содержимое ваших карт NIS. Для предотвращения такого неавторизованного обмена &man.ypserv.8; поддерживает так называемую систему securenets, которая может использоваться для ограничения доступа к некоторой группе хостов. При запуске &man.ypserv.8; будет пытаться загрузить информацию, касающуюся securenets, из файла /var/yp/securenets. Имя каталога зависит от параметра, указанного вместе с опцией . Этот файл содержит записи, состоящие из указания сети и сетевой маски, разделенных пробелом. Строчки, начинающиеся со знака #, считаются комментариями. Примерный файл securenets может иметь примерно такой вид: # 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; получает запрос от адреса, который соответствует одному из этих правил, он будет отрабатывать запрос обычным образом. Если же адрес не подпадает ни под одно правило, запрос будет проигнорирован и в журнал будет записано предупреждающее сообщение. Если файл /var/yp/securenets не существует, ypserv будет обслуживать соединения от любого хоста. Программа ypserv также поддерживает пакет программ TCP Wrapper от Wietse Venema. Это позволяет администратору для ограничения доступа вместо /var/yp/securenets использовать конфигурационные файлы TCP Wrapper. Хотя оба этих метода управления доступом обеспечивают некоторую безопасность, они, как основанные на проверке привилегированного порта, оба подвержены атакам типа IP spoofing. Весь сетевой трафик, связанный с работой NIS, должен блокироваться вашим брандмауэром. Серверы, использующие файл /var/yp/securenets, могут быть не в состоянии обслуживать старых клиентов NIS с древней реализацией протокола TCP/IP. Некоторые из этих реализаций при рассылке широковещательных запросов устанавливают все биты машинной части адреса в ноль и/или не в состоянии определить маску подсети при вычислении адреса широковещательной рассылки. Хотя некоторые из этих проблем могут быть решены изменением конфигурации клиента, другие могут привести к отказу от использования /var/yp/securenets. Использование /var/yp/securenets на сервере с такой архаичной реализацией TCP/IP является весьма плохой идеей, и приведёт к потере работоспособности NIS в большой части вашей сети. TCP Wrapper Использование пакета TCP Wrapper увеличит время отклика вашего сервера NIS. Дополнительной задержки может - оказаться достаточно для возникновения таймаутов в клиентских + оказаться достаточно для возникновения тайм-аутов в клиентских программах, особенно в загруженных сетях или с медленными серверами NIS. Если одна или более ваших клиентских систем страдают от таких проблем, вы должны преобразовать такие клиентские системы во вторичные серверы NIS и сделать принудительную их привязку к самим себе. Запрет входа некоторых пользователей В нашей лаборатории есть машина basie, о которой предполагается, что она является исключительно факультетской рабочей станцией. Мы не хотим исключать эту машину из домена NIS, однако файл passwd на главном сервере NIS содержит учетные записи как для работников факультета, так и студентов. Что мы можем сделать? Есть способ ограничить вход некоторых пользователей на этой машине, даже если они присутствуют в базе данных NIS. Чтобы это сделать, вам достаточно добавить -username в конец файла /etc/master.passwd на клиентской машине, где username является именем пользователя, которому вы хотите запретить вход. Рекомендуется сделать это с помощью утилиты vipw, так как vipw проверит ваши изменения в /etc/master.passwd, а также автоматически перестроит базу данных паролей по окончании редактирования. Например, если мы хотим запретить пользователю bill осуществлять вход на машине basie, то мы сделаем следующее: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; 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:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/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:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Текст предоставил Использование сетевых групп сетевые группы Способ, описанный в предыдущем разделе, работает достаточно хорошо, если вам нужны особые правила для очень малой группы пользователей или машин. В более крупных сетях вы забудете о запрете входа определенных пользователей на важные машины или даже будете настраивать каждую машину по отдельности, теряя таким образом главное преимущество использования NIS: централизованное администрирование. Ответом разработчиков NIS на эту проблему являются сетевые группы. Их назначение и смысл можно сравнить с обычными группами, используемыми в файловых системах &unix;. Главное отличие заключается в отсутствии числового идентификатора и возможности задать сетевую группу включением как пользователей, так и других сетевых групп. Сетевые группы были разработаны для работы с большими, сложными сетями с сотнями пользователей и машин. С одной стороны, хорошо, если вам приходится с такой ситуацией. С другой стороны, эта сложность делает невозможным описание сетевых групп с помощью простых примеров. Пример, используемый в дальнейшем, демонстрирует эту проблему. Давайте предположим, что успешное внедрение системы NIS в вашей лаборатории заинтересовало ваше руководство. Вашим следующим заданием стало расширение домена NIS для включения в него некоторых других машин студенческого городка. В двух таблицах перечислены имена новых машин и пользователей, а также их краткое описание. Имена пользователей Описание alpha, beta Обычные служащие IT-департамента charlie, delta Практиканты IT-департамента echo, foxtrott, golf, ... Обычные сотрудники able, baker, ... Проходящие интернатуру Имена машин Описание war, death, famine, pollution Ваши самые важные серверы. Только служащим IT позволяется входить на эти машины. pride, greed, envy, wrath, lust, sloth Менее важные серверы. Все сотрудники департамента IT могут входить на эти машины. one, two, three, four, ... Обычные рабочие станции. Только реально нанятым служащим позволяется использовать эти машины. trashcan Очень старая машина без каких-либо критичных данных. Даже проходящим интернатуру разрешено ее использовать. Если вы попытаетесь реализовать эти требования, ограничивая каждого пользователя по отдельности, то вам придется добавить на каждой машине в файл passwd по одной строчке -user для каждого пользователя, которому запрещено входить на эту систему. Если вы забудете даже одну строчку, у вас могут начаться проблемы. Гораздо проще делать это правильно во время начальной установки, однако вы постепенно будете забывать добавлять строчки для новых пользователей во время повседневной работы. В конце концов, Мерфи был оптимистом. Использование в этой ситуации сетевых групп дает несколько преимуществ. Нет необходимости описывать по отдельности каждого пользователя; вы ставите в соответствие пользователю одну или несколько сетевых групп и разрешаете или запрещаете вход всем членам сетевой группы. Если вы добавляете новую машину, вам достаточно определить ограничения на вход для сетевых групп. Если добавляется новый пользователь, вам достаточно добавить его к одной или большему числу сетевых групп. Эти изменения независимы друг от друга: нет больше комбинаций для каждого пользователя и машины. Если настройка вашей системы NIS тщательно спланирована, то для разрешения или запрещения доступа к машинам вам нужно будет модифицировать единственный конфигурационный файл. Первым шагом является инициализация карты NIS по имени netgroup. Программа &man.ypinit.8; во FreeBSD по умолчанию этой карты не создаёт, хотя реализация NIS будет её поддерживает, как только она будет создана. Чтобы создать пустую карту, просто наберите ellington&prompt.root; vi /var/yp/netgroup и начните добавлять содержимое. Например, нам нужно по крайней мере четыре сетевых группы: сотрудники IT, практиканты IT, обычные сотрудники и интернатура. 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) IT_EMP, IT_APP и так далее являются именами сетевых групп. Несколько слов в скобках служат для добавления пользователей в группу. Три поля внутри группы обозначают следующее: Имя хоста или хостов, к которым применимы последующие записи. Если имя хоста не указано, то запись применяется ко всем хостам. Если же указывается имя хоста, то вы получите мир темноты, ужаса и страшной путаницы. Имя учетной записи, которая принадлежит этой сетевой группе. Домен NIS для учетной записи. Вы можете импортировать в вашу сетевую группу учетные записи из других доменов NIS, если вы один из тех несчастных, имеющих более одного домена NIS. Каждое из этих полей может содержать шаблоны, подробности даны в странице справочника по &man.netgroup.5;. сетевые группы Не нужно использовать имена сетевых групп длиннее 8 символов, особенно если в вашем домене NIS имеются машины, работающие под управлением других операционных систем. Имена чувствительны к регистру; использование заглавных букв для имен сетевых групп облегчает распознавание пользователей, имен машин и сетевых групп. Некоторые клиенты NIS (отличные от FreeBSD) не могут работать с сетевыми группами, включающими большое количество записей. Например, в некоторых старых версиях &sunos; возникают проблемы, если сетевая группа содержит более 15 записей. Вы можете обойти это ограничение, создав несколько подгрупп с 15 или меньшим количеством пользователей и настоящую сетевую группу, состоящую из подгрупп: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Вы можете повторить этот процесс, если вам нужно иметь более 225 пользователей в одной сетевой группе. Активация и распространение вашей карты NIS проста: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Это приведет к созданию трех карт NIS netgroup, netgroup.byhost и netgroup.byuser. Воспользуйтесь утилитой &man.ypcat.1; для проверки доступности ваших новых карт NIS: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Вывод первой команды должен соответствовать содержимому файла /var/yp/netgroup. Вторая команда не выведет ничего, если вы не зададите сетевые группы, специфичные для хоста. Третья команда может использоваться пользователем для получения списка сетевых групп. Настройка клиента достаточно проста. Чтобы настроить сервер war, вам достаточно запустить &man.vipw.8; и заменить строку +::::::::: на +@IT_EMP::::::::: Теперь только данные, касающиеся пользователей, определенных в сетевой группе IT_EMP, импортируются в базу паролей машины war и только этим пользователям будет разрешен вход. К сожалению, это ограничение также касается и функции ~ командного процессора и всех подпрограмм, выполняющих преобразование между именами пользователей и их числовыми ID. Другими словами, команда cd ~user работать не будет, команда ls -l будет выдавать числовые идентификаторы вместо имён пользователей, а find . -user joe -print работать откажется, выдавая сообщение No such user. Чтобы это исправить, вам нужно будет выполнить импорт всех записей о пользователях без разрешения на вход на ваши серверы. Это можно сделать, добавив еще одну строку в файл /etc/master.passwd. Эта строка должна содержать: +:::::::::/sbin/nologin, что означает Произвести импортирование всех записей с заменой командного процессора на /sbin/nologin в импортируемых записях. Вы можете заменить любое поле в строке с паролем, указав значение по умолчанию в вашем /etc/master.passwd. Проверьте, что строка +:::::::::/sbin/nologin помещена после +@IT_EMP:::::::::. В противном случае все пользовательские записи, импортированные из NIS, будут иметь /sbin/nologin в качестве оболочки. После этого изменения при появлении нового сотрудника IT вам будет достаточно изменять только одну карту NIS. Вы можете применить подобный метод для менее важных серверов, заменяя старую строку +::::::::: в их файлах /etc/master.passwd на нечто, подобное следующему: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Соответствующие строки для обычных рабочих станций могут иметь такой вид: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin И все было прекрасно до того момента, когда через несколько недель изменилась политика: Департамент IT начал нанимать интернатуру. Интернатуре в IT позволили использовать обычные рабочие станции и менее важные серверы; практикантам позволили входить на главные серверы. Вы создали новую сетевую группу IT_INTERN, добавили в нее новую интернатуру и начали изменять настройки на всех и каждой машине... Как говорит старая мудрость: Ошибки в централизованном планировании приводят к глобальному хаосу. Возможность в NIS создавать сетевые группы из других сетевых групп может использоваться для предотвращения подобных ситуаций. Одним из вариантов является создание сетевых групп на основе ролей. Например, вы можете создать сетевую группу с именем BIGSRV для задания ограничений на вход на важные серверы, другую сетевую группу с именем SMALLSRV для менее важных серверов и третью сетевую группу под названием USERBOX для обычных рабочих станций. Каждая из этих сетевых групп содержит сетевые группы, которым позволено входить на эти машины. Новые записи для вашей карты NIS сетевой группы должны выглядеть таким образом: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Этот метод задания ограничений на вход работает весьма хорошо, если вы можете выделить группы машин с одинаковыми ограничениями. К сожалению, такая ситуация может быть исключением, но не правилом. В большинстве случаев вам нужна возможность определять ограничения на вход индивидуально для каждой машины. Задание сетевых групп в зависимости от машин является другой возможностью, которой можно воспользоваться при изменении политики, описанной выше. При таком развитии событий файл /etc/master.passwd на каждой машине содержит две строки, начинающиеся с +. Первая из них добавляет сетевую группу с учётными записями, которым разрешено входить на эту машину, а вторая добавляет все оставшиеся учетные записи с /sbin/nologin в качестве командного процессора. Хорошей идеей является использование ИМЕНИ МАШИНЫ заглавными буквами для имени сетевой группы. Другими словами, строки должны иметь такой вид: +@BOXNAME::::::::: +:::::::::/sbin/nologin Как только вы завершите эту работу для всех ваших машин, вам не нужно будет снова модифицировать локальные версии /etc/master.passwd. Все будущие изменения могут быть выполнены изменением карты NIS. Вот пример возможной карты сетевой группы для этого случая с некоторыми полезными дополнениями: # Сначала определяем группы пользователей 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) # # Теперь задаем несколько групп на основе ролей USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # И группы для специальных задач # Открыть пользователям echo и golf доступ к антивирусной машине SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # Сетевые группы, специфичные для машин # Наши главные серверы WAR BIGSRV FAMINE BIGSRV # Пользователю india необходим доступ к этому серверу POLLUTION BIGSRV (,india,test-domain) # # Этот очень важен и ему требуются большие ограничения доступа DEATH IT_EMP # # Антивирусная машина, упомянутая выше ONE SECURITY # # Ограничить машину единственным пользователем TWO (,hotel,test-domain) # [...далее следуют другие группы] Если вы используете какие-либо базы данных для управления учетными записями ваших пользователей, вы должны смочь создать первую часть карты с помощью инструментов построения отчетов вашей базы данных. В таком случае новые пользователи автоматически получат доступ к машинам. И последнее замечание: Не всегда бывает разумно использовать сетевые группы на основе машин. Если в студенческих лабораториях вы используете несколько десятков или даже сотен одинаковых машин, то вам нужно использовать сетевые группы на основе ролей, а не основе машин, для того, чтобы размеры карты NIS оставались в разумных пределах. Важные замечания Есть некоторые действия, которые нужно будет выполнять по-другому, если вы работаете с NIS. Каждый раз, когда вы собираетесь добавить пользователя в лаборатории, вы должны добавить его только на главном сервере NIS и обязательно перестроить карты NIS. Если вы забудете сделать это, то новый пользователь не сможет нигде войти, кроме как на главном сервере NIS. Например, если в лаборатории нам нужно добавить нового пользователя jsmith, мы делаем вот что: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Вместо pw useradd jsmith вы можете также запустить команду adduser jsmith. Не помещайте административные учетные записи в карты NIS. Вам не нужно распространять административных пользователей и их пароли на машины, которые не должны иметь доступ к таким учётным записям. Сделайте главный и вторичные серверы NIS безопасными и минимизируйте их время простоя. Если кто-то либо взломает, либо просто отключит эти машины, то люди без права входа в лабораторию с легкостью получат доступ. Это основное уязвимое место в любой централизованно администрируемой системе. Если вы не защищаете ваши серверы NIS, вы будете иметь дело с толпой разозлённых пользователей! Совместимость с NIS v1 ypserv из поставки FreeBSD имеет встроенную поддержку для обслуживания клиентов NIS v1. Реализация NIS во FreeBSD использует только протокол NIS v2, хотя другие реализации имеют поддержку протокола v1 для совместимости со старыми системами. Даемоны ypbind, поставляемые с такими системами, будут пытаться осуществить привязку к серверу NIS v1, даже если это им не нужно (и они будут постоянно рассылать широковещательные запросы в поиске такого сервера даже после получения ответа от сервера v2). Отметьте, что хотя имеется поддержка обычных клиентских вызовов, эта версия ypserv не отрабатывает запросы на передачу карт v1; следовательно, она не может использоваться в качестве главного или вторичного серверов вместе с другими серверами NIS, поддерживающими только протокол v1. К счастью, скорее всего, в настоящий момент такие серверы практически не используются. Серверы NIS, которые также являются клиентами NIS Особое внимание следует уделить использованию ypserv в домене со многими серверами, когда серверные машины являются также клиентами NIS. Неплохо бы заставить серверы осуществить привязку к самим себе, запретив рассылку запросов на привязку и возможно, перекрестную привязку друг к другу. Если один сервер выйдет из строя, а другие будут зависеть от него, то в результате могут возникнуть странные - ситуации. Постепенно все клиенты попадут в таймаут и попытаются + ситуации. Постепенно все клиенты попадут в тайм-аут и попытаются привязаться к другим серверам, но полученная задержка может быть значительной, а странности останутся, так как серверы снова могут привязаться друг к другу. Вы можете заставить хост выполнить привязку к конкретному серверу, запустив команду ypbind с флагом . Если вы не хотите делать это вручную каждый раз при перезагрузке вашего сервера NIS, то можете добавить в файл /etc/rc.conf такие строки: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" Дополнительную информацию можно найти на странице справки по &man.ypbind.8;. Форматы паролей NIS форматы паролей Одним из общих вопросов, которые возникают в начале работы с NIS, является вопрос совместимости форматов паролей. Если ваш сервер NIS использует пароли, зашифрованные алгоритмом DES, то он будет поддерживать только тех клиентов, что также используют DES. К примеру, если в вашей сети имеются клиенты NIS, использующие &solaris;, то вам, скорее всего, необходимо использовать пароли с шифрованием по алгоритму DES. Чтобы понять, какой формат используют ваши серверы и клиенты, загляните в файл /etc/login.conf. Если хост настроен на использование паролей, зашифрованных по алгоритму DES, то класс default будет содержать запись вроде следующей: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Последующие строки опущены] Другими возможными значениями для passwd_format являются blf и md5 (для паролей, шифруемых по стандартам Blowfish и MD5 соответственно). Если вы внесли изменения в файл /etc/login.conf, то вам также нужно перестроить базу данных параметров входа в систему, что достигается запуском следующей команды пользователем root: &prompt.root; cap_mkdb /etc/login.conf Формат паролей, которые уже находятся в файле /etc/master.passwd, не будет изменён до тех пор, пока пользователь не сменит свой пароль после перестроения базы данных параметров входа в систему. После этого, чтобы удостовериться в том, что пароли зашифрованы в том формате, который выбран вами, нужно проверить, что строка crypt_default в /etc/auth.conf указывает предпочтение выбранного вами формата паролей. Для этого поместите выбранный формат первым в списке. Например, при использовании DES-шифрования паролей строка будет выглядеть так: crypt_default = des blf md5 Выполнив вышеперечисленные шаги на каждом из серверов и клиентов NIS, работающих на FreeBSD, вы можете обеспечить их согласованность относительно используемого в вашей сети формата паролей. Если у вас возникли проблемы с аутентификацией клиента NIS, начать её решать определённо стоит отсюда. Запомните: если вы хотите использовать сервер NIS в гетерогенной сети, вам, наверное, нужно будет использовать DES на всех системах в силу того, что это минимальный общий стандарт. Greg Sutter Текст написал Автоматическая настройка сети (DHCP) Что такое DHCP? Dynamic Host Configuration Protocol DHCP Internet Software Consortium (ISC) DHCP, или Dynamic Host Configuration Protocol (Протокол Динамической Конфигурации Хостов), описывает порядок, по которому система может подключиться к сети и получить необходимую информацию - для работы в ней. Во FreeBSD используется реализация DHCP от ISC - (Internet Software Consortium), так что вся информация, описывающая - особенности, зависящие от реализации, относится к дистрибутиву - ISC. + для работы в ней. Во FreeBSD версиях младше 6.0 используется + реализация DHCP клиента (&man.dhclient.8;) от ISC + (Internet Software Consortium). Более поздние версии используют + dhclient, импортированный из OpenBSD 3.7. + Вся информация здесь, относительно dhclient относится + либо к ISC, либо к DHCP клиентам. DHCP сервер включён в ISC + дистрибутив. Что описывается в этом разделе - В этом разделе описываются компоненты системы ISC DHCP как со стороны - клиента, так и со стороны сервера. Программа, работающая на клиентской + В этом разделе описываются, как компоненты клиентской части ISC или OpenBSD + DHCP клиента, так и компоненты ISC DHCP системы со стороны сервера. + Программа, работающая на клиентской стороне, dhclient, интегрирована в поставку FreeBSD, а серверная часть доступна в виде порта net/isc-dhcp3-server. Кроме ссылок ниже, много полезной информации находится на страницах справочной системы, описывающих &man.dhclient.8;, &man.dhcp-options.5; и &man.dhclient.conf.5;. Как это работает UDP Когда на клиентской машине выполняется программа dhclient, являющаяся клиентом DHCP, она начинает широковещательную рассылку запросов на получение настроечной информации. По умолчанию эти запросы делаются на 68 порт UDP. Сервер отвечает на UDP 67, выдавая клиенту адрес IP и другую необходимую информацию, такую, как сетевую маску, маршрутизатор и серверы DNS. Вся эта информация даётся в форме аренды DHCP и верна только определенное время (что настраивается администратором сервера DHCP). При таком подходе устаревшие адреса IP тех клиентов, которые больше не подключены к сети, могут автоматически использоваться повторно. Клиенты DHCP могут получить от сервера очень много информации. Подробный список находится в странице Справочника &man.dhcp-options.5;. Интеграция с FreeBSD - Клиент DHCP от ISC, dhclient, полностью - интегрирован во FreeBSD. Поддержка клиента DHCP есть как в программе + DHCP клиент от ISC или от OpenBSD, dhclient, полностью + интегрирован во &os; (относительно, используемой вами версии &os;). Поддержка клиента DHCP есть как в программе установки, так и в самой системе, что исключает необходимость в знании подробностей конфигурации сети в любой сети, имеющей сервер DHCP. Утилита dhclient включена во все версии FreeBSD, начиная с 3.2. sysinstall DHCP поддерживается утилитой sysinstall. При настройке сетевого интерфейса из программы sysinstall второй вопрос, который вам задается: Do you want to try DHCP configuration of the interface? (Хотите ли вы попробовать настроить этот интерфейс через DHCP?). Утвердительный ответ приведёт к запуску программы dhclient, и при удачном его выполнении к автоматическому заданию информации для настройки интерфейса. Есть две вещи, которые вы должны сделать для того, чтобы ваша система использовала DHCP при загрузке: DHCP требования Убедитесь, что устройство bpf включено в компиляцию вашего ядра. Чтобы это сделать, добавьте строчку device bpf (pseudo-device bpf в &os; 4.X) в конфигурационный файл ядра и перестройте ядро. Более подробная информация о построении ядер имеется в . Устройство bpf уже является частью ядра GENERIC, которое поставляется вместе с FreeBSD, так что, если вы не используете другое ядро, то вам и не нужно его делать для того, чтобы работал DHCP. Те, кто беспокоится о безопасности, должны иметь в виду, что устройство bpf является также тем самым устройством, которое позволяет работать программам-снифферам пакетов (хотя для этого они должны быть запущены пользователем root). Наличие устройства bpf необходимо для использования DHCP, но если вы чересчур беспокоитесь о безопасности, то вам нельзя добавлять устройство bpf в ядро только для того, чтобы в неопределённом будущем использовать DHCP. Отредактируйте ваш файл /etc/rc.conf, включив в него следующее: ifconfig_fxp0="DHCP" Обязательно замените fxp0 на имя интерфейса, который вы хотите настраивать динамически, как это описано в . Если dhclient в вашей системе находится в другом месте или если вы хотите задать дополнительные параметры для dhclient, то также укажите следующее (изменив так, как вам нужно): dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP сервер Сервер DHCP, dhcpd, включён как часть порта net/isc-dhcp3-server в коллекцию портов. Этот порт содержит DHCP-сервер от ISC и документацию. Файлы DHCP конфигурационные файлы /etc/dhclient.conf dhclient требует наличия конфигурационного файла, /etc/dhclient.conf. Как правило, файл содержит только комментарии, а настройки по умолчанию достаточно хороши. Этот настроечный файл описан на страницах справочной системы по &man.dhclient.conf.5;. /sbin/dhclient dhclient скомпонован статически и находится в каталоге /sbin. На страница Справочника &man.dhclient.8; дается более подробная информация о dhclient. /sbin/dhclient-script dhclient-script является специфичным для FreeBSD скриптом настройки клиента DHCP. Он описан в &man.dhclient-script.8;, но для нормального функционирования никаких модификаций со стороны пользователя не требуется. /var/db/dhclient.leases В этом файле клиент DHCP хранит базу данных выданных к использованию адресов в виде журнала. На странице &man.dhclient.leases.5; дается гораздо более подробное описание. Дополнительная литература Полное описание протокола DHCP дается в RFC 2131. Кроме того, дополнительная информация есть на сервере . Установка и настройка сервера DHCP Чему посвящён этот раздел Этот раздел даёт информацию о том, как настроить систему FreeBSD для работы в качестве сервера DHCP на основе реализации пакета DHCP от ISC (Internet Software Consortium). Серверная часть пакета не поставляется как часть FreeBSD, так что вам потребуется установить порт net/isc-dhcp3-relay для получения этого сервиса. Обратитесь к для получения более полной информации об использовании коллекции портов. Установка сервера DHCP DHCP установка Для того, чтобы настроить систему FreeBSD на работу в качестве сервера DHCP, вам необходимо обеспечить присутствие устройства &man.bpf.4;, вкомпилированного в ядро. Для этого добавьте строку device bpf (pseudo-device bpf в &os; 4.X) в файл конфигурации вашего ядра. Для получения более полной информации о построении ядер, обратитесь к . Устройство bpf уже входит в состав ядра GENERIC, поставляемого с FreeBSD, так что вам не нужно создавать собственное ядро для обеспечения работы DHCP. Те, кто обращает особое внимание на вопросы безопасности, должны заметить, что bpf является тем устройством, что позволяет нормально работать снифферам пакетов (хотя таким программам требуются привилегированный доступ). Наличие устройства bpf обязательно для использования DHCP, но если вы очень обеспокоены безопасностью, наверное, вам не нужно включать bpf в ваше ядро только потому, что в отдалённом будущем вы собираетесь использовать DHCP. Следующим действием, которое вам нужно выполнить, является редактирование примерного dhcpd.conf, который устанавливается в составе порта net/isc-dhcp3-server. По умолчанию это файл /usr/local/etc/dhcpd.conf.sample, и вы должны скопировать его в файл /usr/local/etc/dhcpd.conf перед тем, как его редактировать. Настройка сервера DHCP DHCP dhcpd.conf dhcpd.conf состоит из деклараций относительно подсетей и хостов, и проще всего описывается на примере: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Этот параметр задаёт домен, который будет выдаваться клиентам в качестве домена, используемого по умолчанию при поиске. Обратитесь к страницам справочной системы по &man.resolv.conf.5; для получения дополнительной информации о том, что это значит. Этот параметр задаёт список разделённых запятыми серверов DNS, которые должен использовать клиент. Маска сети, которая будет выдаваться клиентам. Клиент может запросить определённое время, которое будет действовать выданная информация. В противном случае сервер выдаст настройки с этим сроком (в секундах). Это максимальное время, на которое сервер будет выдавать конфигурацию. Если клиент запросит больший срок, он будет подтверждён, но будет действовать только max-lease-time секунд. Этот параметр задаёт, будет ли сервер DHCP пытаться обновить DNS при выдаче или освобождении конфигурационной информации. В реализации ISC этот параметр является обязательным. Это определение того, какие IP-адреса должны использоваться в качестве резерва для выдачи клиентам. IP-адреса между и включая границы, будут выдаваться клиентам. Объявление маршрутизатора, используемого по умолчанию, который будет выдаваться клиентам. Аппаратный MAC-адрес хоста (чтобы сервер DHCP мог распознать хост, когда тот делает запрос). Определение того, что хосту всегда будет выдаваться один и тот же IP-адрес. Заметьте, что указание здесь имени хоста корректно, так как сервер DHCP будет разрешать имя хоста самостоятельно до того, как выдать конфигурационную информацию. Как только вы закончите составлять свой dhcpd.conf, вы можете продолжить работу запуском сервера при помощи следующей команды: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Если в будущем вам понадобится сделать изменения в настройке вашего сервера, то важно заметить, что посылка сигнала SIGHUP приложению dhcpd не приведёт к перезагрузке настроек, как это бывает для большинства даемонов. Вам нужно послать сигнал SIGTERM для остановки процесса, а затем перезапустить его при помощи вышеприведённой команды. Файлы DHCP конфигурационный файлы /usr/local/sbin/dhcpd dhcpd скомпонован статически и расположен в каталоге /usr/local/sbin. Страницы справочной системы &man.dhcpd.8;, устанавливаемые портом, содержат более полную информацию о dhcpd. /usr/local/etc/dhcpd.conf dhcpd требует наличия конфигурационного файла, /usr/local/etc/dhcpd.conf, до того, как он будет запущен и начнёт предоставлять сервис клиентам. Необходимо, чтобы этот файл содержал все данные, которая будет выдаваться обслуживаемым клиентам, а также информацию о работе сервера. Этот конфигурационный файл описывается на страницах справочной системы &man.dhcpd.conf.5;, которые устанавливаются портом. /var/db/dhcpd.leases Сервер DHCP ведёт базу данных выданной информации в этом файле, который записывается в виде протокола. Страницы справочной системы &man.dhcpd.leases.5;, устанавливаемые портом, дают гораздо более подробное описание. /usr/local/sbin/dhcrelay dhcrelay используется в сложных ситуациях, когда сервер DHCP пересылает запросы от клиента другому серверу DHCP в отдельной сети. Если вам нужна такая функциональность, то установите порт net/isc-dhcp3-server. На страницах справочной системы &man.dhcrelay.8;, которые устанавливаются портом, даётся более полное описание. Chern Lee Текст предоставил Domain Name System (DNS) Обзор BIND По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS. DNS - это протокол, при помощи которого имена преобразуются в IP-адреса и наоборот. Например, в ответ на запрос о www.FreeBSD.org будет получен IP-адрес веб-сервера Проекта FreeBSD, а запрос о ftp.FreeBSD.org возвратит IP-адрес соответствующей машины с FTP-сервером. Точно также происходит и обратный процесс. Запрос, содержащий IP-адрес машины, возвратит имя хоста. Для выполнения запросов к DNS вовсе не обязательно иметь в системе работающий сервер имён. DNS В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах. В этом документа рассматривается BIND 8.x, так как это стабильная версия, используемая во FreeBSD. Начиная с &os; 5.3, с системой поставляется BIND9, инструкции к настройке которого находятся далее в этой главе. Пользователи &os; 5.2 и предыдущих релизов могут установить BIND9 из порта net/bind9. Протокол DNS стандартизован в RFC1034 и RFC1035. На данный момент пакет BIND поддерживается Internet Software Consortium . Используемая терминология Для понимания этого документа нужно понимать значения некоторых терминов, связанных с работой DNS. резолвер обратный DNS корневая зона Термин Определение Прямой запрос к DNS (forward DNS) Преобразование имён хостов в адреса IP Ориджин (origin) Обозначает домен, покрываемый конкретным файлом зоны named, bind, сервер имён Общеупотребительные названия для обозначения пакета BIND, обеспечивающего работу сервера имён во FreeBSD. Резолвер Системный процесс, посредством которого машина обращается к серверу имён для получения информации о зоне Обратный DNS (reverse DNS) Операция, обратная прямому запросу к DNS; преобразование адресов IP в имена хостов Корневая зона Начало иерархии зон Интернет. Все зоны находятся под корневой зоной, подобно тому, как все файлы располагаются ниже корневого каталога. Зона Отдельный домен, поддомен или часть DNS, управляемая одним сервером. зоны примеры Примеры зон: . является корневой зоной org. является зоной ниже корневой зоны example.org. является зоной под зоной org. foo.example.org. является поддоменом, зоной под зоной example.org. 1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*. Как можно видеть, уточняющая часть имени хоста появляется слева. Например, example.org. более точен, чем org., также, как org. более точен, чем корневая зона. Расположение каждой части имени хоста сильно похоже на файловую систему: каталог /dev расположен в корневой файловой системе, и так далее. Причины, по которым вам может понадобиться сервер имён Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён. Авторитетный сервер имён нужен, когда: нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно. зарегистрирован домен, такой, как example.org и в этом домене требуется поставить имена машин в соответствие с их адресами IP. блоку адресов IP требуется обратные записи DNS (IP в имена хостов). резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен. Кэширующий сервер имён нужен, когда: локальный сервер DNS может кэшировать информацию и отвечать на запросы быстрее, чем это происходит при прямом опросе внешнего сервера имён. требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше). Например, когда кто-нибудь запрашивает информацию о www.FreeBSD.org, то обычно резолвер обращается к серверу имён вашего провайдера, посылает запрос и ожидает ответа. С локальным кэширующим сервером DNS запрос во внешний мир будет делаться всего один раз. Каждый дополнительный запрос не будет посылаться за пределы локальной сети, потому что информация уже имеется в кэше. Как это работает Во FreeBSD даемон BIND, по очевидным причинам, называется named. Файл Описание named даемон BIND ndc программа управления даемоном сервера имён /etc/namedb каталог, в котором располагается вся информация о зонах BIND /etc/namedb/named.conf конфигурационный файл для даемона Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён. Запуск BIND BIND запуск Так как сервер имён BIND устанавливается по умолчанию, его настройка сравнительно проста. Чтобы даемон named запускался во время загрузки, поместите в /etc/rc.conf следующую строку: named_enable="YES" Для запуска даемона вручную (после его настройки): &prompt.root; ndc start Конфигурационные файлы BIND конфигурационные файлы Использование <command>make-localhost</command> Обязательно выполните следующие команды: &prompt.root; cd /etc/namedb &prompt.root; sh make-localhost для того, чтобы правильно создать файл - /etc/namedb/localhost.rev локальной обратной + /etc/namedb/master/localhost.rev локальной обратной зоны для loopback-интерфейса. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Refer to the named(8) manual page for details. If you are ever going // to setup a primary server, make sure you've understood the hairy // details of how DNS is working. Even with simple mistakes, you can // break connectivity for affected parties, or cause huge amount of // useless Internet traffic. options { directory "/etc/namedb"; // In addition to the "forwarders" clause, you can force your name // server to never initiate queries of its own, but always ask its // forwarders only, by enabling the following line: // // forward only; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ Как и говорится в комментариях, если вы хотите получить эффект от использования кэша провайдера, то можно включить раздел forwarders. В обычном случае сервер имён будет рекурсивно опрашивать определённые серверы имён Интернет до тех пор, пока не получит ответ на свой запрос. При включении этого раздела он будет автоматически опрашивать сервер имён вашего провайдера (или тот, который здесь указан), используя преимущества его кэша. наличия нужной информации. Если соответствующий сервер имён провайдера работает быстро и имеет хороший канал связи, то в результате такой настройки вы можете получить хороший результат. 127.0.0.1 здесь работать не будет. Измените его на IP-адрес сервера имён провайдера. /* * If there is a firewall between you and name servers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; /* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file "s/named_dump.db"; }; // Note: the following will be supported in a future release. /* host { any; } { topology { 127.0.0.0/8; }; }; */ // Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don't forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; -zone -"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { - type master; - file "localhost.rev"; -}; - // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example secondary config entries. It can be convenient to become // a secondary at least for the zone where your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is the first bytes of the respective IP address, in reverse // order, with ".IN-ADDR.ARPA" appended.) // // Before starting to setup a primary zone, better make sure you fully // understand how DNS and BIND works, however. There are sometimes // unobvious pitfalls. Setting up a secondary is comparably simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. // // NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf). // The directory containing the secondary zones must be write accessible // to BIND. The following sequence is suggested: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s Дополнительная информация о запуске BIND в ограниченном окружении находится в соответствующем разделе. /* zone "example.com" { type slave; file "s/example.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ Это примеры описаний прямой и обратной зон из файла named.conf для вторичных серверов. Для каждого новой зоны, которую будет обслуживать сервер имён, в файл named.conf должна быть добавлена запись. К примеру, самая простая запись для домена example.org может выглядеть вот так: zone "example.org" { type master; file "example.org"; }; Зона является первичной, что отражается в поле , и информация о зоне хранится в файле /etc/namedb/example.org, что указывается в поле . zone "example.org" { type slave; file "example.org"; }; В случае вторичной зоны информация о ней передается с основного сервера имён для заданной зоны и сохраняется в указанном файле. Если и когда основной сервер имён выходит и строя или недосягаем, то скачанная информация о зоне будет находиться на вторичных серверах и они смогут обслуживать эту зону. Файлы зон Пример файла зоны example.org для основного сервера (располагающийся в файле /etc/namedb/example.org) имеет такой вид: $TTL 3600 example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.example.org. @ IN NS ns2.example.org. ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Aliases www IN CNAME @ ; MX Record @ IN MX 10 mail.example.org. Заметьте, что все имена хостов, оканчивающиеся на ., задают полное имя, тогда как все имена без символа . на конце считаются заданными относительно origin. Например, www преобразуется в www.origin. В нашем воображаемом файле ориджином является example.org., так что www преобразуется в www.example.org. Файл зоны имеет следующий формат: recordname IN recordtype value DNS записи Наиболее часто используемые записи DNS: SOA начало зоны ответственности NS авторитативный сервер имен A адрес хоста CNAME каноническое имя для алиаса MX обмен почтой PTR указатель на доменное имя (используется в обратных зонах DNS) example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day example.org. имя домена, а также ориджин для этого файла зоны. ns1.example.org. основной/авторитативный сервер имён для этой зоны. admin.example.org. человек, отвечающий за эту зону, адрес электронной почты с подменённым символом @. (admin@example.org становится admin.example.org) 5 последовательный номер файла. При каждом изменении файла зоны это число должно увеличиваться. В настоящее время для нумерации многие администраторы предпочитают формат ггггммддвв. 2001041002 будет означать, что файл последний раз изменялся 10.04.2001, а последнее число 02 означает, что это была вторая модификация файла за день. Последовательный номер важен, так как он служит для того, чтобы вторичные серверы узнавали об обновлении зоны. @ IN NS ns1.example.org. Это NS-запись. Такие записи должны иметься для всех серверов имён, которые будут отвечать за зону. Символ @, используемый здесь, преобразуется в example.org. Этот символ @ соответствует ориджину. localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 Записи типа A служат для обозначения имён машин. Как это видно выше, имя ns1.example.org будет преобразовано в 3.2.1.2. И снова здесь используется символ ориджина @, обозначая, что example.org будет преобразовано в 3.2.1.30. www IN CNAME @ Записи с каноническими именами обычно используются для присвоения машинам псевдонимов. В этом примере www является псевдонимом для машины, соответствующей ориджину, то есть example.org (3.2.1.30). Записи CNAME могут использоваться для присвоения псевдонимов именам хостов или для использования одного имени несколькими машинами по очереди. MX record @ IN MX 10 mail.example.org. MX-запись указывает, какие почтовые серверы отвечают за обработку входящей электронной почты для зоны. mail.example.org является именем почтового сервера, а 10 обозначает приоритет этого почтового сервера. Можно иметь несколько почтовых серверов с приоритетами 3, 2 и 1. Почтовый сервер, пытающийся доставить почту для example.org, сначала попробует связаться с машиной, имеющий MX-запись с самым большим приоритетом, затем с приоритетом поменьше и так далее, до тех пор, пока почта не будет отправлена. Для файлов зон in-addr.arpa (обратные записи DNS) используется тот же самый формат, отличающийся только использованием записей PTR вместо A или CNAME. $TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.example.org. @ IN NS ns2.example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 10 IN PTR mail.example.org. 30 IN PTR example.org. В этом файле дается полное соответствие имён хостов IP-адресам в нашем описанном ранее вымышленном домене. Кэширующий сервер имён BIND кэширующий сервер имён Кэширующий сервер имён - это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для последующего использования. Для настройки такого сервера достаточно исключить все описания зон из стандартной конфигурации сервера имён. Запуск <application>named</application> в песочнице BIND работа в песочнице chroot Для дополнительной безопасности вам может потребоваться запускать &man.named.8; с правами непривилегированного пользователя и настроить его на выполнение &man.chroot.8; в каталог-песочницу. Это позволит сделать недоступным для даемона named все, что расположено вне песочницы. Если named будет взломан, то это поможет уменьшить возможный ущерб. По умолчанию во FreeBSD имеются пользователь и группа с именами bind, которые предназначены именно для такого использования. Многие рекомендуют вместо настройки named на использование chroot, запускать named внутри &man.jail.8;. В этом разделе такой подход не рассматривается. Так как named не сможет обратиться ни к чему вне песочницы (например, совместно используемым библиотекам, сокетам протоколов и так далее), то нужно выполнить несколько шагов, чтобы named смог работать нормально. В следующем списке предполагается, что каталогом песочницы является /etc/namedb и что вы не делали никаких изменений в содержимом этого каталога. Выполните следующие шаги, работая как пользователь root: Создайте все каталоги, которые ожидает увидеть named: &prompt.root; cd /etc/namedb &prompt.root; mkdir -p bin dev etc var/tmp var/run master slave &prompt.root; chown bind:bind slave var/* Программе named нужен доступ с правом записи в эти каталоги, так что это все, что мы ей предоставим. Измените и создайте базовые файлы зоны и настроек: &prompt.root; cp /etc/localtime etc -&prompt.root; mv named.conf etc && ln -sf etc/named.conf +&prompt.root; mv named.conf etc && ln -sf etc/named.conf &prompt.root; mv named.root master -&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master -&prompt.root; cat > master/named.localhost +&prompt.root; sh make-localhost +&prompt.root; cat > master/named.localhost $ORIGIN localhost. $TTL 6h @ IN SOA localhost. postmaster.localhost. ( 1 ; serial 3600 ; refresh 1800 ; retry 604800 ; expiration 3600 ) ; minimum IN NS localhost. IN A 127.0.0.1 ^D Это позволит программе named протоколировать правильное время в &man.syslogd.8;. syslog лог файлы named Если вы используете &os; версии ранее 4.9-RELEASE, то постройте статически скомпонованную копию named-xfer и скопируйте её в песочницу: &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; make cleandir && make cleandir && make depend && make all &prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all -&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer +&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all +&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer После установки статически скомпонованного named-xfer, во избежание появления старых копий библиотек и программ в дереве исходного кода, требуется некоторая зачистка: &prompt.root; cd /usr/src/lib/libisc &prompt.root; make cleandir &prompt.root; cd /usr/src/lib/libbind &prompt.root; make cleandir &prompt.root; cd /usr/src/libexec/named-xfer &prompt.root; make cleandir Иногда при выполнении этого шага возникают ошибки. Если это случилось, выполните такую команду: - &prompt.root; cd /usr/src && make cleandir && make cleandir + &prompt.root; cd /usr/src && make cleandir && make cleandir и удалите ваше дерево /usr/obj: - &prompt.root; rm -fr /usr/obj && mkdir /usr/obj + &prompt.root; rm -fr /usr/obj && mkdir /usr/obj При этом из вашего дерева исходных текстов будет удалён весь мусор, и повторение вышеописанных шагов должно выполниться успешно. Если вы используете &os; 4.9-RELEASE или более позднюю версию, то копия named-xfer в каталоге /usr/libexec по умолчанию является статически скомпонованной, и вы можете просто скопировать её в песочницу при помощи команды &man.cp.1;. Создайте файл устройства dev/null, который named может видеть и писать в него: - &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 + &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 &prompt.root; chmod 666 null Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc: &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc Это просто для того, чтобы не задавать опцию при каждом запуске &man.ndc.8;. Так как содержимое каталога /var/run удаляется при загрузке, может быть полезно добавить эту команду в &man.crontab.5; для root с использованием параметра . syslog лог файлы named Настройте &man.syslogd.8; на создание дополнительного протоколирующего сокета log, в который может писать named. Для этого добавьте -l /etc/namedb/dev/log к переменной syslogd_flags из файла /etc/rc.conf. chroot Задайте запуск named и выполнение chroot в песочницу, добавив следующее в /etc/rc.conf: named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" Заметьте, что конфигурационный файл /etc/named.conf именуется по полному имени относительно песочницы, то есть в вышеприведённой строке указывается файл, который на самом деле является файлом /etc/namedb/etc/named.conf. Следующим шагом является редактирование файла /etc/namedb/etc/named.conf так, чтобы named знал, какую зону загружать и где найти их на диске. Далее следует прокомментированный пример (все, что специально не прокомментировано, ничем не отличается от настройки сервера DNS, работающего не в песочнице): options { directory "/"; named-xfer "/bin/named-xfer"; version ""; // Не выдавайте версию BIND query-source address * port 53; }; // управляющий сокет ndc controls { unix "/var/run/ndc" perm 0600 owner 0 group 0; }; // Далее следуют зоны: zone "localhost" IN { type master; file "master/named.localhost"; allow-transfer { localhost; }; notify no; }; zone "0.0.127.in-addr.arpa" IN { type master; file "master/localhost.rev"; allow-transfer { localhost; }; notify no; }; -zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { - type master; - file "master/localhost-v6.rev"; - allow-transfer { localhost; }; - notify no; -}; zone "." IN { type hint; file "master/named.root"; }; zone "private.example.net" in { type master; file "master/private.example.net.db"; allow-transfer { 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" in { type slave; masters { 192.168.10.2; }; file "slave/192.168.10.db"; }; В директиве directory указан каталог /, так как все файлы, которые нужны для named, находятся внутри этого каталога (вспомните, что это равнозначно обычному пользовательскому /etc/namedb). Задает полный путь к двоичному выполнимому файлу named-xfer (внутри границ видимости named). Это необходимо, так как named компилируется с тем, чтобы брать named-xfer по умолчанию из /usr/libexec. Задает имя файла (относительно директивы directory выше), в котором named может найти файл зоны для этой зоны. Задает имя файла (относительно директивы directory выше), в котором named должен записывать копию файла зоны для этой зоны после успешной передачи ее с основного сервера. Вот почему нам нужно изменить владельца каталога slave на bind на этапах настроек выше. После выполнения шагов выше либо перезагрузите ваш сервер, либо перезапустите &man.syslogd.8; и запустите &man.named.8;, не забыв использовать новые опции, заданные в syslogd_flags и named_flags. Теперь named должен заработать в песочнице! Безопасность Хотя BIND является самой распространенной реализацией DNS, всегда стоит вопрос об обеспечении безопасности. Время от времени обнаруживаются возможные и реальные бреши в безопасности. Весьма полезно прочесть сообщения безопасности CERT и подписаться на &a.security-notifications; для того, чтобы быть в курсе текущих проблем с обеспечением безопасности Internet и FreeBSD. Если возникают проблемы, то наличие последних исходных текстов и свежеоткомпилированного named не помешает. Дополнительная литература Справочная информация по BIND/named: &man.ndc.8;, &man.named.8; и &man.named.conf.5; Официальная страница ISC BIND FAQ по BIND Книга издательства O'Reilly DNS and BIND 4th Edition RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification Tom Rhodes Автор: Dmitry Morozovsky Перевод на русский язык: <acronym>BIND</acronym>9 и &os; bind9 установка &os; начиная с версии 5.3 содержит в базовой поставке сервер DNS BIND9. Среди прочих нововведений стоит отметить новые возможности, связанные с безопасностью, новую организацию файлов конфигурации и автоматическое использование опции &man.chroot.8;. Первая часть этой главы посвящена обсуждению новых возможностей и их использования, вторая описывает процесс обновления сервера DNS при переходе на &os; 5.3. Мы будем ссылаться на сервер BIND как &man.named.8;. Мы подразумеваем, что читатель знаком с терминологией, описываемой в предыдущей главе. Файлы конфигурации для named в настоящее время располагаются в каталоге /var/named/etc/namedb/ и требуют модификации перед началом использования сервера. Большая часть работы по конфигурации сервера DNS происходит именно в этом каталоге. Конфигурация основной (Master) зоны Для создания основной зоны перейдите в каталог /var/named/etc/namedb/ и выполните команду &prompt.root; sh make-localhost При удачном стечении обстоятельств в каталоге master появится два новых файла: localhost.rev для локального домена и localhost-v6.rev для локальной зоны IPv6. В поставляемом стандартном файле конфигурации named.conf уже есть ссылки на оба файла зон. Конфигурация зависимой (Slave) Зоны Дополнительные домены и поддомены могут быть добавлены как зависимые зоны. В большинстве случаев достаточно просто скопировать файл master/localhost.rev в каталог slave и изменить копию. После изменения файлов зон нужно добавить ссылки на них в основной файл конфигурации named.conf, как в следующем примере для example.com: zone "example.com" { type slave; file "slave/example.com"; masters { 10.0.0.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "slave/0.168.192.in-addr.arpa"; masters { 10.0.0.1; }; }; Отметим, что использованный в этом примере IP адрес является адресом, с которого будут копироваться файлы зон; этот адрес не обязательно является публичным сервером DNS. Стартовая конфигурация системы Для автоматического запуска даемона named при загрузке системы добавьте в файл стартовой конфигурации rc.conf строку named_enable="YES" Есть и другие параметры конфигурации, но эта строка — минимально необходима. Список параметров можно найти на странице справочника &man.rc.conf.5;. Если запуск named не разрешен в rc.conf, сервер можно запустить вручную командой &prompt.root; /etc/rc.d/named start <acronym>BIND</acronym>9: вопросы безопасности &os; автоматически запускает named в ограниченном пространстве &man.chroot.8;; кроме того, существует еще несколько средств, помогающих защитить сервис DNS от возможных атак. Списки ограничения доступа Для ограничения доступа к зонам могут применяться списки доступа. Для этого опишите для домена список IP адресов, которым разрешены запросы к содержимому доменной зоны, и используйте имя этого списка в конфигурации зоны. Вот пример описания списка ограничения доступа: acl "example.com" { 192.168.0.0/24; }; zone "example.com" { type slave; file "slave/example.com"; masters { 10.0.0.1; }; allow-query { example.com; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "slave/0.168.192.in-addr.arpa"; masters { 10.0.0.1; }; allow-query { example.com; }; }; Версия сервера Разрешать всем запросы о версии вашего DNS сервера может быть не самой лучшей идеей: возможный злоумышленник может воспользоваться ей для выяснения известных ошибок и уязвимостей и применить их вашего сервера. Подмена сообщения о версии не защитит ваш сервер от эксплоитов. Защитить сервер может только обновление до версии, не содержащей известных ошибок. Для предотвращения этого в раздел options файла конфигурации named.conf можно вписать строку, скрывающую версию сервера: options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; version "None of your business"; }; Murray Stokely Предоставил Apache HTTP сервер веб серверы настройка Apache Обзор &os; используется в качестве платформы для многих из самых нагруженных серверов в мире. Большинство серверов в интернет используют Apache HTTP сервер. Пакеты Apache должны быть включены в поставку FreeBSD. Если вы не установили их во вместе с системой, воспользуйтесь портами www/apache13 или www/apache2. Как только Apache был успешно установлен, его необходимо настроить. В этом разделе рассказывается о версии 1.3.X Apache HTTP сервера, поскольку эта версия наиболее широко используется в &os;. - Apache 2.X + Apache 2.X содержит много новых технологий, но здесь они не обсуждаются. За дополнительной информацией о - Apache 2.X, обращайтесь к Apache 2.X, обращайтесь к . Настройка Apache файл настройки В &os; основной файл настройки Apache HTTP сервера устанавливается в /usr/local/etc/apache/httpd.conf. Это обычный текстовый &unix; файл настройки с строками комментариев, начинающимися с символа #. Исчерпывающее описание всех возможных параметров настройки находится за пределом рассмотрения этой книги, поэтому здесь будут описаны только наиболее часто модифицируемые директивы. ServerRoot "/usr/local" Указывает верхний каталог установки Apache по умолчанию. Бинарные файлы находятся в bin и sbin, подкаталоги расположены относительно корневого каталога сервера, файлы настройки находятся в etc/apache. ServerAdmin you@your.address Адрес, на который должны будут отправляться сообщения о проблемах с сервером. Этот адрес выводится на некоторые генерируемые сервером страницы, например с сообщениями об ошибках. ServerName www.example.com ServerName позволяет вам устанавливать имя хоста, которое отправляется обратно клиентам, если оно отличается от того, с которым настроен хост (например, использование www вместо реального имени хоста). DocumentRoot "/usr/local/www/data" DocumentRoot: Каталог, внутри которого будут храниться документы. По умолчанию, все запросы обрабатываются внутри этого каталога, но символические ссылки и синонимы могут использоваться для указания на другие каталоги. Хорошей идеей будет сделать резервные копии настроек Apache перед внесением изменений. Как только вы будете удовлетворены первоначальной настройкой, можно запускать Apache. Запуск <application>Apache</application> Apache запуск или остановка Apache не запускается из inetd, как это делают многие другие сетевые серверы. Он настроен для автономного запуска, чтобы обеспечивать большую производительность при обработке HTTP запросов от браузеров клиентов. Для упрощения запуска, остановки и перезапуска сервера существует shell скрипт. Для запуска Apache в первый раз просто выполните: &prompt.root; /usr/local/sbin/apachectl start Вы можете остановить сервер в любой момент, выполнив: &prompt.root; /usr/local/sbin/apachectl stop После внесения любых изменений в файл настроек, вам потребуется перезапустить сервер: &prompt.root; /usr/local/sbin/apachectl restart Для перезапуска Apache без прерывания имеющихся соединений, выполните: &prompt.root; /usr/local/sbin/apachectl graceful Дополнительная информация находится на странице справочного руководства &man.apachectl.8;. Для запуска Apache при старте системы, добавьте в /etc/rc.conf следующую строку: apache_enable="YES" Если вы хотите передать программе Apache httpd дополнительные параметры командной при загрузке системы, они могут быть помещены в дополнительную строку rc.conf: apache_flags="" Теперь, когда веб сервер запущен, вы можете просмотреть свой веб сайт, задав в строке браузера адрес http://localhost/. По умолчанию отображается веб страница /usr/local/www/data/index.html. Виртуальный хостинг Apache поддерживает два различных типа виртуального хостинга (Virtual Hosting). Первый метод основан на именах (Name-based Virtual Hosting). Он использует полученные от клиента заголовки HTTP/1.1 для определения имени хоста. Это позволяет многим различным доменам использовать один и тот же IP адрес. Для настройки Apache на использование этого типа хостинга добавьте в httpd.conf запись подобную следующей: NameVirtualHost * Если веб сервер назывался www.domain.tld и вы хотите настроить виртуальный домен для www.someotherdomain.tld, необходимо добавить в httpd.conf следующие записи: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld -<VirtualHost> +</VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> Замените адреса и пути к документам на те, что вы будете использовать. За дополнительной информацией по настройке виртуальных хостов обращайтесь к официальной документации Apache: . Модули Apache Apache модули Существуют множество различных модулей Apache, которые добавляют функциональность к основному серверу. Коллекция портов FreeBSD предоставляет простой способ установки Apache с некоторыми наиболее популярными дополнительными модулями. mod_ssl веб серверы защита SSL криптография Модуль mod_ssl использует библиотеку OpenSSL для сильной криптографии через протоколы Secure Sockets Layer (SSL v2/v3) и Transport Layer Security (TLS v1). Этот модуль содержит все необходимое для запроса подписанного сертификата из центра сертификации для защищенного веб сервера на &os;. Если вы еще не установили Apache, версия Apache 1.3.X с mod_ssl может быть установлена через порт www/apache13-modssl. Поддержка SSL также доступна для - Apache 2.X + Apache 2.X через порт www/apache2, где она включена по умолчанию. mod_perl Perl Проект интеграции Apache/Perl объединяет мощь языка программирования Perl и HTTP сервера Apache. С модулем mod_perl возможно написание модулей Apache полностью на Perl. Кроме того, постоянно запущенный встроенный в сервер интерпретатор позволяет не тратить ресурсы на запуск внешнего интерпретатора и время на запуск Perl. Если вы еще не установили Apache, его версия с модулем mod_perl может быть установлена через порт www/apache13-modperl. Tom Rhodes Написал PHP PHP В последние несколько лет все большее количество компаний выходит в интернет, стараясь повысить свою узнаваемость и получить больший доход. Это увеличивает потребность в интерактивном веб контенте. В то время, как некоторые компании, такие как µsoft;, представили свои решения в проприетарных продуктах, сообщество открытых исходных текстов ответило на вызов. Один из таких ответов, это широко используемый PHP. PHP, также известный как Hypertext Preprocessor, это скриптовый язык общего назначения, в основном предназначенный для веб разработки. Этот язык может быть встроен в HTML, его синтаксис заимствован из C, &java; и Perl, и он позволяет веб разработчикам быстро писать динамически генерируемые страницы. Добавление поддержки PHP5 к веб серверу Apache производится путем установки порта www/mod_php5. Этот порт устанавливает и настраивает модули, необходимые для поддержки динамических веб страниц. Убедитесь, что в файл /usr/local/etc/apache/httpd.conf были - добавлены следующие строки: + добавлены следующие строки: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> После этого просто вызовите команду apachectl с параметром graceful: &prompt.root; apachectl graceful Поддержка PHP в &os; построена по модульному принципу. Если требуется поддержка какого-либо расширения, администратор должен лишь установить соответствующий порт и перезапустить Apache, как показано выше. Например, для добавления поддержки MySQL к PHP5, просто установите databases/php5-mysql и выполните следующую команду: &prompt.root; apachectl graceful Это включит поддержку MySQL в PHP. Murray Stokely Предоставил Файл сервер и печать для µsoft.windows; клиентов (Samba) Samba сервер Microsoft Windows файл сервер Windows клиенты принт сервер Windows клиенты Обзор Samba это популярный пакет программ с открытыми исходными текстами, которая предоставляет файловые и принт-сервисы µsoft.windows; клиентам. Эти клиенты могут подключаться и использовать файловое пространство FreeBSD, как если бы это был локальный диск, или принтеры FreeBSD, как если бы это были локальные принтеры. Пакет Samba должен быть включен в поставку FreeBSD. Если вы не установили Samba при первой установке системы, ее можно установить из порта или пакета net/samba3. Настройка Файл настройки Samba по умолчанию устанавливается в /usr/local/etc/smb.conf.default. Этот файл необходимо скопировать в /usr/local/etc/smb.conf и отредактировать перед использованием Samba. В файле smb.conf находится информация, необходимая для работы Samba, например определение принтеров и общих каталогов, которые будут использоваться совместно с &windows; клиентами. В пакет Samba входит программа с веб интерфейсом, называемая swat, которая дает простой способ редактирования файла smb.conf. Использование Samba Web Administration Tool (SWAT) Программа веб администрирования Samba (Samba Web Administration Tool, SWAT) запускается как даемон из inetd. Следовательно, в /etc/inetd.conf необходимо снять комментарий перед тем, как использовать swat для настройки Samba: swat stream tcp nowait/400 root /usr/local/sbin/swat Как описано в , после изменения настроек inetd необходимо отправить HangUP сигнал. Как только swat был включен inetd.conf, вы можете использовать браузер для подключения к . Сначала необходимо зарегистрироваться с системной учетной записью root. После успешного входа на основную страницу настройки Samba, вы можете просмотреть документацию или начать настройку, нажав на кнопку Globals. Раздел Globals соответствует переменным, установленным в разделе [global] файла /usr/local/etc/smb.conf. Глобальные настройки Независимо от того, используете ли вы swat, или редактируете /usr/local/etc/smb.conf непосредственно, первые директивы, которые вы скорее всего встретите при настройке Samba, будут следующими: workgroup Имя домена или рабочей группы NT для компьютеров, которые будут получать доступ к этому серверу. netbios name NetBIOS Устанавливает имя NetBIOS, под которым будет работать Samba сервер. По умолчанию оно устанавливается равным первому компоненту DNS имени хоста. server string Устанавливает строку, которая будет показана командой net view и некоторыми другими сетевыми инструментами, которые отображают строку описания сервера. Настройки безопасности Две из наиболее важных настроек в /usr/local/etc/smb.conf отвечают за выбор модели безопасности и за формат паролей для клиентов. Эти параметры контролируются следующими директивами: security Два наиболее часто используемых параметра это security = share и security = user. Если имена пользователей для клиентов совпадают с их именами на компьютере &os;, вы возможно захотите включить безопасность уровня пользователя (user). Это политика безопасности по умолчанию, она требует, чтобы клиент авторизовался перед доступом к совместно используемым ресурсам. На уровне безопасности share клиенту не требуется входить на сервер перед подключением к ресурсу. Эта модель безопасности использовалась по умолчанию в старых версиях Samba. passdb backend NIS+ LDAP SQL база данных Samba поддерживает несколько различных подсистем аутентификации. Вы можете аутентифицировать клиентов с помощью LDAP, NIS+, базы данных SQL, или через модифицированный файл паролей. Метод аутентификации по умолчанию smbpasswd, и здесь рассматривается только он. Предполагая, что используется подсистема по умолчанию smbpasswd, необходимо создать файл /usr/local/private/smbpasswd, чтобы Samba могла аутентифицировать клиентов. Если вы хотите разрешить всем учетным записям &unix; доступ с &windows; клиентов, используйте следующую команду: &prompt.root; grep -v "^#" /etc/passwd | make_smbpasswd > /usr/local/private/smbpasswd &prompt.root; chmod 600 /usr/local/private/smbpasswd Обратитесь к документации на Samba за дополнительной информацией о параметрах настройки. Основные настройки, рассмотренные здесь, достаточны для первого запуска Samba. Запуск <application>Samba</application> Для запуска Samba при загрузке системы, добавьте в /etc/rc.conf следующую строку: samba_enable="YES" Затем вы можете запустить Samba в любой момент, набрав: &prompt.root; /usr/local/etc/rc.d/samba.sh start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Samba состоит из трех отдельных даемонов. Вы можете видеть, что nmbd и smbd запускаются скриптом samba.sh. Если вы включили сервис разрешения имен winbind в smb.conf, то увидите также запуск даемона winbindd. Вы можете остановить Samba в любой момент, набрав: &prompt.root; /usr/local/etc/rc.d/samba.sh stop Samba это сложный программный набор с функциональностью, позволяющей полную интеграцию в сети µsoft.windows;. За дальнейшей информацией о функциях, выходящих за рамки описанной здесь базовой установки, обращайтесь к . Murray Stokely Предоставил Протокол передачи файлов (FTP) FTP серверы Обзор Протокол передачи файлов (File Transfer Protocol, FTP) дает пользователям простой путь передачи файлов на и с FTP сервера. В &os; серверная программа FTP, ftpd, включена в базовую систему. Это упрощает настройку и администрирование FTP сервера в FreeBSD. Настройка Наиболее важный шаг заключается в определении того, каким учетным записям будет позволено получать доступ к FTP серверу. В обычной системе FreeBSD есть множество системных учетных записей, используемых различными даемонами, но пользователям должно быть запрещен вход с использованием этих учетных записей. В файле /etc/ftpusers находится список пользователей, которым запрещен доступ по FTP. По умолчанию он включает упомянутые системные учетные записи, но в него можно добавить и определенных пользователей, которым будет запрещен доступ по FTP. Вам может понадобиться ограничить доступ определенных пользователей без полного запрета использования FTP. Это можно сделать через файл /etc/ftpchroot. В нем находится список пользователей и групп, к которым применяется ограничение доступа. На странице справочника &man.ftpchroot.5; дана подробная информация, и она не будет дублироваться здесь. FTP анонимный Если вы захотите разрешить анонимный FTP доступ на сервер, в системе &os; необходимо создать пользователя ftp. Этот пользователь сможет входить на FTP сервер с именем пользователя ftp или anonymous, с любым паролем (существует соглашение об использовании почтового адреса пользователя в качестве пароля). FTP сервер выполнит &man.chroot.2; при входе пользователя anonymous для ограничения доступа только домашним каталогом пользователя ftp. Существуют два текстовых файла, определяющих сообщение, отправляемое FTP клиентам. Содержимое файла /etc/ftpwelcome будет выведено пользователям перед приглашением на вход. После успешного входа будет выведено содержимое файла /etc/ftpmotd. Обратите внимание, что путь к этому файлу задается относительно домашнего каталога пользователя, так что анонимным пользователям будет отправляться ~ftp/etc/ftpmotd. Как только FTP сервер был правильно настроен, он должен быть включен в /etc/inetd.conf. Все, что необходимо, это удалить символ комментария # из начала существующей строки ftpd: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Как описано в , сигнал HangUP должен быть отправлен inetd после того, как этот файл настройки был изменен. Теперь вы можете войти на FTP сервер, введя: &prompt.user; ftp localhost Поддержка syslog лог файлы FTP Для протоколирования даемон ftpd использует сообщения &man.syslog.3;. По умолчанию, &man.syslog.3; поместит сообщения, относящиеся к FTP, в файл /var/log/xferlog. Местоположение лог файла FTP может быть изменено путем изменения следующей строки в файле /etc/syslog.conf: ftp.info /var/log/xferlog FTP анонимный Учитывайте потенциальные проблемы, возникающие с анонимным FTP сервером. В частности, вы должны дважды подумать, прежде чем позволить анонимным пользователям загружать файлы на сервер. Вы можете обнаружить, что FTP сайт стал форумом, на котором происходит обмен нелицензионным коммерческим программным обеспечением или чем-то еще хуже. Если вам необходимо разрешить анонимную выгрузку файлов на FTP, права должны быть настроены таким образом, чтобы эти файлы не могли прочитать другие анонимные пользователи до их рассмотрения администратором. Tom Hukins Текст предоставил Синхронизация часов через NTP NTP Обзор С течением времени часы компьютера имеют тенденцию отставать. Network Time Protocol - Сетевой Протокол Времени (NTP) является одним из способов вести точное время. Многие сервисы Интернет опираются или сильно зависят от точности часов компьютеров. К примеру, веб-сервер может получать запрос на посылку файла, который был недавно модифицирован. В локальной сети необходимо, чтобы часы компьютеров, совместно использующих файлы, были синхронизированы, чтобы время модификации файлов устанавливалось правильно. Такие службы, как &man.cron.8;, также зависят от правильности установки системных часов, поскольку запускают команды в определенное время. NTP ntpd FreeBSD поставляется с сервером NTP &man.ntpd.8;, который можно использовать для опроса других серверов NTP для установки часов на вашей машине или предоставления услуг точного времени. Выбор подходящих серверов NTP NTP выбор серверов Для синхронизации ваших часов вам нужно найти для использования один или большее количество серверов NTP. Ваш сетевой администратор или провайдер могут иметь сервер NTP для этой цели—обратитесь к ним, так ли это в вашем случае. Существует онлайн список общедоступных серверов NTP, которым можно воспользоваться для поиска ближайшего к вам сервера NTP. Не забудьте выяснить политику выбранного вами сервера и спросить разрешения, если это требуется. Выбор нескольких несвязанных серверов NTP является хорошей идеей в том случае, если один из используемых вами серверов станет недоступным или его часы неточны. &man.ntpd.8; использует ответы, которые он получает от других серверов с умом—он делает предпочтение надежным серверам. Настройка вашей машины NTP настройка Базовая конфигурация ntpdate Если вам нужно только синхронизировать ваши часы при загрузке машины, вы можете воспользоваться утилитой &man.ntpdate.8;. Это может подойти для некоторых настольных машин, которые часто перезагружаются и только требуют изредка синхронизироваться, но на большинстве машин должен работать &man.ntpd.8;. Использование &man.ntpdate.8; при загрузке также хорошо для машин, на которых запущен даемон &man.ntpd.8;. Программа &man.ntpd.8; изменяет время постепенно, тогда как &man.ntpdate.8; устанавливает время вне зависимости от того, насколько велика разница между текущим временем машины и точным временем. Для включения &man.ntpdate.8; во время загрузки, добавьте строчку ntpdate_enable="YES" в файл /etc/rc.conf. Вам также потребуется указать все серверы, с которыми вы хотите синхронизироваться, и все параметры, которые передаются в &man.ntpdate.8;, в ntpdate_flags. NTP ntp.conf Общие настройки NTP настраивается в файле /etc/ntp.conf, формат которого описан в &man.ntp.conf.5;. Вот простой пример: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift Параметр server задает, какие серверы будут использоваться, по одному в каждой строке. Если сервер задан с аргументом prefer, как ntplocal.example.com, то этому серверу отдается предпочтение перед остальными. Ответ от предпочтительного сервера будет отброшен, если он значительно отличается от ответов других серверов, в противном случае он будет использоваться безотносительно к другим ответам. Аргумент prefer обычно используется для серверов NTP, о которых известно, что они очень точны, такими, на которых используется специальное оборудование точного времени. Параметр driftfile задает файл, который используется для хранения смещения частоты системных часов. Программа &man.ntpd.8; использует его для автоматической компенсации естественного смещения часов, позволяя ему поддерживать достаточно правильную настройку, даже если он на некоторый период отключается от внешнего источника информации о времени. Параметр driftfile задает, какой файл используется для сохранения информации о предыдущих ответах от серверов NTP, которые вы используете. Этот файл содержит внутреннюю информацию для NTP. Он не должен изменяться никакими другими процессами. Управление доступом к вашему серверу По умолчанию ваш сервер NTP будет доступен всем хостам в Интернет. Параметр restrict в файле /etc/ntp.conf позволяет вам контролировать, какие машины могут обращаться к вашему серверу. Если вы хотите запретить всем машинам обращаться к вашему серверу NTP, добавьте следующую строку в файл /etc/ntp.conf: restrict default ignore Если вы хотите разрешить синхронизировать свои часы с вашим сервером только машинам в вашей сети, но запретить им настраивать сервер или быть равноправными участниками синхронизации времени, то вместо указанной добавьте строчку restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap где 192.168.1.0 является адресом IP вашей сети, а 255.255.255.0 её сетевой маской. /etc/ntp.conf может содержать несколько директив restrict. Для получения подробной информации обратитесь к подразделу Access Control Support (Поддержка Управления Доступом) в &man.ntp.conf.5;. Запуск сервера NTP Для того, чтобы сервер NTP запускался при загрузке, добавьте строку ntpd_enable="YES" в файл /etc/rc.conf. Если вы хотите передать дополнительные опции в &man.ntpd.8;, то отредактируйте параметр ntpd_flags в файле /etc/rc.conf. Для запуска сервера без перезагрузки вашей машины, выполните команду ntpd, не забыв задать дополнительные параметры из переменной ntpd_flags в файле /etc/rc.conf. К примеру: &prompt.root; ntpd -p /var/run/ntpd.pid Во &os; 4.X вам необходимо заменить каждую строчку ntpd на xntpd. Использование ntpd с временным подключением к Интернет Для нормальной работы программе &man.ntpd.8; не требуется постоянное подключение к Интернет. Однако если ваше временное подключение к Интернет настроено для дозвона по требованию, хорошо бы запретить трафику NTP вызывать дозвон или поддерживать соединение постоянно. Если вы используете пользовательский PPP, то можете воспользоваться директивами filter в файле /etc/ppp/ppp.conf. К примеру: 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 Более подробную информацию можно найти в разделе PACKET FILTERING (ФИЛЬТРАЦИЯ ПАКЕТОВ) в &man.ppp.8;, а примеры в /usr/share/examples/ppp/. Некоторые провайдеры Интернет блокируют трафик по портам с маленькими номерами, что приводит к неработоспособности NTP, так как ответы никогда не достигают вашей машины. Дополнительная литература Документация по серверу NTP может быть найдена в каталоге /usr/share/doc/ntp/ в формате HTML.