System Center 2012 R2 Operations Manager - настраиваем базовый мониторинг ОС Linux на примере Ubuntu Server 14.04 LTS

imageПродолжая тему интеграции развёрнутого нами ранее Linux сервера на базе Ubuntu Server 14.04 LTS в инфраструктуру Windows, в этой заметке мы рассмотрим процесс подключения Linux-севера к системе мониторинга Microsoft System Center 2012 R2 Operations Manager (SCOM).

Информацию о совместимости SCOM c ОС на базе Linux мы сможем найти в документе System Center 2012 Agent Requirements for System Center 2012 R2. На текущий момент в этом документе есть информация о поддержке в качестве Operations Manager Linux/Unix Agent систем Ubuntu Linux Server версий 10.04 и 12.04 (x86/x64). В этой заметке мы попробуем установить агента SCOM на более современную версию Ubuntu - 14.04.1 LTS (GNU/Linux 3.13.0-34-generic x86_64).    

На момент написания этой заметки самая последняя версия пакета управления Management Pack (MP) для базового мониторинга ОС Linux в SCOM доступна по ссылке:
System Center 2012 Management Pack for UNIX and Linux Operating Systems (2014/07).

По указанной ссылке к загрузке доступно множество файлов для поддержки разных Unix/Linux систем. Для поддержки в SCOM Ubuntu Server нам нужно загрузить только два файла:
- System Center 2012 R2 Management Packs for Unix and Linux.msi (инсталляционный пакет содержащий *.mp и *.mpb файлы)
- UniversalLinuxMPGuide.doc (краткая документация по универсальному пакету управления)

***

Для начала обязательно изучим документ UniversalLinuxMPGuide.doc. Из него мы в частности узнаем, что минимальные предварительные требования для работы агента SCOM в Linux можно найти в онлайн-документе Monitoring UNIX and Linux Computers by Using Operations Manager - Supported UNIX and Linux Operating System Versions. Согласно этого документа на Ubuntu потребуется наличие пакетов:

- libc6 - 2.3.6 - C Standard shared library
- OpenSSL - 0.9.8 or 1.0 - OpenSSL Libraries; Secure Network Communications Protocol
- PAM - 0.79-3 - Pluggable Authentication Modules

Подключаемся на наш Ubuntu сервер и проверяем имеющиеся версии указанных пакетов:

dpkg --list libc6 openssl libpam-modules
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture  Description
+++-======================-=================-=========-======================
ii  libc6:amd64            2.19-0ubuntu6.1   amd64 Embedded GNU C Library: Shared libraries
ii  libpam-modules:amd64   1.1.8-1ubuntu2    amd64 Pluggable Authentication Modules for PAM
ii  openssl                1.0.1f-1ubuntu2.5 amd64 Secure Sockets Layer toolkit - cryptographic utility

Как видим, необходимый минимум у нас уже есть.

***

Теперь на сервере SCOM распаковываем загруженный файл System Center 2012 R2 Management Packs for Unix and Linux.msi (выполнять его установку нет реальной необходимости):

msiexec /a "c:\Temp\System Center 2012 R2 Management Packs for Unix and Linux.msi" TARGETDIR="c:\Temp\SC2012-MP-Linux"

Открываем консоль SCOM (Administration > Management Packs > Import Management Packs) и из распакованного каталога MP (c:\Temp\SC2012-MP-Linux) импортируем только те файлы, которые нужны для мониторинга Ubuntu Linux:

Microsoft.Linux.UniversalD.1.mpb
Microsoft.Linux.Universal.Monitoring.mp
Microsoft.Linux.Universal.Library.mp
Microsoft.Linux.Library.mp

image

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

***

Теперь снова перебираемся в Linux, чтобы создать локального пользователя, который в дальнейшем будет использован в качестве Run As Account в SCOM. В нашем примере от имени этого пользователя в дальнейшем будет выполняться удалённое развёртывание агента SCOM.

sudo adduser scom-user

В процессе создания учетной записи система попросит дважды ввести пароль. Среди необязательных данных можно для информативности заполнить значение Full Name…

