Ald руководство администратора

Введение

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

В посте пойдет речь об администрировании ald домена, серверной, клиентской части, а также о поднятии резервного сервера.

Серверная часть

Настройку произвожу на виртуальных машинах в virtualbox, на сервере ip адрес 192.168.1.1, также на данном сервере расположен репозиторий(настройка ip адресов и репозиториев ничем не отличаются от настроек в debian). Первое, что необходимо настроить — это синхронизацию времени: поднимем ntp сервер, который будет брать время с текущей машины. Для это достаточно отредактировать файл /etc/ntp.conf, внеся в него следующие изменения:

server 127.127.1.0

fudge 127.127.1.0 stratum 10

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Параметры подсети укажите в соответсвии с вашими ip адресами.

Запустим службу:

systemctl enable ntp

systemctl start ntp

Так как в ald отсутствует собственный dns сервер, его заменой служит корректно настроенный файл /etc/hosts, который должен быть одинаковый на всех машинах в домене. Перед редактированием данного файла, зададим корректное hostname для сервера:

hostnamectl set-hostname dc1.local

В данной ситуации hostname сервера будет dc1, а имя домена, соответственно, local, именно на эти параметры будет ориентироваться ald-server при инициализации. Последним штрихом перед инициализацией ald сервера буден корректная настройка файла /etc/hosts:

127.0.0.1 localhost

#127.0.1.1 hostname

192.168.1.1 dc1.local dc1

192.168.1.2 dc2.local dc2

192.168.1.101 host1.local host1

192.168.1.102 host2.local host2

Обязательно необходимо «закомментировать» 127.0.1.1, а также важна последовательность указания полного имени хоста, т. е. первым должно быть указано имя хоста с доменом, и только потом имя хоста без домена.

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

sudo apt install ald-server-common fly-admin-ald-server smolensk-security-ald

Пакет smolensk-security-ald — добавит возможность администрировать ald сервер в стандартной утилите fly-admin-smc (об этом будет рассказано далее).

Во время установки будет запрос на создание пароля администратора домена. Для текущей публикации будет создан пароль 12345678, далее данный пароль будет использован для ввода всех машин в домен.

ВАЖНО: Если по каким то причинам у Вас сбились настройки сервера, то их можно отредактировать в файле /etc/ald/ald.conf, в текущем файле важен параметр DOMAIN, значение данного параметра всегда должно начинаться с . (точки), т.е. в текущем примере данная строка будет выглядеть так:

DOMAIN = .local

Инициализируем сервер командой:

ald-init init

После инициализации необходимо перезагрузть сервер. В процессе инициализации домена еще раз будет запрос на создание пароля администратора домена, а также запрос на создание пароля на базу данных kerberos. Если все прошло удачно, то на экране появится сообщение как на рисунке 1.

После данным манипуляций настройка сервера закончена, приступим к настройке клиентской части.

Клиентская часть

Достаточно настроить ntp клиента для синхронизации времени, скопировать файл hosts с сервера, задать имя хоста, а также настроить /etc/ald/ald.conf. В файле /etc/ntp.conf необходимо добавить строки:

server dc1.local

Запустим службу ntp:

systemctl start ntp

systemctl enable ntp

Зададим имя хоста (в данном пример ip адрес хоста 192.168.1.101):

hostnamectl set-hostname host1

Перед настройкой ald.conf необходимо установит необходимые пакеты:

sudo apt install fly-admin-ald-client ald-client

На рисунке 2 представлен пример файла ald.conf (данный файл аналогичен файлу ald.conf с сервера).

После данным манипуляций можно ввести машину в домен командой:

ald-client join

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

Если все прошло удачно, то на экране отобразится текст как на рисунке 3

Резервный сервер ald

Создать резервный сервер также довольно просто. Для этого на будущем резервном сервере (на резервном сервере также необходимо расположить корректный файл hosts), необходимо установить пакеты:

sudo apt install ald-server-common smolensk-security-ald

И отредактировать файл /etc/ald/ald.conf, изменив один параметр:

SERVER_ID=2

Далее зададим корректное имя хоста для резервного сервера:

sudo hostnamectl set-hostname dc2.local

Теперь инициализируем резервный сервер командой:

sudo ald-init init --slave

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

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

sudo ald-init promote

Дополнительно необходимо на всех клиентских рабочих станциях отредактировать файл /etc/ald/ald.conf, как это сделать одной командой будет рассказано в разделе «Дополнительно».

В данном файле необходимо изменить параметр SERVER и SERVER_ID:

