Авторские статьи

Заметки при изучении ALD Pro и использовании в производстве.


Решил зафиксировать в виде заметок изучение ALD Pro и использование в производстве с версии 2.3.0, которая находится на раннем своём этапе развития и полна детских болячек. Чтобы не выносить сор из избы, разработчики Астры прикрыли баг-трекер и теперь всё делается через выделенные каналы поддержки. Данная статья не повод оскорблять Астру, но повод поделиться с вами решёнными проблемами, особенно если вы, так же как и я, вынуждены осваивать функционал ALD Pro в рамках импортозамещения. Чем старее событие, тем оно будет ниже в тексте статьи.

Обновлено на дату 28.11.2024

Оглавление

Компонентная схема ALD Pro
Документация ALD Pro
Что пока не нравится
ALD Pro 2.3.0. Ноябрь 2024
ALD Pro 2.3.0. Июль 2024
ALD Pro 1.4.1 не ищет по атрибутам, кроме дефолтных. Июль 2023
ALD Pro 1.4.1 при установке удаляет ntp, а потом использует его вместо chrony. Июль 2023
Помарка с zabbix-agent'ом. Июнь 2023
Снова не применяются настройки серверов времени. Октябрь 2022
Я сломал Salt. Октябрь 2022
Неработоспособность раздела Пользователи при огромном количестве учётных записей. Август 2022
Проблема с развёртыванием сервера событий. Август 2022
Безграничный журнал Bind. Август 2022
Мониторинг не собирается мониторить. Август 2022
Не применяются настройки серверов времени. Июль 2022
Поломка Справочного Центра. Июль 2022
Поломка системы после ввода мониторинга. Июль 2022
Нельзя русскую букву Ё в русской службе каталога. Июль 2022
Ошибки развёртывания сервера мониторинга. Июль 2022
Ошибки запроса к LDAP по мере ввода букв. Июль 2022
Полезные видеоматериалы ALD Pro на моём канале


Компонентная схема ALD Pro

Компонентная схема устройства Astra Linux Directory Pro для лучшего понимания что спрятано под капотом и как увязано с друг другом для простоты администрирования рядовым администратором.

Новая актуальная компонентная схема устройства Astra Linux Directory Pro.

Новая компонентная схема устройства Astra Linux Directory Pro

Старая компонентная схема устройства Astra Linux Directory Pro для истории. Сыграй в игру - найди отличия!

Старая компонентная схема устройства Astra Linux Directory Pro


Документация ALD Pro

Где брать инструкции ALD Pro?

Всегда отслеживайте в обновлённом руководстве актуальные пути к репозиторию и даты изменения содержимого https://dl.astralinux.ru/aldpro/frozen/01/


Что пока не нравится

Ещё раз напомню, что я не хейтер Astra Linux вообще и ALD Pro в частности. Я линуксоид, хоть и люблю службу каталогов Microsoft Active Directory, так как она мне известна и близка. Но я открыт к новому и к другим концепциям таких каталогов как FreeIPA под капотом у ALD Pro.

  • Мне не нравится, что ответственные архитекторы в Астра, которые должны более тщательно выбирать на основе каких продуктов open source будет в дальнейшем базироваться ALD Pro, постоянно меняют коней на переправе. Эти архитекторы мало и плохо думают заранее, а потом это всё обычно выливается в ошибки и проблемы при обновлении продукта. ALD Pro напоминает больше вулкан, чем стабильную и понятную систему.

    Были замены:

    1. В ALD Pro с версии 1.2.0 произведён переход с dnsmasq на isc-dhcp-server.
    2. Журнал событий в ALD Pro до версии 2.0.0 и ниже основан на решении Fluentd. Журнал событий в ALD Pro после версии 2.0.0 и выше основан на open source решении Syslog-ng.
  • При установке даже актуальной версии ALD Pro можно наблюдать в пробегающих строках и потом в журналах надписей что не найден такой-то файл, PostgreSQL 10 ругается что русская доменная система вместо ГОСТа использует устаревший американский MD5 и что он уже запрещён (Deprecated). Такие вещи портят первое впечатление.
  • Версия ALD Pro уже 1.x, но продукт ещё сырой и тянет на альфу. Тем самым разработчики нарушили негласное правило, указав 1.х как некую готовность к производству. На словах у них всё типа готово, а в логах строки вида - использование settings.DEBUG приводит к утечкам памяти и настоятельно запрещается использовать в производственной среде.

    [2022-08-23 06:06:53,229: WARNING/MainProcess] /usr/lib/python3/dist-packages/celery/fixups/django.py:204: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!

  • Много торчало ушей в ранних версиях ALD Pro жёстковшитых параметров типа ASTRA.LOCAL, паролей Admin:zabbix и SSH логин saltuser с паролем qwerty$4 в файле /etc/salt/master.d/master.conf. Представляете у всех одни и те же пароли. Вот радость то местным кулхацкерам. В актуальных версиях ALD Pro ситуацию исправили, создав файлы *.env в каталоге /etc/aldpro/
  • Архитектурно ALD Pro намекает на армаду серверов хоть и виртуальных с нехилыми требованиями, что для небольших контор будет более чем затратно и избыточно. Не в укор, но для MS AD достаточно для надёжности через избыточность добавить ещё 1 или 2 сервера-контроллера домена, разнести роли хозяев операций (Flexible single-master operations, FSMO) и получить действительно отказоустойчивую систему с master-to-master репликацией. Даже потом, разумно нагружая 2-3 сервера дополнительными ролями, можно удержаться от разрастания серверной платформы. А в ALD Pro намёк что чуть ли не с пелёнок вынь да полож over 8 серверов и получишь все плюшки.
  • Общее пока впечатление что тестированием ALD Pro толком никто не занимается. Нет человека, который просто бы взял ALD Pro, и без всяких средств оркестровки создал ручками вымышленную контору Рога и Копыта, заполнил бы руками поля-атрибуты пользователей, присоединил бы к домену пару-тройку клиентских ПК, добавил дополнительные сервера в армаду и т.д. Очень смешные ошибки и банальные.