Adding user `scom-user' ...
Adding new group `scom-user' (1001) ...
Adding new user `scom-user' (1001) with group `scom-user' ...
Creating home directory `/home/scom-user' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for scom-user
Enter the new value, or press ENTER for the default
        Full Name []: SCOM RunAs Account
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] Y

Как видно из листинга вывода команды, в процессе создания пользователя в системе была создана одноимённая группа scom-user. Добавим данную группу в перечень групп, которым разрешено подключение к системе по протоколу SSH.

sudo nano -Y sh /etc/ssh/sshd_config

Дополним строку конфигурационного файла, где перечисляются разрешённые группы:

# User groups access contol
AllowGroups adm kom-srv-linux-administrators scom-user

Для вступления изменений в силу перезапускаем службу сервера SSH:

sudo service ssh restart

Затем добавляем созданного пользователя scom-user в встроенную в Ubuntu группу sudo для возможности выполнения команд требующих повышения прав доступа в системе

sudo usermod -a -G sudo scom-user

Разрешаем для указанного пользователя запуск sudo без ввода пароля. Для этого выполним команду специального режима редактирования системного файла /etc/sudoers:

sudo visudo

В конец открывшегося файла допишем фрагмент:

# Allow SCOM RunAs Account run sudo passwordless
scom-user ALL=(ALL) NOPASSWD: ALL

Закроем файл с сохранением изменений (Ctrl+X, затем Y).

***

Далее нам необходимо организовать возможность доступа к нашему Linux серверу по портам 22 и 1270 TCP c серверов управления SCOM. Порт TCP 22 мы открывали ранее для возможности подключения из локальной сети по SSH. Порт 1270 откроем сейчас:

sudo iptables -A INPUT -p tcp --dport 1270 -i eth0 -j ACCEPT
sudo service iptables-persistent save

 

***

На SCOM создаём новый Resource Pool, в который включим сервера управления SCOM отвечающие за мониторинг наших Linux систем. Он нужен в частности для того, чтобы данные о создаваемом в дальнейшем SOM Run As Account могли реплицироваться только на эти сервера управления.

В консоли SCOM переходим в Administration > Resource Pools > в меню действий выбираем "Create Resource Pool”. Зададим говорящее за себя имея пула, например “KOM Linux Monitoring Resource Pool

image

Далее на вкладке Pool Membership добавим в пул те сервера управления, которые будут у нас отвечать за мониторинг Linux-систем.

image

Сохраняем созданный пул.

***

Следующим этапом будет создание в SCOM учётной записи для “запуска от имени” (Unix/Linux Run As Account). В консоли SCOM переходим в Administration > Run As Configuration > UNIX/Linux Accounts > в меню действий выбираем “Create Run As Account”. Выбираем тип учетной записи – Monitoring account

image

Задаем аккаунту понятное имя, например “KOM Linux Monitoring Account

image

На вкладке Account Credentials указываем учетные данные пользователя scom-user, которого мы ранее создали в Ubuntu. Выбираем опцию Elevate this account using sudo for privileged access.

image

На вкладке Distribution Security выбираем вариант More secure, что ограничить распространение указанных нами учетных данных и завершаем создание аккаунта кнопкой Create

image

В конце мастер создания Run As Account предупредит нас о том, что созданный аккаунт нужно связать с профилем Run As profile.

image

***

После закрытая мастера создания Run As Account открываем свойства нового аккаунта и переходим на закладку Distribution Security, где появится поле выбора систем, на которые должны быть распространены учетные данные этого аккаунта. Добавляем созданный ранее пул ресурсов содержащий SCOM сервера (“KOM Linux Monitoring Resource Pool”) и сохраняем изменения.

image

***

Далее нам нужно создать профиль Run As Profile на базе ранее созданного Run As Account (Administration > Run As Configuration > Profiles). После импорта MP для мониторинга Linux в SCOM добавляется 3 новых профиля “по умолчанию”:

image

Профиль UNIX/Linux Action Account предполагается использовать для рабочих процессов мониторинга, не требующих повышения уровня прав в системе.

Профиль UNIX/Linux Privileged Account - для рабочих процессов мониторинга, требующих повышения уровня прав в системе, например чтения syslog-а, выполнения задач восстановления типа перезапуска служб и т.п.

Профиль UNIX/Linux Maintenance Account - для задач обслуживания агента SCOM (с использованием SSH), таких как установка агента, обновление, перезапуск его служб и удаление.

В нашем примере мы используем созданный ранее Run As Account для всех трёх типов профилей.

Откроем свойства первого профиля UNIX/Linux Action Account и на закладке Run As Accounts добавим созданный нами ранее аккаунт “KOM Linux Monitoring Account” с типом применения All targeted objects.

image

При сохранении профиля нас предупредят о том, что мы выбрали Run As Accounts, для которого нами ранее был включён режим ограниченной репликации учётных данных. Кликнем по названию аккаунта, чтобы введённые ранее имя пользователя и пароль для этого аккаунта были скопированы на все выбранные нами системы (сервера управления SCOM входящие в специально созданный нами ранее пул “KOM Linux Monitoring Resource Pool”). После этого значок рядом с названием аккаунта должен измениться на зелёную “галочку”.

image

Повторим процедуру для профилей UNIX/Linux Privileged Account и UNIX/Linux Maintenance Account.

***

Теперь можно перейти непосредственно к процессу установки агента SCOM на наш Ubuntu Server. Переходим в раздел консоли Administration > Device Management > в контекстном меню выбираем пункт Discovery Wizard. В открывшемся мастере выбираем тип обнаружения UNIX/Linux computers

image

На вкладке Discovery Criteria выбираем пул ресурсов “KOM Linux Monitoring Resource Pool”, чтобы связать нового Linux-агента SCOM с нужными нам серверами управления. В таблице критериев обнаружения добавляем новый - Add

image

В открывшемся окне в таблицу Discovery Scope вводим FQDN имя нашего Linux-сервера и номер порта SSH, который открыт на этом сервере. В Discovery type оставляем значение по умолчанию All computers. В таблицу Credentials добавляем учетные данные для подключения по протоколу SSH…

image

В форме добавления учетных данных выберем тип учётных данных - User name and password. Укажем имя пользователя и пароль. Параметром This account does not have privileged access определим то, что для выполнения административных действий этой учетной записи требуется повышение прав…

image

А на вкладке Elevation выберем тип повышения прав, согласно типу нашей ОС Ubuntu – Use ‘sudo’ elevation

image

Сохраним настройки учетных данных, затем сохраним настройки критериев обнаружения…image

Все основные исходные данные определены и теперь запускаем обнаружение - Discover

image

Если наш Linux-сервер успешно опрошен, мы получим информацию о версии и архитектуре ОС, и отметив его “галочкой” по кнопке Manage запустим процедуру установки агента SCOM…

image

Дожидаемся успешной установки агента…

image

Через некоторое время после завершения работы мастера Discovery Wizard в консоли SCOM в разделе Administration > Device Management > UNIX/Linux Computers должна появится информация о новом Linux-агенте…

image

А в разделе консоли Monitoring в папке UNIX/Linux Computers можно будет увидеть информацию о состоянии базовых компонент ОС…

image

Теперь можно считать, что задача выполнена. Остается только один момент…

***

Если в нашем окружении используется более одного сервера управления SCOM и мы используем для их объединения ресурсный пул, то стоит обеспечить взаимное доверие корневых сертификатов, генерируемых серверами SCOM для мониторинга UNIX/Linux систем. Первоисточником того, как это сделать, является документ Managing Resource Pools for UNIX and Linux Computers

SCOM использует сертификаты при доступе к управляемым Linux-компьютерам. Каждый SCOM сервер имеет свой корневой сертификат, который используется для подписи агентского сертификата. Если мы хотим посмотреть сертификат, используемый установленным нами агентом SCOM в Ubuntu Server, заглянем в каталог /etc/opt/microsoft/scx/ssl:

openssl x509 -inform pem -in /etc/opt/microsoft/scx/ssl/scx-host-kom-ad01-gw10.pem -noout -text

Из вывода можно будет понять каким именно сервером управления подписан сертификат агента. В данном случае, как видим, сертификат агента был подписан корневым сертификатом сервера KOM-AD01-SCOM01

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=SCX-Certificate/title=SCX634376D2-E3E2-4f31-8561-D08259ADE43D, DC=KOM-AD01-SCOM01
        Validity
            Not Before: Aug 16 09:22:09 2013 GMT
            Not After : Aug 16 09:22:12 2024 GMT
        Subject: DC=com, DC=holding, CN=kom-ad01-gw10, CN=kom-ad01-gw10.holding.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                ...

Также чтобы посмотреть информацию о сертификате, соответствующий *.pem файл можно скопировать на Windows-систему, изменить расширение на *.crt и открыть с помощью проводника.

В случае недоступности одного из серверов SCOM, Linux-агент будет переключён на другой сервер SCOM входящий в соответствующий Resource Pool. В такой ситуации, для того, чтобы не возникло проблем с доверием к агентскому сертификату, нам нужно сделать так, чтобы все сервера SCOM доверяли корневым сертификатам друг-друга. То есть, если у нас например в вышеописанный ресурсный пул KOM Linux Monitoring Resource Pool входит два сервера SCOM (KOM-AD01-SCOM01 и KOM-AD01-SCOM03), то нам нужно корневой сертификат сервера KOM-AD01-SCOM01 экспортировать, а затем импортировать на сервер KOM-AD01-SCOM03. И наоборот, корневой сертификат сервера KOM-AD01-SCOM03 экспортировать, а затем импортировать на сервер KOM-AD01-SCOM01.

Пример команды экспорты сертификата на сервере KOM-AD01-SCOM01: 

cd /d "C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\"
scxcertconfig.exe -export \\Share\SCX-Certificates\KOM-AD01-SCOM01.crt

Пример команды импорта сертификата KOM-AD01-SCOM01.cert на сервере KOM-AD01-SCOM03:

cd /d "C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\"
scxcertconfig.exe -import \\Share\SCX-Certificates\KOM-AD01-SCOM01.crt

После импорта на каждом из серверов список загруженных сертификатов можно получить командой:

scxcertconfig.exe -list

На этом всё.


Дополнительные источники информации:

Всего комментариев: 10 Комментировать

  1. Сергей /

    А могли бы вы написать установку SCOMR2 с нуля и его базовая настройка для внедрения в windows структуру?

  2. Алексей Максимов / Автор записи

    Ищите заметки по тегу SCOM (https://blog.it-kb.ru/tag/scom/). По базовой настройке SCOM материала немало. Есть цикл заметок по развёртыванию SCOM 2012. От 2012 R2 в плане развёртывания отличия не очень существенные.

  3. Василий /

    Алексей, а не планируете рассказать про карту сети, и связки м\у сетевыми устройствами, чтобы на карте была видна топология, и проблемные участки?
    З.Ы. Большое спасибо за статью, очень помогла.

    1. Алексей Максимов / Автор записи

      Не планирую, по крайней мере в ближайшей обозримой перспективе.

  4. Обратная ссылка: Настраиваем базовый мониторинг виртуальной машины HP 3PAR Virtual Service Processor 4.3.0 (Red Hat Enterprise Linux Server 6.1) на базе System Center 2012 R2 Operations Manager | Блог IT-KB /

  5. Андрей /

    Алексей,
    Вы пишете, что:
    "Теперь снова перебираемся в Linux, чтобы создать локального пользователя, который в дальнейшем будет использован в качестве Run As Account в SCOM."
    А можно ли использовать доменный аккаунт, а не локальный?
    Что будет, если в мониторинге большое количество машин с Ubuntu и надо будет сменить пароль для пользователя с привилегиями Acction Account? Вручную менять на всем парке?

    1. Алексей Максимов / Автор записи

      Да наверно можно. Как я понимаю, для этого компьютер с Linux должен иметь компоненты Samba, должен быть добавлен в домен, и доменная учётная запись должна быть соответственно добавлена в группу администраторов Linux-сервера. Просто например в моей практике далеко не всех Linux системах получиться навернуть самбу и затащить в домен. А мониторить при этом нужно все системы. Тут нужно находить какой-то компромисс между удобством и здравым смыслом.

  6. Александр /

    Доброго дня.
    А как Вы решаете проблему мониторинга (установка агента) на Unix/Linux сервер который не находится в АД? Нет записи на DNS сервере?

    1. Алексей Максимов / Автор записи

      Здравствуйте, Александр. Никак не решаем. У нас нет такой проблемы. На самом деле между понятиями "Unix/Linux сервер который не находится в АД", "Нет записи на DNS сервере" и SCOM нет вообще никакой связи. Поэтому сама постановка вопроса мне кажется довольно странной.

      1. Александр /

        Разобрался в чем дело.
        в фале hosts прописал прямую и обратную записи и дискаверинг прошел на ура.
        Спасибо.

Добавить комментарий