Централизованная схема управления сетью с использованием OpenLDAP
Централизованная схема управления сетью с использованием OpenLDAP: хранение настроек DHCP, DDNS, Squid, IPTables в OpenLDAP, использование Ulog-acctd, Squid, Firebird, Perl для учета трафика, административный клиент Network Console на Java
Документ распространяется в соответствии с условиями лицензии GNU Free Documentation License. Ни автор, ни распространители, ни любой другой контрибьютор данного документа, не несет никакой ответственности за физический, финансовый, моральный или любой другой ущерб, понесенный при выполнении рекомендаций данного документа.
- 1. Постановка задачи
- 2. Реализация
- 3. Итоги
- Приложение А. Подключение репозитория nm для пользователей ALT Linux
- Приложение Б. Ссылки
1. Постановка задачи
1.1. Список задач
Для небольшой локальной сети необходимо обеспечить:
- Централизованное управление сетевыми настройками рабочих станций (IP-адрес, DNS-имя, маска, адреса шлюза, DNS-сервера, WINS-сервера) на основании MAC-адреса
- Централизованное управление правами доступа в интернет и способом подключения (NAT, прокси, прозрачный прокси)
- Централизованный учет потребляемого трафика по всем возможным параметрам
- Простой пользователький интерфейс ко всему вышеперечисленному: сеть должен уметь обслуживать человек, имеющий минимальные познания в области системного администрирования.
1.2. Способы решения задач
Традиционно такого рода задачи решаются стандартными средствами открытых 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, так и тех, которые этого не умеют. Кроме того, в статье будут рассмотрены смежные вопросы, имеющие непосредственное отношение к построению централизованной системы управления сетью: учет трафика и написание кроссплатформенного графического интерфейса к системе управления сетью.
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,
dc=myprovider,dc=ru" -w "secret" -f dhcpd.ldif
и проверить, добавлены ли записи, командой:
ldapsearch -h 127.0.0.1 -LLL -b "dc=myserver,dc=myprovider,dc=ru" -D
"cn=manager,dc=myserver,dc=myprovider,dc=ru" -w "secret"
После этого нужно создать конфигурационный файл DHCP-сервера /etc/dhcpd.conf (или взять его из пакета dhcp):
ldap-server "localhost";
ldap-port 389;
ldap-username "cn=manager,dc=myserver,dc=myprovider,dc=ru";
ldap-password "secret";
ldap-base-dn "dc=myserver,dc=myprovider,dc=ru";
ldap-method static;
После запуска 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 следующим образом:
ldapmodify -h 127.0.0.1 -x -D
"cn=manager,dc=myserver,dc=myprovider,dc=ru" -w
"secret" -f dhcpd-ddns-add.ldif
После этого желательно проверить, правильно ли отредактирована главная запись DHCP-сервера: См. пример
Затем необходимо установить bind (apt-get install bind в ALT Linux) и включить в нем поддержку DDNS. Содержимое конфигурационных файлов и права доступа к ним приведены здесь (предполагаем, что bind выполняется в chroot - в ALT Linux так оно и есть):
WOfB3kj8IhJK4OZ5s3zHeQ== - это ключ, сгенерированный следующим образом:
dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATE
После выполнения этой команды создаются файлы 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 (добавленные строки выделены):
...
# Включение схемы для хранения настроек DHCP в LDAP
include /etc/openldap/schema/dhcp.schema
# Включение схемы для хранения
#
настроек Squid и IPTables
include /etc/openldap/schema/internet-access.schema
# pid-файл и файл с аргументами запуска
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
...
После перезапуска OpenLDAP (service ldap restart в ALT Linux) необходимо внести данные, соответствующие схеме, из файла internet-access.ldif
Добавить их можно командой:
ldapmodify -h 127.0.0.1 -x -D
"cn=manager,dc=myserver,dc=myprovider,dc=ru" -w
"secret" -f internet-access.ldif
Для извлечения списка хостов, у которых одно из свойств allowNat, allowProxy или forceProxy установлено в TRUE, можно использовать такой простой скрипт: /opt/scripts/make_ldap_filter.sh
Пример вызова скрипта:
# /opt/scripts/make_ldap_filter.sh allowProxy
192.168.1.11
Eго можно использовать в скрипте, генерирующем правила для IPTables:/opt/scripts/make_iptables.sh
Аналогичный скрипт для Squid (/opt/scripts/make_squid.sh) выглядит так:
#!/bin/sh
/opt/scripts/make_ldap_filter.sh allowProxy >
/etc/squid/allowed_hosts
При этом в конфигурационном файл Squid (/etc/squid/squid.conf) должно быть написано примерно следующее:
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Jabber_ports port 5222
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports !Jabber_ports
acl allowed_hosts src "/etc/squid/allowed_hosts"
http_access allow allowed_hosts
http_access allow localhost
http_access deny all
http_reply_access allow all
icp_access allow all
httpd_accel_host virtual
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
error_directory /usr/share/squid/errors/Russian-koi8-r
coredump_dir /var/spool/squid
visible_hostname myserver.myprovider.ru
2.1.5. Настройка авторизации в OpenLDAP
Если все основные настройки системы хранятся в LDAP, то вполне естественно хранить там же и учетные записи пользователей. Для этого желательно модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены):
...
# Индексы для ускорения поиска в дереве
index objectClass eq
#Индексы для DHCP
index dhcpHWAddress eq
index dhcpClassData eq
# Индексы для авторизации
index cn, uid, uidNumber, gidNumber eq
Затем необходимо создать файл users.ldif со следующим содержимым:
dn: cn=Users, dc=myserver, dc=myprovider, dc=ru
objectClass: top
dn: cn=ldapuser1, cn=Users, dc=myserver, dc=myprovider, dc=ru
objectClass: posixAccount
cn: LDAP User 1
uid: ldapuser1
uidNumber: 1001
gidNumber: 10
homeDirectory: /home/ldapuser1
loginShell: /bin/bash
dn: cn=ldapuser2, cn=Users, dc=myserver, dc=myprovider, dc=ru
objectClass: posixAccount
cn: LDAP User 2
uid: ldapuser2
uidNumber: 1002
gidNumber: 10
homeDirectory: /home/ldapuser2
loginShell: /bin/bash
Содержимое файла необходимо добавить в дерево LDAP командой:
ldapadd -h 127.0.0.1 -x -D
"cn=manager,dc=myserver,dc=myprovider,dc=ru" -w
"secret" -f users.ldif
После этого нужно установить pam_ldap и nss_ldap (apt-get install pam_ldap nss_ldap в ALT Linux) и отредактировать следующие файлы по образцу:
passwd: files ldap nisplus nis
shadow: tcb files ldap nisplus nis
group: files ldap nisplus nis
hosts: files nisplus nis dns
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
bootparams: nisplus [NOTFOUND=return] files
netgroup: nisplus
publickey: nisplus
automount: files nisplus
aliases: files nisplus
host 127.0.0.1
base dc=myserver,dc=myprovider,dc=ru
rootbinddn cn=manager,dc=myserver,dc=myprovider,dc=ru
/etc/ldap.secret:
secret
/etc/pam.d/system-auth: см. пример
/etc/pam.d/system-auth-use_first_pass: см. пример
Теперь созданные пользователи LDAP являются также системными пользователями: См. пример
2.1.6. Хранение в OpenLDAP произвольной справочной информации
Все что в настоящее хранится в LDAP (как информация о хостах, так и о пользователях), тем или иным способом используется различными сервисами. Кроме этого, иногда бывает полезно хранить дополнительную информацию о хостах, которая будет представлять интерес только для системного администратора. Хранение такой дополнительной информации поддерживает схема info.schema:
attributetype ( 1.1.2.1.2.1 NAME 'comment'
DESC 'Host comment'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
objectclass ( 1.1.2.2.1.2 NAME 'hostsInfo' SUP top STRUCTURAL
DESC 'Hosts additional info'
MAY ( comment ))
Необходимо скопровать схему в каталог /etc/openldap/schema и модифицировать файл /etc/openldap/slapd.conf (добавленные строки выделены):
# В дереве LDAP могут присутствовать только такие записи,
#
которые являются экземлярами классов,
описанных в схемах,
#
и удовлетворяют ограничениям этих классов
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
# Включение схемы для хранения настроек DHCP в LDAP
include /etc/openldap/schema/dhcp.schema
# Включение схемы для хранения настроек Squid и IPTables
include /etc/openldap/schema/internet-access.schema
# Включение схемы для хранения справочной
#
информации о хостах
include /etc/openldap/schema/info.schema
# pid-файл и файл с аргументами запуска
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
...
После перезапуска OpenLDAP (service ldap restart в ALT Linux) необходимо создать файл info.ldif
Содержимое файла необходимо внести в дерево LDAP командой:
ldapmodify -h 127.0.0.1 -x -D
"cn=manager,dc=myserver,dc=myprovider,dc=ru" -w
"secret" -f info.ldif
2.1.7. Результат сведения настроек в единое хранилище
После всех модификаций в окончательном варианте дерево LDAP выглядит так: См. листинг
Главный скрипт, который заставляет все необходимые сервисы перечитать конфигурацию (/opt/scripts/make_all.sh), выглядит следующим образом:
#!/bin/bash
echo "Apply DHCP settings ..."
service dhcpd restart
echo "Apply Firewall settings ..."
/opt/scripts/make_iptables.sh
service iptables save
echo "Apply Proxy settings ..."
/opt/scripts/make_squid.sh
service squid restart
Таким образом, первые две задачи - централизованное управление настройками рабочих станций и централизованное управление доступом в интернет - решены. Для внесения изменений в конфигурацию рабочей станции достаточно изменить запись о ней в дереве 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 необходимо добавить строку:
billing = /var/db/firebird/billing.fdb
Затем на сервере Firebird нужно выполнить команду:
/opt/firebird/bin/isql -i metadata.sql
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 необходимо отредактировать следующим образом:
/var/log/squid/access.log {
daily
rotate 7
copytruncate
compress
notifempty
missingok
prerotate
cd /opt/scripts
./translate_squid.pl < /var/log/squid/access.log
endscript
}
/var/log/squid/cache.log {
daily
rotate 7
copytruncate
compress
notifempty
missingok
}
/var/log/squid/store.log {
daily
rotate 7
copytruncate
compress
notifempty
missingok
# This script asks squid to rotate its logs on its own.
# Restarting squid is a long process and it is not worth
# doing it just to rotate logs
postrotate
/usr/sbin/squid -k rotate
endscript
}
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:
multicast groups=1
accounting file=/var/log/ulog-acctd/account.log
dump file=/var/log/ulog-acctd/dump
debug file=/var/log/ulog-acctd/debug.log
pid file=/var/run/ulog-acctd.pid
debug = syscall, misc, statistics, error, error-packet
accounting format="%t\t%p\t%s\t%S\t%d\t%D\t%P\t%b\t%i\t%o\t%f\n"
empty interface="none"
empty prefix="none"
flush=30
fdelay=0
Затем нужно запустить 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 стартовых скрипта:
| Скрипт | Назначение |
| networkconsole-linux-gtk2.sh | Скрипт для запуска Network Console в Linux с использованием GTK2 |
| networkconsole-linux-motif.sh | Скрипт для запуска Network Console в Linux с использованием OpenMotif |
| networkconsole-win32.bat | Скрипт для запуска Network Console в Windows |
При запуске 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 нужно выполнить команду:
/opt/firebird/bin/isql -i procedures.sql
После этого в файле networkconsole.properties исправить
ui.view.traffic.translate=false
на
ui.view.traffic.translate=true
и перезапустить Network Console.
На вкладке "Трафик" на панели инструментов нажать кнопку "Выбрать" и указать требуемый отчет:
Теперь в поле редактирования sql-запроса появится:
-- Потребление proxy-трафика по хостам
select * from proxy_traffic_by_hosts('11.04.2004','11.07.2004')
Этот запрос можно выполнить обычным образом, нажав кнопку "Обновить".
Аналогичным образом можно создавать в базе данных любые отчеты в виде хранимых процедур, принимающих в качестве параметров даты начала и окончания перода, и их описаний в таблице 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.persistance | Сохранение/извлечение потомков LdapEntry в/из LDAP посредством фабрик JNDI |
| networkconsole.datamodel.sax | Представление потомков LdapEntryList и JdbcEntryList в виде потока событий SAX для использования в JAXP |
| networkconsole.datamodel.swt.dialogs | Предоставление диалоговых окон для экспорта и редактирования потомков LdapEntryList и JdbcEntryList |
| networkconsole.datamodel.swt.providers | Предоставление провайдеров JFace отображения потомков LdapEntryList и JdbcEntryList в TableViewer |
Два последних пакета ориентированы на использование 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
rpm-src ftp://ftp.atmsk.ru/pub/prokopiev/nm-repository i586 nm
и выполнить команду apt-get update.
Приложение Б. Ссылки
1. http://ldapzone.spb.ru/ - единственный в рунете сайт, целиком посвященный использованию LDAP
2. http://www.altlinux.ru/, http://www.atmsk.ru/, http://www.linux-os.ru/ - сайты, на которых можно найти описание специфики дистрибутивов ALT Linux
3. http://www.eclipse.org/ - официальный сайт Java-платформы Eclipse, составной частью которой является SWT/JFace