Product SiteDocumentation Site

Глава 7. Решение проблем

7.1. Диагностика
7.1.1. Инструмент диагностики состояния контроллера домена
7.1.2. Инструмент диагностики клиента домена
7.1.3. ALT Diagnostic Tool

7.1. Диагностика

7.1.1. Инструмент диагностики состояния контроллера домена

diag-domain-controller — инструмент диагностики состояния контроллера домена.
diag-domain-controller содержит набор проверок и тестов, по результатам которых можно определить корректность настроек компьютера для работы в качестве контроллера домена. diag-domain-controller имеет модульную структуру. Модули можно вызывать общим списком или отдельно.
Установка:
 apt-get install diag-domain-controller
Синтаксис:
 diag-domain-controller [options] [<diagnostic-task>]
где diagnostic-task — название функции из списка тестов. Если не указывать название функции, будут запущены все тесты.
Возможные опции:
  • -l, --list — вывести список тестов;
  • -V, --version — вывести версию и выйти;
  • -h, --help — показать справку и выйти.
Возможные состояния тестов:
  • DONE — успешное выполнение модуля;
  • WARN — предупреждение для некритических тестов в модуле;
  • FAIL — неудачное выполнение теста.
В таблице Тесты diag-domain-controller приведены тесты, доступные в diag-domain-controller в настоящее время.

Таблица 7.1. Тесты diag-domain-controller

Тест
Описание
is_domain_info_available
Проверка доступности просмотра общей информации о домене
is_hostname_correct
Проверка правильного написания доменного имени узла
is_not_empty_sysvol
Проверяет, содержит ли файлы каталог sysvol
is_samba_package_installed
Проверяет, установлен ли в системе пакет Samba (samba-dc или samba-dc-mitkrb5)
is_samba_service_running
Проверяет, запущена ли служба Samba
are_there_errors_in_samba_databases
Проверяет наличие ошибок в базах Samba
is_ntp_service_running
Проверяет, включена ли синхронизация времени
Примеры (команды запускаются на контроллере домена):
  • вывести список тестов:
    $ diag-domain-controller -l
    is_domain_info_available
    is_hostname_correct
    is_not_empty_sysvol
    is_samba_package_installed
    is_samba_service_running
    are_there_errors_in_samba_databases
    is_ntp_service_running
    
  • запустить тест is_domain_info_available:
    $ diag-domain-controller is_domain_info_available
    is_domain_info_available
    [DONE]: is_domain_info_available
    
  • запустить все тесты:
    $ diag-domain-controller
    [DONE]: is_domain_info_available
    [DONE]: is_hostname_correct
    [DONE]: is_not_empty_sysvol
    [DONE]: is_samba_package_installed
    [DONE]: is_samba_service_running
    [FAIL]: are_there_errors_in_samba_databases
    [WARN]: is_ntp_service_running
    

7.1.2. Инструмент диагностики клиента домена

diag-domain-client — инструмент диагностики состояния клиента домена.
diag-domain-client содержит набор проверок и тестов, по результатам которых можно определить корректность настроек компьютера для работы в домене, а также убедиться, что доступны все необходимые ресурсы домена. diag-domain-client имеет модульную структуру. Модули можно вызывать общим списком или отдельно.
Утилита позволяет записать результат в log-файл. Процесс диагностики зависит от того, находится ли компьютер в домене или нет. Выполнение некоторых проверок требует полномочий суперпользователя. Для корректной работы необходимо получить Kerberos-билет доменного пользователя.
Установка:
 apt-get install diag-domain-client
Синтаксис:
 diag-domain-client [options] [<test-function-name>]
где test-function-name — название функции из списка тестов. Если не указывать название функции, будут запущены все тесты.
Возможные опции:
  • -h, --help — показать справку и выйти;
  • -V, --version — вывести версию и выйти;
  • -v, --verbose — подробный вывод;
  • -w[FILE], --logfile[=FILE] — записать подробный вывод в файл по указанному пути. Если файл не указан, вывод будет записан в файл ./diag-domain-client.log. В случае если файл уже существует, то запись производится в файл с постфиксом (например, diag-domain-client.log.1, diag-domain-client.log.2 и т.д.);
  • -f, --force — принудительная запись в существующий файл;
  • -l, --list — вывести список тестов.