ALD Pro 2.3.0. Ноябрь 2024

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

Ожидание удалённой сессии от пользователя ломает портал управления ALD Pro

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

Портал ALD Pro сломан. Только рестарт.

Если получится выйти из портала, то уже невозможно зайти снова. Помогает перезагрузка Apache - sudo systemctl restart apache2.

Ошибка была связана с тем что нами на сетевом UTM UserGate не были созданы разрешающие правила на доступ с контроллеров домена в сторону клиентских ПК порт 30000 (Список портов ALD Pro). Это нас не извиняет, но в оправдание скажу что в рамках ВКС сам разработчик признал это недоработкой фронтенда, где такую ситуацию с подключением к удалённому клиенту можно и нужно делать в отдельном потоке с разумными таймаутами. ALD Pro должна прощать ошибки, а не исходить из идеальных, эталонных условий.


ALD Pro 2.3.0. Июль 2024

  1. Выполнял в точности пункт "2.5.2 Установка и продвижение резервного контроллера через портал управления" из документации "01_Руководство_администратора_по_установке_и_обновлению_2.3.0_v3.pdf". Задание автоматизации завершается ошибкой. В рамках тикета дали дельные советы как начать с нуля, оформил в виде статьи Повторный ввод в домен ALD Pro сервера-контроллера или клиентского компьютера.
  2. Попросил помощи в рамках тикета "Разделение прав доступа к устройствам CD/DVD для доменных групп". Нужно было создать две доменные группы для ограничения доступа на клиентcких ПК к оптическим приводам только на чтение (группа cdrom_ro) и на чтение-запись (группа cdrom_rw). В Астре по умолчанию любой пользователь имеет доступ к оптическому приводу.

    В рамках тикета выяснили что официальная статья "Разделение прав доступа к устройствам CD/DVD" просто не рабочая и написана от балды. 🤦🏻‍♂️

    Кратко по инструкции нужно было якобы сделать следующее:

    • Создать файл /usr/lib/udev/rules.d/71-uacess-astra.rules (правильнее для linux систем перекрывающие правила создавать в /etc/udev/rules.d/71-uacess-astra.rules, ну да ладно - не будем придираться к неработающей инструкции) с содержимым:
      SUBSYSTEM=="block", KERNEL=="sr[0-9]*", TAG-="uaccess", RUN+="/usr/bin/setfacl -b %E{DEVNAME} ; /usr/bin/setfacl -m g:cdrom_rw:rw %E{DEVNAME} ; /usr/bin/setfacl -m g:cdrom_ro:r %E{DEVNAME}", RUN+="/usr/bin/logger 'Astra UDEV: set access for device %E{DEVNAME}'"
    • После перезагрузки компьютера или команды sudo udevadm control --reload-rules && sudo udevadm trigger через команду udevadm info -q all -n /dev/sr0 | grep TAG
      E: ID_PATH_TAG=pci-0000_00_01_1-ata-2
      E: TAGS=:systemd:seat:

      Вы наблюдаете что тег uaccess точно снят и TAG-="uaccess" работает!

    • Команда getfacl /dev/sr0 показывает что стандартные права linux выставлены как root:cdrom (0660), а значит что setfacl -b %E{DEVNAME} очистила все расширенные ACL. А два вызова setfacl дал двум доменным группам требуемое (-m g:cdrom_rw:rw и -m g:cdrom_ro:r).
      # file: dev/sr0
      # owner: root
      # group: cdrom
      user::rw-
      group::rw-
      group:cdrom_ro:r--
      group:cdrom_rw:rw-
      mask::rw-
      other::---
    • В этом месте уже точно стало понятно что официальная статья полное фуфло, хотя в ней есть раздел "Настройка прав доменных пользователей", где с умным видом описано требуемое, но, как оказалось, недостижимое в Astra Linux + ALD Pro. Совет специалиста заменить user на group sed -i 's/user,noauto/group,noauto/' /etc/fstab вдохнул надежду, но она быстро угасла.
      Читая man 8 mount про group
      Позволяет обычному пользователю (т.е., не суперпользователю) монтировать файловую систему, если он является членом одной из групп, которой принадлежит устройство.

      Я сделал предположение, что фраза "если он является членом одной из групп" скорее всего означает ТОЛЬКО системную группу, но не группу, добавленную через setfacl (ACL). Специалист Астры это подтвердил и стало окончательно понятно что не реализовать задумку с доменными группами.

    • Напомню вам что права 0660 дают членам системной группы cdrom права чтение-запись (rw), но монтирование оптического диска под учётной записью пользователя из группы cdrom показывало read-only.
      mount /dev/sr0 /media/cdrom
      mount: /media/cdrom0: WARNING: device write-protected, mounted read-only.
    • В итоге пришлось отказаться от задумки по разграничению прав доступ в домене ALD Pro на неопределённый срок. Возможно, в будущем это можно будет реализовать легко и просто, как расписывают это менеджеры Астры.
  3. Что нужно знать про роли, привилегии и разрешения?
    Права доступа в службе каталога FreeIPA назначаются с помощью трехуровневой модели безопасности, которая включает в себя Роли (Roles), Привилегии (Privileges) и Разрешения (Permissions). На базовом уровне разрешениям соответствуют инструкции управления доступом 389 Directory Server (Access Control Instructions, ACI), с помощью которых можно предоставить доступ на чтение, запись, поиск и другие действия применительно ко всему каталогу, его ветке или конкретной записи. Разрешения группируются в привилегии, привилегии группируются в роли, а роли уже назначаются пользователям.

    Тренировался делать роль для наших операторов, которые будут работать с учётными записями пользователей. Создал роль, в неё добавил через графический интерфейс портала ALD Pro все привилегии, хоть как-то связанные с User.

    У оператора под его учётной записью в разделе Пользователи в карточке любого пользователя ошибку с нехваткой прав на выполнение данной операции видно только во вкладке "Дополнительные сведения" и "Групповые политики".

    Тикет впервые решался не только в текстовой переписке, а специалист Астры видел мой рабочий стол и управлял моими действиями. Обратите внимание, что специалист попросил сразу переключиться в графический интерфейс FreeIPA вместо родного ALD Pro, так как в родном интерфейсе этого сделать невозможно!!! Добавили в мою роль привилегию ALDPRO - User Reader, а ведь она не отображалась в родном интерфейсе.

    Затем попросил создать с нуля (!) привилегию readgp (ReadGroupPolicy) и наполнить её нужными разрешениями, но в данном месте веб-интерфейс FreeIPA начал выдавать внутреннюю ошибку. Потратив впустую время, мы сделали данный момент в консоли: ipa privilege-add-permission "readgp" --permissions='ALDPRO - Read Group Policies' --permissions='ALDPRO - Read Group Policy Configurations' --permissions='ALDPRO - Read Group Policy Parameters' --permissions='ALDPRO - Read Group Policy Templates'

    А уже потом снова в графике добавили в мою роль новосозданную readgp. В финале вроде исправили ошибку и тикет я закрыл, но осадочек остался.

    На скриншоте не отображена полоса вертикальной прокрутки, но числу 16 можно верить.

    ALD Pro отображает привилегии в конкретной роли

    Наиболее полно отображает в графике FreeIPA и консольная команда ipa role-show 'Моя роль'. Привилегий в моей роли реально 19.

    FreeIPA отображает привилегии в конкретной роли

  4. Вышеописанные ошибки оказалось что были связаны с вводом ранее мной команды из официальной инструкции ipa privilege-add-permission 'Host Enrollment' --permissions='System: Add Hosts'. Специалист Астры подтвердил это, сломав ею свой тестовый стенд. Удаление System: Add Hosts из Host Enrollment не возвращает ситуацию к работоспособному состояние и откату проблемы. Тикет переведён в состояние - подтверждён разработчиками. Более подробно в Как сломать ALD Pro?
  5. Хотел создать для своих коллег роль, где они видят (чтение, read) все возможности ALD Pro в графическом интерфейсе портала управления, но могут что-то менять только в определённых разделах (например Пользователи и Компьютеры, Групповая Политика, Автоматизация).

    Ответ:
    По результату проверки на тестовом стенде выявлено, что в текущей версии продукта, привилегии со значением Read не включают отображение соответствующих разделов на Веб портале ALD Pro. Содержимое отображается в случае выдачи привилегий на полный доступ.

    По информации от разработчиков, штатными средствами создать пользовательскую роль, отвечающую описанным Вами требованиям, в ALD Pro версии 2.3.0 создать невозможно. Ролевое управление групповыми политиками, политиками ПО и заданиями автоматизации будет реализовано в ALD Pro версии 2.4.0, выпуск которой назначен на осень 2024 года.

  6. В домене ALD Pro есть группа lpadmin (UID 113). Добавление в неё доменных учётных записей в теории даёт доступ к принтерам на клиентских ПК. Подразумевается что и на клиентских ПК у всех есть локальная группа lpadmin c UID 113, но это не так! Установка Astra Linux на различные системы с различным форм-фактором не гарантирует что группа lpadmin определённо будет с UID 113. Тикет переведён в состояние - Передано профильной команде. По мне так это какая-то ошибка в проектировании самой сути ALD Pro (error by design).