SERVER=dc2.local #dc2.local – резервный сервер

SERVER_ID=2 #2 – id резервного сервера

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

sudo ald-client commit-config

Администрирование ald сервера

Как было написано ранее, администрирование можно производить через стандартную системную утилиту fly-admin-smc. Ее можно запустить через консоль, либо в панели управления, перейдя на вкладку «Безопасность» и запустив аплет «Политика безопасности». Первым делом необходимо настроить политику паролей в соответствии с вашими требованиями:

На рисунке 6 представлена вкладка политики паролей. После настройки политики можно приступить к созданию пользователей и настройке их прав.

На вкладке «Пользователи» необходимо нажать на кнопку +, ввести имя, тип файловой системы установить local (также можно хранить каталоги на сетевых ресурсах), а также убрать галку «новая» напротив надписи «Первичная группа». При этом пользователь будет добавлен в группу «domain user». Далее создадим пароль для пользователя.

На вкладке «Привилегии домена» можно сделать пользователя «администратором» домена, а также разрешить авторизацию с конкретных доменных машин, или с любых машин, входящих в домен.

На вкладке «МРД» указываем, к каким меткам пользователь имеет доступ, а также уровень целостности.

Дополнительно

Представьте такую ситуацию, в будущий домен будет входить 100, или более машин, раскидать в ручную файл hosts будет довольно проблематично, в данной ситуации поможет bash с СИ подобным синтаксисом.

На тестовом стенде имеется подсеть 192.168.1.0/24, 192.168.1.1 — сервер, 192.168.1.2-192.168.1.100 — рабочие станции. На каждой машине(в том числе и на сервере) имеется пользователь user, с паролем 12345678. Данный пользователь должен быть полноценным администратором(с доступом к sudo, во время установки системы создается пользователь имеющий данные права) системы и иметь уровень целостности 63, для выполнения данной цели необходимо выполнить следующие команды:

sudo usermod -aG astra-admin,astra-console user

sudo pdpl-user -l 0:0 -i 63 user

Если пользователь user отсутствует в системе — выполним следующие команды:

sudo useradd -m -G astra-admin,astra-console -s /bin/bash user

sudo passwd user

sudo pdpl-user -l 0:0 -i 63 user

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

sudo apt install sshpass

После данным манипуляций можно приступить к формированию ключа(без sudo, с правами пользователя user), для без парольного доступа:

shh-keygen -t rsa -b 1024

Распространим ключи на рабочие станции:

for((i=2;i<101;i++)); do sshpass -p 12345678 ssh-copy-id -f -o StrictHostKeyChecking=no user@192.168.1.$i; done

Скопируем файл hosts на все машины с помощью утилиты scp:

for((i=2;i<101;i++)); do scp /etc/hosts user@192.168.1.$i:/home/user; ssh user@192.168.1.$i sudo cp /home/user/hosts /etc/hosts; done

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

Таким же образом можно редактировать данный файл на всех хостах в домене(например необходимо удалить строку с именем хоста — host40):

for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i '/host40/d' /etc/hosts; done

Если Вам необходимо переключиться на резервный сервер на всех клиентских машинах, выполним команду:

for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i ‘s/SERVER=dc1.local/SERVER=dc2.local/g’ /etc/ald/ald.conf; sudo sed -i ‘s/SERVER_ID=1/SERVER_ID=2/g’ /etc/ald/ald.conf; sudo ald-client commit-config -f; done

Заключение

Как видно из данной публикации ald домен довольно просто разворачивать, а также очень просто администрировать используя стандартную системную утилиту fly-admin-smc.

Я администрирую серверы на базе Astra Linux и хочу рассказать о своем видении настройки ALD домена: серверной части, клиентской, использовании файла hosts (по сравнению с DNS сервером). Также дам описание настройки резервного сервера.

ALD мне интересен в первую очередь потому, что уже имеет интеграцию с Astra Linux. Статья будет вам полезна, если вы собираетесь узнать больше о Astra Linux не только из официальной wiki. Кроме того, эту операционную систему (вместе с рядом других решений компании «Астра») смогут поставить на виртуальную машину клиенты публичного облака #CloudMTS.

Серверная часть

Настройку произвожу на виртуальных машинах в virtualbox, на сервере ip-адрес 192.168.1.1, также на данном сервере расположен репозиторий (настройка ip-адресов и репозиториев ничем не отличаются от настроек в Debian, на базе которой построена Astra). Первое, что необходимо настроить — это синхронизацию времени: поднимем ntp сервер, который будет брать время с текущей машины. Для это нужно отредактировать файл /etc/ntp.conf, внеся в него следующие изменения:

server 127.127.1.0
fudge 127.127.1.0 stratum 10
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Параметры подсети укажите в соответствии с вашими ip адресами.

Запустим службу:

systemctl enable ntp
systemctl start ntp

Вы можете использовать DNS сервер — bind, например. Он присутствует в стандартном репозитории Astra Linux. На мой взгляд, использование файл hosts — это более простая реализация, чем полноценный DNS сервер. При этом корректно настроенный файл /etc/hosts должен быть одинаковый на всех машинах в домене. Перед редактированием данного файла зададим корректное hostname для сервера:

hostnamectl set-hostname dc1.local

В данной ситуации hostname сервера будет dc1, а имя домена, соответственно, local, именно на эти параметры будет ориентироваться ald-server при инициализации. Последним штрихом перед инициализацией ald сервера будет корректная настройка файла /etc/hosts:

127.0.0.1   localhost
#127.0.1.1 hostname
192.168.1.1     dc1.local     dc1
192.168.1.2     dc2.local     dc2
192.168.1.101   host1.local host1
192.168.1.102   host2.local host2

Обязательно необходимо «закомментировать» 127.0.1.1, а также важна последовательность указания полного имени хоста, т. е. первым должно быть указано имя хоста с доменом, и только потом имя хоста без домена.

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

sudo apt install ald-server-common fly-admin-ald-server smolensk-security-ald

Пакет smolensk-security-ald добавит возможность администрировать ald сервер в стандартной утилите fly-admin-smc (об этом будет рассказано далее).

Во время установки будет запрос на создание пароля администратора домена. Для текущей публикации будет создан пароль 12345678, далее данный пароль будет использован для ввода всех машин в домен.

ВАЖНО. Если по каким-то причинам у вас сбились настройки сервера, то их можно отредактировать в файле /etc/ald/ald.conf. В текущем файле важен параметр DOMAIN, значение данного параметра всегда должно начинаться с . (точки), т.е. в текущем примере данная строка будет выглядеть так:

DOMAIN = .local

Инициализируем сервер командой:

ald-init init

После инициализации необходимо перезагрузить сервер. В процессе инициализации домена будет еще запрос на создание пароля администратора домена, а также запрос на создание пароля на базу данных kerberos. Если все прошло удачно, то на экране появится сообщение:

Теперь приступим к настройке клиентской части.

Клиентская часть

Настроим ntp клиента для синхронизации времени, скопируем файл hosts с сервера, зададим имя хоста, а также настроим /etc/ald/ald.conf. В файле /etc/ntp.conf необходимо добавить строки:

server dc1.local

Запустим службу ntp:

systemctl start ntp
systemctl enable ntp

Зададим имя хоста (в данном пример ip адрес хоста 192.168.1.101):

hostnamectl set-hostname host1

Перед настройкой ald.conf необходимо установить необходимые пакеты:

sudo apt install fly-admin-ald-client ald-client

Ниже представлен пример файла ald.conf (данный файл аналогичен файлу ald.conf с сервера):

Теперь можно ввести машину в домен командой:

ald-client join

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

Если все прошло удачно, то на экране отобразится следующий текст:

Резервный сервер ald

На будущем резервном сервере необходимо установить пакеты:

sudo apt install ald-server-common smolensk-security-ald

И отредактировать файл /etc/ald/ald.conf, изменив один параметр:

SERVER_ID=2

Далее зададим корректное имя хоста для резервного сервера:

sudo hostnamectl set-hostname dc2.local

Теперь инициализируем резервный сервер командой:

sudo ald-init init --slave

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

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

sudo ald-init promote

Необходимо на всех клиентских рабочих станциях отредактировать файл /etc/ald/ald.conf. Как это сделать одной командой — расскажу в разделе «Дополнительно».

В данном файле необходимо изменить параметры SERVER и SERVER_ID:

SERVER=dc2.local #dc2.local – резервный сервер

SERVER_ID=2 #2 – id резервного сервера

И далее выполнить команду:

sudo ald-client commit-config

Администрирование ald сервера

Как было написано ранее, администрирование можно производить через стандартную системную утилиту fly-admin-smc. Ее можно запустить через консоль, либо в панели управления, перейдя на вкладку «Безопасность» и запустив аплет «Политика безопасности». Первым делом необходимо настроить политику паролей в соответствии с вашими требованиями:

Выше представлена вкладка политики паролей. После настройки политики можно приступить к созданию пользователей и настройке их прав.