Возможные состояния тестов:
  • DONE — успешное выполнение модуля;
  • SKIP — пропуск проверки, если проверка выполняется без полномочий суперпользователя;
  • WARN — предупреждение для некритических тестов в модуле;
  • FAIL — неудачное выполнение теста.
Если компьютер введен в домен, утилита diag-domain-client выдаёт FAIL для тех проверок, когда несоответствие проверяемого элемента приводит к неработоспособности машины в домене. При выполнении программы не суперпользователем некоторые проверки могут быть пропущены (SKIP) или находиться в состоянии WARN. В случае успешного выполнения отображается статус DONE.
В таблице Тесты и проверки diag-domain-client приведены тесты и проверки, доступные в diag-domain-client в настоящее время.

Таблица 7.2. Тесты и проверки diag-domain-client

Тест/Проверка
Описание
check_hostnamectl
Отображает полную информацию о узле и соответствующие настройки: имя, значок, система, версия ядра, архитектура, информация о виртуализации (при наличии)
test_hostname
Проверяет, является ли имя компьютера полностью определенным именем домена (FQDN)
check_system_auth
Отображает метод аутентификации пользователей, используемый в подсистеме PAM (sss, winbind — компьютер введен в домен, local — не введен). Выводит содержимое файла /etc/pam.d/system-auth
is_samba_package_installed
Проверяет, установлен ли в системе пакет Samba (samba-dc или samba-dc-mitkrb5)
test_domain_system_auth
Проверяет, подходит ли метод аутентификации для работы машины в домене (допустимые значения: sss, winbind)
check_system_policy
Отображает, какие политики применяются в процессе PAM-аутентификации: local — никакие, gpupdate — локальные и доменные
test_gpupdate_system_policy
Проверяет, настроено ли применение групповых политик в системе
check_krb5_conf_exists
Проверяет наличие, отображает права доступа и содержимое файла конфигурации krb5.conf
check_krb5_conf_ccache
Отображает текущий способ кеширования Kerberos-билетов — keyring, file, dir
test_keyring_krb5_conf_ccache
Проверяет настроенный способ кеширования Kerberos-билетов (для keyring)
check_krb5_conf_kdc_lookup
Проверяет включен ли поиск Kerberos-имени домена через DNS. Допустимыми значениями для «dns_lookup_kdc» в /etc/krb5.conf являются — true/yes
check_krb5_keytab_exists
Проверяет наличие, права доступа и дату последнего изменения файла /etc/krb5.conf. В этом файле хранятся принципалы и хеши пароля доменной учётной записи компьютера
check_keytab_credential_list
Отображает содержимое файла /etc/krb5.conf (файл с учётными данными машинного пользователя). В этом файле хранятся принципалы и хеши пароля доменной учётной записи компьютера.
Требуется запуск от root, иначе SKIP
check_resolv_conf
Проверяет наличие и выводит содержимое файла конфигурации разрешения имен resolv.conf
compare_resolv_conf_with_default_realm
Сравнивает домен для поиска (поле search в /etc/resolv.conf) с доменом по умолчанию, указанным для Kerberos
check_smb_conf
Проверяет наличие и выводит содержимое файла настроек конфигурации Samba
compare_smb_realm_with_krb5_default_realm
Сравнивает домен, указанный в файле конфигурации Samba, с доменом по умолчанию, указанным для Kerberos
test_smb_realm
Проверяет корректное заполнение информации о домене в конфигурационных файлах Samba и Kerberos
test_domainname
Сверяет доменное имя из /etc/hostname с именем домена в составе FQDN-имени узла
check_time_synchronization
Отображает настройку синхронизации времени с сервером; выводит подробную информацию — часовой пояс, временную зону и т.д. Необходимо для корректной работы с сертификатами, электронной подписью, билетами Kerberos
test_time_synchronization
Проверяет, включена ли синхронизация времени
check_nameservers
Проверяет доступность всех контроллеров домена по имени (host <domain FQDN>) и IP-адресу (работает ли resolv.conf)
check_domain_controllers
Проверяет доступность всех контроллеров домена в домене (из srv-записей). Отображает версии контроллеров домена (из LDAP)
check_kerberos_and_ldap_srv_records
Проверяет наличие srv-записей вида _kerberos._udp.<domain FQDN> и _ldap._tcp.<domain FQDN> для домена. Требуется для корректной работы машины в домене. Без записей Kerberos, sssd и winbind не смогут найти контроллеры домена
compare_netbios_name
Сравнивает короткое имя машины из /etc/hostname с NetBios-именем машины в smb.conf
check_common_packages
Проверяет наличие установленных основных пакетов и их версий (alterator-auth, libnss-role, libkrb5 и libsmbclient)
check_group_policy_packages
Проверяет наличие установленных основных пакетов и их версий для управления групповыми политиками (local-policy и gpupdate)
check_sssd_ad_packages
Проверяет наличие установленного мета-пакета и его версии для аутентификации c помощью sssd (task-auth-ad-sssd)
check_sssd_winbind_packages
Проверяет наличие установленного мета-пакета и его версии для аутентификации c помощью winbind (task-auth-ad-winbind)
Примеры:
  • вывести список тестов:
    $ diag-domain-client -l
    check_hostnamectl
    test_hostname
    check_system_auth
    test_domain_system_auth
    check_system_policy
    test_gpupdate_system_policy
    check_krb5_conf_exists
    check_krb5_conf_ccache
    test_keyring_krb5_conf_ccache
    check_krb5_conf_kdc_lookup
    check_krb5_keytab_exists
    check_keytab_credential_list
    check_resolv_conf
    compare_resolv_conf_with_default_realm
    check_smb_conf
    compare_smb_realm_with_krb5_default_realm
    test_smb_realm
    test_domainname
    check_time_synchronization
    test_time_synchronization
    check_nameservers
    check_domain_controllers
    check_kerberos_and_ldap_srv_records
    compare_netbios_name
    check_common_packages
    check_group_policy_packages
    check_sssd_ad_packages
    check_sssd_winbind_packages
    
  • запустить тест check_smb_conf:
    $ diag-domain-client check_smb_conf
    is_domain_info_available
    [DONE]: is_domain_info_available
    
  • запустить тест check_krb5_conf_kdc_lookup с подробным выводом информации:
    $ diag-domain-client check_krb5_conf_kdc_lookup -v
    ===============================================================================
    | Samba environment diagnostic tool |
    -------------------------------------------------------------------------------
    Version: 0.2.8
    Date: Ср 09 окт 2024 12:54:51 EET
    -------------------------------------------------------------------------------
    System information
    Kernel: 5.10.212-std-def-alt1
    Branch: p10
    ===============================================================================
    
    ===============================================================================
    | check_krb5_conf_kdc_lookup |
    -------------------------------------------------------------------------------
    
    /etc/krb5.conf: dns_lookup_kdc is enabled
    
    -------------------------------------------------------------------------------
    Check DNS lookup kerberos KDC status: [DONE]
    ===============================================================================
    
  • запустить все тесты:
    $ diag-domain-client
    Check hostname persistance: [DONE]
    Test hostname is FQDN (not short): [DONE]
    System authentication method: [DONE]
    Domain system authentication enabled: [DONE]
    System policy method: [DONE]
    System group policy enabled: [DONE]
    Check Kerberos configuration exists: [DONE]
    Kerberos credential cache status: [DONE]
    Using keyring as kerberos credential cache: [DONE]
    Check DNS lookup kerberos KDC status: [DONE]
    Check machine crendetial cache is exists: [DONE]
    Check machine credentials list in keytab: [SKIP]
    Check nameserver resolver configuration: [DONE]
    Compare krb5 realm and first search domain: [DONE]
    Check Samba configuration: [DONE]
    Compare samba and krb5 realms: [DONE]
    Check Samba domain realm: [DONE]
    Check hostname FQDN domainname: [DONE]
    Check time synchronization: [DONE]
    Time synchronization enabled: [WARN]
    Check nameservers availability: [WARN]
    Check domain controllers list: [FAIL]
    Check Kerberos and LDAP SRV-records: [DONE]
    Compare NetBIOS name and hostname: [DONE]
    Check common packages: [DONE]
    Check group policy packages: [DONE]
    Check SSSD AD packages: [DONE]
    Check SSSD Winbind packages: [WARN]
    
  • записать вывод теста check_krb5_conf_kdc_lookup в файл /tmp/diag-domain-client.log:
    $ diag-domain-client check_krb5_conf_kdc_lookup -w/tmp/diag-domain-client.log
    Check DNS lookup kerberos KDC status: [DONE]
    
    просмотреть содержимое файла /tmp/diag-domain-client.log:
    $ cat /tmp/diag-domain-client.log
    ===============================================================================
    | Samba environment diagnostic tool |
    -------------------------------------------------------------------------------
    Version: 0.2.8
    Date: Ср 09 окт 2024 12:54:24 EET
    -------------------------------------------------------------------------------
    System information
    Kernel: 5.10.212-std-def-alt1
    Branch: p10
    ===============================================================================
    
    ===============================================================================
    | check_krb5_conf_kdc_lookup |
    -------------------------------------------------------------------------------
    
    /etc/krb5.conf: dns_lookup_kdc is enabled
    
    -------------------------------------------------------------------------------
    Check DNS lookup kerberos KDC status: [DONE]
    ===============================================================================
    