ALD Pro 1.4.1 не ищет по атрибутам, кроме дефолтных. Июль 2023

Для обкатки работы ALD Pro в качестве системы управления учётными данными (IdM) была сделана тестовая учётная запись вымышленного пользователя, у которой атрибут mail специально содержит отличающееся значение от атрибута krbprincipalname. Были созданы и заполнены информацией дополнительные атрибуты (в терминах ALD Pro - user-custom-attr). Для обкатки вопросов работы почтовых алиасов (псевдонимов) Postfix + ALD Pro был прописан конкретный алиас в атрибуте proxyAddresses у пользователя.

В разделе Управление доменом - Пользователи и группы - вкладка Параметры пользователей - Поля поиска пользователей содержит по умолчанию uid,givenname,sn,telephonenumber,ou,title. Обратите внимание что в списке нет атрибута rbtamiddlename (Отчество, РБТА (РБТ-АСТРА) среднее имя). В разделе Пользователи и компьютеры - Пользователи можно найти учётную запись по отчеству. Тот случай когда положительный результат вызывает вопрос - а с чего?

Приведение списка uid,givenname,sn,telephonenumber,ou,title к uid,givenname,sn,telephonenumber,ou,title,mail,proxyAddresses,user-custom-attr никак не улучшает поиск в UI ALD Pro. Невозможно найти тестовую учётку, осуществляя поиск по атрибутам mail, proxyAddresses, user-custom-attr.

