Как установить агент linux

Обновлено: 04.07.2024

Установленный агент Consul позволяет обмениваться информацией с кластером, отправляя состояние работы сервисов, которые запущены на узле. Мы рассмотрим процесс установки агента на компьютер под управлением Linux на базе Deb (Ubuntu, Debian) или RPM (Rocky Linux, CentOS). Также мы приведем примеры регистрации и настройки проверки сервисов.

Подготовка системы

Предварительно, необходимо настроить брандмауэр. Открываем порты 8300,8301,8302,8500. В зависимости от системы управления netfilter, команды будут отличаться.

а) iptables (как правило для систем на базе deb):

iptables -I INPUT -p tcp --match multiport --dports 8300,8301,8302,8500 -j ACCEPT

iptables -I INPUT -p udp --match multiport --dports 8301,8302 -j ACCEPT

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

б) firewalld (чаще для RPM-based):

firewall-cmd --permanent --add-port=/tcp

firewall-cmd --permanent --add-port=/

Установка агента

На различные системы агент устанавливается, почти, одинаково.

Для начала, установим дополнительные пакеты:

wget — утилита для загрузки файлов.
unzip — пакет для распаковки архивов zip.

Для этого, как раз, используются разные команды (в зависимости от операционной системы).

apt install wget unzip

yum install wget unzip

Теперь можно приступать к установке консула.

На странице со списком релизов необходимо посмотреть на все версии и выбрать необходимую. Также мы можем посмотреть версию consul на сервере:

. и установить такую же.

Так или иначе, создаем переменную с номером версии:

И скачиваем архив с бинарным файлом:

Распаковываем его в каталог /usr/bin:

unzip consul_$_linux_amd64.zip -d /usr/bin

Проверяем, что команды консул выполняются:

Мы должны увидеть версию программы:

Настройка и запуск агента

Настроим запуск агента в качестве сервиса. Для этого мы создадим юнит в systemd.

Создаем учетную запись, от которой будет работать агент:

* в данном примере мы создадим системную (-r) учетную запись consul. Для удобства восприятия мы также добавим комментарий (-c).

Создаем каталоги для приложения консул:

mkdir -p /var/lib/consul /etc/consul.d

И выставим на них соответствующие права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

* в данном примере мы указали, что владельцем данных каталогов будет созданная учетная запись consul. Права будут полные у владельца, остальные смогут читать данные.

Создаем конфигурационный файл:

server — указывает на использование серверного режима. При значении false используется режим клиента.
datacenter — датацентр, к которому будет присоединяться участник кластера. dc1 — датацентр по умолчанию.
node_name — имя, которым будет представлен узел в кластере.
data_dir — каталог на компьютере, который будет использоваться консулом для хранения своей информации.
bind_addr — IP-адрес, на котором будет слушать сервис.
client_addr — адрес, к которому будут привязаны клиентские интерфейсы. На практике, были проблемы при указании нескольких адресов. Проблема не наблюдается при использовании 127.0.0.1 для client_addr и внешнего сетевого адреса для bind_addr.
retry_join — список серверов консула, к которым должен присоединиться агент.
encrypt — ключ, который был сформирован для серверов консул и используется в качестве значения параметра encrypt (его можно посмотреть в конфигурационном файле на сервере consul).
log_level — уровень логирования. Возможны варианты trace, debug, info, warn, err. По умолчанию используется info.
enable_syslog — вести ли системный лог.
disable_compat_1.9 — запрещает все метрики, которые объявлены устаревшими, начиная с версии 1.9.

Проверяем корректность настройки:

consul validate /etc/consul.d/

Мы должны увидеть:

Configuration is valid!

Продолжаем. Создаем юнит в systemd:

[Unit]
Description=Consul client agent
Requires=network-online.target
After=network-online.target