7.1.3. ALT Diagnostic Tool

ALT Diagnostic Tool (ADT) — приложение для диагностики ОС с графическим и терминальным интерфейсом.
Утилита ADT позволяет:
  • проводить диагностику системы посредством набора подготовленных утилит;
  • выводить на экран результаты диагностики;
  • сохранять файл журнала с результатами диагностики;
  • выполнять операции, требующие привилегий, от учетной записи непривилигированного пользователя.
Программа ADT предназначена для:
  • системных администраторов;
  • опытных пользователей;
  • службы технической поддержки.
Запуск инструментов диагностики регулируется системным администратором, позволяя создавать отчеты пользователям, не передавая им административные полномочия.

7.1.3.1. Установка

Для работы с ADT необходимо установить:
  • ADT (пакет adt);
  • диагностические инструменты (например, пакеты diag-domain-client, diag-domain-controller).
Установка ADT:
# apt-get install adt
Установка инструментов диагностики состояния клиента домена и состояния контроллера домена:
# apt-get install diag-domain-client diag-domain-controller

7.1.3.2. Работа с ADT

Запустить и добавить в автозагрузку службу alterator-manager:
# systemctl enable --now alterator-manager.service
Запустить ADT можно:
  • из командной строки:
    $ adt
  • в рабочей среде Mate: МенюСистемныеADT;
  • в рабочей среде KDE5: Меню запуска приложенийНастройкиADT.
