Поиск по этому блогу

среда, 20 января 2010 г.

Удалённый доступ Linux-to-Linux, или ...

Удалённый доступ Linux-to-Linux, или Просто об SSH и VNC.



Когда пришлось решать проблему удалённого доступа между правильными ОС,
встал вполне логичный вопрос о том, как это осуществить. В голову сразу
пришёл протокол SSH, о
котором уже как-то читал, но не решался попробовать в действии, т.к.
полагал что всё будет нудно и сложно, да и вообще мне это было не
нужно. На самом деле, в простейшем случае, это совсем не так. Итак,
если у вас и на обоих ПК установлен дистрибутив Ubuntu Linux, то
получить графический доступ к рабочему столу, но по протоколу VNC, можно вообще в пару кликов мыши.

VNC

     Для
этого сначала на удалённом ПК зайдите в "Система -> Параметры ->
Удалённый рабочий стол" или в терминале выполните (сразу условимся: "$"
перед командой - достаточно прав пользователя, а "#" означает, что
нужны привилегии рута):

$ vino-preferences

После этого откроется окно настроек.
     Итак,
для предоставления доступа нужно отметить пункт "Позволять другим
пользователям видеть ваш рабочий стол". На этом можно и остановиться,
но посмотрим, что предложили нам в дополнительных настройках. Здесь
можно обратить внимание на разделы "Безопасность" вкладки "Общие" и
"Уведомления" вкладки "Дополнительно". Можно вообще отключить
какое-либо уведомление о подключении, убрав отметки пунктов в разделе
"Безопасность", а в "Уведомления" отметив "Никогда не показывать
значок". В принципе, настройки не нуждаются в комментариях, всё
элементарно. После произведения настроек жмём "Закрыть". Так же
необходимо убедиться, что открыты порты диапазона 5000-5006. Всё, ПК
готов к соединению.
     Теперь, когда настройки удалённого ПК завершены, перейдём к осуществлению подключения. Для этого уже на рабочем ПК наберём:

$ vncviewer 111.111.111.111:0

Где
"111.111.111.111" - IP удалённого ПК, а "0" (нуль) после двоеточия -
номер дисплея удалённого ПК. Всё. Если в настройках не были указаны
подтверждение или ввод пароля, то сразу откроется окно, в котором и
будет отображён рабочий стол удалённого ПК. Можно пользоваться не
только управлением мышью, но и клавиатурой. Хочу отметить, что если
запустить вот так:

$ vncviewer FullScreen=1 111.111.111.111:0

то
рабочий стол будет отображён в полноэкранном режиме, а не в окне. Если
вы захотите выйти из полноэкранного режима, то нажмите F8 и уберите
соответствующую галочку. Так же здесь имеются дополнительные настройки
соединения в меню "Settings", которые так же доступны в виде свойств
при запуске vncviewer (в терминале: $ vncviewer --help).
     Данный
метод есть смысл использовать только в случае достаточно быстрого
Интернет-соединения и на десктоп-ориентированных ПК с X Window System.
А так как сам по себе этот протокол всё-таки не отличается особой
безопасностью, то работать с ПК, содержащим важные данные, не
рекомендуется. В случае работы с важными данными гораздо лучше
запускать VNC-сессию через SSH-тоннель. Но это не входит в данный
обзор, поэтому пока ограничимся шифрованным доступом к командной
оболочки удалённого ПК.

SSH

     С
помощью SSH всё не так красочно, но зато быстро и надёжно. Используя
SSH можно без проблем организовать надёжный и шифрованный канал между
двумя машинами. Приступим.
     Для начала необходимо убедится, что на удалённом ПК работает SSH-сервер:

$ ps -ax|grep sshd

Должна появится строка вроде "5437 ? Ss 0:00 /usr/sbin/sshd". Если это не так, то запускаем

# /etc/init.d/ssh start

или устанавливаем его (демон запустится автоматически):

# apt-get install openssh-server

Убедитесь, что порт 22 для TCP-соединений не закрыт. С удалённой машиной всё :)
     Теперь переходим к поднятию соединения. Убедитесь, что у вас установлен SSH-клиент:

$ aptitude search openssh-client

В начале строки должна стоять буква "i". Если это не так, то:

# apt-get install openssh-client


     Осуществлять
аутентификацию будем по двум ключам - приватному (шифрованный) и
публичному. Это просто и удобно, лучше чем по паролю на удалённом ПК.
Для этого нужно сначала создать эти два ключа:

$ ssh-keygen

Будет
задана как минимум пара вопросов. Место расположения ключа оставьте по
умолчанию, т.е. на первый вопрос просто нажмите Ввод, а вот потом
введите ключевую фразу и в следующем шаге подтвердите ввод. Фраза
должна быть более 4-х байт, но лучше с запасом. 6-8 символов вполне
подойдут. После этого скопируем публичный ключ на тот самый удалённый
ПК через Сеть (трафик шифруется):

$ ssh-copy-id user@ip

Где
"user" - название учётной записи пользователя удалённого ПК, от имени
которого вы будете работать, а "ip" - IP того ПК. После установления
соединения ответьте "yes" на подтверждение передачи публичного ключа
через интернет, а потом введите пароль этого аккуанта. Всё, ключ
скопирован на удалённый ПК. С этого момента вы сможете заходить на него
без ввода пароля пользователя, а лишь вводя свою ключевую фразу для
расшифровки своего же (приватного) ключа. Делается это очень просто:

$ ssh user@ip

Таким
образом, если вы будет работать под чьим-то аккуантом, то его владелец
сможет сменить пароль после передачи ключа, а вы этого даже не заметите.
     Итак,
после подключения у вас в терминале/консоли будет выведено
информационное сообщение, а строка приглашения изменится на
user@server, где "server" - уже имя удалённой машины.

Устанавливаем и настраиваем систему м...

Устанавливаем и настраиваем систему мониторинга сети OpenNMS (opennms monitoring)

1. Cайт OpenNMS - http://www.opennms.org.
2. Документация OpenNMS - http://www.opennms.org/index.php/Docu-overview




Когда количество активного оборудования и серверов в сети неуклонно
растет, а контролировать работоспособность и качество предоставляемых
сервисов становится все сложнее, на помощь приходит система
мониторинга сети OpenNMS.

Кратко о системе мониторинга OpenNMS

OpenNMS - система мониторинга сетевой инфраструктуры уровня
предприятия, распространяемая по модели свободного программного
обеспечения (Open Source). Кроме обычной для Open Source-проектов
поддержки сообществом пользователей, производитель предоставляет
многоуровневое коммерческое сопровождение продукта: от внедрения до
обеспечения технической поддержки 24х7 и обучения персонала.

Данная система реализована на Java, поэтому появляется такое
положительное качество, как кроссплатформенность.

Поддерживаются ОС:

* Linux:
* Debian Etch и Lenny (x86 и x86_64);
* Red Hat Enterprise Linux/CentOS (3, 4 и 5; x86 и x86_64);
* Fedora Core (версии с 2 по 8, x86 и x86_64);
* Mandriva 2007 и 2008;
* SuSE (9 и 10).
* Solaris 8, 9, и 10 (SPARC и x86);
* Mac OS X (10.4+, PowerPC и x86);
* Windows 2000, XP, 2003 (Vista и Server 2008 не тестировались).


Теоретически OpenNMS может запуститься на любой платформе,
поддерживающей Java SDK 1.4 и выше. Также к положительным качествам
можно отнести модульность системы и возможность развертывания частей
системы на раздельных серверах (СУБД, демоны сбора статистики и
веб-интерфейс могут быть разнесены). Конечно, можно добавить и ложку
дегтя: за Java-реализацию, обеспечившую кроссплатформенность, пришлось
заплатить увеличением потребления ресурсов.

Система OpenNMS отвечает за мониторинг функционирующих в сетевой
инфраструктуре сервисов, таких как Web, DNS, DHCP, сервисы СУБД
(Oracle, MSSQL, PostgreSQL и др.), однако информация о состоянии
сетевых устройств также доступна.

В системе упрощены способы добавления новых сетевых устройств для
мониторинга, и общий принцип работы основан на автоматическом
обнаружении (discovery) сетевых устройств. Обнаружение состоит из двух
частей - определение интерфейсов (IP-адресов) и определение
функционирующих на этих интерфейсах сервисов. Определение интерфейсов
осуществляется на основе протокола ICMP (Ping), а определение сервисов
- с помощью сборщиков (collectors). На данный момент существует
несколько сборщиков, но далее мы подробно рассмотрим сбор статистики,
основанный на протоколе SNMP.

