В крупной сети существует достаточно много серверов. Как говорилось выше, серверы часто распределены по сети - и в каждой подсети существует сервер. Такая архитектура повышает эффективность работы сети, но противоречит общей цели централизации управления настройкой.
Чем больше в сети серверов, тем более рассредоточено управление и тем более вероятно возникновение ошибок в настройках. Работа с распределенными серверами требует механизма централизованного управления и распространения информации среди серверов. В TCP/IP таких механизмов существует несколько.
Для переноса настроек с центральной системы на группу распределенных систем может использоваться любой протокол передачи файлов. Подойдет FTP или TFTP, однако подобное использование протоколов связано с некоторыми сложностями. FTP и TFTP - протоколы диалоговые, они требуют выполнения многих команд для получения файла, что затрудняет написание соответствующих сценариев. Кроме того, FTP требует парольной идентификации для получения доступа к файлам, а большинство специалистов но безопасности реагируют на хранение паролей в сценариях недовольными гримасами. По этим причинам мы не будем рассматривать эти протоколы в качестве средства распространения файлов настройки. Кроме того, если вы знакомы с FTP (а вы должны быть знакомы с этим протоколом!), то знаете, как использовать его для передачи файла настройки.
Второй вариант - использовать для распространения информации NFS. NFS позволяет клиентам использовать файлы с сервера так, словно это локальные файлы. NFS - очень мощный инструмент, однако в качестве средства распространения информации, необходимой для загрузки серверов, он имеет определенные ограничения. Неполадки с электропитанием, влияющие на распределенные серверы, могут стать причиной сбоя и центрального сервера. Загрузка распределенных серверов и их клиентов будет отложена до того времени, пока центральный сервер не начнет нормальную работу в сети.
Организация доступа к единственной копии файла настройки противоречит усилиям, направленным на распределение служб загрузки, поскольку возникает слишком большая зависимость от центрального сервера.
Одним из способов избежать проблемы является периодическое копирование распределенными серверами файла настройки из смонтированной файловой системы на локальный диск. Это решение легко автоматизировать, но оно создает возможную ситуацию, когда распределенные серверы в определенные моменты времени будут отставать в синхронизации - копируя файл настройки по расписанию, а не тогда, когда изменилась основная копия файла. Есть, разумеется, и иной подход: все удаленные серверы экспортируют файловые системы, монтируемые центральным сервером. Тогда центральный сервер может копировать файл настройки непосредственно в удаленные файловые системы, когда изменяется основная копия файла. Тем не менее существуют и более простые пути.
r-команды Unix rep и relist реализуют наиболее популярные методы распространения файлов настройки.
rep - Программа удаленного копирования (remote сору, гер) - это обычный протокол передачи файлов. Применительно к поставленной задаче она имеет два преимущества перед FTP: легко позволяет автоматизировать процессы и не требует использования паролей. Автоматизация с гер проста потому, что для передачи файла требуется одна-единственная строка. В следующем примере выполняется передача файла dhcpd.conf с головного сервера на удаленный сервер arthropod.wrotethebook.com:
# rep /etc/dhcpd.conf arthropod.wrotethebook.com:/etc/dhcpd.conf
Для каждого удаленного сервера, которому необходимо передать файл, добавьте подобную строку в процедуру обновления основной копии файла настройки.
гср - лишь один из вариантов решения задачи о распространении основной копии файла настройки. Программа relist, будучи не столь простой в приме- нении, часто оказывается более предпочтительным выбором, поскольку имеет ряд возможностей, делающих ее особенно подходящей для решения подобных задач.