Внешний вид программы ADT без установленных инструментов диагностики:
Интерфейс ADT без установленных инструментов диагностики
Внешний вид программы ADT с инструментами диагностики:
Интерфейс ADT с установленными инструментами диагностики
Для выбора набора тестов следует дважды щелкнуть мышью по его названию, либо выделить набор и нажать кнопку Выбрать инструмент. Откроется окно с набором тестов инструмента:
ADT. Набор тестов для диагностики клиента домена
В области управления инструментом диагностики доступны опции: Отчет, Запустить все тесты, Назад. Напротив каждого теста находятся кнопки Запустить и Журнал.
Нажатие на кнопку Запустить все тесты запускает весь набор тестов выбранного инструмента:
ADT. Результат выполнения набора тестов
Для того чтобы запустить отдельный тест, необходимо нажать кнопку Запустить, расположенную справа от названия теста:
ADT. Запуск отдельного теста
Нажатие на кнопку Журнал выводит отчет теста от утилиты инструмента диагностики (если инструмент поддерживает такую возможность):
ADT. Отчет теста
Для поиска конкретного теста среди доступных можно воспользоваться строкой Фильтр:
ADT. Фильтр
Для сохранения полного отчёта инструмента в файл (если инструмент поддерживает такую возможность) следует нажать кнопку Отчет на панели инструментов:
ADT. Сохранение отчета в файл

