Я с вами полностью согласен и не претендую на гуру модулей. Просто показал с чего начал, для чего была необходимость, а модуль появился уже для другой задачи, и решил весь путь объединить в статью.
Конечно, буду разбираться с модулями и автотестами благодаря сообществу!
Ну и вам спасибо, что хоть и критикуете, но говорите о правильных вещах и по делу.
Приветствую, так я и сказал вот мой пр, чтобы люди после статьи могли придти и посмотреть.
А линтеры поругались только на тесты в их ci/cd. А сам код уже все ок, там все поправлено и сделано.
А с тестами сложно протестировать этот модуль в рамках ci/cd, так как опыт написания тестов у меня не большой и я попросил помощи коллег в ПР с тестами.
Приветствую! Очень подробно и по теме, но не со всем я готов согласиться. На то это и форум, где каждый говорит что думает, а мой код - это опенсорс, и любой может прийти и добавить комментарии в PR.
Отказались от публичного, поддерживаемого API
Я не отказался, а как вы правильно указали сделал углубленное изучение общения утилиты и системы. Далее просто убрал утилиту, и общаюсь самостоятельно, минуя proxy в лице sssctl
Про «минимальное количество зависимостей» особенно показательно
Dbus-python vs sssd-tools — это переход от функциональной зависимости к системной абстракции. D-Bus — это стандартный системный IPC-механизм, который уже присутствует в любом современном дистрибутиве. Это как заменить прямой вызов конкретной программы на использование системного сокета.
Жёсткая привязка к infopipe
Жёсткая привязка к infopipe — но это и есть официальный публичный D-Bus интерфейс SSSD, зарегистрированный в системе. Это не reverse engineering, а использование предоставленного разработчиками SSSD API, который более стабилен, чем парсинг CLI вывода.
Зависимость от конкретной реализации SSSD
Dbus-python является стандартной библиотекой для работы с системной шиной, тогда как sssd-tools — это специфичная утилита конкретного пакета. Первая является частью экосистемы системного программирования на Python, вторая — внешней CLI обёрткой.
Заметный прирост производительности» без единого замера — это отдельный жанр технической фантастики
Вы правы в том, что я не предоставил детальных замеров производительности — это действительно упущение, которое стоило бы исправить.
Однако позвольте объяснить, почему даже без точных цифр этот подход даёт системные преимущества.
Вы утверждаете, что sssctl тоже использует D-Bus, но здесь есть принципиальная разница: прямой вызов метода против запуска процесса, который внутри себя делает тот же вызов.
Даже если накладные расходы на запуск процесса составляют миллисекунды, в контексте Ansible-модуля, выполняющегося на сотнях хостов, эта разница становится значимой.
Но что ещё важнее — это качество интеграции. Для модуля Ansible, который должен быть предсказуемым и лёгким, прямой D-Bus вызов — это более чистая архитектура, даже если абсолютный прирост скорости измеряется миллисекундами на одном вызове.
Хардкод путей вида: /org/freedesktop/sssd/infopipe/Domains/{domain.replace(".", "_2e")}
Путь /org/freedesktop/sssd/infopipe/Domains/{domain} — это не хардкод в смысле "зашитых значений", а следование документально зафиксированной схеме D-Bus именования, которую использует сам SSSD.
Кодирование точки как _2e — это стандартное преобразование D-Bus для специальных символов в object paths, а не произвольное решение.
Важный нюанс: если разработчики SSSD изменят эту схему путей в будущей версии, то сломается не только мой код, но и любой другой софт, использующий этот интерфейс, включая потенциально GUI-утилиты и системные мониторинговые инструменты. D-Bus интерфейсы, особенно зарегистрированные в системе, имеют определённые ожидания стабильности.
Ansible-модуль — отдельная категория
Мой PR открыт для комментариев, на то это и open-source
Так я разработчик AstraWizard, я пишу то, что хочу.
Я делаю тесты и показываю их не видео.
Я не пишу что-то просто, чтобы делать тесты на молекуле.
Это не обычные роли или коллекции, которые легко проверить, учитывая всю мою обертку на баш и гуи.
Я не заявлял , что я пишу что-то на ansible , я сказал я его использую под капотом, чтобы удаленно выполнять то, что моя первая версия софта делала локально через баш.
PR принят, в ближайшие недели ожидается релиз в 12.2 версии
Я с вами полностью согласен и не претендую на гуру модулей. Просто показал с чего начал, для чего была необходимость, а модуль появился уже для другой задачи, и решил весь путь объединить в статью.
Конечно, буду разбираться с модулями и автотестами благодаря сообществу!
Ну и вам спасибо, что хоть и критикуете, но говорите о правильных вещах и по делу.
Приветствую, так я и сказал вот мой пр, чтобы люди после статьи могли придти и посмотреть.
А линтеры поругались только на тесты в их ci/cd. А сам код уже все ок, там все поправлено и сделано.
А с тестами сложно протестировать этот модуль в рамках ci/cd, так как опыт написания тестов у меня не большой и я попросил помощи коллег в ПР с тестами.
Приветствую! Очень подробно и по теме, но не со всем я готов согласиться.
На то это и форум, где каждый говорит что думает, а мой код - это опенсорс, и любой может прийти и добавить комментарии в PR.
Я не отказался, а как вы правильно указали сделал углубленное изучение общения утилиты и системы.
Далее просто убрал утилиту, и общаюсь самостоятельно, минуя proxy в лице sssctl
Dbus-python vs sssd-tools — это переход от функциональной зависимости к системной абстракции. D-Bus — это стандартный системный IPC-механизм, который уже присутствует в любом современном дистрибутиве. Это как заменить прямой вызов конкретной программы на использование системного сокета.
Жёсткая привязка к infopipe — но это и есть официальный публичный D-Bus интерфейс SSSD, зарегистрированный в системе. Это не reverse engineering, а использование предоставленного разработчиками SSSD API, который более стабилен, чем парсинг CLI вывода.
Dbus-python является стандартной библиотекой для работы с системной шиной, тогда как sssd-tools — это специфичная утилита конкретного пакета. Первая является частью экосистемы системного программирования на Python, вторая — внешней CLI обёрткой.
Вы правы в том, что я не предоставил детальных замеров производительности — это действительно упущение, которое стоило бы исправить.
Однако позвольте объяснить, почему даже без точных цифр этот подход даёт системные преимущества.
Вы утверждаете, что sssctl тоже использует D-Bus, но здесь есть принципиальная разница: прямой вызов метода против запуска процесса, который внутри себя делает тот же вызов.
Даже если накладные расходы на запуск процесса составляют миллисекунды, в контексте Ansible-модуля, выполняющегося на сотнях хостов, эта разница становится значимой.
Но что ещё важнее — это качество интеграции. Для модуля Ansible, который должен быть предсказуемым и лёгким, прямой D-Bus вызов — это более чистая архитектура, даже если абсолютный прирост скорости измеряется миллисекундами на одном вызове.
Путь /org/freedesktop/sssd/infopipe/Domains/{domain} — это не хардкод в смысле "зашитых значений", а следование документально зафиксированной схеме D-Bus именования, которую использует сам SSSD.
Кодирование точки как _2e — это стандартное преобразование D-Bus для специальных символов в object paths, а не произвольное решение.
Важный нюанс: если разработчики SSSD изменят эту схему путей в будущей версии, то сломается не только мой код, но и любой другой софт, использующий этот интерфейс, включая потенциально GUI-утилиты и системные мониторинговые инструменты.
D-Bus интерфейсы, особенно зарегистрированные в системе, имеют определённые ожидания стабильности.
Мой PR открыт для комментариев, на то это и open-source
https://github.com/ansible-collections/community.general/pull/11120
Супер! Спасибо что подробно и по теме.
Благодарю за информацию
Так понимаю не open-source, а чисто идея и общий концепт разобран? Или можно подглядеть ваши исходнички?
пока что нет.
В скором времени будет доступно начиная с версии 3.0.0.
https://www.tadviser.ru/index.php/Статья:Алексей_Фоменко,_Группа_Астра:_служба_каталога_ALD_Pro_трансформирует_разрозненную_ИТ-инфраструктуру_в_управляемую_систему?erid=no
Можно оформить ПР. Я буду только рад развитию проекта с помощью сообщества
Согласен, есть что доработать.
Но пароль не видно в открытом виде нигде.
History и логи не видно пароля, насколько я смотрел.
Так я разработчик AstraWizard, я пишу то, что хочу.
Я делаю тесты и показываю их не видео.
Я не пишу что-то просто, чтобы делать тесты на молекуле.
Это не обычные роли или коллекции, которые легко проверить, учитывая всю мою обертку на баш и гуи.
Я не заявлял , что я пишу что-то на ansible , я сказал я его использую под капотом, чтобы удаленно выполнять то, что моя первая версия софта делала локально через баш.
спасибо я знаю в чем разница.
Проекту более 2-х лет. Использования bash не более чем мое удобство, и не желания плодить множество файлов с шаблонами.
Данный код не виден конечному пользователю, а красота для меня стоит на втором месте, после функционала полезного конечному пользователю.
В планах конечно и переписать на питон.
И оформить в роли может быть некоторые таски.
Ну и добавить хендлеры, темплейты для конфигов.
Просто раньше писал, чтобы работало , так как хотел много функционала сразу реализовать.
Все замечания учитываю и поддерживаю , что best practices никто не отменял
Да согласен, что все можно было использовать.
Но тут и простая работа написана 2 года назад.
Я раньше не топил за красоту кода.
Щас я уже пишу нормальные роли:) просто нет времени переписать весь код. Об этом еще в 1 статье говорил. И про fqcn и так далее.
?
То что я не кладу готовый кофеин в правлю его на удаленной тачке ?
?
То, что я не использовать модуль ?
Первый проект помогатор, был полностью на bash.
Исходники у меня в гите также есть
Ansible использовал чтобы админы не ходили ножками на 100500 компов.
А так все мои плейбуки можно переписать под баш и использовать чисто их.
То есть просто кладем баш на тачку заходим по ссш и запускаем и все
Ну странно имхо это все.
А так ну оценка не главное, главное чтобы люди кто и до этого пользовался проектом поняли его суть
Да я знаю что площадка хабр цениться своими ценителями и оценщиками.
Ведь главное не содержимое статьи , а то что человек написал во вступление.
Знаете что такое помощь людям?
Опенсорс?
Деньги не решают все на свете, хоть и бывает выгорание, но когда люди пишут в лс или почту и благодарят за проекты, и как они ими пользуются я рад.
А работа и зп у меня и так есть