В очередной рассылке Let’s Encrypt уведомила о грядущем прекращении рассылки с напоминанием об окончании срока действия сертификата:

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

В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite

Сервис достаточно функциональный и позволяет в бесплатной версии наблюдать до 250 сертификатов, что более чем достаточно как для личных, так и для корпоративных нужд.

Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.

Кому лень регистрироваться – можно войти через Google или Microsoft.

По мотивам реальных событий.

▫️ Вася решил мониторить температуру произвольных устройств.

▫️ Вася решил использовать для этого sensors

▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:

UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.

❓Что не так сделал Вася?

​​В чем был не прав Вася?

Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.

▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.

▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.

▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.

▫️ Затем это все передается команде awk, где и происходит основная магия.

🔹 -F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.

🔹 {avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.

🔹 END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.

👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.

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

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

Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +37.9°C  (low  =  -0.1°C, high = +114.8°C)
                       (crit = +119.8°C)

Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:

sensors | grep nvme-pci-0100 -A 2

Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:

sensors | grep nvme-pci-0100 -A 2 | tail -n 1

И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:

sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'

Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.

Уже видели новость? Слёрм запускает серию вебинаров с экспертами из бигтеха про вакансии в DevOps.

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

🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?

📆 Первая встреча: 13 февраля в 19:00

Ведущий: Вячеслав Федосеев, TeamLead DevOps в «‎Честном знаке», автор канала «‎DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru

Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.

Расписание, подробности и ссылки на встречи — в боте 📌

#реклама
О рекламодателе
erid: 2W5zFHUFkK2

Вроде это знают все, как оказалось - не все.

Linux - начинающим. Потоки, перенаправление потоков, конвейер

После того, как вы освоили базовые принципы работы с Linux, позволяющие более-менее уверенно чувствовать себя в среде этой операционной системы, следует начать углублять свои знания, переходя к более глубоким и фундаментальным принципам, на которых основаны многие приемы работы в ОС.

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

Все это очень широко используется и понимание того, как это работает важно для любого Linux-администратора.

https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html

​​Чтоб ты жил в эпоху перемен

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

Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.

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

Самая большая ошибка – это выполнить все изменения разом, потому что после этого, если что-то пойдет не так, будет совершенно непонятно, что именно стало причиной такого поведения и за что браться в первую очередь. Получится такой пожар во время наводнения.

Поэтому вносить изменения надо постепенно, даже если они «срочные». Сядьте и распишите все что вам требуется изменить. Обычно это изменения нескольких видов:

Обновить существующее ПО/оборудование

Добавить новое ПО/оборудование

Изменить текущие настройки/включить новые

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

Мы, например, предпочитаем использовать для этого интеллект-карты, где можно легко разбить задачу на этапы и указать зависимости, пример такой карты в скриншоте под данной заметкой.

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

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

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

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

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

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

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

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

Даже если проблема комплексная и появляется на пересечении нескольких изменений, то тоже будет примерно понятно это комбо, так как вы всегда будете видеть, какой из добавленных или измененных компонентов привел к проблеме и сможете провести причинно-следственные связи, хотя бы примерно определив предполагаемого виновника.

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

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

В комментариях к статье читатели посоветовали еще один конфигуратор для PostgreSQL.

Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).

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

https://tantorlabs.ru/pgconfigurator

Сегодня у нас в Белгороде случилась страшная трагедия. BMW X7 в самом центре Белгорода протаранил карету Скорой помощи. Две девушки фельдшера погибли на месте, водитель крайне тяжелый в реанимации.

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

​​Неочевидное - невероятное

Работая с определенным оборудованием накапливается опыт и определённые практики. Некоторые действуют на подсознательном уровне.

Так в Mikrotik если мы что-то изменили - оно становится синим. Но не всегда и не везде.

Откроем брандмауэр и создадим там правило пустышку, ну, скажем, такое.

0 chain=forward action=accept log=no log-prefix=""

Теперь откроем его в Winboх и полазим на закладке Extra, ничего не трогаем, просто смотрим. Как видим ничего не посинело, спокойно уходим и жмем OK.