Примечание

Для возможности генерирования файла с отчетом, инструмент диагностики должен поддерживать опции -r, --report.

7.1.3.3. Руководство администратора

7.1.3.3.1. Компоненты
Alterator-manager — модульный сервис, предназначенный для конфигурации посредством D-Bus. Весь функционал реализуется в виде модулей, а интерфейсы описываются в конфигурационных файлах «alterator entry».
Система межпроцессного взаимодействия D-Bus — механизм для обмена сообщениями между различными программами в ОС. D-Bus позволяет программам отправлять сообщения и вызывать методы других программ, обеспечивая совместную работу и координацию между приложениями. D-Bus представляет из себя совокупность следующих шин:
  • Системная шина — создаётся при старте демона D-Bus. Предназначена для взаимодействия между различными системными службами, а также взаимодействие пользовательских приложений с этими службами;
  • Сессионная шина — создаётся для каждого пользователя во время авторизации как отдельный экземпляр. Предназначена для взаимодействия между пользовательскими приложениями в рамках одной сессии.
На шинах D-Bus регистрируются службы, предоставляющие определенные функции. Они могут быть как частью операционной системы, так и сторонними приложениями.
Для каждой службы заводятся объекты, представляющие собой абстракции реальных ресурсов или служб.
У каждого объекта есть один или несколько интерфейсов, которые определяют, какие действия можно совершить с объектом. Интерфейсы описывают методы (функции), которые можно вызвать, свойства, которые можно запросить или изменить, и сигналы, которые объект может отправлять.
Объекты, создаваемые службами. Каждая служба может создавать объекты, которые представляют собой абстракции реальных ресурсов или служб. Например, служба сетевого менеджера может предоставлять объекты для каждого сетевого соединения.
Интерфейсы объектов. У каждого объекта есть один или несколько интерфейсов, которые определяют, какие действия можно совершить с объектом. Интерфейсы описывают методы (функции), которые можно вызвать, свойства, которые можно запросить или изменить, и сигналы, которые объект может отправлять.
Каждая служба поддерживающая D-Bus представлена в виде объектов на этих шинах. А взаимодействие между ними осуществляется посредством интерфейсов и методов этих объектов.
На системной шине методы запускаются с правами root и имеют высокие привилегии. На сессионной шине методы запускаются с правами пользователя и не имеют доступа к системным ресурсам, которые требуют высоких привилегий. С точки зрения alterator-manager диагностический инструмент является объектом на D-Bus, описанном в двух файлах «alterator entry»:
  • .backend — описывает интерфейс диагностического инструмента, обеспечивающий взаимодействие с D-Bus. В нем же описываются методы интерфейса: info, run, list, report;
  • .diagnostictool — описывает отображение диагностического инструмента в ADT. Содержит информацию о тестах, доступных в рамках описываемого диагностического инструмента.
alterator-module-executor — модуль альтератора для обработки файлов .backend и запуска исполняемых файлов.
7.1.3.3.2. Алгоритм работы
Алгоритм работы ALT Diagnostic Tool:
  1. Systemd служба alterator-manager во время запуска создает на шине D-Bus службу с именем «ru.basealt.alterator».
  2. Systemd служба alterator-module-executor собирает информацию из файлов .backend обо всех установленных диагностических инструментах и создает объекты на системной и сессионных (в зависимости от расположения backend-файлов) шинах D-Bus с именами вида «ru.basealt.alterator.<имя инструмента>».
  3. ADT формирует список диагностических инструментов, обращаясь к D-Bus и получая информацию обо всех объектах сервиса «ru.basealt.alterator», имеющих интерфейс «ru.basealt.alterator.diag1».
  4. Для каждого диагностического инструмента ADT вызывает на D-Bus метод List, чтобы получить список всех возможных тестов.
  5. ADT запускает через D-Bus метод Run, передав ему в качестве параметра имя теста.
  6. По коду возврата ADT получает информацию об успешном/не успешном прохождении теста, а из данных, полученных из stderr и stdout формирует журнал выполнения теста.
