Управление сетевой инфраструктурой по протоколу snmp. часть 1. знакомство со стандартом и инструментарием

Пакеты для обработки MIB-файлов

Для создания набора OID-ов при разработке собственного проекта потребуется подготовить файлы MIB, в
которых должна быть определена следующая информация:

• поддерево иерархии собственных OID в базе данных MIB (в дереве);
• структура поддерева;
• OID узлов поддерева;
• типы данных объектов в поддереве.

В принципе, от создания MIB-файлов можно отказаться, так как символьные имена узлов дерева нужны
только для восприятия человеком, и если уже известна полная числовая запись OID интересующего параметра,
то можно написать код агента для работы с этим OID. Однако на практике чаще применяется другой подход:

1. в соответствии со строгим синтаксисом готовится один или несколько связанных MIB-файлов;
2. производится автоматическая синтаксическая проверка и при необходимости правка MIB-файлов, для этого
   используются утилиты и
   (она находится в пакете libsmi.i686,
   который мы ещё не устанавливали).
3. MIB-файлы помещаются в один из каталогов, где они будут доступны подсистеме SNMP при поиске,
   выполняемом по стандартным путям.
4. после этого вызываются автоматические генераторы кода, которые по описанным в MIB-файлах OID выполняют
   генерацию шаблонов кода для работы с ними; существует много сторонних пакетов для генерации кода на
   языках C, C++, Java один из таких генераторов для языка C —
   входит в состав пакета net-snmp-perl.
5. полученные шаблоны кода включаются в код проекта, далее код шаблона наполняется конкретным
   программным кодом.

Остаётся только выполнить установку недостающих пакетов libsmi.i686 и
net-snmp-perl:

$ sudo yum install libsmi-*
...
Установлено:
  libsmi-devel.i686 0:0.4.8-9.fc17
Обновлено:
  libsmi.i686 0:0.4.8-9.fc17
Выполнено!
New leaves:
  libsmi-devel.i686
$ which smilint
/usr/bin/smilint
$ sudo yum install net-snmp-perl
...
Установлено:
  net-snmp-perl.i686 1:5.7.1-5.fc17
$ which mib2c
/usr/bin/mib2c
$ sudo yum install net-snmp-devel
...
Установлено:
  net-snmp-devel.i686 1:5.7.1-5.fc17
Установлены зависимости:
  elfutils-devel.i686 0:0.154-2.fc17
  elfutils-libelf-devel.i686 0:0.154-2.fc17
  lm_sensors-devel.i686 0:3.3.2-5.fc17
  popt-devel.i686 0:1.13-10.fc17
  rpm-devel.i686 0:4.9.1.3-7.fc17
$ which net-snmp-config
/usr/bin/net-snmp-config

Basic Example

The command takes a single OID, and will display a list of all the results which lie within the subtree rooted on this OID:

 % snmpwalk -v 2c -c demopublic test.net-snmp.org system
 SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715
 SNMPv2-MIB::sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.hpux10
 SNMPv2-MIB::sysUpTime.0 = Timeticks: (586998396) 67 days, 22:33:03.96
 SNMPv2-MIB::sysContact.0 = Wes Hardaker wjhardaker@ucdavis.edu
 SNMPv2-MIB::sysName.0 = net-snmp
 SNMPv2-MIB::sysLocation.0 = UCDavis
 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
 SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
 SNMPv2-MIB::sysORID.2 = OID: IF-MIB::ifMIB
 SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
 SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
 SNMPv2-MIB::sysORDescr.1 = The Mib module for SNMPv2 entities.
 SNMPv2-MIB::sysORDescr.2 = The MIB module to describe generic objects for network interface sub-layers
 SNMPv2-MIB::sysORDescr.4 = The MIB module for managing IP and ICMP implementations
 SNMPv2-MIB::sysORDescr.5 = The MIB module for managing UDP implementations
 SNMPv2-MIB::sysORUpTime.1 = Timeticks: (82) 0:00:00.82
 SNMPv2-MIB::sysORUpTime.2 = Timeticks: (81) 0:00:00.81
 SNMPv2-MIB::sysORUpTime.4 = Timeticks: (83) 0:00:00.83
 SNMPv2-MIB::sysORUpTime.5 = Timeticks: (82) 0:00:00.82