В это же время, FreeIPA под капотом у ALD Pro осуществляет поиск нормально, как и ожидается. Не отображает, естественно, дополнительные атрибуты ALD Pro в карточке пользователя, но, по-крайней мере, ищет и отображает те учётные записи, которые удовлетворяют поисковому запросу.

В службе поддержки отписались что на их тестовых стендах указанное поведение воспроизвелось. Передано разработчикам. 🤦🏻‍♂️


ALD Pro 1.4.1 при установке удаляет ntp, а потом использует его вместо chrony. Июль 2023

Во время установки ALD Pro 1.4.1 команда sudo apt-get install -q -y aldpro-mp удаляет сервер времени ntp для замены его на chrony.

В журнале /var/log/apt/history.log

Commandline: apt-get install -q -y aldpro-mp
Install: ca-certificates-java:amd64 (20190405, automatic), .... , chrony:amd64 (3.4-4+deb10u1+ci202109031327+astra1, automatic), ...
Remove: ntp:amd64 (1:4.2.8p15+dfsg-1+ci202109031329+astra1)

В системе можно убедиться что ntp больше нет как программы, но остались конфигурационные файлы (rc)

dpkg -l | grep ntp

rc ntp 1:4.2.8p15+dfsg-1+ci202109031329+astra1 amd64 Network Time Protocol daemon and utility programs
ii ntpdate 1:4.2.8p15+dfsg-1+ci202109031329+astra1 amd64 client for setting system time from NTP servers (deprecated)

Указание своих серверов (10.1.2.3 и 10.1.2.4) времени в закрытом от Интернета сегменте сети приводит к тому, что ALD Pro правит не файл /etc/chrony/chrony.conf, а не нужный файл /etc/ntp.conf

cat /etc/ntp.conf | grep -vE "(^#|^$)"
...
server 10.1.2.3 iburst
server 10.1.2.4 iburst
...

А файл /etc/chrony/chrony.conf остаётся дефолтным

cat /etc/chrony/chrony.conf | grep -vE "(^#|^$)"
...
pool 0.ru.pool.ntp.org iburst
pool 1.ru.pool.ntp.org iburst
pool 2.ru.pool.ntp.org iburst
pool 3.ru.pool.ntp.org iburst
server ntp3.vniiftri.ru iburst
server ntp4.vniiftri.ru iburst
server ntp21.vniiftri.ru iburst
server vniiftri2.khv.ru iburst
server ntp2.niiftri.irkutsk.ru iburst
server ntp3.stratum2.ru iburst
server ntp2.stratum2.ru iburst
server ntp.msk-ix.ru iburst
...

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