На вкладке «Пользователи» необходимо нажать кнопку +, ввести имя пользователя, тип файловой системы, установить local (также можно хранить каталоги на сетевых ресурсах), а также убрать галку «новая» напротив надписи «Первичная группа». При этом пользователь будет добавлен в группу «domain user». Далее создадим пароль для пользователя.

На вкладке «Привилегии домена» можно сделать пользователя «администратором» домена, а также разрешить авторизацию с конкретных доменных машин, или с любых машин, входящих в домен.

На вкладке «МРД» указываем, к каким меткам пользователь имеет доступ, а также уровень целостности.

Дополнительно: «заливка» hosts на все рабочие станции

Представьте ситуацию, в будущий домен будет входить 100 или более машин. Раскидать в ручную файл hosts — проблематично. В данной ситуации поможет bash с СИ подобным синтаксисом.

На тестовом стенде имеется подсеть 192.168.1.0/24, 192.168.1.1 — сервер, 192.168.1.2 — 192.168.1.100 — рабочие станции. На каждой машине (в том числе и на сервере) имеется пользователь user с паролем 12345678. Данный пользователь должен быть полноценным администратором (с доступом к sudo, во время установки системы создается пользователь имеющий данные права) и иметь уровень целостности 63. Для данной цели необходимо выполнить следующие команды:

sudo usermod -aG astra-admin,astra-console user
sudo pdpl-user -l 0:0 -i 63 user

Если пользователь user отсутствует в системе, выполним следующие команды:

sudo useradd -m -G astra-admin,astra-console -s /bin/bash user
sudo passwd user
sudo pdpl-user -l 0:0 -i 63 user 

Чтобы не вводить пароль при распространении ключей, необходимо установить утилиту sshpass:

sudo apt install sshpass

Теперь можно приступить к формированию ключа (без sudo, с правами пользователя user), для беспарольного доступа:

shh-keygen -t rsa -b 1024

Распространим ключи на рабочие станции:

for((i=2;i<101;i++)); do sshpass -p 12345678 ssh-copy-id -f -o  StrictHostKeyChecking=no user@192.168.1.$i; done

Скопируем файл hosts на все машины с помощью утилиты scp:

for((i=2;i<101;i++)); do scp /etc/hosts user@192.168.1.$i:/home/user; ssh user@192.168.1.$i sudo cp /home/user/hosts /etc/hosts; done

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

Таким же образом можно редактировать данный файл на всех хостах в домене. Например, нам необходимо удалить строку с именем хоста host40:

for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i '/host40/d' /etc/hosts; done

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

for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i 's/SERVER=dc1.local/SERVER=dc2.local/g' /etc/ald/ald.conf; sudo sed -i 's/SERVER_ID=1/SERVER_ID=2/g' /etc/ald/ald.conf; sudo ald-client commit-config -f; done

На этом у меня сегодня всё, спасибо за ваше внимание.

Делитесь в комментариях вашим опытом.

Выбрать готовые образы программных решений для виртуальных машин IaaS можно в личном кабинете на сайте #CloudMTS.

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

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

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

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

Главная инструкция по развёртыванию ALD Pro комплекса: ПРОГРАММНЫЙ КОМПЛЕКС «ALD PRO» Руководство администратора. Версия 1.1.2

Всегда отслеживайте репозиторий https://dl.astralinux.ru/aldpro/stable/repository-main/dists/ и обновляйте свои тестовые стенды для получения актуальной версии.

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

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

• Версия 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!

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

Снова не применяются настройки серверов времени. Октябрь 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 был обновлён до версии 1.1.1. Проблема частично сдвинулась с мёртвой точки: страницы (paging) начали работать и корректно оформляют ~10000 записей, но поиск не работает до сих пор.

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

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

Так же разработчик упомянул что доступна новая версия ALD Pro 1.1.2, в которой ряд проблем возможно решены. Всегда отслеживайте репозиторий https://download.astralinux.ru/aldpro/stable/repository-main/dists/ и обновляйте свои тестовые стенды для получения актуальной версии.

Проблема с развёртыванием сервера событий. Август 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. Это объясняет, но не извиняет разработчиков. У меня, как у пользователя-потребителя, должно всё работать искаропки. Их лозунги: «Простое управление службой каталогов» и «Простое решение сложных задач».

Безграничный журнал 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
Не сразу понял что справка сломалась.

Советы НЕ помогли:
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

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

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

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

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

Ошибки развёртывания сервера мониторинга. Июль 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.

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

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

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

Дата последней правки: 2023-04-13 12:26:41