Основной единицей мониторинга системы является интерфейс (interface),
который уникально определяется на основе IP-адреса. Сервисы (services)
привязаны к интерфейсам, а интерфейсы, расположенные на одном
устройстве, группируются в узел (node).

Что ж, давайте не будем упускать шанс оценить качество системы и
удобство работы с ней самостоятельно, не полагаясь на рекламные
строчки и чужие мнения. Приступим к установке.


Установка в дистрибутиве Fedora 8 Linux

Перед началом установки хотелось бы предупредить вас о некоторых
тонкостях. Во-первых, для текущей версии OpenNMS 1.5.90 сервер
PostgreSQL ветки 8.3.Х не поддерживается, так что устанавливать
будем сервер ветки 8.2. Во-вторых, начиная с версии OpenNMS 1.3.6 в
составе дистрибутива отсутствует библиотека jicmp, которую необходимо
будет загрузить отдельно.

Также для работы системы нам понадобится JDK. Уточню, что
необходима именно версия JDK (Java Developer Kit), а не JRE (Java
Runtime Environment), так как веб-интерфейс написан на Java/JSP, а для
компиляции JSP в сервлет необходим компилятор Java, который
отсутствует в JRE.

Установка JDK

Java Development Kit (JDK) можно скачать с сайта компании Sun либо
установить с помощью yum из репозитория Tigro.

Если данный репозиторий у вас не подключен, то можно установить его
через RPM-менеджер:

rpm -ihv http://mirror.yandex.ru/fedora/tigro/8/i386/tigro-release-8-1.i386.rpm


После установки репозитория можно воспользоваться yum:

yum install jdk


Хочу упомянуть об одном неприятном моменте: после установки JDK в
Fedora 8 необходимо выполнить ряд дополнительных шагов, чтобы
заставить работать виртуальную машину. Дело в том, что при попытке
запуска любого Java-приложения выдается ошибка следующего вида:

java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed


Проблема всем давно известная (попробуйте поискать в Google строку с
ошибкой) и решается в Fedora 8 следующим образом:

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/java/jdk1.6.0_05/jre/lib/i386/xawt/libmawt.so


Возможно, ваш путь к файлу libmawt.so будет отличаться от приведенного
выше.

Установка PostgreSQL

Если у вас еще не установлен PostgreSQL [4], то установим с помошью
yum:

yum install postgresql-server


Теперь выполним начальную инициализацию:

/sbin/service postgresql initdb


Далее необходимо задать базовые настройки сервера. Для этого нужно
отредактировать файлы pg_hba.conf и postgresql.conf, находящиеся в
/var/lib/pgsql/dat.

Правим файл pg_hba.conf:

local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust


Файл postgresql.conf:

listen_addresses = 'localhost'


Еще раз напомню, что это тестовая установка и конфигурационные файлы
очень упрощены, проблемы безопасности полностью игнорируются и доступ
к серверу БД никак не защищен.

Запускаем сервер:

/sbin/service postgresql start


и переходим к следующему шагу.


Установка OpenNMS

Есть несколько веток программы для установки: stable, development и
nightly snapshot, причем разработчикам рекомендуется использовать
ветку development. На момент написания статьи была доступна версия
1.5.90.

Для установки можно скачать установочный jar-файл, но проще будет
установить дополнительный репозиторий OpenNMS для yum:

rpm -Uvh http://yum.opennms.org/repofiles/opennms-repo-unstable-fc8.noarch.rpm


Данной командой мы установили репозиторий yum для development-ветки
OpenNMS. Теперь необходимо установить пакет opennms с помошью yum:

yum install opennms


Дополнительно необходимо установить пакеты jrrd (опционально вместо
rrd), jicmp и iplike:

yum install jrrd
yum install jicmp
yum install iplike


По умолчанию устанавливается веб-интерфейс opennms-webapp-jetty для
встроенного в OpenNMS контейнера сервлетов Jetty, но есть также версия
веб-интерфейса для Tomcat и называется opennms-webapp-standalone.

После успешной установки необходимо запустить скрипт поиска
установленной виртуальной машины Java:

cd /opt/opennms/bin
./runjava -s


Если по какой-то причине скрипт отработает некорректно (например, вы
установили JDK по нестандартному пути), либо у вас установлено
несколько разных JDK и вы хотите указать скрипту конкретную, то можно
задать явный путь:

./runjava -S /usr/java/jdk1.6.0_5/bin/java


Теперь можно запускать скрипт начальной конфигурации:

./install -dis


Итак, если мы ничего не упустили, то скрипт отработает без ошибок.
После завершения установочного скрипта не забываем посмотреть, все ли
прошло хорошо:

- searching for jicmp:
- trying to load /usr/lib/libjicmp.so: OK
- searching for jrrd:
- trying to load /usr/lib/libjrrd.so: OK
- checking database version... 8.2


Должны быть найдены библиотеки jicmp и jrrd. Если что-то пошло не так,
то можно явно задать пути поиска:

./install -disU -l /usr/lib/jni:/usr/lib


Также не забываем, что если мы устанавливаем базу данных OpenNMS на
свежую инсталляцию СУБД PostgreSQL, то пароль пользователя postgres
пока пустой. Если же у вас уже был установлен сервер PostgreSQL, то
вам могут понадобиться опциональные аргументы для скрипта инсталляции:

-A,--admin-password <arg>
// Пароль администратора сервера postgres (по умолчанию: '')

-a,--admin-username <arg>
// Имя администратора сервера postgres (по умолчанию: 'postgres')

-c,--clean-database
// Очистить существующую базу при создании

-D,--database-url <arg>
// JDBC УРЛ базы данных (по умолчанию: jdbc:postgresql://localhost:5432/)

-P,--database-name <arg>
// Имя базы данных PostgreSQL (по умолчанию: opennms)

-p,--password <arg>
// Пароль для базы данных opennms (по умолчанию: 'opennms')

-u,--username <arg>
// Имя пользователя БД opennms (по умолчанию: 'opennms')


Список всех возможных атрибутов можно просмотреть, набрав:

./install -help


После успешной начальной установки и конфигурации можно запускать
OpenNMS:

./opennms start


Теперь набираем в браузере строку http://127.0.0.1:8980/opennms/ и
вводим имя пользователя "admin" и пароль "admin".


Установка в Windows XP

Установка для Windows не должна вызвать каких-либо затруднений и
сводится к запуску файла opennms-installer-1.5.90.jar и следованию
указаниям графического установщика, поэтому подробно описывать процесс
не имеет смысла. Перед установкой необходимо предварительно
инсталлировать JDK не ниже 5 версии и PostgreSQL ветки 8.2 (8.3 не
поддерживается). Также отдельно устанавливается библиотека jicmp,
и путь к ней должен содержаться в переменной окружения PATH.


Описание сетевой инфраструктуры для мониторинга

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


Рисунок 1. Общая схема сети организации с удаленными офисами


Пусть адресное пространство корпоративной сети будет задано следующим
образом:

* 10.10.10.0/24 - адресное пространство головного офиса, выделенное
для серверов, маршрутизаторов, коммутаторов, сетевых принтеров и т.
п.;


* 10.10.11.0/24 - адресное пространство головного офиса для рабочих
станций пользователей;


* 10.10.12.0/24 - адресное пространство офиса No.1;


* 10.10.13.0/24 - адресное пространство офиса No.2;


* 10.10.14.0/24 - адресное пространство офиса No.3.


Наша сеть состоит из достаточного количества маршрутизаторов (например
Cisco 2800 серии в головном офисе и маршрутизаторов попроще - Cisco
серий 2600, 1800 и т. п.). На маршрутизаторах настроены SNMP-агенты
различных версий, включая третью. Кроме того, имеются также серверы,
среди которых терминальные, серверы баз данных, почтовые и т. п., на
многих из которых также установлены SNMP-агенты (например, с помощью
Net-SNMP).


Настройка диапазонов сетевого обнаружения (Discovery)

Параметры обнаружения устройств описываются в файле
discovery-cofiguration.xml. Уточню, что все конфигурационные файлы
хранятся в каталоге openNMS-install-path\etc, где openNMS-install-path
- путь установки OpenNMS. Ниже представлен пример файла
discovery-cofiguration.xml для нашего варианта сетевой инфраструктуры:

<discovery-configuration threads="1" packets-per-second="1"
initial-sleep-time="30000"
restart-sleep-time="86400000"
retries="3" timeout="800">

<include-range retries="2" timeout="1500">
<begin>10.10.10.1</begin>
<end>10.10.14.254</end>
</include-range>
<exclude-range>
<begin>10.10.11.1</begin>
<end>10.10.11.254</end>
</exclude-range>
<specific>10.10.11.1</specific>
<include-url>file:/opt/OpenNMS/etc/moreip.txt</include-url>
</discovery-configuration>


