Способы решения задач
Традиционно такого рода задачи решаются стандартными средствами открытых UNIX-систем. Для решения каждой подзадачи конфигурируется один из стандарных сервисов:
- dhcpd - для автоматической выдачи сетевых настроек клиентам на основании их MAC-адресов либо произвольно
- bind - для прямого и обратного преобразования имен сетевых клиентов и их IP-адресов
- squid - для организации кэширующего прокси-сервера
- ipchains или iptables для Linux и ipfw для FreeBSD - для организации брандмауэра с дополнительными функциями вроде поддержки прозрачного прокси и NAT
- сервер баз данных (как правило, MySQL) для хранения данных о трафике + какая-нибудь система сбора этих данных
Основной недостаток такого решения - сложность администрирования. Например, чтобы включить в сеть еще один компьютер, необходимо проделать следующее:
- прописать этот компьютер в конфигурационном файле dhcpd
- прописать его в файлах прямой и обратной зоны bind
- прописать его в acl squid
- прописать его в стартовом скрипте брандмауэра
Т.е. человеку, обслуживающего такую систему, приходится выполнять слишком много рутинной работы. Гораздо правильнее будет переложить большую часть работы на плечи компьютера.
Простейшей способ упростить администрирование сводится к выделению наиболее часто изменяемых параметров и вынесению их в отдельное хранилище - текстовый или xml-файл, базу данных и т.д. Затем для каждого сервиса пишется скрипт, вынимающий необходимые данные из главного конфигурационного файла, и генерирующий конфиг для самого сервиса.
Написание скриптов для генерации конфигов может быть довольно трудоемкой задачей. Ситуацию упрощает тот факт, что многие сервисы имеют возможность хранить свои конфигурационные данные не в текстовых файлах, а в некотором внешнем хранилище, в качестве которого чаще всего выступает LDAP. Некоторые особо продвинутые сервисы даже имеют развитые средства для написания собственных backend-ов (примеры - bind и courier-imap), однако LDAP все равно остается самым распространенным внешним хранилищем конфигурационных даных.
Цель данной статьи - показать, как использовать LDAP для хранения конфигурационных данных как тех сервисов, которые непосредственно умеют работать с LDAP, так и тех, которые этого не умеют. Кроме того, в статье будут рассмотрены смежные вопросы, имеющие непосредственное отношение к построению централизованной системы управления сетью: учет трафика и написание кроссплатформенного графического интерфейса к системе управления сетью.
