Всем привет! На работе всю неделю занимался с ELK. ELK — это стек из трёх инструментов: Elasticsearch, Logstash и Kibana, который используется для сбора, хранения, анализа и визуализации логов и данных.
Elasticsearch обеспечивает быстрое полнотекстовое поиск и индексацию, Logstash собирает и обрабатывает данные из разных источников, а Kibana строит наглядные дашборды для анализа этих данных. Стек помогает централизованно управлять большими объёмами информации. 
Не стоит путать ELK с системой мониторинга вроде Zabbix. ELK предназначен для анализа данных логов, а Zabbix строится на мониторинге текущего состояния систем с пороговыми значениями и реакцией на отклонения.
В ELK логи стекаются со множества серверов в одно место, и очень удобно искать ошибки через полнотекстовый поиск.
Я поднимал ELK через docker-compose из этого репозитория https://github.com/deviantony/docker-elk/.
Этот набор программ нисколько не простой. Очень помогло видео «ELK: как собрать логи в одном месте» https://www.youtube.com/watch?v=syjTFmLY2T4.
Сначала я сильно путался со словом Index. Index в Elasticsearch — это не индекс в реляционных базах данных. Это таблица для хранения документов. А вообще про эту базу данных есть хорошее видео «ElasticSearch: Всё, что нужно знать за 30 минут» https://www.youtube.com/watch?v=vxE1aGTEnbE. И настройки Index ну очень неочевидные и находятся в разных местах (см. картинку).
Но логи можно не только собирать, но и трансформировать. Далеко не всё из многомегабайтных логов нужно хранить, кое-что нужно отбрасывать, а часть информации добавлять.
Больше всего меня добил Logstash. Вносим одну строчку в его настройки из официальной документации, и всё умирает. Kibana сообщает, что пропала нода Elasticsearch. Я с этим пробился почти весь день. И в результате перешёл на сбор логов на Filebeat https://www.elastic.co/beats/filebeat. Его настраивать в разы проще. Но это только под Linux, а под FreeBSD он отказался работать, я пару часов выяснял причину, оказалось надо больше прав на API-ключ.
ELK-stack я всё-таки настроил, но с нуля осваивать сложную систему сильно трудоёмко.
Ещё одна задача была связана с Asterisk. У нас ведётся автоматическая запись телефонных разговоров, и эта система перестала работать. И ошибка в логах странная: «Закончилось место на диске». Оказалось, что телефонные переговоры записываются во временную файловую систему в оперативной памяти, а затем конвертируются в mp3 и сбрасываются в постоянное хранилище. Временное хранилище оказалось переполненным. Я его сохранил записи разговоров в формате wav себе в домашнюю папку. Но в постоянное хранилище они всё равно не сбрасывались. Начал искать процедуру работы с ним. Оказалось, что пользователь asterisk не может создать там папку для хранения, потому что права на корневую папку назначены root. Кто и зачем это сделал, мне выяснить так и не удалось. В результате запись разговоров пошла, а старые записи я конвертировал из wav в mp3 через многопоточный скрипт, который написала ChatGPT.
В итоге за эту неделю я настроил ELK-стек для сбора и анализа логов, разобрался с особенностями Elasticsearch, упростил процесс с помощью Filebeat и восстановил систему записи звонков в Asterisk. Опыт получился непростым, но очень ценным.

Эта неделя была короткая. Поэтому занимался созданием только одной основной задачей — созданием резервной копии сервера телефонии Asteriks.

По Asteriks накачал уйму видео, по факту вагон мусора. Но есть 2 хороших:
- Траблшутинг связи в Asterisk https://www.youtube.com/watch?v=S9NZZ_VGMzY
- Роман Перцев — Asterisk Tips & Tricks https://www.youtube.com/watch?v=Bw_cBl3nqOc
Прежде чем делать резервное копирование, дай, думаю, пройдусь по папкам, посмотрю, что больше всего занимает место. Оказалось, что 150Gb занимает неотправленная почта. И файлов там миллионы, команда ls «вешается».
Но при помощи ChatGPT нашёл способ удаления файлов в 8 потоков.