Согласно приведенному файлу, будет осуществляться опрос (посылаться
ICMP ping) диапазона адресов 10.10.10.0/24, 10.10.12.0/24,
10.10.13.0/24 и 10.10.14.0/24, а также одиночного IP-адреса 10.10.11.1
и списка IP-адресов, указанных в файле /opt/OpenNMS/etc/moreip.txt.

Опишем некоторые глобальные атрибуты по умолчанию, задаваемые в теге
<discovery-configuration>:

* threads - количество потоков для опроса.


* packets-per-second - количество генерируемых ICMP-пакетов в
секунду. Не стоит указывать слишком большое число, если задержки в
вашей сети велики.


* initial-sleep-time - время перед стартом процесса обнаружения (в
миллисекундах, значение по умолчанию - 5 минут). Задержка необходима
для полного старта системы, перед тем как начнут генерироваться
события (events).


* restart-sleep-time - время после окончания процесса обнаружения,
через которое процесс будет повторно запущен (в миллисекундах,
значение по умолчанию - 24 часа).


* timeout - время ожидания ответа от обнаруживаемого IP-адреса.


* retries - количество попыток обнаружения, если с первой попытки
ничего не обнаружено.



Глобальные атрибуты можно переопределить внутри вложенных в тег
<discovery-configuration> тегов.

* Тег <specific> - указывает определенный IP-адрес, включенных в
процесс обнаружения.


* Тег <include-range> - указывает диапазон IP-адресов, включенных в
процесс обнаружения.


* Тег <exclude-range> - указывает диапазон IP-адресов, исключенных из
процесса обнаружения.


* Тег <include-url> - определяет файл со списком включенных в процесс
обнаружения IP-адресов, один IP-адрес в каждой строке.


Все вложенные теги необязательны, но возможно также их множественное
добавление. Так, можно задать несколько диапазонов с помощью
<include-range>, определить несколько тегов <specific> и
<include-url>.

Итак, при запуске системы OpenNMS по истечении времени
initial-sleep-time запускается процесс обнаружения интерфейсов. Если
получен ответ на ICMP-запрос, то для обнаруженного интерфейса
регистрируется событие (event) newSuspect, на основе которого в
дальнейшем будет осуществлена попытка обнаружения сервисов,
функционирующих на данном интерфейсе. А что делать, если ICMP-запросы
блокируются сетевым экраном? Для таких случаев существует
альтернативный метод для регистрации событий newSuspect. В подкаталоге
bin установленной системы openNMS находится Perl-скрипт send-event.pl,
который можно использовать для самостоятельной регистрации данного
события:

/opt/opennms/bin/send-event.pl --interface ip-address uei.opennms.org/internal/discovery/newSuspect


где "ip-address" - нужный IP-адрес.

Посмотреть на ход процесса обнаружения можно, заглянув в файл
discovery.log, находящийся в подкаталоге logs установленной системы
openNMS.


Настройка процесса обнаружения сервисов (Capabilities daemon)

После того как зарегистрированы события newSuspect для обнаруженных
интерфейсов, приходит время работы демона capsd (capabilities daemon).
Его задачей является распознавание всех функционирующих на интерфейсе
сервисов. Рассмотрим пример конфигурационного файла
capsd-configuration.xml. Конфигурация файла позволяет очень гибко
управлять ходом процесса обнаружения сервисов. В первых строчках
определяются глобальные параметры функционирования сервиса:

<capsd-configuration rescan-frequency="86400000"
initial-sleep-time="300000"
management-policy="managed"
max-suspect-thread-pool-size="6"
max-rescan-thread-pool-size="3"
abort-protocol-scans-if-no-route="false">


где:

* rescan-frequency - время, через которое происходит повторное
сканирование интерфейса на предмет обнаружения сервисов.


* initial-sleep-time - время задержки после запуска openNMS перед
началом сканирования сервисов.


* management-policy - контролирует процесс сканирования сервисов.


Если установлен в "managed" - то все события newSuspect будут
обработаны, если же параметр установлен в значение "unmanaged", то
все события newSuspect будут проигнорированы, и сканирование не
произойдет. Параметр можно переопределить в теге
<protocol-configuration>, о котором будет рассказано дальше.

* max-suspect-thread-pool-size - количество одновременных потоков
сканирования при первоначальном обходе адресов. Увеличение значения
ускоряет сканирование ценой потребляемых ресурсов.


* max-rescan-thread-pool-size - количество создаваемых потоков на
интерфейсах с уже обнаруженными сервисами при повторном сканировании.


* abort-protocol-scans-if-no-route - если параметр выставлен в
"false", то попытки сканирования сервисов при получении сообщения
"no route to host" продолжатся, так как это сообщение может быть в
некоторых случаях вызвано наличием межсетевого экрана. Если параметр
примет значение "true", то сканирование интерфейса будет
остановлено.


Далее в конфигурационном файле идет описание сервисов (protocols).
Определение сервисов основано на установлении TCP-подключения на
определенный порт, но есть также специальные классы для некоторых
сервисов. Список сервисов, поддерживаемых "из коробки" можно
просмотреть в конфигурационном файле (возможно также добавление
дополнительных сервисов с помощью тега <protocol-plugin>).

При обработке события newEvent, в случае, если IP-адрес определен как
"managed" демон capsd начинает сканирование сервисов в порядке их
следования в конфигурационном файле. Первым в конфигурационном файле
указан протокол ICMP:

<protocol-plugin protocol="ICMP"
class-name="org.opennms.netmgt.capsd.IcmpPlugin"
scan="on" user-defined="false">
<property key="timeout" value="2000"/>
<property key="retry" value="2"/>
</protocol-plugin>


Описание каждого сервиса заключено внутри тега <protocol-plugin>.
Данный тег содержит следующие атрибуты:

* protocol - название сервиса;


* class-name - определяет класс, который будет использоваться для
сканирования сервиса;


* scan - признак включения сканирования данного сервиса ("on" -
сканирование сервиса включено, "off" - сервис не будет
сканироваться);


* user-defined - добавление новых сервисов возможно через
веб-интерфейс. В таком случае атрибут примет значение "true".


В каждом сервисе можно указывать дополнительные параметры,
определяемые через значения key и value внутри тега <property>. Кроме
того, применительно к каждому сервису можно применять дополнительный
тег <protocol-configuration>, в котором можно описывать группы
IP-адресов, исключенные (или включенные) из сканирования. Например:

<protocol-plugin protocol="SNMP"
class-name="org.opennms.netmgt.capsd.plugins.SnmpPlugin" scan="on"
user-defined="false">

<protocol-configuration scan="off" user-defined="false">
<range begin="10.10.12.1" end="10.10.14.254"/>
<property key="timeout" value="4000"/>
<property key="retry" value="3"/>
</protocol-configuration>
<protocol-configuration scan="on" user-defined="false">
<specific>10.10.11.1</specific>
</protocol-configuration>

<property key="timeout" value="2000" />
<property key="retry" value="1" />
</protocol-plugin>


В приведенном выше примере мы переопределили группу адресов
(10.10.12.1 -10.10.14.254), для которых определение сервиса SNMP будет
отключено, и добавили адрес 10.10.11.1, для которого наличие сервиса
будет определяться. Также можно переопределить общие для всех
настройки обнаружения, заданные в головном теге <capsd-configuration>
с помощью тега <ip-management>:

<ip-management policy="managed">
<range begin="10.10.10.1" end="10.10.14.254"/>
<include-url>file:/opt/OpenNMS/etc/include</include-url>
</ip-management>


где значение атрибута policy может принимать значение "managed" и
"unmanaged".

Данные настройки действуют на все указанные в capsd-configuration
сервисы, если только диапазон адресов для какого-либо сервиса (в нашем
случае - SNMP) не переопределен c помощью тега
<protocol-configuration>.

Необходимо заметить, что если в процессе обнаружения (discovery)
интерфейс по каким-то причинам не был определен, и не было
зарегистрировано событие newSuspect, демон capsd для такого интерфейса
не будет запущен, даже если указать IP-адрес в файле конфигурации
capsd явно.


Настройка периодичности опросов (polling)

После сбора информации об узлах, интерфейсах и функционирующих на них
сервисах приходит время мониторинга. Информация о состоянии сервисов,
интерфейсов и узлов собирается двумя основными способами.

Первый способ основан на периодических опросах (polling).
Процессы-мониторы подключаются к ресурсу и производят простой тест,
чтобы определить текущее состояние ресурса. Если ресурс недоступен -
генерируется определенное событие.