Блок-схема взаимодействия компонентов:
Блок-схема взаимодействия компонентов
7.1.3.3.3. Разработка инструмента диагностики
7.1.3.3.3.1. Формат файлов инструмента диагностики
Минимальный набор файлов для инструмента диагностики в ADT:
  • исполняемый файл;
  • файлы .backend и .diagnostictool (или .diag), описывающие сущности Alterator Entry.

Примечание

Оба варианта .diagnostictool и .diag считаются верными.
7.1.3.3.3.2. Требования к исполняемому файлу
Исполняемый файл может быть как бинарным, так и текстовым (написанным на интерпретируемом языке). Файл должен поддерживать запуск в следующем виде:
/путь_к_исполняемому_файлу {param}
где {param} — означает имя теста, который необходимо выполнить.
При успешном завершении теста исполняемый файл должен завершиться с кодом возврата 0. При не успешном завершении теста — с кодом возврата отличным от 0.
Лог выполнения нужно выводить в стандартный вывод.
Необходима также поддержка следующих ключей:
  • -l или --list — вывод списка тестов. Список необходимо выводить в стандартный вывод. Имя каждого теста должно быть с новой строки;
  • -r или report — сгенерировать файл с отчетом. Файл с отчетом может представлять собой как текстовые данные, так и бинарные (например, архив). Его содержимое необходимо направить в стандартный вывод. ADT получит этот вывод и сохранит в файл с именем вида «имя_инструмента_дата» и суффиксом, указанным в файле .diagnostictool.
Исполняемый файл рекомендуется разместить в каталоге согласно стандарту FHS (Filesystem Hierarchy Standard).
7.1.3.3.3.3. Рекомендации к файлам .backend и .diagnostictool
Для описания файлов .backend и .diagnostictool следует воспользоваться спецификацией Alterator Entry
Файлы .backend и .diagnostictool являются текстовыми и содержат описание в виде секций. Синтаксис файлов:
[имя секции1]
Поле1 = значение
Поле2 = значение
ПолеN = значение
[имя секции2]
Поле1 = значение
Поле2 = значение
ПолеN = значение
[имя секцииN]
Поле1 = значение
Поле2 = значение
ПолеN = значение
При этом следует учитывать:
  • все поля чувствительны к регистру и должны начинаться с заглавной буквы;
  • перед и после знака «=» пробелы;
  • значения полей указываются без кавычек;
  • значения могут содержать пробелы;
  • сли строка начинается с символа «#», то она считается комментарием и при чтении информации из файла игнорируется.
Имя каталога должно соответствовать суффиксу в имени файла:
  • ./backends для файла .backend;
  • ./diagnostictools для файла .diagnostictool (или .diag).
7.1.3.3.3.3.1. Файл .diagnostictool
Файл .diagnostictool имеет имя вида <имя диагностического инструмента>.diagnostictool.
Если разрабатываемый диагностический инструмент предполагается распространять, то файлы сущностей необходимо разместить в каталоге /usr/share/alterator/diagnostictools/. В противном случае, рекомендуется использовать каталог /etc/alterator/diagnostictools/.
Файл .diagnostictool содержит информацию для GUI Он включает секцию [Alterator Entry] и секции, описывающие варианты тестирования.
Секция [Alterator Entry]:
  • [Alterator Entry]
    • Name — идентификатор инструмента (имя без пробелов);
    • Type — всегда Diagnostictool;
    • DisplayName — имя инструмента;
    • DisplayName[локаль] — имя инструмента, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали;
    • Comment — описание инструмента;
    • Comment[локаль] — описание, выводящиеся в GUI, если используется интерфейс с использованием указанной в скобках локали;
    • Icon — имя файла с иконкой;
    • ReportSuffix — суффикс файла с отчетом. Этот файл будет создаваться при вызове метода Report.
  • Секции, описывающие варианты тестирования:
    • [Название секции соответствует названию теста]
    • DisplayName — идентификатор теста (имя без пробелов);
    • DisplayName[локаль] — имя теста, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали;
    • Comment — описание теста;
    • Comment[локаль] — описание теста, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали.