Но не тут-то было, вывод правил в терминал покажет нам:

0 chain=forward action=accept psd=21,3s,3,1 limit=1,5:packet dst-limit=1,5,dst-address/1m40s time=0s-1d,sun,mon,tue,wed,thu,fri,sat log=no
log-prefix="

Внезапно!

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

Во всем виноват IPsec, однозначно!

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

Чтобы потом не было подобных вопросов. Хотя это как раз классика: я поднял IPsec и где мои маршруты? Равно как и почему у меня из-за NAT работает ровно один клиент.

Тем более что подобные вещи достаточно легко гуглятся. Но увы, чаще всего сначала делают, потом ходят по граблям и только потом начинают читать.

Не надо так. IKEv2 - отличный инструмент для удаленного доступа, тем более он уже есть в каждом клиенте, но для соединения сетей выберите что-то другое.

​​Про IPsec для самых маленьких

Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).

Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.

При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.

Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.

Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.

IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.

Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.

В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.

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

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

Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.

Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.

GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.

Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.

А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.

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

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

❓ Хотите научиться запускать сайты на Linux с нуля?

На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.

💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.

⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.

⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.

👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://otus.pw/cYLN/?erid=2W5zFJhhwcU 

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Б/у диски Seagate массово продаются под видом новых.

Еще с января не утихает скандал с массовой продажей в розницу б/у серверных дисков Seagate под видом новых.

Первыми о таких случаях сообщили продавцы из Германии, а на настоящий момент поддельная продукция была обнаружена и в других странах Европы, Австралии, Тайланде, Японии.

Диски имеют сброшенный SMART, что создает иллюзию нового, но если сделать запрос к счетчику продолжительности использования FARM, то будет виден реальный пробег диска, который составляет от 15 000 до 50 000 часов.

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

Его предварительные результаты ведут к китайским майнинговым фермам, которые добывали монету Chia. Теперь, после падения рентабельности многие фермы закрылись и на рынок выплеснулось большое количество бывших в интенсивном употреблении дисков.

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

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

Поэтому крайне внимательно относитесь к покупке такой продукции и обязательно проверяйте реальную наработку, это можно сделать официальной утилитой с сайта производителя.

​​Lithnet Password Protection for Active Directory (LPP)

Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.

Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1

Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.

Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'

Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.

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

Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.

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

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

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

И все это, как мы уже говорили – бесплатно, по лицензии MIT.

✅ Страница проекта: https://github.com/lithnet/ad-password-protection

❗️Освойте новые инструменты DevOps и администрирования со скидкой до 15 000₽

Хотите вырасти как специалист и работать на более сложных проектах? 

▶️Собрали курсы, которые охватывают весь спектр необходимых знаний и инструментов для профессионального роста  一 от контейнеризации с Docker и оркестрации с Kubernetes, до автоматизации CI/CD и управления облачной инфраструктурой. 

▶️Вы научитесь мониторить и логировать системы, строить надежные CI/CD пайплайны, предоставлять и поддерживать вычислительную инфраструктуру с помощью кода, балансировать нагрузку БД и многое другое.

🎁А чтобы учиться было еще приятнее, всем инженерам, администраторам и DevOps дарим промокод FEB25 на скидку 15000₽
*ввести его можно в окне оплаты, оно откроется после заполнения формы контактов

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

#реклама
О рекламодателе

​​Резервные копии Active Direcitory

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

В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.

Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.

Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.

Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.

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

Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.

Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.

Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.

Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.

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

Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».

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

В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.

Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.

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

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

И снова нестареющая классика, ибо в очередной раз сегодня слушали про первичные контроллеры и прочую ересь.

Мифы и легенды Active Directory. Хозяева ролей FSMO

Active Directory, как и любая серьезная система с долгой историей успела приобрести свой фольклор, неотъемлемой частью которого являются мифы и легенды.

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

Сегодня же попытаемся понять, что делают и чего не делают хозяева операций, для чего они вообще нужны и можно ли жить без них.

https://interface31.ru/tech_it/2022/06/mify-i-legendy-active-directory-hozyaeva-roley-fsmo.html