cd /var/spool/clientmqueue  
find . -type f -print0 | xargs -0 -n 1000 -P 8 rm -f

Но и он работал около суток.
Дальше я нашёл логи для самописных скриптов, которые уже несколько лет не ротировали. Они тоже стали гигабайтными. Дописал конфиг, и логи стали ротироваться. Всё, что может быть автоматизировано, должно быть автоматизировано.
Сам же решил хранить настройки Asteriks в git. Вот всё бы хорошо, но сервер GitLab он внутренний, и доступ к нему возможен только из внутри по OpenVPN. Но на сервере FreeBSD уже есть один туннель OpenVPN, необходимо было создать второй в другую сеть, где живёт Gitlab. Было целое приключение с созданием второго сервиса OpenVPN с разными конфигурациями. И ChatGPT сильно «фантазировала». Но решение было найдено https://gist.github.com/orion55/4e8f68859afe07add2a3c78b21e5e370. Необходимо создать копию службы OpenVPN и прописать правильные параметры. Нет ничего невозможного для человека с интеллектом.

Дома возникла проблема, китайский комп, который у меня служил в качестве файлопомойки, неожиданно умер. В результате я купил Synology NAS DS224+. Не самое дешевое решение, но он мне понравился. И интерфейс удобный, и qBittorrent через docker установил. Я собрал все свои скаченные учебные курсы и сериалы в одну кучку, получилось 2Тб. И когда я их смотреть буду?
Это где-то третья или четвёртая реинкарнация моей домашней файлопомойки. Я и Raspberry Pi использовал, и старый ноут. Но ничего не понравилось. А этот как-то сразу зашёл, компактный, тихий, можно отключить светодиоды на ночь.
Что не понравилось: хитрые китайцы поставляют его без жёстких дисков и дополнительной оперативной памяти. Всё по минимуму, а вот стоимость критичных деталей, без которых он нормально работать не может, равно по стоимости самого NAS. Буду смотреть, сколько он проживёт.

Эта неделя напомнила мне, что даже простая задача может вскрыть массу неочевидных проблем. От мусора в очереди почты до настройки второго OpenVPN — всё требует внимания и терпения. Всё в итоге сводится к одному: если что-то можно улучшить, я это улучшу.

Продолжаю заниматься сервером телефонии Asteriks.
Утром вошёл на сервер и обнаружил тупой брутфорс: перебор номеров телефонов и паролей. Явно кто-то за наш счёт хочет позвонить в Никарагуа. Начал копать в сторону fail2ban. Fail2ban — это система для защиты от брутфорс-атак, который сканирует системные логи и автоматически блокирует IP-адреса с подозрительной активностью через правила брандмауэра. Оказалось, она просто не запущена. Посмотрел конфиги, кое-что поправил и запустил. Брутфорс прекратился. От полноценного DDOS fail2ban вряд ли спасёт, но от тупых китайских ботов вполне.