[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
RuntimeDirectory=consul
ExecStart=/usr/bin/consul agent \
-config-dir=/etc/consul.d \
-pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s

Перечитываем конфигурацию systemd:

Разрешаем автозапуск сервиса, стартуем его и проверяем статус:

systemctl enable consul

systemctl start consul

systemctl status consul

На любом из узлов кластера выполним:

Среди членов кластера мы должны увидеть свой компьютер, например:

.
agent01 192.168.0.100:8301 alive client 1.10.2 2 dc1 <default>

С агентом завершили.

Использование ACL

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

На сервере переходим в каталог с конфигурациями консула и создаем файл с политикой:

* это пример политики, которой слишком много позволено. Для увеличения безопасности, мы можем ограничиться перечислением конкретных значений. Например, service "web" для возможности регистрировать сервисы, названия которых начинаются на web.

Создаем политику agent на основе файла agent-policy.txt:

consul acl policy create -name "agent" -rules @agent-policy.txt

И после, создаем токен на основе политики agent:

consul acl token create -description "Token for Agent" -policy-name agent

Мы получим что-то на подобие:

AccessorID: ddcf169e-237b-836c-47cf-537c12a3818f
SecretID: 37570fdb-798c-24e5-c8c3-612e86031345
Description: Token for Agent
Local: false
Create Time: 2021-09-09 16:36:57.216491588 +0300 MSK
Policies:
b3f3a892-c792-726c-8136-9744fd7e0f7b - agent

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

Переходим на клиентскую ноду и открываем наш конфигурационный файл:

<token> — это сформированный на сервере токен.

Перезагружаем консул на агенте:

systemctl restart consul

Рассмотрим общий принцип регистрации сервиса в консуле.

Для каждого сервиса можно создавать свой конфигурационный файл (или писать все в одном). Пошагово, необходимо:

Добавить настройку в консул.
Проверить конфигурацию и перезапустить сервис consul.
Проверить регистрацию.
Настроить проверку состояния.

Синтаксис для конфигурации при регистрации сервиса следующий:

Чтобы настройка применилась, перезагружаем консул.

Проверить, что сервис зарегистрировался можно в веб-панели. Также мы можем опросить сервис в DNS:

nslookup -port=8600 <тег>.<имя сервиса>.service.<датацентр>.<домен> <IP-адрес сервера консул>

dig @<IP-адрес сервера консул> -p 8600 <тег>.<имя сервиса>.service.<датацентр>.<домен>

* в боевой среде стоит настроить перенаправление запросов для домена консула (по умолчанию, consul) на серверы консула. Также для корректной работы многих приложений необходимо сделать так, чтобы консул отвечал на DNS-запросы по порту 53 — для этого можно использовать dnsmasq.

Более конкретно, мы рассмотрим настройки в примерах.

Для проверки состояния нашего сервиса используется конфигурация следующего вида:

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

Но чтобы это работало, в конфигурационном файле консула нужно добавить две строки:

.
"enable_local_script_checks": true,
"enable_script_checks": true
.

Перейдем к конкретике.

Примеры регистрации сервисов

По мере необходимости, я буду добавлять новые примеры.

0. Включение возможности делать проверку

Предварительно, разрешаем выполнение проверок. Для этого открываем наш конфигурационный файл консула:

.
"enable_local_script_checks": true,
"enable_script_checks": true

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

Проверяем конфигурационный файл и перезапускаем консул:

consul validate /etc/consul.d/

systemctl restart consul

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Configuration is valid!

. то с конфигурационным файлом все хорошо — можно продолжать.

systemctl restart consul

В панели управления должен появиться наш сервис:

nslookup -port=8600 web.service.dc1.consul 192.168.0.15

nslookup -port=8600 front.web.service.dc1.consul 192.168.0.15

. должен вернуть IP-адрес нашего сервера с агентом, например:

Non-authoritative answer:
Name: web.service.dc1.consul
Address: 192.168.0.100

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

systemctl restart consul

3. KeyDB (Redis)

KeyDB и Redis являются довольно популярными базами резидентского типа. Рассмотрим на примере первой процесс регистрации сервиса в Consul и проверки состояния, которое мы будем проверять с помощью скрипта.

Проверяем конфигурационный файл:

consul validate /etc/consul.d/

Создаем скрипт для проверки состояния базы:

if [ "$ping_check" = "PONG" ]
then
exit 0
else
exit 2
fi

Разрешим его запуск на исполнение:

chmod +x /scripts/keydb_check.sh

systemctl restart consul

Вывод из эксплуатации членов кластера

Рассмотрим процесс удаление сервисов и нод кластера.

Снятие с регистрации сервисов

consul catalog services

* где web — имя нашего сервиса, который необходимо снять с регистрации.

Удаление нод

На агенте вводим:

Если нам нужно форсированно удалить ноду, то с любого участника, где можно управлять кластером, вводим:

consul force-leave agent01

Возможные ошибки

При настройке агента мы можем столкнуться с различными проблемами. Для их решения нам может помочь команда:

Также рассмотрим те, с которыми столкнулся я.

No installed keys could decryp

Ошибка возникаем при попытке подключить узел к кластеру. В итоге мы не обнаруживаем его среди участников (когда смотрим командой consul members). При этом мы видим в логах ошибку

. No installed keys could decryp

Причина: мы указали неверное значение для параметра encrypt.

Решение: состоит из двух шагов — проверки значения encrypt и удаление временного файла, где хранится его значение.

Для начала смотрим на сервере конфигурационный файл и находим в нем значение для опции encrypt. Точно такое же значение должно быть и на клиенте.

Однако, этого недостаточно, так как после первого запуска был создан файл local.keyring, в котором хранится неправильное значение. Просто удаляем его:

rm -f /var/lib/consul/serf/local.keyring

* где /var/lib/consul — путь, который мы указали в конфигурационно файле агента.

Перезагружаем консул на агенте:

systemctl restart consul

Coordinate update blocked by ACLs

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

Причина: на сервере включен ACL и требуется дополнительная аутентификация.

Решение: на клиенте включаем ACL, а на сервере создаем токен. Подробнее процедура описана выше.

Поддержка этой версии Operations Manager прекращена. Рекомендуем перейти на Operations Manager 2019.

Эта статья содержит сведения о последней версии агента Linux для System Center Operations Manager 1801 и процесс его установки.

Эта версия агента Linux поддерживает сборщик данных для Linux с открытым исходным кодом (Fluentd), который собирает данные из многих источников. Мониторинг на основе OMI для поддерживаемых рабочих нагрузок Linux продолжит работать без изменений.

Новые возможности в версии 1801

Добавлен новый подключаемый модуль преобразователя, который позволяет пользователям использовать сторонние подключаемые модули для мониторинга файлов журнала Operations Manager.
Добавлена поддержка для проверки подлинности сервера.
Добавлена поддержка дополнительных дистрибутивов Linux.

Поддерживаемые платформы

В этом выпуске поддерживаются дистрибутивы Linux, перечисленные в следующей таблице.

Операционная система Linux	Поддерживаемая версия
Red Hat Enterprise Linux Server	5 (x86/x64) 6 (x86/x64) 7 (x86/x64)
Cent OS	5 (x86/x64) 6 (x86/x64) 7 (x64)
Ubuntu	12.04 LTS (x86/x64) 14.04 LTS (x86/x64) 16.04 LTS (x86/x64)
Debian	6 (x86/x64) 7 (x86/x64) 8 (x86/x64)
Oracle Linux	5 (x86/x64) 6 (x86/x64) 7 (x64)
SUSE Linux Enterprise Server	11 (x86/x64) 12 (x64)

<Обновление существующих агентов Operations Manager и OMS в настоящее время не поддерживается>.

Поддерживаемые конфигурации развертывания

Operations Manager поддерживает приведенные далее конфигурации отчетов агентов в группе управления.

Серверы Linux, отправляющие отчеты непосредственно на сервер управления.
Сервер Linux, отправляющий отчеты на сервер шлюза.
Серверы Linux, отправляющие отчеты на связанный сервер шлюза.

Установка агента

Вы можете установить последнюю версию агента Linux для Operations Manager с помощью автоматического обнаружения или вручную. Автоматическое обнаружение работает так же, как и в предыдущей версии. Используйте прежнюю процедуру, которая описана в этой статье.

Чтобы вручную установить агенты на компьютерах под управлением UNIX или Linux, выполните следующие процедуры. После импорта необходимых пакетов управления для конкретной версии UNIX или Linux, для которой вы настраиваете мониторинг, вы найдете пакеты агента в следующей папке на сервере управления: %ProgramFiles%\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Пакет управления размещается на установочном носителе Operations Manager в каталоге \ManagementPacks.

Установка вручную

Агент предоставляется в формате самораспаковывающегося устанавливаемого пакета сценария оболочки. Этот пакет содержит пакеты Debian и RPM для каждого из компонентов агента. Вы можете установить его напрямую или извлечь отдельные пакеты, которые вам нужны. Предоставляются отдельные пакеты для архитектур x64 и x86.

Для этого потребуется выполнить следующие действия.

Установите агент и зарегистрируйте Operations Manager в качестве рабочей области.
Откройте TCP-порт на сервере управления или сервере шлюза.
Настройте сертификат проверки подлинности сервера.
Определите сервер Linux с помощью мастера обнаружения.

В следующих разделах описаны шаги, позволяющие установить агент Linux вручную.

Установка агента

Пакеты установки агента вы можете найти в папке %Program Files%\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits. Перенесите нужный пакет (x86 или x64) на настраиваемый компьютер под управлением Linux с помощью команд scp или sftp.

Установите пакет, выполнив на компьютере следующую команду. Параметр enable-opsmgr открывает порт 1270 для взаимодействия агента с сервером управления.

sudo sh ./omsagent-1.4.0-45.universald.1.x64.sh --install --enable-opsmgr

Выполните команду omsadmin.sh, указав в качестве идентификатора рабочей области значение scom. Эту команду необходимо выполнять от имени пользователя root (с помощью команды sudo для повышения прав). Этот скрипт создает в папке /etc/opt/microsoft/omsagent/scom/certs/scom-cert.pem сертификат, для которого вы на следующем шаге получите подпись сервера управления.

/opt/microsoft/omsagent/bin/omsadmin.sh -w scom

В папке /etc/opt/microsoft/omsagent/scom/conf/ создайте файл конфигурации с именем omsadmin.conf и следующим содержимым. Введите имя компьютера и укажите номер 8886 для порта службы OMED.

Настройка TCP-порта для службы OMED

Чтобы включить сбор данных, в Operations Manager необходимо использовать TCP-порт 8886 для установления входящей связи между агентом Linux и сервером управления или сервером шлюза.

Настройка сертификатов

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

На компьютере под управлением Linux найдите файлы /etc/opt/omi/ssl/omi-host-<hostname>.pem и /etc/opt/microsoft/omsagent/scom/certs/scom-cert.pem и скопируйте их в любое расположение на сервере управления.

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

scxcertconfig -sign omi-host-<hostname>.pem omi_new.pem and scxcertconfig -sign scom-cert.pem scom-cert_new.pem

Скопируйте файл omi_new.pem в каталог /etc/opt/omi/ssl/ , а файл scom-cert_new.pem — в каталог /etc/opt/microsoft/omsagent/scom/certs/ на компьютере под управлением Linux. Удалите старые файлы сертификатов и присвойте их имена новым файлам сертификатов, чтобы заменить их.

Перезапуск агента

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

Обнаружение

После развертывания агентов на компьютерах UNIX и Linux вручную их все еще требуется обнаружить в Operations Manager с помощью мастера обнаружения. В поле "Тип обнаружения" выберите значение Обнаруживать только компьютеры с установленным агентом UNIX или Linux. Дополнительные сведения см. в статье Установка агента в операционные системы UNIX и Linux с помощью мастера обнаружения.

Установка агента ESET Management в ОС Linux выполняется с помощью команды в терминале. Убедитесь, что соблюдены все необходимые условия.

1. Загрузите сценарий установки агента:

2. Сделайте файл исполняемым:

chmod +x agent-linux-x86_64.sh

3. Запустите сценарий установки согласно примеру ниже (новые строки разделяются при помощи разделителя «\», что позволяет скопировать всю команду в терминал).

Установка с сервера

sudo ./agent-linux-x86_64.sh \
--skip-license \
--hostname=10.1.179.36 \
--port=2222 \
--webconsole-user=Administrator \
--webconsole-password=aB45$45c \
--webconsole-port=2223

Параметры

Подключение к ESET PROTECT Server разрешено с использованием параметров --hostname и --port (порт не используется, если указана запись SRV). Возможные форматы подключения:.

Имя хоста или IP-адрес ESET PROTECTServer, к которому нужно подключиться.

Порт сервера ESET PROTECT () (по умолчанию — 2222 )

Локальный путь к файлу сертификата агента (дополнительная информация о сертификате ).

Да (для автономной работы)

Путь к файлу центра сертификации сервера (дополнительные сведения о центре сертификации ).

Да (для автономной работы)

Пароль сертификата агента.

Да (для автономной работы)

Пароль центра сертификации.

Да (если он используется)

Во время установки от пользователя не потребуется подтверждение лицензионного соглашения.

— зашифрованное содержимое в кодировке Base64, принадлежащее сертификату открытого ключа в кодировке PKCS12, а также закрытый ключ, используемый для настройки защищенных каналов связи с сервером и агентами. Из параметров --cert-path или --cert-content используйте только один.

Зашифрованное содержимое в кодировке Base64, принадлежащее сертификату закрытого ключа центра сертификации в кодировке DER (этот сертификат используется для проверки удаленных узлов (прокси-серверов или серверов)). Из параметров --cert-auth-path и --cert-auth-content используйте только один.

Имя хоста или IP-адрес, используемый веб-консолью для подключения к серверу (если оставить пустым, будет скопировано значение параметра hostname).

Порт, с помощью которого веб-консоль подключается к серверу (значение по умолчанию — 2223 ).

Имя пользователя, с помощью которого веб-консоль подключается к серверу (значение по умолчанию — Administrator ).

Пароль, используемый веб-консолью для подключения к серверу.

Да (пароль системного администратора)

Если используется прокси-сервер

Программа по улучшению продуктов включается.

Программа по улучшению продуктов отключается.

Подключение и сертификаты

Параметры типа пароля

Параметры типа пароля могут быть указаны в качестве переменных среды, файлов, в формате обычного текста или считаны из stdin . Например:

--password=env:SECRET_PASSWORD , где SECRET_PASSWORD — это переменная среды с паролем;

--password=file:/opt/secret , где пароль содержит первая строка обычного файла /opt/secret ;

--password=stdin — средство установки должно считать пароль, указанный путем стандартного ввода;

параметр --password="pass:PASSWORD" равноценен параметру --password="PASSWORD" и является обязательным, если фактический пароль — это "stdin" (standard input) или строка, которая начинается со слов "env:" , "file:" или "pass:" .

Пароль сертификата не должен содержать следующие символы: " \ Эти символы вызывают критическую ошибку во время инициализации агента.

Как вы, возможно, уже знаете, в недалеком будущем увидит свет наш новый продукт — Veeam Agent for Linux. И уже сейчас все желающие могут оценить это решение в ходе анонсированной программы бета-тестирования. Чтобы получить доступ к бета-версии, нужно зарегистрироваться здесь, и вы получите на email ссылку для скачивания. Обратите внимание, что период бета-тестирования закончится 1 сентября 2016 года – затем вы сможете установить уже релизную версию.

Итак, что же умеет бета? За ответом добро пожаловать под кат.

Может использоваться как для виртуальных, так и для физических машин.
Работает с машинами семейств Debian и RedHat. Доступен в виде пакетов RPM и DEB.
Поддерживаются версии ядра Linux, начиная с 2.6.32 (т е. даже если у вас очень старенькая инсталляция, то и она будет поддержана при условии, что у вас стоит официальное ядро для данного дистрибутива).
Работает с 32-битной и 64-битной архитектурой.

Veeam Agent for Linux Service – компонент, отвечающий за работу со всеми задачами и необходимыми ресурсами. Регистрируется как обычный сервис, автоматически стартует при старте ОС и работает в фоновом режиме.
Veeam Agent for Linux Job Manager – процесс, который запускается вышеназванным сервисом для каждой сессии задания резервного копирования и отвечает за ее работу.
Veeam Agent – это, собственно, рабочая лошадка, которая выполняет операции передачи данных: во время бэкапа копирует их в репозиторий, а во время восстановления – наоборот, а также выполняет дедупликацию, компрессию, и т.д.
Veeam Agent for Linux Driver – модуль ядра Linux, который отвечает за создание снапшотов томов вашей машины.
SQLite database engine — используется для хранения конфигурации; если у вас его нет – то поставится в процессе установки продукта.

Для работы решения необходимо наличие пакета Dynamic Kernel Module Support (DKMS), который требуется для компиляции модуля ядра, а также пакета LVM2, который требуется для поддержки операции с томами LVM. Если их нет на машине, то установите их – к примеру, DKMS на CentOS можно поставить из дополнительного репозитория EPEL.

После того, как прошла установка первого компонента, можно переходить к установке собственно Veeam Agent for Linux (для установки понадобятся права root):

Агент Veeam Agent for Linux устанавливается в виде сервиса, с которым затем можно работать, применяя команду veeamconfig. Для просмотра списка ее опций после команды veeamconfig введите --help. Ну и затем можно переходить уже непосредственно к работе – а там уже практически все понятно и без подсказок, но мы все же вкратце рассмотрим сначала процесс бэкапа.

Вводим имя, которое хотим дать заданию.
На шаге Backup mode выбираем, хотим ли мы бэкапить всю машину (Entire machine), какой-либо том (Volume level backup) или отдельные файлы и папки (File level backup):
Затем указываем тип репозитория (Destination Location), куда будут сохраняться резервные копии. Если репозитория у нас еще нет, то мастер попросит его создать. В качестве репозитория поддерживаются:
- устройства с прямым подключением (USB, eSATA, FС и т.п.)
- сетевые файловые системы NFS, SMB (CIFS)
- локальное устройство хранения (не рекомендуется)
В данном примере в качестве репозитория выбирается папка NFS с общим доступом:

Наше задание успешно отработало, и на экране появилась соответствующая информация в поле Status:

В репозитории на NFS-сервере теперь лежат файлы резервной копии (.VBK и .VBM), поименованные согласно названию задания и времени создания:

Имея резервную копию, можно посмотреть, как Veeam Agent for Linux умеет выполнять восстановление Linux-сервера на уровне файла, тома, или же вообще «на голое железо» — но об этом в следующем посте.

Читайте также: