ВИЗИТКА 



Aнтон Абрамов,
старший программист «Базальт СПО»

Linux-инструмент диагностики
с графическим интерфейсом – Alt Diagnostic Tool

Администратор Linux получает GUI запуска привычных скриптов для системных тестов, пользователь – удобные инструменты поиска неполадок, а техподдержка – отчет со стороны клиентов.

В материале пойдет речь про описание утилиты, подготовку и работу с ней, а также приводятся примеры скриптов для системных администраторов, которые бы хотели самостоятельно автоматизировать тестирование Linux-систем в организации.

1. Определение ADT

Активное замещение коммерческих западных цифровых систем в России с 2022 года положило начало широкому распространению операционных систем, создаваемых национальными командами разработчиков. Многие команды собирают дистрибутивы на основе открытой разработки ядра Linux. Необходимость массового внедрения Linux-подобных систем породила целый набор специфических требований к дистрибутивам.

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

Рисунок 1: Внешний вид ALT Diagnostic Tool

Рисунок 2: Интерфейсы и методы объекта на шине D-Bus

Разработка «Базальт СПО», о которой пойдет речь – это графическое и терминальное приложение ALT Diagnostic Tool  (ADT) – инструмент диагностики операционной системы. ADT предназначен для запуска инструментов с тестами системы. Это может быть проверка состояния компьютера в домене, диагностики интернет-соединения, здоровья жесткого диска или стабильности RAID-массива.

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

Программа ADT предназначена для:

1. Системных администраторов.
2. Опытных пользователей.
3. Службы технической поддержки.

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

Цель ALT Diagnostic Tool – предоставить удобный интерфейс запуска диагностических инструментов. Такие инструменты можно поместить в инструменты диагностики – формат работы ADT. Файлы со скриптами инструментов упакованы в пакеты и выполняются без привилегий суперпользователя.

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

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

Утилита предоставляет следующие возможности:

1. Проводить диагностику системы посредством набора подготовленных тестов.
2. Выводить на экран результаты диагностики.
3. Сохранять файл журнала с результатами диагностики.
4. Выполнять операции, требующие привилегий, от учетной записи непривилегированного пользователя.

2. Работа с ADT

ADT вызывает методы через системную шину системы межпроцессного взаимодействия D-Bus. Такой подход имеет ряд преимуществ:

• Совместимость со всеми приложениями демона D-Bus.
• Независимость от окружения рабочего стола.
• Безопасное выполнение действий с привилегиями суперпользователя.
• Возможности по ограничению запуска методов через сценарии polki.;
• Управление polkit-ограничениями через групповые политики.

Рисунок 3: Список доступных тестов инструмента диагностики

Для пользователя работа с ADT сводится к трем шагам: установке пакета приложения, установке пакетов диагностических инструментов, запуску установленного приложения из системного меню или через терминал.

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

При централизованном управлении в «Альт Домене» есть возможность установки пакетов с ADT и инструментами диагностики через групповые политики. Для этого используется машинная политика установки пакета на целевые рабочие места. В ряде случаев администратору необходимо запускать приложения в привилегированном режиме, но на сторонних рабочих местах у пользователя не должно быть доступа к учетной записи локального администратора.

Большое преимущество ADT – запуск любых тестов диагностики не требует (!) привилегий суперпользователя. То есть администратору достаточно установить в систему пакет, попросить пользователя выполнить тест, и переслать файл с отчетом.

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

3. Разработка собственных инструментов диагностики

Важная деталь – ADT специально спроектирован так, чтобы пользователи могли создавать собственные скрипты диагностики. Опытный администратор, владеющий навыками скриптовых языков, достаточно быстро сможет создать файлы собственных тестов. ADT быстро подхватит backend-файлы новых инструментов с тестами проверки.

Для нового инструмента диагностики потребуется: исполняемый файл скрипта, файл с описанием тестов диагностики *.Diagnostictool (или *.Diag), backend-файл с описанием интерфейсов объекта для шины D-Bus.

Исполняемый файл может быть написан на любом языке, который поддерживает операционная система. Требования к файлу: вывод списка тестов через ключ «-l», вывод отчета с результатом тестирования через ключ «-r».

Тип backend-файла описывает D-Bus интерфейс и его методы. На основании backend-файла alterator-module-executor создаст на шине D-Bus и зарегистрирует интерфейсы. В тексте описания указывается несколько секций: «Alterator Entry», «Info», «Run», «List», «Report».

В первой секции указываются сведения о создаваемом интерфейсе на шине D-Bus. В этой секции обязательны пять ключей: Module (модуль обработки backend-файла), Interface (D-Bus интерфейс, для описания которого создан файл), Name (имя объекта), thread_limit (максимальное число тредов), action_id (ключ для утилиты polkit).

Секции «Info», «Run», «List», «Report» описывают методы создаваемого интерфейса – информация, запуск, список [тестов], отчет. В этих же секциях указывается путь к исполняемому файлу скрипта и внутренние параметры.

Тип файла Diagnostictool описывает тесты в составе инструмента диагностики – перечень для отображения на экране пользователю и описание. В этом файле один обязательный ключ – Name (уникальное имя теста) и три вспомогательных – DisplayName (отображаемое имя),  Comment (краткое описание), Icon (отображаемый значок).

Трех указанных файлов – исполняемого, backend, diagnostictool – уже достаточно, чтобы на системной шине D-Bus появился новый интерфейс с методами, а приложение ADT считало параметры этого интерфейса и отобразило на экране.

Общий вид путей для файлов с установкой из пакета:

/usr/share/alterator/backends/<уникальное имя>.backend
/usr/share/alterator/diagnostictools/<название инструмента>/<уникальное имя инструмента>.diagnostictool

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

/etc/alteratot/backends/<уникальное имя>.backend
/etc/alterator/diagnostictools/<название инструмента>/<уникальное имя инструмента>.diagnostictool

4. Безопасность

У специалиста – системного администратора, читающего материал, – появится закономерный вопрос об уязвимостях ALT Diagnostic Tool. Предположим, пользователь (без прав учетной записи root) создаст сценарий командной оболочки bash c командой «rm -rf /» внутри файла, добавит к нему соответствующие diag- и backend-файлы, запустив все это через ADT. Что станет с системой после запуска такого «теста»? Отследим цепочку выполнения элементов утилиты.

Чтобы запустить исполняемый файл необходим файл .backend. Этот файл описывает D-Bus интерфейсы и методы. На основании .backend-файлов alterator-module-executor создаст и зарегистрирует на D-Bus соответствующие объекты. Модуль альтератора требует сохранять .backend-файлы для интерфейса ADT в директориях: /usr/share/alterator/backends/, либо /etc/alterator/backends/. Права на запись и исполнение в директориях /usr и /etc регулирует администратор. По умолчанию в системе установлен запрет на создание файлов в указанных директориях и подкаталогах без прав суперпользователя. Следовательно, ADT не создает дополнительную уязвимость для администратора рабочего места.

5. Тест-драйв

Чтобы посмотреть работу приложения ADT в операционной системе Альт, достаточно выполнить команды:

$su-
#apt-get update
#apt-get dist-upgrade
#apt-get install adt, domain-diag

Тем, кто заинтересуется разработкой собственных тестов для ADT, рекомендуем также ссылки на спецификацию, шаблон примера, документацию и открытый код разработки приложения.

1. Шаблон примера инструмента диагностики https://gitlab.basealt.space/alt/diag-example
2. Код проекта https://gitlab.basealt.space/alt/adt
3. Спецификация https://gitlab.basealt.space/alt/alterator-entry/-/blob/master/doc/README.md

Ключевые слова: Альт, Linux, диагностика, тест, Alt Diagnostic Tool, D-Bus

Подпишитесь на журнал

Комментарии могут оставлять только зарегистрированные пользователи