Заметки при изучении ALD Pro
Решил зафиксировать в виде заметок изучение ALD Pro, которая находится на раннем своём этапе развития и полна детских болячек. Чтобы не выносить сор из избы, разработчики Астры прикрыли баг-трекер и теперь всё делается через выделенные каналы поддержки. Данная статья не повод оскорблять Астру, но повод поделиться с вами решёнными проблемами, особенно если вы, так же как и я, вынуждены осваивать ALD Pro в тестовой среде в рамках импортозамещения. Чем старее событие, тем оно будет ниже в тексте статьи.
Обновлено на дату 25.07.2023
Компонентная схема ALD Pro
Компонентная схема устройства Astra Linux Directory Pro для лучшего понимания что спрятано под капотом и как увязано с друг другом для простоты администрирования рядовым администратором.
Где брать инструкции ALD Pro?
- С данного сайта в архиве ПРОГРАММНЫЙ КОМПЛЕКС «ALD PRO» Руководство администратора. Версия 2.0.
- Официальный сайт. Руководство администратора. Инструкция по развертыванию и обновлению.
- Официальный сайт. Инструкция по планированию ресурсов.
- Официальный сайт. Руководство пользователя.
Всегда отслеживайте репозиторий 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 серверов и получишь все плюшки.
- Общее пока впечатление что тестированием ALD Pro толком никто не занимается. Нет человека, который просто бы взял ALD Pro, и без всяких средств оркестровки создал ручками вымышленную контору Рога и Копыта, заполнил бы руками поля-атрибуты пользователей, присоединил бы к домену пару-тройку клиентских ПК, добавил дополнительные сервера в армаду и т.д. Очень смешные ошибки и банальные.
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 был обновлён до версии 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 от разработчиков.
