Продолжая тему интеграции развёрнутого нами ранее 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
В некоторых блогах можно найти упоминание о том, что после импорта этих 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”
Далее на вкладке Pool Membership добавим в пул те сервера управления, которые будут у нас отвечать за мониторинг Linux-систем.
Сохраняем созданный пул.
***
Следующим этапом будет создание в SCOM учётной записи для “запуска от имени” (Unix/Linux Run As Account). В консоли SCOM переходим в Administration > Run As Configuration > UNIX/Linux Accounts > в меню действий выбираем “Create Run As Account”. Выбираем тип учетной записи – Monitoring account
Задаем аккаунту понятное имя, например “KOM Linux Monitoring Account”
На вкладке Account Credentials указываем учетные данные пользователя scom-user, которого мы ранее создали в Ubuntu. Выбираем опцию Elevate this account using sudo for privileged access.
На вкладке Distribution Security выбираем вариант More secure, что ограничить распространение указанных нами учетных данных и завершаем создание аккаунта кнопкой Create
В конце мастер создания Run As Account предупредит нас о том, что созданный аккаунт нужно связать с профилем Run As profile.
***
После закрытая мастера создания Run As Account открываем свойства нового аккаунта и переходим на закладку Distribution Security, где появится поле выбора систем, на которые должны быть распространены учетные данные этого аккаунта. Добавляем созданный ранее пул ресурсов содержащий SCOM сервера (“KOM Linux Monitoring Resource Pool”) и сохраняем изменения.
***
Далее нам нужно создать профиль Run As Profile на базе ранее созданного Run As Account (Administration > Run As Configuration > Profiles). После импорта MP для мониторинга Linux в SCOM добавляется 3 новых профиля “по умолчанию”:
Профиль 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.
При сохранении профиля нас предупредят о том, что мы выбрали Run As Accounts, для которого нами ранее был включён режим ограниченной репликации учётных данных. Кликнем по названию аккаунта, чтобы введённые ранее имя пользователя и пароль для этого аккаунта были скопированы на все выбранные нами системы (сервера управления SCOM входящие в специально созданный нами ранее пул “KOM Linux Monitoring Resource Pool”). После этого значок рядом с названием аккаунта должен измениться на зелёную “галочку”.
Повторим процедуру для профилей UNIX/Linux Privileged Account и UNIX/Linux Maintenance Account.
***
Теперь можно перейти непосредственно к процессу установки агента SCOM на наш Ubuntu Server. Переходим в раздел консоли Administration > Device Management > в контекстном меню выбираем пункт Discovery Wizard. В открывшемся мастере выбираем тип обнаружения UNIX/Linux computers
На вкладке Discovery Criteria выбираем пул ресурсов “KOM Linux Monitoring Resource Pool”, чтобы связать нового Linux-агента SCOM с нужными нам серверами управления. В таблице критериев обнаружения добавляем новый - Add
В открывшемся окне в таблицу Discovery Scope вводим FQDN имя нашего Linux-сервера и номер порта SSH, который открыт на этом сервере. В Discovery type оставляем значение по умолчанию All computers. В таблицу Credentials добавляем учетные данные для подключения по протоколу SSH…
В форме добавления учетных данных выберем тип учётных данных - User name and password. Укажем имя пользователя и пароль. Параметром This account does not have privileged access определим то, что для выполнения административных действий этой учетной записи требуется повышение прав…
А на вкладке Elevation выберем тип повышения прав, согласно типу нашей ОС Ubuntu – Use ‘sudo’ elevation
Сохраним настройки учетных данных, затем сохраним настройки критериев обнаружения…
Все основные исходные данные определены и теперь запускаем обнаружение - Discover
Если наш Linux-сервер успешно опрошен, мы получим информацию о версии и архитектуре ОС, и отметив его “галочкой” по кнопке Manage запустим процедуру установки агента SCOM…
Дожидаемся успешной установки агента…
Через некоторое время после завершения работы мастера Discovery Wizard в консоли SCOM в разделе Administration > Device Management > UNIX/Linux Computers должна появится информация о новом Linux-агенте…
А в разделе консоли Monitoring в папке UNIX/Linux Computers можно будет увидеть информацию о состоянии базовых компонент ОС…
Теперь можно считать, что задача выполнена. Остается только один момент…
***
Если в нашем окружении используется более одного сервера управления 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
На этом всё.
Дополнительные источники информации:
А могли бы вы написать установку SCOMR2 с нуля и его базовая настройка для внедрения в windows структуру?
Ищите заметки по тегу SCOM (https://blog.it-kb.ru/tag/scom/). По базовой настройке SCOM материала немало. Есть цикл заметок по развёртыванию SCOM 2012. От 2012 R2 в плане развёртывания отличия не очень существенные.
Алексей, а не планируете рассказать про карту сети, и связки м\у сетевыми устройствами, чтобы на карте была видна топология, и проблемные участки?
З.Ы. Большое спасибо за статью, очень помогла.
Не планирую, по крайней мере в ближайшей обозримой перспективе.
Обратная ссылка: Настраиваем базовый мониторинг виртуальной машины HP 3PAR Virtual Service Processor 4.3.0 (Red Hat Enterprise Linux Server 6.1) на базе System Center 2012 R2 Operations Manager | Блог IT-KB /
Алексей,
Вы пишете, что:
"Теперь снова перебираемся в Linux, чтобы создать локального пользователя, который в дальнейшем будет использован в качестве Run As Account в SCOM."
А можно ли использовать доменный аккаунт, а не локальный?
Что будет, если в мониторинге большое количество машин с Ubuntu и надо будет сменить пароль для пользователя с привилегиями Acction Account? Вручную менять на всем парке?
Да наверно можно. Как я понимаю, для этого компьютер с Linux должен иметь компоненты Samba, должен быть добавлен в домен, и доменная учётная запись должна быть соответственно добавлена в группу администраторов Linux-сервера. Просто например в моей практике далеко не всех Linux системах получиться навернуть самбу и затащить в домен. А мониторить при этом нужно все системы. Тут нужно находить какой-то компромисс между удобством и здравым смыслом.
Доброго дня.
А как Вы решаете проблему мониторинга (установка агента) на Unix/Linux сервер который не находится в АД? Нет записи на DNS сервере?
Здравствуйте, Александр. Никак не решаем. У нас нет такой проблемы. На самом деле между понятиями "Unix/Linux сервер который не находится в АД", "Нет записи на DNS сервере" и SCOM нет вообще никакой связи. Поэтому сама постановка вопроса мне кажется довольно странной.
Разобрался в чем дело.
в фале hosts прописал прямую и обратную записи и дискаверинг прошел на ура.
Спасибо.