Помарка с zabbix-agent'ом. Июнь 2023

На тестовом стенде ALD Pro 1.4.1 с одним единственным контроллером домена БЕЗ дополнительного развёртывания каких-либо других компонент, а уж точно без сервера мониторинга, автоматически ставится zabbix-agent по зависимостям после команды sudo apt-get install -q -y aldpro-mp

Commandline: apt-get install -q -y aldpro-mp
... , zabbix-agent:amd64 (1:5.0.7+dfsg-1~bpo10+1.1, automatic) ....

После чего в журнале будете наблюдать каждую минуту рестарт агента

Jun 21 12:42:48 dc sudo[17045]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/systemctl restart zabbix-agent
Jun 21 12:43:48 dc sudo[17216]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/systemctl restart zabbix-agent

Данный компонент не является обязательным или критичным для функционирования ALD Pro, поэтому служба поддержки вначале рекомендовала отключить:

sudo systemctl stop zabbix-agent
sudo systemctl disable zabbix-agent
sudo systemctl mask zabbix-agent

затем переместить файл /etc/logrotate.d/zabbix-agent, но это всё не решало проблему, так как виновником являлся aldpro-client-service-discovery.

Jun 27 09:28:20 dc aldpro-client-service-discovery[8257]: Failed to restart zabbix-agent.service: Unit zabbix-agent.service is masked.
Jun 27 09:28:20 dc aldpro-client-service-discovery[8257]: Current zabbix servers: ['127.0.0.1', '192.168.1.0/24', '2001:db8::/32', '::1', 'zabbix.example.com\n\n127.0.0.1']

Помарка, потому что разработчики могли бы более элегантно решить данную ситуацию. Например, при развёртывании сервера мониторинга добавить задание Salt на установку zabbix-agent'ов на узлы домена. А так отделались зависимостями у пакета aldpro-mp - нужен/не нужен агент, есть/нет сервер мониторинга, пофигу - ставим!

А на минутку представьте что, если сервер мониторинга так и не будет поднят, а будет поднят сервер событий, то его содержимое будет заполнено мусорными сообщениями всех заббикс агентов всех серверов!

Передано разработчикам и конкретная дата исправления пока не ясна.


Снова не применяются настройки серверов времени. Октябрь 2022

Уже делал тикет на эту проблему, когда ваши настройки и хотелки своих серверов времени не применяются. В рамках тикета мне чётко сказали что проблему устранили в версии ALD Pro 1.1.2. Вот думайте что угодно - соврали и не сделали или снова сломали, но мой тестовый стенд стал версии 1.1.3, а я снова вижу эту проблему. Снова тикет и снова ответ - Проблема известна разработчикам, ожидается исправление в ALD Pro версии 1.2.0.


Я сломал Salt. Октябрь 2022

Целиком и полностью моя вина! Вышел из отпуска и к этому моменту вышла версия 1.1.2, до которой и хотелось обновить свой тестовый стенд. Традиционно в мире Debian, прежде чем прыгать на новую версию, настоятельно рекомендуется вначале обновить систему в рамках релиза и уже потом прыгать в бездну. Запустил просто apt update && apt -y full-upgrade и не заметил как сломал Salt в рамках релиза 1.1.1. В ранее созданных тикетах разработчики часто просили вывод команды sudo salt '*' test.ping, который легко и просто опрашивает всех миньонов. Команда показала что у меня отвалились 2 сервера из 4 в моей будущей армаде серверов ALD Pro .

В логах /var/log/salt/minion на проблемных серверах на каждый вызов sudo salt '*' test.ping можно наблюдать строки:

2022-10-04 09:15:06,812 [salt.crypt :788 ][ERROR ][1451] Sign-in attempt failed: {'enc': 'pub', 'pub_key': '----BEGIN PUBLIC KEY----
nMIIBIjANB.......'}
2022-10-04 09:15:06,814 [salt.minion :1149][ERROR ][1451] Error while bringing up minion for multi-master. Is master at dc1.company.ru responding?
2022-10-04 09:15:16,581 [salt.minion :1095][ERROR ][1451] Minion unable to successfully connect to a Salt Master.

Гуглёж показал верный ответ, но в то время я его не понял и не был готов воспринять, так как не знаком с Salt. Ошибка намекает на разницу в версиях, но это чуть позже мне разжевал лишь специалист из компании Astra. Из предоставленных отчётов команды sos report он выяснил что я где-то забыл мозги и на проблемных серверах указал совершенно не те адреса репозиториев, нарушив инструкцию.

Адреса репозитория для самой Astra Linux SE как платформы для ALD Pro должны быть пока версии 1.7.1
deb http://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.1/ repository-base 1.7_x86-64 main non-free contrib
deb http://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.1/ repository-extended 1.7_x86-64 main contrib non-free

Вот цитата ответа специалиста:
Тестирование ПК ALD Pro с ОС Astra Linux Special Edition версии 1.7.2 не окончено. Рекомендуем воздержаться от использования обновления 1.7.2 до окончания тестирования, так как мы не можем гарантировать беспроблемную работу ПК ALD Pro с ОС Astra Linux Special Edition версии 1.7 с установленным оперативным обновлением 2. Совместимость c Astra Linux Special Edition 1.7.2 будет добавлена в будущих версиях ALD Pro. Проблема с работой Salt вероятнее всего была вызвана отличием версий Salt, установленных на контроллере домена и "проблемных серверах".

Команда dpkg -l | grep salt подтвердила расхождение в версиях. Решил сделать ход конём: обновить стенд до версии 1.1.2 и исправить ситуацию с Salt через механизм понижения версии (apt downgrade).

Адреса репозиториев на проблемных серверах были исправлены согласно инструкции и выполнена команда sudo apt install salt-api=3004+ds-1 salt-common=3004+ds-1 salt-master=3004+ds-1 salt-minion=3004+ds-1 salt-ssh=3004+ds-1
dpkg: предупреждение: снижение версии salt-ssh с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-minion с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-master с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-common с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-api с 3004.2+ds-1 до 3004+ds-1

После рестарта сервисов sudo systemctl restart salt-master; sudo systemctl restart salt-api; sudo systemctl restart salt-minion ситуация была исправлена.

Мораль сей басни? Быть более внимательным, поменьше отсебятины, безукоснительно следовать инструкции.


Неработоспособность раздела Пользователи при огромном количестве учётных записей. Август 2022

Решено было протестировать работоспособность проекта ALD Pro на большом количестве учётных записей, чтобы рассмотреть ALD Pro НЕ как службу каталогов с кучей функционала, а хотя бы как Identity management (IdM). Обратились в рамках выделенного канала поддержки к разработчикам с вопросом, а есть ли готовые инструменты и/или API ALD Pro? И если нет, то можно ли безопасно использовать инструменты и/или API проекта FreeIPA, который трудится под капотом? Ответ был - вот держите скрипт ald.py, который явно показал что даже сами разработчики не используют API и просто формируют в питоновском скрипте вызовы консольной команды ipa. Данный скрипт так же не подошёл из-за того что просто тупо генерируются учётные записи вида user0, user1 ... userN, где N желаемое вами число. Хотелось заранее поучиться массовой заливке учётных записей с заполнением стандартных и своих атрибутов и желательно данными, максимально приближенные к реальности. Жизнь может и часто приподносит сюрпризы.

Попросил у коллег обезличенные данные (ФИО, должность, код подразделения). Знаете ли вы, что Отчество это не обязательно одно слово и может быть несколько слов через пробел? Другими словами, есть мужчины, у которых полное имя состоит из нескольких слов (привет от капитана Очевидность ).

С помощью простого bash скрипта из Comma-Separated Values (CSV) файла создал примерно ~10000 учётных записей в ALD Pro. Учётные записи для теста создавались по следующей схеме:

  • Русские ФИО преобразовались транслитом в английские буквы с добавлением кода подразделения, чтобы полные тёзки получали уникальную тестовую учётную запись. Так Иванов Иван Иванович из бухгалтерии (код подразделения 010) получит учётку ivanoff.ivan.i.010
  • В цикле while команды ipa собственно создавали нужное
    ipa user-add ${name} --first="${I}" --last="${F}"
    ipa passwd ${name} 12345678
    ipa user-mod ${name} --title="${TITLE}"
    ipa user-mod ${name} --setattr=rbtamiddlename="${O}"

После 18 часов работы, так как не оптимизированная версия bash скрипта тратила почти 6 секунд на 1 учётку, тестовый сервер ALD Pro для чистоты эксперимента был перезагружен после заполнения данными.

Работа в веб-интерфейсе показала полную непригодность использования ALD Pro в качестве хотя бы Identity management (IdM):

  • Консольная команда ipa user-find находит, к примеру, учётные записи с фамилией Петров. Веб интерфейс - не находит ничего, ни по-русски, ни по-английски по имени учётки petroff!
  • Ожидаешь что при большом количестве учётных записей в веб-интерфейсе в разделе Пользователи появится большое количество экранов-страниц (page), но кнопка Далее позволяет лишь "дойти" до цифры 14 (и то иногда), после чего происходит некий сброс-сбой и ты оказываешься на странице с номером 10 или 11, как карта ляжет. На экране будет - не найдено!

    Много учётных записей вызывают проблемы в ALD Pro

Суть проблемы неясна, идёт разбирательство. Конкретная дата исправления пока не ясна. В рамках решения проблемы с поломкой центра помощи ALD Pro был обновлён до версии 1.1.1. Проблема частично сдвинулась с мёртвой точки: страницы (paging) начали работать и корректно оформляют ~10000 записей, но поиск не работает до сих пор.

Разработчик в рамках вебинара от 29.09.2022 рассказал что при таких огромных количествах учётных записей требуется создание дополнительных сайтов (site). Но это нужно всё перепроверить в тестовой среде и многое остаётся не понятным. Под капотом многие данные хранятся в PostgreSQL и такие смешные цифры ~10000 точно не его ограничение. Пользователи домена и вся информация в атрибутах нормально хранится в LDAP каталоге и нормально оперируется консольными утилитами FreeIPA. Такие смешные проблемы с цифрами выше 10000 это скорее всего ограничение смузихлёбного интерфейса, построенного с помощью Django и ReactJS.

Если нет 2 часа свободного времени, то лучше будет просто посмотреть концовку и ответы на вопросы участников.

Так же разработчик упомянул что доступна новая версия ALD Pro 1.1.2, в которой ряд проблем возможно решены. Всегда отслеживайте официальный репозиторий, указанный в документации и обновляйте свои тестовые стенды для получения актуальной версии.


Проблема с развёртыванием сервера событий. Август 2022

Журнал заданий автоматизации уведомил об успешном развёртывании роли сервера событий на отдельном выделенном для этих целей сервере (назовём его audit.company.ru), но в разделе "Серверы журнала событий" по-прежнему пусто и если опять нажать кнопку - "Развернуть сервер журнала событий" снова предлагается audit.company.ru как свободный для установки, словно на него и не развёртывалась ранее роль сервера событий.

В рамках поддержки разработчики попросили ввести команду sudo salt '*' test.ping с главного контроллера домена dc1, которая выявила что на втором-контроллере-домена-реплике dc2.company.ru не доступен (не работает, не отвечает) salt-minion: Minion did not return. [Not connected].

Рестарт службы salt-minion на dc2 и sudo salt '*' test.ping рапортует что всё успешно - напротив всех серверов True. После чего развёртывание службы роли сервера событий прошло успешно и сервер audit.company.ru отобразился в разделе "Серверы журнала событий".

По иронии судьбы, рестарт служб salt так же помог с проблемой развёртывания сервера мониторинга. Мне впредь наука - прежде чем делать тикеты, смотреть статус и рестартить службы Salt. Это объясняет, но не извиняет разработчиков. У меня, как у пользователя-потребителя, должно всё работать искаропки. Их лозунги: "Простое управление службой каталогов" и "Простое решение сложных задач".

Простое управление службой каталогов ALD Pro

ALD Pro! Простое решение сложных задач

С ALD Pro не требуется консоль и глубокие знания Linux. Обо всём позаботились разработчики


Безграничный журнал Bind. Август 2022

Для DNS службы в файле /etc/bind/named.conf определён файл журнала /var/cache/bind/named.run

options {
  directory "/var/cache/bind";
  ...
};

logging {
  channel default_debug {
    file "named.run";
    severity dynamic;
    print-time yes;
  };
};

Но нет ограничивающих параметров в размере файл-журнала средствами самого Bind типа versions 10 size 100m; или, как принято в linux системах, файл-параметр для LogRotate в каталоге /etc/logrotate.d/, регламентирующий смену (rotate) файла журнала и/или упаковку старых журналов Bind.

Файл-журнал /var/cache/bind/named.run довольно быстро нарастает в размере, особенно в изолированных от Интернет сегментах сети из-за недоступности сайтов родительских (upstream) проектов и/или протокола IPv6.

Типа такого
02-Aug-2022 09:42:09.954 network unreachable resolving 'grafana.com/AAAA/IN': 2001:503:ba3e::2:30#53
02-Aug-2022 09:42:10.740 host unreachable resolving 'grafana.com/A/IN': 202.12.27.33#53

Считаю что неограниченный ничем рост журнала Bind это упущение, требующее контроля и/или ограничений. Место на диске не резиновое и рано или поздно закончится.

Конкретная дата исправления пока не ясна.


Мониторинг не собирается мониторить. Август 2022

Разработчики упустили тот момент, что сервер мониторинга не обязательно будет развёрнут последним, чтобы он принялся обнаруживать (discovery) остальные сервера из группы ipaservers, которые были развёрнуты до него. Глупая и досадная оплошность. Через веб-интерфейс Zabbix в разделе Configuration - Discovery можно наблюдать правило atk_drule, которое НЕ изменилось с даты развёртывания самого сервера мониторинга и НЕ содержит какие либо IP адреса серверов ПОСЛЕ. Поэтому логично что в разделе Configuration - Hosts нет новичков и на мониторинг они не поставлены.

Конкретная дата исправления пока не ясна.


Не применяются настройки серверов времени. Июль 2022

В разделе "Служба синхронизации времени" вкладка "Внешний пул NTP серверов" если указать ваши сервера времени для обкатки работы домена в изолированном сегменте сети без прямого доступа к Интернет, то они не применяются. Если вы вручную измените содержимое /etc/chrony/chrony.conf, то значение естественно будет сброшено Salt в дефолт.

Разработчики вскоре исправят ситуацию, а пока, как обходной манёвр, можно добавить свои сервера напрямую в файл и повесить атрибут неизменяемости (immutable) sudo chattr +i /etc/chrony/chrony.conf

РЕШЕНО в версии ALD Pro 1.1.2.


Поломка Справочного Центра. Июль 2022

К данному моменту ALD Pro был штатно обновлён на новую версию 1.1.0 обязательно через sudo apt update && sudo apt full-upgrade
Не сразу понял что справка сломалась.

Поломка Справочного Центра ALD Pro

Советы НЕ помогли:
cd /opt/rbta/aldpro/mp/api/help-center
python3 manage.py migrate
tar -xzf dump.json.tar.gz
python3 manage.py loaddata dump.json
sudo apachectl graceful

РЕШЕНО в версии ALD Pro 1.1.1.


Поломка системы после ввода мониторинга. Июль 2022

Поломка ALD Pro после ввода системы мониторинга

Оказалось что какой-то из разработчиков не доглядел при написании задач для Salt и указал жёстковшитый домен ASTRA-LOCAL вместо вашего домена в виде элемента dirsrv@DOMAIN-NAME.service у Zabbix. В этом месте меня напряг совет исправить ситуацию напрямую в веб-интерфейсе Zabbix с входом через дефолтный логин Admin и пароль zabbix.

жёстковшитое значение ASTRA-LOCAL в сервере мониторинга ALD Pro

Что-то я пока не представляю как мне оптимальнее спрятать армаду серверов ALD Pro от пользователей, кроме как упросить сетевиков-коллег отделить ALD Pro в отдельную подсеть с жёсткой фильтрацией доступа.


Нельзя русскую букву Ё в русской службе каталога. Июль 2022

Просто ужас, когда отгрёб такую дичь. Ответ: Указанная ошибка будет исправлена в версии ALD Pro 1.2.0. Планируемая дата выхода — сентябрь 2022 года.

Нельзя русскую букву Ё в русской службе каталога ALD Pro


Ошибки развёртывания сервера мониторинга. Июль 2022

По документу ПРОГРАММНЫЙ КОМПЛЕКС «ALD PRO» Руководство администратора была попытка развернуть штатно через GUI сервер мониторинга. Сервер мониторинга был установлен, настроен и введён в домен. Оставалось лишь развернуть роль, но задача завершалась с ошибкой.

Помог совет: Попробуйте перед запуском задания установку роли выполнить на контроллере домена команды:
sudo systemctl restart salt-master
sudo systemctl restart salt-api
sudo systemctl restart salt-minion

На сервере мониторинга перед запуском задания выполните команду: sudo systemctl restart salt-minion


Ошибки запроса к LDAP по мере ввода букв. Июль 2022

В поле "Руководитель подразделения" можно указать учётную запись из ниспадающего списка, но в больших организациях при огромном количестве учёток проще начинать набирать нужное в надежде что фильтр начнёт убавлять список. Но возникала ошибка запроса. Ситуация исправлена в ALD Pro версии 1.1.0.

Ошибки запроса к LDAP ALD Pro


Полезные видеоматериалы ALD Pro на моём канале

В связи с замедлением Youtube, ниже приведённые видеоматериалы доступны в RuTube и VK Video.

Собственное изучение ALD Pro. Ролики воссоздают задания, которые шли к тестовому полигону из 8 готовых виртуальных машин.

Видео ALD Pro от разработчиков.

Дополнительные материалы:

Дата последней правки: 2024-11-28 09:49:09

RSS vasilisc.com   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи об Astra Linux
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта

Лучшее на сайте:

1С под Linux.   Ускорение Ubuntu.   21 пример iptables.   Цикл статей о Ceph.   Убунту в дикой среде.   Ubuntu Linux на SSD.   Ubuntu для блондинок.   Поддержка железа в Linux.   BTSync на службе у админа.   Андроид программы в Ubuntu.   Прокидывание портов для p2p.   Анти СПАМ в Postfix.   Полноприводный электросамокат для бездорожья взрослый обеспечит стабильность


Любое копирование с сайта разрешено при наличии индексируемой ссылки на оригинал, без nofollow и noindex. Страница создана за 0.046 сек.