Затем было погружение в дивный мир монтирования NFS. NFS — это протокол сетевой файловой системы, позволяющий клиентам монтировать и работать с удалёнными директориями на сервере так, как если бы они были локальными.
В чём проблема: отвалился важный скрипт обработки записи телефонных разговоров. А в логах пишется дивная ошибка: «Не удалось прочитать файл /home/development/projects/modules/submodules/experimental/features/audio/processing/pipelines/abc/2023/05/10/output.wav из сетевого диска /mnt/media». Я весь сервер облазил, нет ни такого пути, ни такого файла, и папка, откуда /mnt/media, пустая. Пообщался с коллегой. Файл «output.wav» нашли на другом сервере. Путём долгих рассуждений выяснил, что всё, что в пути файла до «abc», отбрасывается, и скрипт ищет файл по следующему пути /mnt/media/2023/05/10/output.wav. Но папка /mnt/media была пустой. Файл fstab тоже не содержал записи об NFS. Поэтому через NFS примонтировали к ней корень пути /2023/05/10/ и прописал эту запись в файл fstab. Скрипт заработал.
Начал с коллегой думать, в чём корень проблемы. Я где-то неделю назад я вместо перезагрузки Asteriks перезагрузил сам сервер. А перезагрузка сервера в нашей компании — это явление экстраординарное, т. к. чаще всего проблему на Linux-серверах это не решает. Поэтому сервера работают годами без перезагрузки. Но я привык перегружать сервера на Windows, там хватает утечек памяти. Думаю, дело было так: кто-то давным-давно примонтировал сетевую шару вручную через NFS, а вот в файле fstab прописать её забыл. После перезагрузки она автоматом не смонтировалась, и работа скрипта поломалась. Пару седых волос я на этом случае заработал.

Продолжаются мои приключения с ZFS. ZFS — это современная файловая система, обеспечивающий пулы хранения, copy-on-write, мгновенные снапшоты и сквозную проверку целостности данных. Передо мной стоит задача сделать резервную копию сервера телефонии.
Напомню, он работает под FreeBSD на ZFS. Меня не покидает ощущение, что эта FreeBSD меня когда-нибудь убьёт. Приходится ломать через себя очень много привычек из мира Linux. И файлы конфигов в других местах, и управление службами по-другому. Всё выглядит также как Linux, но работает чуть-чуть по-иному, и вот это чуть-чуть сильно бесит, ожидаешь один результат, получаешь иной.
ZFS — система умная, в неё уже встроено резервное копирование на уровне снапшотов. И ничего придумывать не нужно, нужно только настроить другой сервер. Вот с этим и возникла проблема. ZFS она как бы есть, но там какая-то дивная чехарда с лицензиями, поэтому в официальную поставку Linux-дистрибутивов её не включают, и надо ставить вручную. FreeBSD убивает не только меня, но и коллег. Поэтому решили мягко мигрировать на Debian. Но просто так на Debian ZFS не установить. Но есть хорошая инструкция «Debian Bookworm Root on ZFS» https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html. И как же это сделать? Если вкратце, надо загрузится с LiveCD, разметить диск, установить загрузчик, скопировать операционку и провести её настройки из chroot. Я шёл по этой инструкции, но периодически пропускал важные команды. Но с 3-го раза у меня получилось! Теперь буду настраивать получение ZFS-снапшотов с удалённого сервера телефонии по расписанию. А также буду пробовать восстановить полученной снапшот на виртуалку со FreeBSD. Кто хочет понять, как работает ZFS изнутри, рекомендую видео «Моя лекция о COW-файловых системах (ZFS, BTRFS)» https://www.youtube.com/watch?v=z9G4oD5YPKw. После просмотра у меня отпали вопросы, как ZFS архивирует данные, проверяет их целостность, как борется с дублями данных, как у ней организован RAID и снапшоты. И я понял, разработка серьёзной файловой системы — очень масштабная задача.

Я продолжаю углубляться в администрирование серверов телефонии на базе Asterisk, сталкиваясь с типичными, но поучительными проблемами: брутфорс, неработающие NFS-смонтированные каталоги, нестандартное поведение FreeBSD и настройка ZFS. Каждый инцидент — это опыт, который делает систему надёжнее, а меня — профессиональнее. Главное — не сдаваться и досконально разбираться в происходящем.

