• 1. Постановка задачи
  • 1.1. Список задач
  • 1.2. Способы решения задач
• 2. Реализация
  • 2.1. Подсистема управления настройками
    • 2.1.1. Первоначальная настройка OpenLDAP
    • 2.1.2. Настройка связки DHCP+LDAP
    • 2.1.3. Настройка DDNS
    • 2.1.4. Настройка Squid и IPTables
    • 2.1.5. Настройка авторизации в OpenLDAP
    • 2.1.6. Хранение в OpenLDAP произвольной справочной информации
    • 2.1.7. Результат сведения настроек в единое хранилище
  • 2.2. Подсистема учета трафика
    • 2.2.1. Создание базы данных
    • 2.2.2. Учет прокси-трафика
    • 2.2.3. Учет NAT-трафика
  • 2.3. Графический интерфейс системы администрирования
    • 2.3.1. Описание графического интерфейса с точки зрения пользователя
    • 2.3.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) и отредактировать следующие файлы по образцу:

/etc/nsswitch.conf:

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

/etc/ldap.conf:

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