7.1.3.3.3.3.2. Файл .backend
Файл .backend имеет имя вида <имя диагностического инструмента>.ru.basealt.alterator.backend.
Если разрабатываемый диагностический инструмент предполагается распространять, то файлы сущностей необходимо разместить в каталоге:
  • /usr/share/alterator/backends/system — если объект необходимо создать на системной шине;
  • /usr/share/alterator/backends/user — если объект необходимо создать на сессионной шине;
В противном случае, рекомендуется использовать каталог:
  • /etc/alterator/backends/system/ — если объект необходимо создать на системной шине;
  • /etc/alterator/backends/user/ — если объект необходимо создать на сессионной шине;
Секция [Alterator Entry] описывает информацию об объекте и содержит следующие поля:
  • [Alterator Entry]
    • Type — содержит тип метода. Всегда имеет значение Backend;
    • Module — всегда executor;
    • Name — идентификатор инструмента (имя без пробелов);
    • Interface — идентификатор интерфейса. Имеет значение ru.basealt.alterator.diag1. Можно сократить до diag1;
    • thread_limit — указывает максимальное число потоков при одновременном выполнении нескольких методов.
Секция Info описывает метод Info и содержит следующие поля:
  • [Info]
    • execute — в качестве параметра необходимо передать команду, выводящую содержимое файла .diagnostictool (cat <путь к файлу>);
    • stdout_bytes — всегда enabled;
    • thread_limit — всегда 3;
    • action_id — содержит идентификатор метода. Всегда имеет значение Info.
Секция Run описывает метод Run и содержит следующие поля:
  • [Run]
    • execute — содержит строку для запуска тестов вида <путь к исполняемому файлу> {param};
    • stdout_signal_name — всегда diag1_stdout_signal. ADT ожидает сигнал с таким именем;
    • stderr_signal_name — всегда diag1_stderr_signal. ADT ожидает сигнал с таким именем;
    • action_id — содержит идентификатор метода. Всегда имеет значение Run.
Секция List описывает метод List и содержит следующие поля:
  • [List]
    • execute — содержит команду для вывода списка всех возможных тестов в виде <путь к исполняемому файлу> -l;
    • stdout_strings — всегда enabled;
    • action_id — содержит идентификатор метода. Всегда имеет значение List.
Секция Report содержит следующие поля:
  • [Report]
    • execute — содержит команду для создания отчета в виде <путь к исполняемому файлу> -R;
    • stdout_bytes — всегда enabled;
    • action_id — содержит идентификатор метода. Всегда имеет значение Report.
7.1.3.3.4. Пример инструмента диагностики
Ниже представлен пример диагностического инструмента для определения производителя материнской платы.
Пример состоит из трех файлов:
  • исполняемый файл: /usr/bin/diag-example;
  • файл .backend: /usr/share/alterator/backends/diag-example.backend;
  • файл .diag, описывающий тесты: /usr/share/alterator/diagnostictools/diag-example.diag.
7.1.3.3.4.1. Исполняемый файл
Содержимое исполняемого файла /usr/bin/diag-example:
#!/bin/bash
#
# Copyright (c) 2024 Evgeny Sinelnikov <sin@altlinux.org>
#
# Example diagnostic tool
#
# SPDX-License-Identifier: GPL-2.0-or-later
#

set -euo pipefail

. shell-getopt