Всю неделю продолжал делать резервную копию сервера телефонии через ZFS.
Ещё раз прошерстил сервер и решил посмотреть, что занимает больше всего места. Оказалось, логи, они не ротируются от слова «совсем». За пару лет их размер стал несколько гигабайт.
Во FreeBSD ротация логов осуществляется с помощью демона newsyslog, который управляется конфигурацией в /etc/newsyslog.conf. Он проверяется по cron, и ротация выполняется на основе размера файла, возраста и количества копий. Для корректного завершения работы с логом программе обычно отправляется сигнал USR1 — он инициирует переоткрытие файлов журналов без перезапуска процесса.
Однако после получения сигнала USR1 сервер телефонии Asterisk умирает. А должен просто начать запись в новый файл логов. Сколько ни бился, решения этой проблемы я не нашёл, поэтому в cron по расписанию каждую ночь перезапускаю сервер телефонии.
Затем мне поставили задачу, что когда клиент звонит из города или клиенту в город, должно звучать сообщение, что «разговор записывается». Столкнулся с двумя проблемами: кое-где сообщение звучит, а разговор не записывает, кое-где разговор записывается, а сообщение звучит. Поставил проигрывать сообщение везде, где ведётся запись. Оказалось, что внутренние переговоры хоть и записываются, но это сообщение выводить не нужно. Пользователи пугаются.
В Asterisk есть базовое понятие Dialplan — это сценарий, описывающий, как обрабатываются входящие и исходящие звонки. Он реализован на Asterisk Extension Language (AEL). Это сильно упрощенный язык программирования, предназначенный для описания логики обработки вызовов. Так вот, там есть оператор GoTo. Какое фундаментальное правило при работе с GoTo? Нельзя «прыгать» выше по коду и в другие файлы. Это приводит к «лапша»-коду. Те, кто писал Dialplan до меня, про это правило не слышали. Я, пока выяснял, почему не идёт запись входящих городских звонков, через лог нашёл 5 переходов goto в 3 разных файлах. Горите в аду бывшие сисадмины этой АТС. Но я отследил только один входящий маршрут. Угадайте, сколько их всего? 26. Я решил автоматизировать обработку Dialplan, иначе я «закопаюсь».
Но случилось великое событие, я клонировал сервер телефонии через ZFS. Перенёс с «bare metal» на виртуалку. Передачу снапшотов сделал через zrepl https://zrepl.github.io/. А само клонирование реализовал по видео «How to move FreeBSD to another machine (ZFS)» https://www.youtube.com/watch?v=SP7kWg2KHm0. Я напишу 2 больших статьи. Первая — как передать снапшоты на другой сервер при помощи zrepl, вторая — как перенести снапшот на виртуалку со FreeBSD. Будет с чем выступить на конференции.
За время работы я понял, как важно наводить порядок и автоматизировать всё, что можно. Логи не ротировались, Dialplan запутан, сервер падает от простого сигнала — всё это мешает. Теперь всё работает стабильнее, и у меня собрался хороший материал для двух понятных и полезных статей.

