Для перемещения по дереву справки используйте строки заголовка.

Справка по NSG Linux 2.1.1
Дерево команд: services.autoconf-server.kick-values.…далее…

Что это такое?

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

Зачем это нужно?

Чтобы передавать клиентам указующие и направляющие пинки.

Как это настроить?

Команды @kick генерируют в системе событие, для которого именем виртуального датчика будет sys.kick. и имя клиента или группы, соответственно, а состояние датчика — одно из выбранных при исполнении команды. Это событие поступает в локальный обработчик событий (здесь же, на этом сервере). В обработчике должно быть определено соответствующее событие и, в зависимости от выбранного способа управления, настроено необходимое действие. Например, сервер может зайти на клиента по SSH (если этот механизм заранее настроен) и выполнить на нём некоторую команду. Или послать на клиента управляющее SMS. Или написать на заборе опубликовать на брокере MQTT сообщение типа "Вася лох"; прочитав его, клиент "Вася" должен понять, что он находится в состоянии "лох", и принять соответствующие меры; дальнейшая настройка этих действий выполняется на клиенте. Подробно см. пример ниже.

Список состояний, доступных в выпадающем меню команд @kick, формируется пользователем в данном пункте. Для добавления команд в список используйте команды +, _new или _insert. Данный список является нумерованным и упорядочивается автоматически; нумерация определяет порядок элементов в меню @kick. Для удаления используйте команду - или _remove.

Что делать, если это не работает?

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


Пример конфигурации

Предположим, что для для централизованного управления клиентами в некоторой конкретной системе необходимо предусмотреть следующие операции:

autoconf-server
: kick-values
: : 1 = reconfigure
: : 2 = reboot
: : 3 = update-software
: : 4 = restart-m1
: : 5 = restart-m2

При этом в системе определены группа mytestgroup и в ней клиент ATM001. Для группы и для клиента имеется команда @kick:

autoconf-server
: clientconf
: : mytestgroup
: : : @kick =[        ▾] ▸
: : : ATM001
: : : : @kick =[        ▾] ▸

Меню каждой из команд содержит 5 пунктов, определённых выше. Например, если выбран первый пункт меню, то при выполнении команд генерируются события, соответственно:

sys.kick.mytestgroup = reconfigure
sys.kick.ATM001 = reconfigure

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

event-handler
: event-actions
: : mqttpub
: : : myasskick
: : : : topic = "nsg/sys/kick"
: : : : server = "127.0.0.1:1883"
: 1
: : virt-sensor = "sys.kick.*"
: : action = "#mqttpub.myasskick"
mqtt
: enable = true
: : conf
: : : acl_file = false
: : : allow_anonymous = true
: : : password_file = false

В результате в теме nsg/sys/kick будет опубликовано сообщение (в формате JSON — по умолчанию), соответственно:

{"sensor_name":"sys.kick.mytestgroup","sensor_value":"reconfigure","timestamp":"время"}

или

{"sensor_name":"sys.kick.ATM001","sensor_value":"reconfigure","timestamp":"время"}

(Можно также использовать формат sensor_value, но JSON удобнее и универсальнее.)

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

event-handler
: event-generators
: : mqttsub
: : : myasskick
: : : : topic = "nsg/sys/kick"
: : : : server = "ip.адрес.сервера.mqtt:1883"
: : : : sensor-name = "$.sensor_name"
: : : : sensor-value = "$.sensor_value"

и обработку этих событий:

event-handler
: 1
: : virt-sensor = "sys.kick.ATM001"
: : state = "reconfigure"
: : script = "nsgsh -f30 \\".system.autoconf(enable=true _apply)\\""
: 2
: : virt-sensor = "sys.kick.ATM001"
: : state = "reboot"
: : script = "reboot"
: 3
: : virt-sensor = "sys.kick.ATM001"
: : state = "update-software"
: : script = "nsgupdate -if ftp://our.corporate.ru/nsg-linux-custom-current/nsg1700-image.bin"
: : script-timeout = 3600
: 4
: : virt-sensor = "sys.kick.ATM001"
: : state = "restart-m1"
: : script = "nsgsh -qr .port.m1.restart=nil"
: 5
: : virt-sensor = "sys.kick.ATM001"
: : state = "restart-m2"
: : script = "nsgsh -qr .port.m2.restart=nil"
: 6
: : virt-sensor = "sys.kick.mytestgroup"
: : state = "reconfigure"
: : script = "nsgsh -f30 \\".system.autoconf(enable=true _apply)\\""
: 7
: : virt-sensor = "sys.kick.mytestgroup"
: : state = "reboot"
: : script = "reboot"
: 8
: : virt-sensor = "sys.kick.mytestgroup"
: : state = "update-software"
: : script = "nsgupdate -if ftp://our.corporate.ru/nsg-linux-custom-current/nsg1700-image.bin"
: : script-timeout = 3600
: 9
: : virt-sensor = "sys.kick.mytestgroup"
: : state = "restart-m1"
: : script = "nsgsh -qr .port.m1.restart=nil"
: 10
: : virt-sensor = "sys.kick.mytestgroup"
: : state = "restart-m2"
: : script = "nsgsh -qr .port.m2.restart=nil"

Всего рассматриваются 5 состояний двух датчиков. Показания других датчиков (например, sys.kick.ATM002) игнорируются.

ПРИМЕЧАНИЕ. Для обновления программного обеспечения (события 3 и 8) использована фирменная утилита nsgupdate. Предполагается, что каждая новая версия выкладывается в одно и то же указанное место под одним и тем же именем.
Результат автоматического обновления ПО не может быть гарантирован (например, из-за чрезмерной фрагментации оперативной памяти в результате длительной работы), поэтому его необходимо контролировать с помощью внешней ситемы мониторинга или вручную (хотя бы по факту перезагрузки и переподключения клиента).

Таким образом, исполнение на сервере команды

.services.autoconf-server.clientconf.mytestgroup.ATM001.@kick=reconfigure

будет приводить к повторному запросу конфигурации на клиенте ATM001, а исполнение команды

.services.autoconf-server.clientconf.mytestgroup.@kick=reconfigure 

— к повторному запросу конфигурации на всех клиентах, входящих в группу mytestgroup.

ПРИМЕЧАНИЕ. В шаблоне конфигурации клиентов удобно описывать виртуальные датчики как sys.kick.$(ID) и sys.kick.$(GROUP), соответственно.

© Network Systems Group 2015–2024 Отдел документации