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

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

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

Другой подход — удаление всех текстовых файлов и выдача каждому компьютеру информации о его конфигурации с центрального сервера. Делать это сложнее, чем просто копировать файлы, но зато попутно решаются некоторые другие проблемы. Например, клиенты в любом случае будут получать исправленные версии файлов, даже если во время внесения изменений машина-клиент была отключена. Кроме того, получать информацию с сервера в некоторых случаях можно быстрее, чем из файла (это зависит от быстродействия локального диска и объема кэширования, выполняемого сервером). С другой стороны, отказ сервера может привести к зависанию всей сети.

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

В настоящей главе мы рассмотрим некоторые базовые методики синхронизации файлов в сети, а затем поговорим о двух наиболее широко используемых административных СУБД (NIS и NIS+) и одной относительно новой системе, которая способна завоевать широкую популярность в ближайшие несколько лет (LDAP).

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

В руководствах (в соответствии с общими принципами UNIX-культуры) предполагается, что администраторы будут использовать систему типа NIS или NIS+, если таковая имеется. Однако если в организации не решаются сложные задачи, то и в сложных решениях нет необходимости. Иногда самое "лобовое", самое тривиальное решение оказывается наилучшим.

Наша организация состоит из нескольких связанных, но независимых "участков". Совместно используется лишь незначительная часть административных данных. В нашей схеме распространения файлов каждый участок имеет один-два сервера, где хранятся оригиналы его системных файлов. Это разновидность среды, в которой принцип последовательного копирования файлов работает хорошо, поскольку задача сводится к простой перекачке данных, без подгонки их под условия конкретных архитектур или сетей.

Административная база данных NIS (Network Information Service — сетевая информационная служба) была выпущена в свет компанией Sun в 80-х гг. Сначала она называлась Sun Yellow Pages (Желтые страницы Sun), но по причинам правового характера ее пришлось переименовать. Команды NIS до сих пор начинаются с префикса ур, поскольку имя, данное при рождении, забыть трудно. Многие фирмы купили у Sun лицензию на это программное обеспечение, что сделало NIS наиболее широко распространенной системой совместного использования файлов.

В начале 90-х компания Sun выпустила новую административную СУБД: NIS+. Невзирая на сходство названий, NIS и NIS+ не связаны друг с другом. Система NIS+ гораздо сложнее, чем NIS, и не столь популярна. Подробнее о ней рассказывается в параграфе 18.4. В табл. 18.2 отражены сведения о поддержке NIS и NIS+ в наших тестовых системах.

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

Хотя серверы NIS+ могут обслуживать клиентов NIS (с некоторым снижением уровня безопасности), NIS+ — совершенно другая система, у которой нет общего с NIS кода. Она поддерживается некоторыми крупными поставщиками ОС (например, HP-UX), но вследствие своей сложности не входит ни в одну из бесплатных операционных систем.

NIS+ — это хороший пример того, что Фредерик Брукс-младший (Frederick P. Brooks, Jr.) в своей классической книге The Mythical Man-Month ("Мифический человеко-месяц"), посвященной технологиям разработки программного обеспечения, назвал "эффектом второй системы". Эта система пытается пробиться к пользователям на волне успеха своей предшественницы, избегая всех ошибок и ловушек предыдущей концепции. Разработчики уделили существенное внимание ее формальной архитектуре. Теоретически система должна получиться совершенной. На практике же она неуклюжа, тяжеловесна и находится несколько в стороне от повседневной жизни. Нам рассказали, что даже в самой компании Sun ею не пользуются.