Настройка периодичности опросов описывается в файле
poller-configuration.xml. Для удобства введено понятие пакета
(package) сервисов. В файле можно описать несколько пакетов, в каждом
из которых можно указать собственную периодичность опросов, а также
определить уникальное подмножество опрашиваемых сервисов. Кроме того,
в каждом пакете можно задавать собственную модель действий при
недоступности сервиса. Период опроса в случае недоступности сервиса
меняется динамически и может гибко настраиваться. Также для каждого
пакета можно задать время простоя, когда не будет производиться опрос
сервисов. Глобально периоды простоя для всех пакетов можно задать в
файле poll-outages.xml.

Данные опросов собираются с помощью библиотеки jrrd - Java-реализации
всем известной RRD (Round Robin Database).

Рассмотрим файл poller-configuration.xml:

<poller-configuration threads="30"
serviceUnresponsiveEnabled="false"
nextOutageId="SELECT nextval('outageNxtId')" xmlrpc="false">
<node-outage status="on" pollAllIfNoCriticalServiceDefined="true">
<critical-service name="ICMP" />
</node-outage>


Параметр threads определяет максимальное количество потоков для
опроса. Варьируется в зависимости от количества опрашиваемых устройств
и мощности сервера. Будьте внимательны с данным параметром, при
большом количестве опрашиваемых устройств может потребоваться
увеличить количество потоков для опроса, так как демон может не успеть
опросить все устройства в течение заданного времени. Узнать, успевает
ли демон опросить все устройства и сервисы, можно, заглянув в файл
logs/daemon/poller.log. В файле нужно найти строку, содержащую
максимальное значение параметра alive:

2008-05-15 17:01:16,201 DEBUG [PollerScheduler-40 Pool]
RunnableConsumerThreadPool$SizingFifoQueue:
adjust: started fiber PollerScheduler-40 Pool-fiber21
ratio = 1.0476191, alive = 21


Если значение параметра alive+1 (так как есть еще родительский поток)
близко к значению параметра threads, то есть смысл увеличить
количество потоков опроса.

Параметр serviceUnresponsiveEnabled определяет, какое событие будет
генерироваться в случае кратковременного сбоя - "выход из строя"
(outage) или только "сервис не отвечает" (unresponsive).

Чтобы не генерировать событие "выход из строя" при кратковременной
недоступности, нужно выставить этот параметр в "true".

Тег <node-outage> определяет поведение в случае недоступности всех
интерфейсов на узле.

Если во время опроса какой-либо сервис на интерфейсе не отвечает,
генерируется событие NodeLostService, если все сервисы на интерфейсе
не отвечают, то генерируется событие InterfaceDown. Если параметру
status присвоено значение "on", то в случае недоступности всех
интерфейсов узла не генерируется множество событий NodeLostService и
InterfaceDown, а лишь одно событие - NodeDown. Во время недоступности
узла, в случае, если с помощью тега <critical-service> определен
критический сервис (в нашем случае ICMP), будет опрашиваться только
критический сервис. После того как критический сервис будет
восстановлен, начнут опрашиваться все остальные сервисы. Если тег
<critical-service> не задан, то опрос всех сервисов определяется
параметром pollAllIfNoCriticalServiceDefined. Если данное свойство
имеет значение "false", то будет опрашиваться только первый сервис в
пакете, иначе - все. Для удобства создадим на основе уже готового
пакета exmaple1 пакет ICMP-PKG и поместим туда единственный сервис
ICMP, так как хотим опрашивать устройства по данному протоколу чаще,
чем, например, собирать статистику по SNMP:


<package name="ICMP-PKG">
<filter>IPADDR != '0.0.0.0'</filter>
<include-range begin="1.1.1.1" end="254.254.254.254" />
<rrd step="60">
<rra>RRA:AVERAGE:0.5:1:89280</rra>
<rra>RRA:AVERAGE:0.5:60:8784</rra>
<rra>RRA:AVERAGE:0.5:1440:366</rra>
<rra>RRA:MAX:0.5:1440:366</rra>
<rra>RRA:MIN:0.5:1440:366</rra>
</rrd>
<service name="ICMP" interval="30000"
user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="3000" />
<parameter key="rrd-repository"
value="D:/PROGRA~1/OpenNMS/share/rrd/response" />
<parameter key="rrd-base-name" value="icmp" />
<parameter key="ds-name" value="icmp" />
</service>
<downtime interval="20000" begin="0" end="300000"/>
<!-- 20s, 0, 5m -->
<downtime interval="120000" begin="300000" end="3600000"/>
<!-- 2m, 5m, 1h -->
<downtime interval="300000" begin="3600000" end="432000000"/>
<!-- 5m, 1h, 5d -->
<downtime begin="432000000" delete="true" />
<!-- anything after 5 days delete -->
</package>




Обратите внимание на тег <filter>. Внутри пакета он может быть задан в
единственном числе. В теге можно задать фильтрацию IP-адресов по
маскам. Например, так: <filter>IPADDR = '10.*.*.*'</filter> - будут
опрашиваться лишь адреса 10.0.0.0/8. Также можно задавать диапазоны
адресов с помощью уже известного тега <include-range>, внутри которого
задан диапазон IP-адресов для опроса. Напомню, что опрашиваться будут
лишь сервисы на интерфейсах, найденных в процессе обнаружения. То есть
сервисов на интерфейсе может быть найдено множество, однако сбор
статистики будет происходить лишь по сервисам, указанным в пакетах
файла poller-configuration. Внутри пакета с помощью тега <service>
может быть определено несколько сервисов (в нашем пакете только сервис
ICMP). Рассмотрим атрибуты и вложенные теги тега <service>:

Атрибут status может принимать значения "on" - статистика собирается
и "off" - сбор статистики отключен.

В тегах <parameter> с помощью атрибутов key и value задаются
дополнительные параметры, среди которых следует обратить внимание на
параметр rrd-repository, в котором задается путь для хранения данных
опросов. Учтите, что этот параметр связан с параметром rrd.base.dir в
файле opennms.properties. Не забывайте об этом, если будете переносить
конфигурационные файлы с сервера на сервер.

В тегах <downtime> описывается поведение опроса сервиса в случае его
недоступности:

* Атрибут interval - задает периодичность опроса при недоступности;


* Атрибут begin - время начала заданного периода опроса
миллисекундах;


* Атрибут end - время с окончания заданного периода опроса в
миллисекундах.


То есть в строке:

interval="20000" begin="0" end="300000"/>


указано, что в случае недоступности сервиса производить опрос каждые
20 секунд, начиная с нулевой секунды и по достижении 5 минут времени
недоступности. Начиная с пяти минут недоступности сервиса можно
увеличить интервал опроса до 2 минут, таким образом уменьшив нагрузку
на вычислительные ресурсы:

<downtime interval="120000" begin="300000" end="3600000"/>


а после недоступности сервиса в течение часа увеличить интервал опроса
еще больше.

Тег <rrd>, в котором задаются параметры сбора и хранения данных,
заслуживает более пристального изучения и будет рассмотрен позже.

Второй способ сбора статистики основан на коллекторах (collectors). Он
немного сложнее в настройке, но может дать больше информации.
Существует возможность использования нескольких коллекторов, мы
остановимся подробнее на сборе статистики с помощью опросов
SNMP-агентов.


Настройка сбора статистики по протоколу SNMP

При настройках по умолчанию в OpenNMS 1.5.90 для сбора статистики на
основе коллекторов используется протокол SNMP версии 1 и 2(с). Однако
существует также возможность использовать протокол SNMP-версии 3. Для
активации возможности сбора информации по SNMPv3 необходимо
использовать библиотеку SNMP4J [1], поддерживающую протокол SNMPv3 (по
умолчанию используется библиотека JoeSNMP). Однако для большинства
случаев достаточно SNMPv1 и SNMPv2. Для активации SNMPv3 необходимо
раскомментировать строчку:

org.opennms.snmp.strategyClass=org.opennms.netmgt.snmp.snmp4j.Snmp4JStrategy


в файле opennms.properties и поставить символ комментария перед
строчкой с JoeSNMP.

Теперь следует возвратиться к файлу capsd-configuration.xml и добавить
для удобства новый сервис с названием SNMPv3 (название может быть
любым, удобным вам). В будущем это поможет отличать узлы с
обнаруженными SNMP-агентами разных версий:

<protocol-plugin protocol="SNMPv3"
class-name="org.opennms.netmgt.capsd.SnmpPlugin"
scan="on" user-defined="false">
<property key="force version" value="SNMPv3"/>
<property key="timeout" value="2000"/>
<property key="retry" value="3"/>
</protocol-plugin>