It can also be used with a single MIB (scalar) object, or even an exact
instance OID — returning the corresponding value:

 % snmpwalk -v 2c -c demopublic test.net-snmp.org sysDescr
 SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715
 % snmpwalk -v 2c -c demopublic test.net-snmp.org sysDescr.0
 SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715

Conversely, it’s also possible to start the walk at a higher level,
retrieving more than one group of information.

 % snmpwalk -v 2c -c demopublic test.net-snmp.org .iso

would typically retrieve all the information known to an agent.
(Output omitted here, for obvious reasons!)

Формат сообщений

Сообщения SNMP состоят из 2 частей: имени сообщества (community name) и
данных (data). Имя сообщества назначает среду доступа для набора NMS,
которые используют это имя. Можно сказать, что NMS, принадлежащие
одному сообществу, находятся под одним и тем же административным
началом. Т.к. устройства, которые не знают правильного имени
сообщества, исключаются из операций SNMP, управляющие сетей также
используют имя сообщества в качестве слабой формы опознавания.

Информационная часть сообщения содержит специфичную операцию SNMP
(get, set, и т.д.) и связанные с ней операнды. Операнды обозначают
реализации об’екта, которые включены в данную транзакцию SNMP.

Сообщения SNMP официально называются протокольными единицами данных
(protocol data units — PDU). На Рис. 32-3 изображен формат пакета SNMP.

PDU операций get и set SNMP состоят из следующих частей:

Request-ID (идентификатор запроса).

Устанавливает связь между командами и ответами.

Error-status (состояние сбоя).

Указывает ошибку и ее тип.

Error-index (индекс ошибки).

Устанавливвает связь между ошибкой и
конкретной реализацией об’екта.

Variable bindings (переменные привязки).

Состоят из данных
SNMP PDU. Пепеменные привязки устанавливают связь между конкретными
переменными и их текущими значениями.

Enterprise (предметная область).

Идентифицирует тип об’екта, генерирующего данную ловушку.

Agent address (адрес агента).

Обеспечивает адрес об’екта, генерирующего данную ловушку.

Generic trap type (групповой тип ловушки).

Обеспечивает групповой тип ловушки.

Specific trap code (специфичный код ловушки).

Обеспечивет специфичный код ловушки.

Time stamp (временной ярлык).

Обеспечивает величину времени,
прошедшего между последней повторной инициализацией сети и генерацией
данной ловушки.

Variable bindings (переменные привязки).

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

Спонсоры:

Хостинг:

Maxim ChirkovДобавить, Поддержать, Вебмастеру

Обращение к SNMP

Теперь можно проверить работу утилит SNMP, начав со стандартных системных OID. В SNMPv2c (2-ой
версии SNMP на основе сообществ, community) опция -c в утилитах
определяет имя сообщества, по принадлежности к которому в конфигурационном файле
snmpd.conf разграничиваются полномочия доступа:

$ snmpwalk -v1 localhost -c public system
SNMPv2-MIB::sysDescr.0 = STRING: Linux notebook 3.5.2-1.fc17.i686.PAE #1 SMP ...
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (48754) 0:08:07.54
SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> ...
SNMPv2-MIB::sysName.0 = STRING: notebook
SNMPv2-MIB::sysLocation.0 = STRING: Unknown (edit /etc/snmp/snmpd.conf)
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (8) 0:00:00.08
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
...
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementations
...
SNMPv2-MIB::sysORUpTime.10 = Timeticks: (8) 0:00:00.08
$ snmpget -v1 localhost -c public SNMPv2-MIB::sysName.0
SNMPv2-MIB::sysName.0 = STRING: notebook
$ snmpget 192.168.1.5 -v1 -c public system.sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux notebook 3.5.2-1.fc17.i686.PAE #1 SMP ...