PROG="${0##*/}"
PROG_VERSION='0.0.1'

cmd="run"
global_retval=0

print_version()
{
cat <<EOF
$PROG version $PROG_VERSION
Written by Evgeny Sinelnikov <sin@altlinux.org>

Copyright (C) 2024 Evgeny Sinelnikov <sin@altlinux.org>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
EOF
exit
}

show_usage()
{
cat <<EOF
$PROG - example diagnostic tool.

Usage: $PROG [options] [<diagnostic-task>]

Options:
-l, --list                list of diagnostic tasks;
-V, --version             print program version and exit;
-h, --help                show this text and exit.

Report bugs to https://bugzilla.altlinux.org/

EOF
exit
}

TEMP=$(getopt -n "$PROG" -o "l,V,h" -l "list,version,help" -- "$@") || show_usage
eval set -- "$TEMP"

while :; do
case "$1" in
    --) shift; break
        ;;
    -l|--list) cmd="list";
        ;;
    -V|--version) print_version
        ;;
    -h|--help) show_usage
        ;;
    *) fatal "Unrecognized option: $1"
        ;;
esac
shift
done

task_list="$*"

task_show()
{
local func="$1"

echo "$func"
}

task_run()
{
local retval=126
local func="$1"

if test -n "$task_list"; then
    echo "$task_list" | tr ' ' '\n' | grep -q "^$func\$" ||
        return 0
fi

$func && retval=0 || retval="$?"
test $retval = 0 || global_retval=1

return $retval
}

task()
{
local task="$1"

case "$cmd" in
    list) task_show "$task"
        ;;
    run) task_run "$task" && echo "[DONE]: $task" || echo "[FAIL]: $task"
        ;;
    *) fatal "Unrecognized command: $cmd"
        ;;
esac
}

is_gigabyte()
{
/usr/sbin/dmidecode -s baseboard-manufacturer | grep -q "^Gigabyte Technology"
}

is_std_def_kernel_running()
{
uname -r | grep -q '^[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+-std-def-'
}

task is_gigabyte
task is_std_def_kernel_running

exit "$global_retval"
7.1.3.3.4.2. Файл .backend
Содержимое файла /usr/share/alterator/backends/diag-example.backend:
[Alterator Entry]
Type = Backend
Module = executor
Name = diag_example
Interface = diag1

[Info]
execute = cat /usr/share/alterator/diagnostictools/diag-example.diag
stdout_bytes = enabled
stdout_byte_limit = 200000
action_id = Info

[Run]
execute = diag-example {param}
stdout_signal_name = diag_example_stdout_signal
stderr_signal_name = diag_example_stderr_signal
thread_limit = 1
action_id = Run

[List]
execute = diag-example -l
stdout_strings = enabled
stdout_strings_limit = 200000
action_id = List
7.1.3.3.4.3. Файл .diag, описывающий тесты
Содержимое файла /usr/share/alterator/diagnostictools/diag-example.diag:
[Alterator Entry]
Type = diag
Name = Example
DisplayName = Diagnostic tool example
DisplayName[ru] = Пример инструмента диагностики
Comment = Diagnostic tool comment
Comment[ru] = Комментарий к диагностическому инструменту
Icon = system-run

[is_gigabyte]
DisplayName = Is motherboard manufacturer — Gigabyte?
DisplayName[ru] = Производитель материнской платы — Gigabyte?
7.1.3.3.4.4. Отображение диагностического инструмента в интерфейсе ADT

Примечание

Для того чтобы новый диагностический инструмент отображался интерфейсе ADT, необходимо перезапустить alterator-manager:
# systemctl restart alterator-manager.service
Пример отображения диагностического инструмента в интерфейсе ADT
Набор тестов инструмента

7.1.3.4. Ошибки и нестандартные случаи

Если диагностический инструмент не отображается, необходимо проверить объект alterator-manager с именем ru.basealt.alterator на системной шине D-Bus:

Примечание

Для этого можно использовать утилиту D-Feet (пакет d-feet):
D-Feet