Также необходимо добавить сервис с таким же именем в файл
poller-configuration.xml, если этого не сделать, сервис определится,
но опрашиваться не будет. Здесь есть одна тонкость - если не указывать
конкретную версию протокола и вообще исключить строчку <property
key="force version" value="SNMPv3"/> (как это сделано в конфигурации
по умолчанию), то будут найдены SNMP-агенты версий, указанных в файле
snmp-config.xml.

При сканировании сервиса SNMP демон capsd обращается за дополнительной
информацией в файл snmp-config.xml:

<?xml version="1.0"?>
<snmp-config port="161" retry="3" timeout="1500"
read-community="public" write-community="private">
<definition version="v3" security-name="myname"
auth-protocol="MD5" auth-passphrase="yourmd5pass">
<specific>10.10.10.1</specific>
<specific>10.10.11.1</specific>
</definition>
<definition version="v1" read-community="charoday">
<specific>10.10.14.1</specific>
</definition>
</snmp-config>


В файле находится дополнительная информация для опроса SNMP-агентов.

Корневой тег файла называется <snmp-config> и содержит следующие
атрибуты:

* port - порт, через который идет обращение к SNMP-агенту;
* retry - количество попыток подключения к SNMP-агенту;
* timeout - время ожидания ответа от агента;
* read-community - строка для доступа на чтение к SNMP-агенту;
* write-community - строка для доступа на запись к SNMP-агенту;
* version - версия SNMP-протокола.


Можно переопределить атрибуты, указанные в корневом теге, описав
внутри него тег <definition>. В нашем случае в первом вложенном теге
<definition> мы переопределили версию протокола SNMP. Внутри этого
тега также можно определять диапазоны IP-адресов с помощью тегов
<include-range>, <specific> и <exclude-range>.

Для определения протокола SNMPv3 существуют дополнительные атрибуты:

* security-name - имя для аутентификации;


* auth-protocol - протокол шифрования пароля аутентификации (SHA или MD5);


* auth-passphrase - пароль аутентификации (шифруется MD5 или SHA);


* privacy-protocol - протокол шифрования данных (DES);


* privacy-passphrase - пароль шифрования данных.


Протокол SNMPv3 поддерживает три типа аутентификации: noAuthNoPriv,
authNoPriv и authPriv.

Если указать все атрибуты - получим тип authPriv (самый защищенный
тип: шифруются данные авторизации и все передаваемые данные).

Если не указывать атрибуты privacy-protocol и privacy-passphrase, то
получим тип authNoPriv, когда в защищенном виде передаются лишь
аутентификационные данные, остальные данные не шифруются.

Если указать только атрибут security-name, то получим самый
незащищенный тип noAuthNoPriv.

Подробнее о модели безопасности SNMPv3 (User-Based Security Model -
USM и VACM - View-based Access-Control Model) можно найти в RFC3414 и
RFC3415.

Обратите внимание, что библиотека SNMP4J [8] ревностно относится к
соблюдению стандартов, согласно которым auth-passphrase должен быть не
менее 8 символов, то же касается и privacy-passphrase. Поэтому не
советую испытывать судьбу коротким паролем. Подробнее о настройке
SNMPv3 на оборудовании фирмы Cisco можно узнать из [9].

Что дальше?

После осуществления всех приведенных выше настроек можно запустить
openNMS:

./opennms start


или для Windows:

opennms.bat start


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



Рисунок 2. Главная страница веб-интерфейса

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



Что ж, вопросы с установкой решены (см. No.5 за 2008 г.), и система
openNMS работает. Как же теперь сделать ее более функциональной, а
работу с ней более удобной? Запасаемся временем и терпением, не
забываем подключить к работе голову и руки - и вперед!


Возможности веб-интерфейса

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

Рисунок 1. Главная страница веб-интерфейса

В верхней части интерфейса расположено основное навигационное меню, с
помощью которого можно просмотреть список всех проверяемых узлов (меню
"Node List"), либо с помощью поискового интерфейса (меню "Search")
найти конкретное устройство по различным критериям поиска: IP-адресу,
наименованию, предоставляемому сервису и др.

Каждому узлу можно сопоставить дополнительную инвентарную информацию и
затем просматривать ее через меню "Assets" (имущество). Путем
несложной навигации можно узнать подробную статистику о текущих и
исправленных отказах (меню "Outages") устройств и сервисов, об
авариях (меню "Alarms"), а также обо всех событиях (меню "Events"),
зарегистрированных системой.

В меню "Reports" (отчеты) можно просмотреть отчеты о доступности и
графики, полученные при опросах устройств. Это могут быть и основанные
на ICMP-запросах RoundTrip Ping и StrafePing (статистика по потерянным
пакетам), и графики, основанные на данных, собранных с помощью SNMP.
Имеется возможность составлять собственные отчеты (Custom Reports),
основанные на собранных данных.

В меню "Surveillance" (слежение) можно сгруппировать информацию об
узлах сети по определенным признакам в виде таблицы. Можно, например,
категоризировать устройства по территориальной принадлежности и типу
оборудования. По умолчанию ни один узел не принадлежит какой-либо
категории, добавление узла в категорию можно произвести через
администраторский интерфейс (меню "Admin").

В меню "DashBoard" (панель инструментов) на основе категоризации из
меню "Surveillance" собрана дополнительная информация о состоянии
устройств, такая, как текущие аварии, состояние об отказах устройства
за последние 24 часа и статистические графики.

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


Группировка узлов по определенным признакам с помощью таблиц слежения

Визуальное представление многих данных мониторинга, просматриваемых
через веб-интерфейс, можно изменять в некоторых пределах. Одна из
удобных функций заключается в возможности группировки узлов сети по
различным признакам в виде таблицы слежения. В меню "Surveillance"
(слежение) уже задано разбиение на категории по умолчанию (см. рис. 2),
однако сетевые устройства пока не привязаны к существующим категориям
слежения.

Рисунок 2. Вид меню "Surveillance" после установки системы

Добавить устройство в необходимую категорию по определенным признакам
можно через меню "Admin -> Manage Surveillance Categories" (см. рис.
3).

Рисунок 3. Добавление узлов в категории по определенным признакам

В строках и столбцах таблицы слежения определяются признаки наблюдаемых
устройств, а в местах пересечения конкретной строки и столбца
отображается количество узлов, удовлетворяющих этим признакам. Можно
создать необходимое количество собственных категорий слежения, на
основе которых в дальнейшем построить собственную таблицу (таких таблиц
может быть несколько). Для создания таблицы слежения или модификации
существующей необходимо отредактировать конфигурационный файл
surveillance-views.xml:


<?xml version="1.0" encoding="utf-8"?>
<surveillance-view-configuration
xmlns:this="http://www.opennms.org/xsd/config/surveillance-views"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opennms.org/xsd/config/surveillance-views
http://www.opennms.org/xsd/config/surveillance-views.xsd"
default-view="by Priority and Office" >
<views >
<view name="default" refresh-seconds="300" >
<rows>
<row-def row="1" label="Main Office" >
<category name="MainOffice"/>
</row-def>
<row-def row="2" label="Filial 1" >
<category name="Filial-1" />
</row-def>
<row-def row="3" label="Filial 2" >
<category name="Filial-2" />
</row-def>
<row-def row="4" label="Filial 3" >
<category name="Filial-3" />
</row-def>
</rows>
<columns>
<column-def col="1" label="Routers" >
<category name="Routers" />
</column-def>
<column-def col="2" label="Servers" >
<category name="Servers" />
</column-def>
<column-def col="3" label="Switches" >
<category name="Switches" />
</column-def>
</columns>
</view>

<view name="by Priority and Office" refresh-seconds="300" >
<rows>
<row-def row="1" label="Main Office" >
<category name="MainOffice"/>
</row-def>
<row-def row="2" label="Filial 1" >
<category name="Filial-1" />
</row-def>
<row-def row="3" label="Filial 2" >
<category name="Filial-2" />
</row-def>
<row-def row="3" label="Filial 3" >
<category name="Filial-3" />
</row-def>
</rows>
<columns>
<column-def col="1" label="High Priority" >
<category name="HighPriority" />
</column-def>
<column-def col="2" label="Mid Priority" >
<category name="MidPriority" />
</column-def>
<column-def col="3" label="Low Priority" >
<category name="LowPriority" />
</column-def>
</columns>
</view>
</views>
</surveillance-view-configuration>