Так выполняются запросы к , а вот как выглядит
статическая диагностика одного из поддеревьев OID-ов и его численное представление:

$ snmptranslate -Tp -OS SNMPv2-MIB::sysOREntry
+--sysOREntry(1)
   |  Index: sysORIndex
   |
   +-- ---- INTEGER   sysORIndex(1)
   |        Range: 1..2147483647
   +-- -R-- ObjID     sysORID(2)
   +-- -R-- String    sysORDescr(3)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -R-- TimeTicks sysORUpTime(4)
            Textual Convention: TimeStamp
$ snmptranslate -On SNMPv2-MIB::sysOREntry
.1.3.6.1.2.1.1.9.1

Таким способом можно получить полную спецификацию (тип, способ доступа) для этого же узла:

bash-4.2$ snmptranslate -Td -On SNMPv2-MIB::sysOREntry
.1.3.6.1.2.1.1.9.1
sysOREntry OBJECT-TYPE
  -- FROM	SNMPv2-MIB
  MAX-ACCESS	not-accessible
  STATUS	current
  INDEX		{ sysORIndex }
  DESCRIPTION	"An entry (conceptual row) in the sysORTable."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) sysORTable(9) 1 }

General Properties

Sub-menu:

This sub menu allows to enable SNMP and to configure general settings.

Note: engine-id field holds the suffix value of engine-id, usually SNMP clients should be
able to detect the value, as SNMP values, as read from the router. However there is a
possibility that this is not the case. In which case, the engine-ID value has to be set
according to this rule: <engine-id prefix> + <hex-dump suffix>, so as an example, if you
have set 1234 as suffix value you have to provide 80003a8c04 + 31323334, combined hex (the
result) is 80003a8c0431323334

Обзор и основные понятия

Principle of SNMP Communication

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

Управляемые протоколом SNMP сети состоят из трех ключевых компонентов:

• Управляемое устройство;
• Агент — программное обеспечение, запускаемое на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства;
• Система сетевого управления (Network Management System, NMS) — программное обеспечение, взаимодействующее с менеджерами для поддержки комплексной структуры данных, отражающей состояние сети.

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

Агентом называется программный модуль сетевого управления, располагающийся на управляемом устройстве, либо на устройстве, подключенном к интерфейсу управления управляемого устройства. Агент обладает локальным знанием управляющей информации и переводит эту информацию в специфичную для SNMP форму или из неё (медиация данных).

В состав Системы сетевого управления (NMS) входит приложение, отслеживающее и контролирующее управляемые устройства. NMS обеспечивают основную часть обработки данных, необходимых для сетевого управления. В любой управляемой сети может быть одна и более NMS.

Special Cases and Examples

Here are some examples of more complex configurations, include supporting different views for a SNMPv3 user based on their security level.

VACM Views, or How to restrict access to particular branches in the tree

####
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):

#       sec.name  source          community
com2sec local     localhost       secret42

####
# Second, map the security names into group names:

#               sec.model  sec.name

####
# Third, create a view for us to let the groups have rights to:

#           incl/excl subtree                              mask
view all    included  .1


####
# Finally, grant the groups access to their views:

#                context sec.model sec.level match  read     write  notif
access MyRWGroup ""      any       noauth    exact  all      all    none

VACM Masks, or How to restrict access to a particular index (row) in a Table

Using the directive in , one can limit users to a single row in a table. To do this, the optional parameter is specified. Here is an excerpt from the man page:

      view NAME TYPE SUBTREE 
             The defines the named view. TYPE is either included
             or  excluded.   MASK is a list of hex octets, sepa-
             rated by '.' or ':'.  The MASK defaults to "ff"  if
             not specified.

             The  reason  for the mask is, that it allows you to
             control access to one row in a table,  in  a  rela-
             tively  simple  way.  As  an example, as an ISP you
             might consider giving each customer access  to  his
             or her own interface:

             view cust1 included interfaces.ifTable.ifEntry.ifIndex.1 ff.a0
             view cust2 included interfaces.ifTable.ifEntry.ifIndex.2 ff.a0

             (interfaces.ifTable.ifEntry.ifIndex.1 == .1.3.6.1.2.1.2.2.1.1.1,
             ff.a0 == 11111111.10100000. which nicely covers up and including
             the row index, but lets the user vary the field of the row)

