Централизованная схема управления сетью с использованием OpenLDAPЦентрализованная схема управления сетью с использованием OpenLDAP: хранение настроек DHCP, DDNS, Squid, IPTables в OpenLDAP, использование Ulog-acctd, Squid, Firebird, Perl для учета трафика, административный клиент Network Console на Java Документ распространяется в соответствии с условиями лицензии GNU Free Documentation License. Ни автор, ни распространители, ни любой другой контрибьютор данного документа, не несет никакой ответственности за физический, финансовый, моральный или любой другой ущерб, понесенный при выполнении рекомендаций данного документа.
1. Постановка задачи1.1. Список задачДля небольшой локальной сети необходимо обеспечить:
1.2. Способы решения задачТрадиционно такого рода задачи решаются стандартными средствами открытых UNIX-систем. Для решения каждой подзадачи конфигурируется один из стандарных сервисов:
Основной недостаток такого решения - сложность администрирования. Например, чтобы включить в сеть еще один компьютер, необходимо проделать следующее:
Т.е. человеку, обслуживающего такую систему, приходится выполнять слишком много рутинной работы. Гораздо правильнее будет переложить большую часть работы на плечи компьютера. Простейшей способ упростить администрирование сводится к выделению наиболее часто изменяемых параметров и вынесению их в отдельное хранилище - текстовый или xml-файл, базу данных и т.д. Затем для каждого сервиса пишется скрипт, вынимающий необходимые данные из главного конфигурационного файла, и генерирующий конфиг для самого сервиса. Написание скриптов для генерации конфигов может быть довольно трудоемкой задачей. Ситуацию упрощает тот факт, что многие сервисы имеют возможность хранить свои конфигурационные данные не в текстовых файлах, а в некотором внешнем хранилище, в качестве которого чаще всего выступает LDAP. Некоторые особо продвинутые сервисы даже имеют развитые средства для написания собственных backend-ов (примеры - bind и courier-imap), однако LDAP все равно остается самым распространенным внешним хранилищем конфигурационных даных. Цель данной статьи - показать, как использовать LDAP для хранения конфигурационных данных как тех сервисов, которые непосредственно умеют работать с LDAP, так и тех, которые этого не умеют. Кроме того, в статье будут рассмотрены смежные вопросы, имеющие непосредственное отношение к построению централизованной системы управления сетью: учет трафика и написание кроссплатформенного графического интерфейса к системе управления сетью. 2. РеализацияДля построения сервера был использован Linux, а точнее ALT Linux Master 2.2. В целом система выглядит так:
Реализация каждого компонента системы далее рассмотрена подробно. 2.1. Подсистема управления настройками2.1.1. Первоначальная настройка OpenLDAPПосле установки OpenLDAP (в ALT Linux это можно сделать выполнив команду apt-get install openldap openldap-servers openldap-clients openldap-guide) необходимо отредактировать его главный конфигурационный файл /etc/openldap/slapd.conf следующим образом: См. пример В конфигурационном файле определены только самые необходимые настройки. Об остальных можно прочесть в комментариях к оригинальному конфигурационному файлу и в документации к OpenLDAP. Теперь можно запустить OpenLDAP (в ALT Linux это можно сделать выполнив команду service ldap start). 2.1.2. Настройка связки DHCP+LDAPДля хранения конфигурации ISC DHCP-сервера в LDAP его необходимо пересобрать с патчем dhcp-3.0.1rc13-ldap-patch (его последнюю версию можно найти на http://home.ntelos.net/~masneyb/). Пользователи ALT Linux вместо ручной пересборки могут подключить репозиторий nm и выполнить команду apt-get install dhcp. После установки DHCP-сервера нужно скопировать файл dhcp.schema (который также можно найти в составе пакета dhcp) в каталог /etc/openldap/schema и модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены): См. пример После перезапуска OpenLDAP (service ldap restart в ALT Linux) необходимо создать файл dhcpd.ldif (или взять его из пакета dhcp). Содержимое файла необходимо добавить в дерево LDAP командой: ldapadd -h 127.0.0.1 -x -D "cn=manager,dc=myserver, и проверить, добавлены ли записи, командой: ldapsearch -h 127.0.0.1 -LLL -b "dc=myserver,dc=myprovider,dc=ru" -D После этого нужно создать конфигурационный файл DHCP-сервера /etc/dhcpd.conf (или взять его из пакета dhcp):
После запуска DHCP-сервера (service dhcpd start в ALT Linux) в качестве источника настроек он будет использовать дерево LDAP. 2.1.3. Настройка DDNSПервоначально для хранения конфигурации DNS в LDAP планировалось использовать соответствующий backend bind. Но затем нашлось более простое решение: DDNS - динамический DNS, автоматически редактирующий записи о хостах в файлах прямой и обратной зон по запросу DHCP-сервера. Для его настройки необходимо отредактировать настройки DHCP-сервера непосредственно в дереве LDAP, используя файл dhcp-ddns-add.ldif Содержимое файла необходимо внести в дерево LDAP следующим образом:
После этого желательно проверить, правильно ли отредактирована главная запись DHCP-сервера: См. пример Затем необходимо установить bind (apt-get install bind в ALT Linux) и включить в нем поддержку DDNS. Содержимое конфигурационных файлов и права доступа к ним приведены здесь (предполагаем, что bind выполняется в chroot - в ALT Linux так оно и есть): WOfB3kj8IhJK4OZ5s3zHeQ== - это ключ, сгенерированный следующим образом:
После выполнения этой команды создаются файлы Kdhcp_update.+157+56116.key и Kdhcp_update.+157+56116.private, из любого можно взять строку ключа. Перед первым запуском bind необходимо выставить на каталог /var/lib/bind/zone права rwxrwx---, чтобы bind мог стать владельцем файлов зон и создать файлы журналов. После того, как первый хост будет зарегистирирован в DNS, права можно вернуть обратно. Если все сконфигурировано верно, при регистрации первого хоста в логах можно увидеть следующее 2.1.4. Настройка Squid и IPTablesНи Squid, ни IPTables не поддерживают хранение собственных настроек в LDAP. Для Squid существует модуль авторизации пользователей из LDAP, но нам требуется разграничение доступа не по пользователям, а по рабочим станциям. Настройки IPTables - это стартовый скрипт и/или файл дампа, что тоже не совсем подходит. Самый простой выход в данной ситуации - создание собственной схемы internet-access.schema В схеме определяется класс internetAccess и его атрибуты: allowNat (разрешить использование NAT), allowProxy (разрешить использование прокси-сервера) или forceProxy (использовать прокси-сервер в прозрачном режиме). Cозданную схему необходимо скопировать в каталог /etc/openldap/schema и модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены):
После перезапуска OpenLDAP (service ldap restart в ALT Linux) необходимо внести данные, соответствующие схеме, из файла internet-access.ldif Добавить их можно командой:
Для извлечения списка хостов, у которых одно из свойств allowNat, allowProxy или forceProxy установлено в TRUE, можно использовать такой простой скрипт: /opt/scripts/make_ldap_filter.sh Пример вызова скрипта:
Eго можно использовать в скрипте, генерирующем правила для IPTables:/opt/scripts/make_iptables.sh Аналогичный скрипт для Squid (/opt/scripts/make_squid.sh) выглядит так:
При этом в конфигурационном файл Squid (/etc/squid/squid.conf) должно быть написано примерно следующее:
2.1.5. Настройка авторизации в OpenLDAPЕсли все основные настройки системы хранятся в LDAP, то вполне естественно хранить там же и учетные записи пользователей. Для этого желательно модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены):
Затем необходимо создать файл users.ldif со следующим содержимым:
Содержимое файла необходимо добавить в дерево LDAP командой:
После этого нужно установить pam_ldap и nss_ldap (apt-get install pam_ldap nss_ldap в ALT Linux) и отредактировать следующие файлы по образцу:
/etc/pam.d/system-auth-use_first_pass: см. пример Теперь созданные пользователи LDAP являются также системными пользователями: См. пример 2.1.6. Хранение в OpenLDAP произвольной справочной информацииВсе что в настоящее хранится в LDAP (как информация о хостах, так и о пользователях), тем или иным способом используется различными сервисами. Кроме этого, иногда бывает полезно хранить дополнительную информацию о хостах, которая будет представлять интерес только для системного администратора. Хранение такой дополнительной информации поддерживает схема info.schema:
Необходимо скопровать схему в каталог /etc/openldap/schema и модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены):
После перезапуска OpenLDAP (service ldap restart в ALT Linux) необходимо создать файл info.ldif Содержимое файла необходимо внести в дерево LDAP командой:
2.1.7. Результат сведения настроек в единое хранилищеПосле всех модификаций в окончательном варианте дерево LDAP выглядит так: См. листинг Главный скрипт, который заставляет все необходимые сервисы перечитать конфигурацию (/opt/scripts/make_all.sh), выглядит следующим образом:
Таким образом, первые две задачи - централизованное управление настройками рабочих станций и централизованное управление доступом в интернет - решены. Для внесения изменений в конфигурацию рабочей станции достаточно изменить запись о ней в дереве LDAP и выполнить скрипт /opt/scripts/make_all.sh 2.2. Подсистема учета трафикаВ качестве СУБД для подсистемы учета трафика был выбран Firebird Classic Server 1.5. Основная причина такого выбора заключалась в том, что сервер, на котором конфигурировалась подсистема управления настройками, имел очень скромную аппаратную конфигурацию. В то же время рядом стоял уже настроенный сервер БД, поэтому и было принято решение использовать его. Скрипты для обработки данных о трафике написаны на Perl, поэтому для их работы необходимо наличие в системе самого Perl'а и DBI-драйвера для Firebird, последняя версия которого доступна с http://dbi-interbase.sourceforge.net/. Пользователи ALT Linux вместо ручной установки драйвера могут подключить репозиторий nm и выполнить команду apt-get install perl-DBD-InterBase. Кроме того, необходимо наличие как минимум клиентской части Firebird. Существует 2 неправильных способа установить клиентскую часть Firebird: установить Firebird целиком (его последняя версия доступна на http://firebird.sourceforge.net/) или скопировать с машины, на которую он установлен, файл libfbclient.so.1.5.0 и создать ссылку libfbclient.so.1 -> libfbclient.so.1.5.0. Правильным способом была бы пересборка Firebird c учетом специфики ALT Linux (включая разбиение его на пакеты firebird-server-cs, firebird-server-ss, firebird-client, firebird-devel, firebird-doc), однако эту задачу я отложил до лучших времен. 2.2.1. Создание базы данныхДля создания базы данных на сервере Firebird необходимо создать следующий файл: metadata.sql В файл /opt/firebird/aliases.conf на сервере Firebird необходимо добавить строку:
Затем на сервере Firebird нужно выполнить команду:
2.2.2. Учет прокси-трафикаИсточником данных о трафике, проходящем через прокси-сервер Squid, является файл /var/log/squid/access.log. Формат файла описан в документации Squid. Существует множество готовых программ и скриптов для анализа содержимого access.log, доступных по какой-либо открытой лицензии. На основе одного из них (скрипта из пакета loganalyzer из ALT Linux) с минимальными изменениями был написан скрипт /opt/scripts/translate_squid.pl Для регулярной очистки файла access.log и загрузки его содежимого в базу данных можно использовать мехнизм logrotate. В этом случае файл /etc/logrotate.d/squid необходимо отредактировать следующим образом:
2.2.3. Учет NAT-трафикаДля учета NAT-трафика используется механизм ULOG. Работает он следующим образом: средствами IPTables для части пакетов может быть указана цель ULOG. Это означает, что копии пакетов (или только заголовки) из ядра отправляются в userspace, где их ждет специальный демон, умеющий их обрабатывать. В настоящее время существует 2 таких демона: ulogd и ulog-acctd. Ulog-acctd проще, компактнее и умеет группировать пакеты, поэтому он и был выбран как средство учета NAT-трафика. Последнюю версию ulog-acctd можно загрузить с http://alioth.debian.org/projects/pkg-ulog-acctd. Пользователи ALT Linux вместо ручной сборки могут подключить репозиторий nm и выполнить команду apt-get install ulog-acctd. После установки ulog-acctd необходимо отредактировать его конфигурационный файл /etc/ulog-acctd.conf:
Затем нужно запустить ulog-acctd (service ulog-acctd start в ALT Linux). Источником данных о трафике, проходящем через ulog-acctd, является файл /var/log/ulog-acctd/account.log. Для обработки данных о трафике на основе скрипта из пакета loganalyzer из ALT Linux был написан скрипт /opt/scripts/translate_ulog.pl Для регулярной очистки файла account.log и загрузки его содежимого в базу данных можно использовать мехнизм logrotate. В этом случае файл необходимо отредактировать следующим образом 2.3. Графический интерфейс системы администрированияДля адинистрирования системы можно использовать стандартные средства LDAP (от утилит, работающих в режиме командной строки, до графических клиентов: GQ - http://biot.com/gq/, JXplorer - http://pegacat.com/jxplorer/) и Firebird (от стандартного isql до IBExpert - http://ibexpert.com/). Однако все они обладают слишком широкой функциональностью, поэтому для управления созданной структурой была создана Network Console. Бинарный дистрибутив (для Linux и Windows) лежит здесь, а исходные коды - здесь. Network Console написана на Java, поэтому для исполнения она требует JRE, а для компиляции - JDK. И JDK, и JRE (как отдельно, так и в составе JDK) доступны на http://java.sun.com/j2se/1.4.2/download.html. 2.3.1. Описание графического интерфейса с точки зрения пользователяВ составе бинарного дистрибутива есть 3 стартовых скрипта:
При запуске Network Console необходимо указать параметры подключения к OpenLDAP и Firebird:
Кроме того, существуют еще 2 параметра подключения к OpenLDAP, которые можно изменить только в конфигурационном файле networkconsole.properties: См. пример Главное окно запущенной Network Console состоит из 3-х вкладок: 1. Управление пользователями OpenLDAP (теми, кто может модифицировать дерево LDAP, в том числе и с помощью Network Console) - версия для GTK2 2. Управление настройками хостов - версия для OpenMotif 3. Выполнение запросов к базе данных, в которой хранится информация о трафике - версия для Win32 Для первых двух вкладок возможно добавление, удаление и редактирование записей: См. рисунок Для всех вкладок возможен экспорт списка в XML с XSLT-трансформацией:
Для вкладки "Трафик" возможно использование готовых запросов, реализованных в виде хранимых процедур. Чтобы использовать эту возможность, необходимо на сервере Firebird создать файл procedures.sql со следующим содержимым. Затем на сервере Firebird нужно выполнить команду:
После этого в файле networkconsole.properties исправить ui.view.traffic.translate=false на ui.view.traffic.translate=true и перезапустить Network Console. На вкладке "Трафик" на панели инструментов нажать кнопку "Выбрать" и указать требуемый отчет:
Теперь в поле редактирования sql-запроса появится: -- Потребление proxy-трафика по хостам Этот запрос можно выполнить обычным образом, нажав кнопку "Обновить". Аналогичным образом можно создавать в базе данных любые отчеты в виде хранимых процедур, принимающих в качестве параметров даты начала и окончания перода, и их описаний в таблице TRANSLATION. Вносить изменения в Network Console для поддержки этих отчетов не требуется. 2.3.2. Реализация графического интерфейсаВ состав архива с исходными кодами Network Console включены все необходимы библиотеки, поэтому ничего, кроме стандартного JDK, для сборки не потребуется. Для сборки необходимо отредактировать файл build.sh (или build.bat) и выполнить его с параметром distrib-crossplatform. Для отрисовки графического интерфейса Network Console использует SWT/JFace вместо стандартной для Java библиотеки Swing. Основное отличие SWT/JFace от Swing - использование стандартных графических библиотек той операционной системы, под управлением которой исполняется приложение. Например, под Windows Network Console использует Win23 API, а под Linux - GTK2 или OpenMotif. Помимо увеличения производительности такой подход позволяет Network Console выглядеть стандартным образом в различных средах и использовать настройки внешнего вида той среды, в которой она работает. Отрицательная стророна такого подхода - использование механизма JNI для подключения графических библиотек и, как следствие, худшая переносимость по сравнению со Swing, который не использует никаких посторонних библиотек, а рисует виджеты собственными средствами. Приводить здесь листинг всех исходных кодов Network Console не имеет смысла, лучше ограничиться общим описанием пакетов и классов. Основным пакетом является networkconsole.datamodel. Диаграмма, на которой изображены классы и интерфейсы пакета и связи между ними, выглядит так. В пакете существуют 2 иерархии: потомки абстрактных классов Entry (предствляет запись, которая может храниться как в LDAP, так и в JDBC) и EntryList (представляет набор таких записей). Потомки LdapEntry имеет фиксированное число полей (для каждого поля определены методы set/get/describe), а количество полей JdbcEntry заранее не известно. Значения полей потомков LdapEntry можно модифицировать. Потомки EntryList умеют оповещать о своих изменениях с помощью интерфейса IEntryListAdapter. Примеры использования классов пакета networkconsole.datamodel можно найти в пакете networkconsole.tests. Следующие пакеты используют классы networkconsole.datamodel для решения своих задач:
Два последних пакета ориентированы на использование networkconsole.datamodel в десктопном приложении на основе SWT/JFace, но ничто не мешает создать аналогичные пакеты для использования классов networkconsole.datamodel в приложении с web-интерфейсом или интерфейсом на основе Swing. Пакет networkconsole.swt.extensions расширяет возможности SWT/JFace, добавляя поддержку еще одного провайдера - ITableColumnProvider - для управления колонками TableViewer. Наконец, в пакете networkconsole.ui находится основной код Network Console - диалоговое окно для ввода параметров подключения, главное окно приложения, вкладки, окно выбора готовых отчетов об использовании трафика. Такое разделение на пакеты/классы позволяет локализовать внесение изменений, не затрагивая те модули, для которых эти изменения не принципиальны. Например, чтобы добавить поддержку еще одного параметра для хоста, нужно исправить только класс LdapHostEntry и 2 фабрики из networkconsole.datamodel.persistance: LdapHostObjectFactory и LdapHostStateFactory, при этом основной код Network Console править не нужно. 3. ИтогиГлавное - не конкретные решения, а технология. Предложенные в статье решения применимы без изменений для довольно узкого круга задач. Но описанная технология в любом случае позволяет упростить администрирование небольших локальных сетей. Та же технология с некоторыми изменениями (фактически они сведутся к увеличению настроек, хранимых в LDAP, поддержке новых сервисов и, как следствие, к модификации Network Console) может быть использована для управления более крупными сетями. Приложение А. Подключение репозитория nm для пользователей ALT LinuxДля подключения репозитория nm необходимо вписать следующие строки в файл /etc/apt/sources.list: rpm ftp://ftp.atmsk.ru/pub/prokopiev/nm-repository i586 nm и выполнить команду apt-get update. Приложение Б. Ссылки1. http://ldapzone.spb.ru/ - единственный в рунете сайт, целиком посвященный использованию LDAP |