В тег <views> вложен тег <view>, в котором описываются строки и столбцы
таблицы категорий. В параметре name тега <view> задается название
таблицы категорий. В теге <rows> описываются строки таблицы с помощью
вложенных тегов <row-def>, а в теге <columns> с помощью <column-def>
описываются столбцы. В тегах <row-def> и <column-def>, которые являются
строками и столбцами таблицы категорий, описываются категории узлов с
помощью тегов <category>. Данные в тегах <category> должны
соответствовать данным, заполненным через меню "Admin -> Manage
Surveillance Categories" (данные хранятся в таблице categories базы
данных PostgreSQL), иначе при попытке перейти в меню "Surveillance"
мы получим ошибку.

В приведенном выше примере описаны два разных разбиения на категории -
"default" и "by Priority and Office" (см. рис. 4), однако вы можете
создать таблицы слежения по вашим потребностям.

Рисунок 4. Вид меню "Surveillance" после настройки таблицы категорий

В корневом теге <surveillance-view-configuration> в параметре
default-view можно задать отображаемую по умолчанию таблицу слежения (в
приведенном выше конфигурационном файле этому параметру присвоено имя
таблицы "by Priority and Office", которая будет отображаться при
переходе в меню "Surveillance" и "DashBoard" (см. рис. 5).

Рисунок 5. Меню "DashBoard" после настройки таблицы категорий

Настройка уведомлений

В openNMS существует возможность использовать систему уведомлений,
чтобы оповещать пользователей о происходящих событиях. Основным методом
уведомлений является отправка e-mail-сообщений пользователю, но
существует и ряд других методов, например, отправка POST/GET-запросов
на веб-сервер, отправка уведомлений по протоколу XMPP (jabber),
пересылка уведомлений посредством запуска внешней программы (подобным
образом можно отправить SMS-сообщение с помощью GSM-модема) и
уведомления с помощью формирования SNMP traps.

Мы рассмотрим классический способ с отправкой уведомлений на
электронную почту, для чего нам понадобится внести необходимые
настройки в следующие конфигурационные файлы:

* javamail-configuration.properties - в файле содержатся настройки
почтового сервера и учетной записи (почтового ящика);


* destinationPaths.xml - в файле описывается, кто получает
уведомления;


* notifd-configuration.xml - здесь описываются глобальные настройки
службы уведомлений;


* notificationCommands.xml - в файле описываются методы уведомления,
такие, как e-mail-оповещения, XMPP и др.;


* notification.xml - здесь содержится описание уведомлений.


Будем использовать тип доставки javaEmail (уведомления на электронную
почту) для оповещения о происходящих в системе событиях. Для этого
изменим настройки файла javamail-configuration.properties, чтобы
отправлять сообщения через ящик на сервере Google Mail, например
(однако это может быть и ваш корпоративный почтовый сервер):

org.opennms.core.utils.useJMTA=false
org.opennms.core.utils.transport=smtps
org.opennms.core.utils.mailHost=smtp.gmail.com
org.opennms.core.utils.smtpport=465
org.opennms.core.utils.authenticate=true
org.opennms.core.utils.authenticateUser=user@gmail.com
org.opennms.core.utils.authenticatePassword=userpass
org.opennms.core.utils.starttls.enable=true
org.opennms.core.utils.smtpssl.enable=true
org.opennms.core.utils.messageContentType=text/html
org.opennms.core.utils.charset=windows-1251


Google Mail использует SMTP over SSL (TLSv1 и SSLv3), поэтому параметр
org.opennms.core.utils.smtpssl.enable выставлен в true, в качестве
транспорта (org.opennms.core.utils.transport) используется SMTPS, а
порт для подключения (org.opennms.core.utils.smtpport) используется
стандартный для SMTPS - 465. В более простых случаях, когда
используется обычный SMTP-протокол без шифрования, необходимо будет
заменить номер порта на 25, транспорт - на smtp и параметры
smtpssl.enable и starttls.enable=true выставить в false.

В файле destinationPaths.xml содержится информация об адресах доставки
уведомлений:

<?xml version="1.0" encoding="UTF-8"?>
<destinationPaths xmlns=
"http://xmlns.opennms.org/xsd/destinationPaths">
<ns1:header xmlns:ns1="http://xmlns.opennms.org/xsd/types">
<rev xmlns="">1.2</rev>
<created xmlns="">10 Июнь 2008 г. 4:43:30 GMT</created>
<mstation xmlns="">localhost</mstation>
</ns1:header>
<path name="Email-Admin" initial-delay="0s">
<target interval="0s">
<name xmlns="">Admin</name>
<command xmlns="">javaEmail</command>
</target>
</path>
</destinationPaths>


Атрибут name тега <path> определяет имя блока адреса доставки. Значение
данного атрибута также используется в файле notifications.xml в
качестве адреса доставки при описании конкретного вида уведомлений.
Внутри каждого тега <path> можно описать несколько вложенных тегов
<target>, в которых с помощью тега <name> можно описать адресатов,
которым будут посылаться уведомления, а также способ доставки (в нашем
случае javaEmail) с помощью тега <command>. В качестве адресата может
выступать как отдельный пользователь, так и группа или роль. Добавить
учетную запись пользователя, группы и роли можно через веб-интерфейс
(меню "Admin -> Configure Users, Groups and Roles") или через
конфигурационные файлы users.xml (пользователи) и groups.xml (группы и
роли).

Для обеспечения более гибкой отправки уведомлений в файле
destinationPaths.xml можно описать несколько дополнительных тегов
<path>:

<path name="Email-Filial1" initial-delay="0s">
<target interval="0m">
<name xmlns="">Filial1</name>
<autoNotify xmlns="">auto</autoNotify>
<command xmlns="">javaEmail</command>
</target>
</path>


В приведенном выше коде создается путь для отправки уведомлений на
адрес абонента Filial1. Конечно, учетная запись пользователя (или
группы, роли) Filial1 должна быть предварительно создана, в таком
случае уведомления будут отправляться, например, одному или нескольким
сотрудникам филиала No.1. Эти сотрудники будут получать почтовые
сообщения в случае проблем с сетевыми устройствами или сервисами.

Настройки уведомлений задаются в файле notifications.xml. По умолчанию
здесь уже заданы стандартные типы уведомлений, которые отправляются на
адрес доставки Email-Admin (то есть всем пользователям группы Admin).
Теперь добавим собственное уведомление, которое будет отправляться по
адресу доставки Email-Filial1:

<notification name="Filial1-nodeDown" status="on" writeable="yes">
<uei xmlns="">uei.opennms.org/nodes/nodeDown</uei>
<rule xmlns="">IPADDR IPLIKE 10.10.12.*</rule>
<destinationPath xmlns="">Email-Filial1</destinationPath>
<text-message xmlns="">
All services are down on node %nodelabel%.
</text-message>
<subject xmlns="">Node %nodelabel% down.</subject>
<numeric-message xmlns="">111-%noticeid%</numeric-message>
</notification>


Описанное уведомление будет отправлено по адресу Email-Filial1 (см.
файл destinationPaths.xml) при возникновении события nodeDown (<uei
xmlns=""> uei.opennms.org/nodes/nodeDown </uei>), когда недоступны
узлы, принадлежащие сети 10.10.12.0/24 (см. правило <rule
xmlns="">IPADDR IPLIKE 10.10.12.*</rule>).

Аналогичным образом можно добавить уведомления, отправляемые другим
адресатам при возникновении различных событий.

Тюнинг сбора и отображения SNMP-статистики

Настройки сбора информации, получаемой по протоколу SNMP, описываются в
файле data-collection-config.xml. Данные собираются путем посылки
GET-запросов, содержащих определенный OID (Object IDentificator),
устройству, поддерживающему протокол SNMP. В ответ возвращаются
некоторые значения, которые сохраняются затем в RRD-файлах (RoundRobin
Database (RRD) - это проект, выросший из известного проекта MRTG.
Проект оказался довольно удачным и в настоящее время используется не
только в оpenNMS, но и во многих других системах мониторинга).

В файле data-collection-config.xml уже содержится информация по OID
(Object ID) из MIB (Management Information Base) наиболее
распространенных устройств (как аппаратных, например Cisco Pix, так и
программных - Asterisk), поддерживающих протокол SNMP.

OID описываются внутри тега <mibObj>:

<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />


В свою очередь, для обеспечения более удобного дальнейшего
использования OID группируются с помощью тега <group>, например:

<group name="my-mib2-interfaces" ifType="all">
<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />
</group>


Если параметру ifType тега <group> присвоено значение "all", как в
примере выше, это значит, что данные в группе имеют табличную природу,
и тогда параметр instance тега <mibObj> принимает последовательные
значения (в нашем случае ifIndex, содержащий индексы имеющихся в
системе интерфейсов). Случай с нетабличными данными проще. Параметр
ifType тега <group> принимает значение "ignore", а параметр instance
тега <mibObj> принимает значение "0".

Различные типы SNMP-устройств описываются в тегах <systemDef>. Для
каждого типа устройств определена одна или несколько OID-групп, на
основе которых для устройства и его интерфейсов в rrd-файлы будет
собираться статистика:

<systemDef name="Cisco Routers">
<sysoidMask>.1.3.6.1.4.1.9.1.</sysoidMask>
<collect>
<includeGroup>cisco-memory</includeGroup>
<includeGroup>cisco-router</includeGroup>
<includeGroup>cisco-temperature</includeGroup>
<includeGroup>cisco-voltage</includeGroup>
<includeGroup>cisco-router-interface</includeGroup>
<includeGroup>mib2-interfaces</includeGroup>
<includeGroup>adsl-line</includeGroup>
</collect>
</systemDef>


При обнаружении на устройстве службы SNMP система OpenNMS пытается
определить тип устройства, посылая GET-запрос с OID=1.3.6.1.2.1.1.2.0.
Полученный ответ сравнивается со значением тега <sysoidMask>,
вложенного в тег <systemDef>.

Например, для многочисленного семейства маршрутизаторов фирмы Cisco
этот ответ будет содержать подстроку .1.3.6.1.4.1.9.1. На основании
такого ответа SNMP-сборщик будет собирать информацию, посылая
GET-запросы с OID, описанными в конфигурации для данного типа
оборудования.

В случае наличия специфичного оборудования можно создать дополнительные
группы OID, а также определить с помощью тега <systemDef> новый тип
оборудования, в который и вложить необходимые OID-группы. Обычно с
таким специфичным оборудованием распространяются и дополнительные
MIB-базы. Для ускорения импортирования данных OID из таких MIB-файлов в
состав дистрибутива openNMS включена утилита mib2opennms, с помощью
которой можно преобразовать данные из MIB-файла в набор тегов <mibObj>,
которые используются в файле data-collection-config.xml.

Давайте теперь рассмотрим, как записываются и хранятся в RRD-файлах
собранные по протоколу SNMP данные. Периодичность сбора данных, а также
продолжительность их хранения описывается в теге <rrd>:

<rrd step="60">
<rra>RRA:AVERAGE:0.5:1:263520</rra>
<rra>RRA:AVERAGE:0.5:60:8784</rra>
<rra>RRA:AVERAGE:0.5:1440:366</rra>
<rra>RRA:MAX:0.5:1440:366</rra>
<rra>RRA:MIN:0.5:1440:366</rra>
</rrd>


Параметр step тега <rrd> определяет шаг хранения информации в
rrd-файлах. Вложенный тег <rrа> состоит из следующих атрибутов:

RRA:Cf:xff:steps:rows


где:

* RRA - однозначно определяет строку как конфигурационную команду.


* cf - тип объединения данных, принимает значения AVERAGE, MAX, MIN
или LAST.


* xff - при объединении собранных значений в одно может случиться, что
некоторые значения не определены (например, какое-то время узел был
недоступен). Данный параметр определяет минимальный процент
неопределенных данных, при котором все собранные за период данные
становятся неопределенными. По умолчанию это 50% (0,5).


* steps - означает коэффициент групировки собранных данных, например:


* 1 - данные сохраняются на каждом шаге (то есть ежеминутноо, в случае,
step=60);


* 60 - данные группируются за 60 периодов и затем сохраняются(то есть
интервал сохранения - 1 час).


* rows - определяет количество сохраняемых значений. Цифра 263520
означает, что данные, в случае ежеминутной группировки будут храниться
около полугода (188 дней).


Собранная в RRD-файлах информация может быть представлена в виде
графиков. Настройка графиков на основе собранных по SNMP данных
производится в файле snmp-graph.properties. В качестве значений секции
reports через запятую перечислены все доступные графики. При
первоначальной установке OpenNMS их уже достаточно внушительное
количество. После перечисления всех графиков находится полная
информация по каждому из графиков. Чтобы лучше понять принцип
построения графиков, можно добавить график состояния интерфейса во
времени, принимающий значение "0" в случае "падения" интерфейса и
"1" - в случае его нормального функционирования. Для этого вернемся
снова к файлу data-collection-config.xml, в который необходимо добавить
соответствующий OID =.1.3.6.1.2.1.2.2.1.8, например, в группу
mib2-interfaces:

<group name="mib2-interfaces" ifType="all">
<mibObj oid=".1.3.6.1.2.1.2.2.1.8" instance="ifIndex"
alias="ifOperStatus" type="integer" />
<mibObj oid=".1.3.6.1.2.1.2.2.1.10" instance="ifIndex"
alias="ifInOctets" type="counter" />
<mibObj oid=".1.3.6.1.2.1.2.2.1.16" instance="ifIndex"
alias="ifOutOctets" type="counter" />
.... другие oid
</group>


Теперь для тех SNMP-устройств (точнее, для их интерфейсов, так как это
данные уровня интерфейса, а не узла), в описании которых указана данная
OID-группа, будет собираться статистика по состоянию интерфейса. Однако
в графическом виде информацию о состоянии интерфейсов посмотреть пока
не получится. Для просмотра графиков на основе rrd-данных необходимо
будет внести соответствующие дополнения в конфигурационный файл
snmp-graph.properties. Добавим строку mib2.opstat в секцию reports
файла snmp-graph.properties. Теперь добавим следующие строки ниже
секции report:

report.mib2.opstat.name=Interface Operational Status
report.mib2.opstat.columns=ifOperStatus
report.mib2.opstat.type=interfaceSnmp
report.mib2.opstat.command=--title="Interface Operational Status" \
--lower-limit 0 --upper-limit 2 --rigid \
--vertical-label="Up(1)|Down (0)" \
--width 400 \
--height 100 \
DEF:opst={rrd1}:ifOperStatus:AVERAGE \
CDEF:copst=2,opst,- \
LINE2:copst#00ff00:"OperStatus" \
GPRINT:copst:AVERAGE:"Status (0 - down 1 - up) \\: %2.0lf %s" \


В данных строках мы описали внешний вид графика, на котором будут
отображаться данные о состоянии интерфейса (ноль на графике - интерфейс
"опущен", а единица - интерфейс функционирует нормально)

В строке "report.mib2.opstat.columns=ifOperStatus" описываются
данные, на основе которых строится график.

Значение interfaceSnmp параметра report.mib2.opstat.type означает, что
график создается для интерфейсов узла (возможен тип nodeSNMP - то есть
для всего узла, а не его интерфейсов).

В строке "DEF:opst={rrd1}:ifOperStatus:AVERAGE \" дается определение
opst - переменной, на основе средних значений (AVERAGE) которой будет
строиться график.

В строке "CDEF:copst=2,opst,- \" дано определение производной
переменной copst, значение которой есть функция 2-opst. Функцию ввели
для того, чтобы отображаемый график выглядел более привычно (в
диапазоне значений от 0 до 1), так как возвращаемые значения для
"поднятого" интерфейса - 1, в противном случае - 2. Функция 2 - opst
решает данную проблему.

В строке "LINE2:copst#00ff00:"OperStatus" \" описывается вид графика,
его цвет и название графика.

Строка "GPRINT:copst:AVERAGE:"Status (0 - down 1 - up) \\: %2.0lf %s"
\", как видно из названия, ответственна за рисование графика на основе
переменной copst.

В строках height и width задаются размеры графика.

После внесения данной информации в конфигурацию openNMS мы можем
просматривать на графике историю изменения оперативного состояния
интерфейса (см. рис. 6).

Рисунок 6. График изменения состояния (Up/Down) интерфейса во времени

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

Заключение

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

Система оказалась очень гибкой и функциональной, хотя для настройки
некоторых дополнительных функций и пришлось затратить некоторое
количество усилий. В качестве несомненных плюсов также можно назвать и
активность разработчиков проекта, с каждой новой версией добавляющих
новые функции и исправляющих выявленные ошибки. За время, прошедшее
после выхода первой статьи, было выпущено три обновления продукта,
последнее из которых (версия 1.5.93 на момент написания статьи) было
посвящено только работе над ошибками. Также на официальном сайте есть
внятная документация, хотя, возможно, она не совсем оптимально
структурирована. А после выхода статьи появилась возможность почитать о
системе и на русском.

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

Приложение

Проблема с кириллицей

Данная информация, возможно, уже потеряла актуальность в связи с
выходом исправлений в новой версии 1.5.93. Дело в том, что в процессе
работы с веб-интерфейсом в версии 1.5.90 обнаружилась одна неприятная
проблема с отображением кириллицы. Для ее решения пришлось немного
модифицировать некоторые *.jsp-файлы веб-интерфейса (в сервлетах такой
проблемы не наблюдалось). Принцип модификации заключался в добавлении в
JSP-страницу строки java-кода с указанием используемой кодировки UTF8:

<%response.setCharacterEncoding("UTF-8");%>


То есть все данные, передаваемые сервером браузеру, должны отправляться
в кодировке UTF8.

Возможно, существовало более элегантное решение проблемы отображения
кириллицы, но на тот момент я его не нашел, поэтому до исправления
данной ошибки воспользовался описанным выше способом. В последней
версии (на момент написания статьи - 1.5.93) проблема с кириллицей
полностью исправлена, что не может не радовать.





Network Security Toolkit поможет адми...

 







Network Security Toolkit поможет администраторам сети



Network Security Toolkit - это один из многих дистрибутивов Linux типа
Live CD, направленных на анализ безопасности сети. NST дает
администраторам простой доступ к широкому множеству открытых сетевых
приложений, многие из которых включены в сотню лучших средств безопасности, рекомендованных сайтом insecure.org.


Последняя версия NST - 1.8.0 была выпущена в июне. Предыдущие версии
NST были основаны на Fedora Core 5, а эта новая версия - на Fedora 8,
используется ядро Linux 2.6.25.6-27.fc8 с окружением рабочего стола
Fluxbox. Можно скачать NST с авторского сайта - либо как ISO-образ Live CD, либо виртуальную машину VMware.


При загрузке с Live CD вам будет предложено несколько вариантов
загрузки, для различных аппаратных возможностей или требуемых служб.
Вариант по умолчанию - "desktop/laptop", включающий все утилиты NST,
поддержку USB и консоль. Во всех вариантах требуется наличие
работающего DHCP-сервера, иначе придется ввести параметры сети вручную.
Процесс загрузки занимает минуту или две, и по соображениям
безопасности перед первым попаданием в командную строку необходимо
ввести новый пароль root. Здесь пользователь уже может запустить
Fluxbox с помощью простой команды startx.


Можно установить NST и на жесткий диск,
однако этот процесс не так прост. В больших организациях совершенно
необходимо постоянно следить за сетевой активностью и безопасностью,
поэтому установить NST на жесткий диск будет чрезвычайно полезно.

Виртуальная машина NST дает вам удобную возможность попробовать
дистрибутив на мощной машине. Единственным недостатком такого подхода
является ограничения в использовании беспроводных сетевых карт, ведь
VMware считает беспроводной адаптер за обычную Ethernet-карту
виртуальной машины.

Что у него внутри?


Пусть непритязательный внешний вид Fluxbox не сбивает вас с толку.
Хотя интерфейс легкий и простой, но из него доступно множество мощных
сетевых средств. Из средств защиты от сетевых вторжений можно упомянуть
Kismet, Snort, AirSnort, NMAP и Wireshark. Nessus - популярный сканер
уязвимостей, которому не было уделено внимания в последнем
BackTrack-релизе (BT3), на сей раз включен в дистрибутив. Помогут вам
следить за состоянием сети такие программы как Nagios, Argus и Zabbix.
В дополнение к этим административным средствам, дистрибутив включает в
себя еще и пользовательские программы - почтовый клиент (Pooka), клиент
мгновенного обмена сообщениями (Pidgin), веб-браузер (Firefox),
средства обработки текстов и графики (ImageMagick, XPDF, Nedit и
другие), антивирус (ClamAV), терминальные коммуникации (GTKterm,
Minicom), удаленный рабочий стол (VNC, TSClient) и средства
восстановления данных (cfdisk, Partition Image). Я был удивлен,
обнаружив в составе дистрибутива свободную программу для GPS-навигации
GPSDrive. Еще включены СУБД MySQL и PostgreSQL, а если вам нужен
почтовый сервер - к вашим услугам Sendmail.





Меню Fluxbox в NST

Для запуска программ, включенных в NST, можно пользоваться либо
веб-интерфейсом (Web user interface, WUI), основанном на AJAX и JSON,
либо выбирать их из меню Fluxbox. Если вы знаете, чего ищете, просто
нажмите правой кнопкой мышки на рабочем столе - появится меню Fluxbox
со всеми программами, разделенными по категориям. К примеру, все
графические средства проверки уязвимостей системы можно найти в подменю
Security Applications, а общие средства для работы с сетью (такие как Wireshark) расположены в Network Applications.
Можно упрекнуть разработчиков меню NST Fluxbox в том, что некоторые
программы присутствуют одновременно в разных категориях; к примеру,
приложение ATerm находится в подменю NST WUI и Desktop Applications.





Пользовательский интерфейс


Если программа не обладает графическим интерфейсом или требует консоли
для своей настройки, NST упрощает работу с ней посредством помещения ее
в WUI. Можно выбрать как упрощенный WUI, в котором программы
сгруппированы в соответствии с решаемой задачей (сниффинг, мониторинг
или проверка на вторжения); так и из категоризированного списка.

WUI упрощает использование программ. При выборе программы или
задачи вам будет показана страница, на которой нужно выбрать
определенный скрипт - для настройки или выполнения операции. Если нужно
изменить настройки, это можно легко сделать, отредактировав
конфигурационные файлы программы или введя параметры команды. На
странице каждой программы также есть ее описание и краткая
документация.

Попробуем NST


После беглого осмотра всех программ, я установил NST на отдельный
компьютер и ввел его в нашу офисную сеть. Был задействован
неиспользуемый относительно слабый компьютер - сервер Dell PowerEdge
2500 с процессором Pentium III 1GHz, 768 Мб ОЗУ, тремя сетевыми картами
10/100 и двумя жесткими дисками по 18 Гб.

Сначала я указал первоначальные настройки (такие как IP-адрес)
и включил службы SSH, HTTPS и VNC. Одна из основных особенностей
дистрибутива - веб-интерфейс WUI, и я решил попробовать его в действии,
а именно настроил ntop и Zabbix для проверки сетевого трафика и
слежения за состоянием некоторых серверов.


Настроить ntop очень просто. Всего лишь выберите категорию Network в NST WUI. В подкатегории Monitor
будет располагаться ntop. Нажатие на ntop откроет его конфигурационную
страницу. Выберите интересующую вас сетевую карту, введите другие опции
ntop (годятся настройки по умолчанию) и нажмите на кнопку Start,
чтобы включить ntop. В дополнение ко всему WUI показывает команду, с
помощью которой ntop был включен. Вернитесь на предыдущую страницу и
нажмите "Use ntop interface (HTTPS)", чтобы войти на страницу ntop. На
странице ntop вы увидите сетевой трафик, различные его типы (TCP, UDP,
ARP и т.д.), источник трафика и другую информацию. Итак, можно следить
за трафиком за три щелчка мышки.

Настройка Zabbix, проверяющего состояние хостов в сети, требует
большего количества шагов. Хост в сети может быть сервером или сетевым
устройством. Агент, который можно скачать с сайта Zabbix,
должен быть установлен на каждом исследуемом хосте. Из той же
подкатегории что и ntop, выберите Zabbix Server Management для входа на
его конфигурационную страничку. Перед запуском Zabbix необходимо
включить службы mysqld и ntpd, это можно сделать,
нажав на соответствующих кнопках. После этого просто запустите службу
Zabbix, отправляйтесь на страницу Zabbix, ищите и добавляйте хосты и
можно проводить мониторинг сети.

Можно бегло проверить безопасность своей сети с помощью Snort,
расположенного в WUI в меню Security. Выберите нужный сетевой
интерфейс; я выбрал тот, на котором работает файрволл, ведь большинство
атак и вторжений производятся из интернета. Когда я взглянул на отчеты
Acid (интерфейс Snort), там было огромное количество предупреждений;
если бы не наш файрволл, сеть бы давно вышла из строя.

Еще я проверил безопасность серверов и рабочих станций внутри
сети с помощью Nessus. Были найдены явные уязвимости, однако так как
NST не содержит лицензии на Nessus, более подробный отчет представлен
не был.

Безопасность под вашим контролем


NST, обладая сбалансированным набором средств сетевого мониторинга,
анализа и безопасности, может дать явные преимущества сетевому
администратору, ценой одного лишь старого сервера. Через веб-интерфейс
WUI упрощаются все задачи. Работать с ним могут даже неопытные
администраторы, которые не пользовались Linux (и особенно консолью) и
таким образом задействовать всю мощь сетевых средств с открытым
исходным кодом.