Неделя выдалась какая-то странная и вся в телефонии. Дали задачу выводить сообщение, что «ваш разговор записывается». Но у нас в компании, оказывается, около 70 соединений (транков) с операторами связи, а на транке может быть до 26 номеров.
Я решил отследить, почему один разговор не записался. Оказалось, сообщение производится, а сама запись не ведётся. Анализировал около 3-х часов. Ощущение, код для мини-АТС писала «пьяная шимпанзе» хвостом. 5 операторов GoTo по разным файлам. Нашёл ошибку, но это только один транк и один номер. Я понял, что погибну.
Начал писать проект для синтаксического разбора логов https://github.com/orion55/dial-scan, чтобы он проанализировал конфигурационные файлы Asterisk и проверил, достижима ли функция записи. Т. е. вместо меня прошёл по всем GoTo. Просто длина одного файла около 12 тыс. строк кода. Вручную это сделать нереально.
В качестве хранения решил использовать графовую базу данных [RedisGraph](https://github.com/RedisGraph/RedisGraph). Т. е. важны именно связи, а не данные.
Начать писать начал, но не закончил, т. к. файлы конфигов «битые», синтаксически ошибочные. Asterisk выдаёт уйму предупреждений. Он, конечно, их обрабатывает, но для меня пока это задача со звёздочкой.
В результате, раз «снайперская винтовка» с точечным поиском и анализом файлов не сработала, использовал «пулемёт» — сделал глобальную замену в файлах. Использовал sed, добавил дополнительный параметр к существующей процедуре и стал анализировать длину входящих и исходящих номеров. По факту написал ещё один «костыль». Вот хорошее видео по sed [Linux by Rebrain: Работа в sed](https://www.youtube.com/watch?v=mcT4Y311eWU).
Была задача некорректную работу голосового меню. Кто-то поставил уйму задержек, которые не нужны, и пользователь большую часть времени слушал тишину, точнее, не слушал, а бросал трубку. Я поставил фоновую музыку и ускорил обработку вызова. Опять код писала «пьяная шимпанзе». На самом деле, это коллективное творчество, и, как я понял, я уже 5-й администратор телефонии в этой организации. Каждый программировал мини-АТС в меру своих знаний и умений. Результат получился, мягко говоря, не очень.
Всё это окончательно убедило меня в одном: если мини-АТС на протяжении лет программировали пять разных людей, не договариваясь друг с другом, то результат будет соответствующий — словно код писали с закрытыми глазами, да ещё и по очереди. Каждый внёс что-то своё, и теперь вся логика диалплана напоминает археологический раскоп — слой за слоем, от костылей до магии. Попытка навести порядок вручную — как чинить реактивный двигатель с отвёрткой. Поэтому я и начал писать свой инструмент, чтобы парсить, строить связи и проверять логику вызовов автоматически, а не методом шаманства. sed помог, но это как лечить перелом пластырем. Пора переходить от ремесла к инженерии — с валидацией, тестами и графовым анализом вместо угадайки и надежды, что всё сработает. Иначе — так и будем по кругу чинить то, что должно было работать с самого начала.

Написал большую статью «Когда просто бэкап — это скучно, ZFS, Asterisk и немного магии» https://infoblog72.ru/blog/kogda-prosto-bekap-eto-skuchno-zfs-asterisk-i-nemnogo-magii.html Она для тех, кто работает с инфраструктурой и отвечает за живучесть сервисов. Рассказываю, как организовал резервное копирование Asterisk-сервера на FreeBSD через ZFS снапшоты, автоматизировал репликацию на удалённый Debian-сервер с помощью zrepl и какие подводные камни возникли в процессе.

В статье описываю реальную рабочую конфигурацию, подход к проектированию, поясняю, почему выбран pull-метод, и делюсь всеми ключевыми командами. Никакой теории ради теории — только практика и конкретика.

Статья для тех, кто хочет не просто бэкапить, а строить надёжную систему восстановления.

Продолжаю разбираться с Asterisk. Была интересная задача — необходимо было на одном из номеров выводить женским голосом сообщение: «Данная линия не обслуживается». Искать девушку и записывать её голос я не стал, а воспользовался сервисом Yandex SpeechKit. Он озвучил это сообщение женским голосом. Затем я преобразовал полученный аудиофайл в нужный формат, понятный Asterisk (ffmpeg -i input.wav -ar 8000 -ac 1 -c:a pcm_s16le output.wav), и задача была выполнена.
Ещё в нашей фирме есть мобильное приложение, позволяющее совершать звонки. Мне потребовалось выяснить, через какой транк осуществляется звонок. Приложение разработано на Yii. Я решил скачать исходники, зайти на production-сервер и создать архив проекта. Архив создавался примерно полчаса, разросся до размера около 70 Гб, заполнив всё доступное пространство, и завершился ошибкой. Вместе с архиватором отказал и сам production-сервер. Так я случайно «уронил» production, правда всего лишь на десять минут. Выяснилось, что помимо исходников программы я пытался скопировать ещё и каталог загрузок («upload»). Само приложение я потом успешно скачал через GitLab, и оно заняло около одного гигабайта.
Процесс совершения звонков из мобильного приложения выглядит так: PHP-код подключается по SSH к серверу Asterisk и запускает Bash-скрипт с параметрами абонента и направления звонка. Скрипт формирует текстовый файл-заготовку звонка, который затем обрабатывается Asterisk. Однако почему бы не воспользоваться API самого Asterisk, позволившим бы совершить звонок простым HTTP-запросом типа POST? Судя по всему, разработчики на PHP были незнакомы с таким решением. Причины выбора именно этого метода остаются для меня загадкой.
К слову, заметил любопытное сходство между фреймворком Yii и такими технологиями, как NestJS, ASP.NET Core. Здесь прекрасно проявляется принцип объектно-ориентированного программирования, классы, объекты, интерфейсы.
Из этого опыта я вынес несколько выводов. Во-первых, даже простая задача — вроде озвучивания фразы — требует знания инструментов, которые сильно экономят время. Во-вторых, любые действия на production нужно тщательно обдумать, даже если речь идёт об простой архивации. И наконец, архитектура решений, вроде звонков из приложения, должна опираться на здравый смысл и знание возможностей платформы.

В блоге вышла новая статья «Как восстановить Asterisk из снапшота — пошаговая инструкция» https://infoblog72.ru/blog/kak-vosstanovit-asterisk-iz-snapshota-poshagovaya-instrukcziya.html. В ней я рассказываю, как поднять виртуальную копию сервера телефонии на базе FreeBSD 13.1, начиная с загрузки LiveCD и настройки русской раскладки, заканчивая передачей ZFS-снапшота по SSH и активацией загрузочного датасета. Всё описано строго по шагам — без воды и с реальными командами.

Разбираю ключевые действия: создание временного /etc, запуск SSH, получение IP через DHCP, подготовку диска, создание пула zfspool, выбор нужного снапшота и восстановление через zfs send | ssh zfs receive. После этого сервер практически готов к запуску, остаётся лишь отключить ISO и включить машину.

Если вы работаете с Asterisk и используете ZFS, обязательно прочитайте статью. Это реальный опыт восстановления, который можно повторить в условиях продакшена — без лишних рисков и с контролем на каждом этапе.

Продолжаю изучать FreeBSD. Выяснил, что эта операционная система наполнена магией. Система magic распознает тип файлов, Daemon — это служба, ELF — тип файла, а Wizard — это волшебник.

Смотрю курс по FreeBSD, и там тренер рассказал анекдот: «Однажды Ланселоту пришло письмо от короля Артура с заданием: «Ты должен пройти Испытание Рыцаря-администратора. Ответь на этот вопрос: Какие 4 заглавные буквы не являются правильными ключами утилиты ls в FreeBSD?» Ланселот думал долго, но так ничего и не вспомнил. Тогда он написал в ответ: «Не знаю, но точно не -HELP».

Почему это смешно (для тех, кто не в теме)? В системах Unix-like, включая FreeBSD, утилиты, как правило, не имеют опции -HELP. Вместо этого используется man ls, --help, или можно просто попробовать запустить команду без аргументов. Настоящий юниксовый гуру знает, что помощи от самой программы ждать не стоит — только от man или info.

Узнал про vimtutor.ru — это встроенный в систему учебник по vim. А также, что Docker во FreeBSD нет. Есть Jails — родные BSD-контейнеры, но вот Docker нет.

Пока система выглядит, мягко говоря, странно. Есть 2 пути до конфигов: /etc — сама система и /usr/local/etc — конфиги установленных приложений. Все важные настройки хранятся в одном файле /etc/rc.conf — демоны, сеть и файрволл. Поэтому он может принимать огромные размеры. В общем, система, мягко говоря, «странная», если нет большой необходимости переходить, не рекомендую.

Продолжаю изучать Asterisk. Установил на виртуалке FreePBX. Это такой веб-интерфейс над Asterisk. Устанавливал вот по этому гайду: «FreePBX 16 on Debian 12 with Asterisk 18» https://www.youtube.com/watch?v=LRghtpGsYTg. Как было правильно сказано, FreePBX для автоматизации самых простых операций, чтобы реализовать что-то более-менее посложнее, надо писать самому.

Узнал, что существует Kamailio https://www.kamailio.org/w — SIP-прокси для Asterisk. Кто-то может возразить, но есть же haproxy, он прекрасно всё проксирует. Да, прекрасно, но с обрывом разговора, а Kamailio — без обрыва.

Мой вывод такой. Во FreeBSD здесь всё делается руками, осознанно и с пониманием. Это не «поставил и заработало», а «разобрался — и теперь работает так, как нужно именно тебе». Такой подход требует времени, но зато даёт полную прозрачность и контроль.

Продолжаю изучать FreeBSD. Смотрю учебный курс по FreeBSD 2011 года. Прошло 14 лет, а FreeBSD не поменялась от слова «совсем». Есть изменения, но они не радикальные. Если брать Linux даже 5-летней давности, разница сильно видна, а здесь как в болоте — всё тихо и спокойно. Не знаю, в чём причина, возможно, FreeBSD живёт на грантах, а Linux на сообществе. Но выглядит это печально.

На работе получил задание наклеить стикеры с номерами на сетевые розетки и патч-панель, вспомнил молодость, когда бегал с перфоратором и тянул витую пару. Сильно устал, физподготовка никакая. Заодно выяснил, часть розеток на патч-панели расшита как попало, часть вообще на плане не отражена, они «лишние». Как монтажники делали работу и как у них её принимали — вопрос открытый. Но задачу закрыл.

Продолжил изучать Kamailio — SIP-прокси сервер. По этому списку статей https://blog.ipcalls24.com/sip-register-in-kamailio/. Я всё думал, почему Kamailio такой мощный, а потому что-то низкоуровневый. Там все методы SIP-протокола реализовать самому, а это большой кусок АТС. А во время реализации можно вмешаться и настроить так, как удобно. Kamailio — это мощно, но сложно.

Решил сделать лабораторку из плейлиста «Построение IT-инфраструктуры» https://www.youtube.com/playlist?list=PL148XRxlt8SjX804Fkvn5N5KR9IeaGEz_ от «Сисадмин Михалыч». Автор прекрасно знает матчасть и даёт реальный кейс построения серверной части для небольшой компании. Он даже контроллер домена поднимает на SAMBA под Linux, как и DNS- и DHCP-сервера. Но вот инструменты для управления использует от Windows. То, что реализовано под Linux, смотреть без слёз невозможно, автор даже сам нужный софт. Притом, что всю инфраструктуру он реализует на AltLinux https://www.basealt.ru/. Я выполнял за ним, и AltLinux от российских разработчиков мне понравился. По крайней мере, управление сетью достаточно логичное. Что не понравилось, на рабочей станции в оболочке Gnome по умолчанию кнопки заголовка окна «Свернуть» и «Развернуть» отключены, надо включать вручную. Первичный контроллер домена на SAMBA я пробовал поднять лет 10 назад, но не получилось. OpenSource — это, конечно, здорово, но тогда проект SAMBA делали 2 человека на голом энтузиазме. Потом пришёл MS и стал «дружить» с Linux, а до этого пытался его «убить». Сейчас создание домена прошло с полпинка. «Сисадмин Михалыч» настроил выход локальной сети через роутер, а как мне пройти этот роутер и достучаться до машины за роутером? Помогла команда ssh -J root@192.168.1.144 root@10.10.10.10. Я эту команду ещё ни разу не использовал. Чисто моё мнение, контроллер домена для компьютеров с Windows лучше поднимать на Windows, т. к. разработка на Linux всегда будет отстающей. А как лабораторка этот плейлист очень неплоха.

Продолжая погружаться в администрирование, понимаю: решения с открытым исходным кодом дают гибкость, но требуют опыта и терпения. Однако в боевых условиях критичные сервисы, такие как контроллер домена для Windows-клиентов, я бы доверил самой Windows. А всё остальное — отличное поле для экспериментов и роста.