Note: The mask seperator character can be «.» or «:».

So, to be a little more visual about it:

.1.3.6.1.2.1.2.2.1.1.1 == interfaces.ifTable.ifEntry.ifIndex.1 
 1 1 1 1 1 1 1 1 1 0 1 (00000) == (ff.a0)
               ^ ^ ^ ^
               | | | |-- the index
               | | |---- the column
               | |------ ifEntry
               |-------- ifTable

So each bit in the mask indicates if the corresponding OID must match or not. In the above example, all parts of the OID except the colum must match. So this view allows access to any column of the first row in the ifTable. So, paired with an row for the ifTable, only row 1 would be accessible to the user.

Now, to bring it all together with the other access control directives. Assuming 2 customers, and each is only connected to a specific interface (eg customer 1 is connected to eth0 and customer 2 is connected to eth1):

####
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):

#       sec.name  source          community
com2sec local     localhost       secret42
com2sec  192.168.1.0/24  public
com2sec  192.168.2.0/24  public

####
# Second, map the security names into group names:

#               sec.model  sec.name
group MyRWGroup v1         local
group MyRWGroup v2c        local

####
# Third, create a view for us to let the groups have rights to:

#           incl/excl subtree                              mask
view all    included  .1

####
# Finally, grant the groups access to their views:

#                context sec.model sec.level match  read     write  notif
access MyRWGroup ""      any       noauth    exact  all      all    none

It is important to note that this works because the customers are on different networks. If all the customers are on the same network, then it is important to note that sniffing network traffic could expose one customer’s «community string» to another customer, allowing the second customer to view the first customers interface statistics via SNMP. In this case, you would want to use the encryption capabilities offered by SNMPv3 usm users, instead of SNMPv1 and SNMPv2 community strings.

Детали протокола

SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы получаются по порту 10161, а ловушки отправляются на порт 10162.

В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units — PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.

Все PDU протокола SNMP построены следующим образом:

Ниже перечислены семь протокольных единиц обмена SNMP:

GetRequest

Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция. Менеджеру будет возвращён Response (ответ) с текущими значениями.

SetRequest

Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращён Response с (текущими) новыми значениями переменных.

GetNextRequest

Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращён Response со связанными переменными для переменной, которая является следующей в базе MIB в лексиграфическом порядке. Обход всей базы MIB агента может быть произведён итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.

GetBulkRequest

Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращён Response с несколькими связанными переменными, обойдёнными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введён в SNMPv2.

Response

Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки.

Эта единица используется как ответ и на Get-, и на Set-запросы, в SNMPv1 называется GetResponse .

Trap

Асинхронное уведомление от агента — менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменён в SNMPv2 и PDU переименовали в SNMPv2-Trap.

InformRequest

Асинхронное уведомление от менеджера менеджеру или от агента менеджеру. Уведомления от менеджера менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована, и не сообщается о потерянных пакетах. InformRequest исправляет это обратным отправлением подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введён в SNMPv2.

Безопасность

• SNMP версий 1 и 2c подвержены перехвату пакетов со строками сообщений, так как они не используют шифрование.
• Все версии SNMP подвержены атакам грубой силой и словарным перебором для угадывания строк сообщества, строк аутентификации, ключей аутентификации, строк шифрования или ключей шифрования, поскольку они не используют «рукопожатие» вида запрос-ответ.
• Хотя SNMP работает с TCP и другими протоколами, обычно он используется с UDP, то есть без установки соединения и с уязвимостью для атак подменой IP. Для ограничения SNMP-доступа могут быть использованы списки доступа к устройству, но и механизмы защиты SNMPv3 способны успешно мешать атакам.
• Обширные возможности в настройке SNMP многими поставщиками не используются в полную силу, отчасти из-за недостатка безопасности в версиях SNMP до SNMPv3, а также из-за того, что многие устройства просто не могут быть настроены с помощью изменений отдельного объекта базы MIB.
• SNMP возглавляет составленный SANS Institute список «Common Default Configuration Issues» с вопросом изначальной установки строк сообщества на значения «public» и «private» и занимал десятую позицию в SANS Top 10 Самых критических угроз Интернет-безопасности за 2000 год.

Автоматическая настройка

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

Пока требования безопасности различны в разных организациях, следует проявлять осторожность при использовании этой функции, особенно с учётом таких особенностей, как центры обработки данных со смешанными арендаторами, объекты размещения серверов и подобные условия

Вопросы реализации

Реализации SNMP варьируются среди поставщиков платформ. В отдельных случаях SNMP не считается достаточно серьёзным для элемента основной разработки и потому является просто дополнительной функцией. Некоторые крупные поставщики оборудования имеют склонность к чрезмерному расширению своих собственных интерфейсов командной строки (command line interface, CLI) и систем контроля.

Простая на вид структура дерева и линейная индексация в SNMP не всегда достаточно хорошо понимаются в пределах внутренних структур данных, которые являются элементами базовой конструкции платформы. Следовательно, обработка SNMP-запросов на определённых наборах данных может привести к большей, чем необходимо, нагрузке на процессор. Одним из примеров этой проблемы являются большие таблицы маршрутизации, такие как BGP и IGP.

Вступление

Данная статья посвящена протоколу SNMP (Simple Network Management Protocol) — одному из
протоколов модели OSI, который практически не был затронут в документации просторов RU-нета.
Автор попытался заполнить этот вакуум, предоставив читателю почву для размышлений и
самосовершенствования, касательно этого, возможно нового для Вас, вопроса.
Этот документ не претендует на звание «документации для разработчика», а просто отражает
желание автора, насколько это возможно, осветить аспекты работы с данным протоколом,
показать его слабые места, уязвимости в системе «security», цели преследованные создателями
и объяснить его предназначение.

Заключение

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

Подсистема оповещения предназначена для рассылки электронных писем ответственным лицам при возникновении критических событий. Число критических событий для каждого устройства неограниченно.

Графики для собираемых параметров не создаются по умолчанию. Для каждого опрашиваемого устройства их надо настраивать вручную, исходя из ваших потребностей. Описание графиков хранится в базе данных конфигурации. Каждый график может отображать до четырёх различных параметров (три – в виде линии и один – в виде сплошной области). CFM создаёт графики в векторном формате (svg). Это минимизирует затраты вычислительных ресурсов сервера на создание графика и позволяет применять различные эффекты, характерные для данного графического формата. Сервер не хранит сформированные графики, а отправляет их в виде XML-файлов клиенту. Далее клиентское ПО занимается отрисовкой графики. В нашем случае это делает Firefox.

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

В CFM ведётся собственная база данных MIB. Она используется для построения дерева MIB и в других утилитах для подмены числовых значений OID на символьные, а также для получения описания конкретного OID. В состав дистрибутива CFM входит большое количество файлов MIB, охватывающее практически все широко распространённые устройства. Однако файлы MIB представлены не в стандартном виде, а в формате SPM (Simple Presentation Mib). SPM — это формат простого представления файлов MIB. Разработан специально для проекта CFM для упрощения программной обработки файлов MIB. Оригинальный формат (описанный в различных RFC) весьма запутан, сложен, нечётко структурирован и плохо поддаётся синтаксическому разбору программным образом. Кроме того, в повседневной работе редко возникает нужда использовать всё, что создатели данного стандарта вложили в него. Формат SPM — это упрощенное представление MIB в формате XML. Для преобразования файлов MIB в формат SPM была написана соответствующая утилита командной строки. Преобразованный файл с помощью графического интерфейса легко добавляется в общую базу MIB на сервере CFM.

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

Также, если среди читателей IBM developerWorks есть желающие принять участие в разработке CFM, просим связаться с автором статьи, являющимся автором данного программного проекта.