Обзор российских ОС. Альт Рабочая станция 11

Альт не стал включаться в гонку основных разработчиков отечественных Linux дистрибутивов, выпустивших мажорные обновления своих продуктов летом и осенью 2024 года. Новая платформа 11 увидела свет весной 2025 года, но предназначалась только для тестирования, а пригодная для продуктивного применения версия 11.1 была выпущена только осенью. Поэтому сегодня самое время посмотреть на новую ОС Альт Рабочая станция, как фаворита всей линейки систем.

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

✅ Читать далее: https://interface31.ru/post/obzor-rossiyskih-os-alt-rabochaya-stanciya-11/

Как скачать DEB-пакет со всеми зависимостями

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

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

Все скачанные пакеты система размещает в каталоге /var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.

apt clean

После чего перейдем к скачиванию:

apt reinstall --download-only package_name

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

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

dpkg --add-architecture i386
apt update

После чего точно также делаем:

apt reinstall --download-only package_name:i386

После чего переходим в /var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.

Проблема динамического подключения вместо Server Binding в Mikrotik
 
Данная проблема знакома многим, кто работает c VPN в Mikrotik. Вы настроили привязки Server Binding, маршруты, правила брандмауэра и вдруг какой-то клиент перестает работать. Почему?
 
Если мы заглянем в список интерфейсов, то увидим там созданный для него динамический интерфейс вместо Server Binding, если этот динамический интерфейс удалить, то клиент тут же переподключится нормально.
 
Обычно данная проблема возникает при быстром переподключении клиента и связана с тем, что в момент нового подключения старая сессия еще считается роутером активной и поэтому он создает клиенту новое, динамическое подключение.
 
Как с этим бороться? Ограничить клиента единственным подключением, для этого в профиле, который используют ваши клиенты перейдите на вкладку Limits и поставьте опцию Only One в состояние yes.
 
Либо выполните в терминале:
 

/ppp profile set [find name=vpn-profile] only-one=yes

 
Также возможно следует уменьшить значение Keepalive Timeout для вашего VPN-сервера, которое по умолчанию установлено как 60 сек.

Ментальные карты – что это за зверь и с чем его едят?

Многие из нас используют в своей работе различные варианты графического представления информации. Блок-схемами, диаграммами или презентациями уже никого не удивить. А вот ментальные, они же интеллект карты (Mind Map) пока для многих остаются диковинкой.

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

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

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

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

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

У заказчика возник новый вопрос? Тут же добавляем его на карту. Возникла какая-то мысль или была выявлена какая-то особенность? Тоже добавляем. Выявили зависимость – отразили.

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

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

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

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

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

А вы знаете о таком инструменте как ментальные карты? Используете в своей работе?

Никогда такого не было и вот опять!
 

В прошивках, применяемых в потребительских и промышленных маршрутизаторах, коммутаторах, беспроводных точках доступа и системах видеонаблюдения компании Tenda, выявлен бэкдор (CVE-2026-11405), позволяющий получить доступ к web-интерфейсу с правами администратора в обход штатного процесса аутентификации и независимо от настроек учётной записи администратора.
 
Предоставляемые права доступа позволяют управлять всеми настройками, манипулировать трафиком, отключить средства защиты и использовать устройство как плацдарм для атаки на системы в локальной сети.
 
Проблема вызвана наличием в процессе /bin/httpd недокументированной функциональности, встроенной в функцию login(). В случае неудачного завершения штатной проверки пароля по хэшу на основе алгоритма MD5 для любого логина, в коде вызывалась функция GetValue("sys.rzadmin.password"), проверяющая совпадение пароля со значением, предопределённым в прошивке в открытом виде.
 
В случае совпадения, независимо от указанного логина, создавался сеанс с правами администратора.
 
Для использования бэкдора достаточно наличия доступа для отправки запросов к устройству по HTTP или HTTPS. В качестве обходной меры защиты рекомендуется запретить обращение к встроенному в прошивки HTTP-серверу из внешних сетей.
 
Наличие проблемы подтверждено в прошивках:
US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
US_AC10V1.0re_V15.03.06.46_multi_TDE01
US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
US_AC6V2.0RTL_V15.03.06.51_multi_TDE01

 
✅ Отсюда:  https://www.opennet.ru/opennews/art.shtml?num=65856

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

Восстанавливаем The Dude при ошибке db failure: disk I/O error: stopped

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

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

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

Открываем терминал RouterOS и выполняем в нем следующие команды:

/dude set enabled=no
/dude vacuum-db 
/dude set enabled=yes

Если The Dude запустился и работает, то вам повезло, если нет, то переходим к тяжелой артиллерии. Останавливаем службу The Dude:

/dude set enabled=no

И скачиваем файл базы данных dude.db на ПК, также нам понадобится утилита sqlite3.exe, которую можно скачать на официальном сайте.

Теперь выгрузим дамп поврежденной базы:

sqlite3.exe dude.db ".recover" > repair.sql

И соберем из дампа новую исправную базу:

sqlite3.exe dude_new.db < repair.sql

Если все прошло без ошибок, то переименовываем dude_new.db в dude.db и копируем обратно на роутер. Также обратите внимание на размер новой базы, она должна быть примерно такого же размера, как и старая.

После чего уже в RouterOS включаем службу The Dude:

/dude set enabled=yes

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

Полное удаление или переустановка Яндекс.Диска

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

У одного из заказчиков на неделе сломался Яндекс.Диск, причем в нескольких местах. Симптомы: Яндекс.Диск не выходит из состояния синхронизации, отмечая таким образом все файлы и папки и постепенно занимает 100% процессорного времени.

При этом другие клиенты на этом же аккаунте работают нормально, смена аккаунта на больном ПК тоже не помогает.

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

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

А навело нас на эту мысль то, что на одном из ПК после «удаления» и перезагрузки Яндекс.Диск запустился и потребовал учетные данные, а после их ввода успешно заработал, точнее снова повис на синхронизации.

Как выяснилось, при удалении Яндекс.Диска полностью сохраняется содержимое папок:



 AppData\Local\Yandex
 AppData\Roaming\Yandex

В первой живут настройки и логи, во второй сам Яндекс.Диск, который прекрасно запускается оттуда даже после «удаления».

Поэтому для полного удаления или переустановки эти директории следует удалить. Также еще советуем удалить скрытую директорию

 .sync

В папке с синхронизируемыми файлами. После того как вы все удалили можете перезагрузить ПК и заново установить Яндекс.Диск.

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

А давайте кого-нибудь заблокируем!

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

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

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

Сеть =>  Брандмауэр => Приложение => Лог

Классический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.

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

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

Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.

👆 Сообщения лога через брандмауэр не проходят!

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

Но постойте, ведь приложение сообщает клиенту об ошибке? Сообщает, но очень редко делает это открытым текстом, на улице 2026 год и подавляющее большинство коммуникаций зашифровано. Прошли те времена, когда мы могли посмотреть содержимое пакета и сказать «ага».

Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.

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

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

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

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

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

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

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

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

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

Кому сейчас доверять?

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

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

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

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

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

Скажем для оперативной памяти допустимый процент брака не более 1%, а для материнских плат 3-6%, так как это гораздо более сложные устройства.

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

И процент здесь выше, хотя тоже колеблется в зависимости от типа комплектующих, так для оперативной памяти 2-5%, а у материнских плат 5-12%, у видеокарт тоже достаточно высокая планка - до 11%.

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

Хороший пример – память, не работающая на максимальной частоте. На базовой частоте работает? Работает. А остальное, даже если это зашито в XMP-профиль, вам никто не обещал. И мало ли что там на коробке написано.

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

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

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

Все, что лежит у них на прилавках не первый день и не имеет наклейки «новинка» брать можно, хоть у них, хоть в других местах. Но есть одна тонкость.

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

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

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

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

Установка и настройка WineHQ

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

Для этого принято использовать Wine (_Wine Is Not Emulator_) - свободную реализацию Windows API, позволяющую запускать Windows программы в Linux среде. Но мало просто установить Wine, главное - правильно его использовать, особенно если вы запускаете самые различные программы с разными требованиями и настройками.

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

Пакеты Wine традиционно используют две архитектуры - AMD64 and i386, что требует включения в ОС поддержки 32-битной архитектуры. Однако начиная с Ubuntu 25.10 и Debian Testing (Wine 10.8 и новее) выполнен переход на WoW64 и 32-битные пакеты больше не требуются.

✅ Читать далее: https://interface31.ru/post/ustanovka-i-nastrojka-winehq/

Сборки Windows – вчера, сегодня, завтра

Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.

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

По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.

Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.

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

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

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

В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.

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

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

При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.

Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.

Во-вторых, практически все компании стали жить «по белому» избегая установки нелицензионного ПО. Хотя, чтобы не оставлять пользователя совсем с голым ПК многие начали добавлять в образы свободное ПО.

При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.

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

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

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

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

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

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

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

Про современные сборки, бессмысленные и беспощадные...

Tiny 11 - дело ZverCD живет и торжествует

Сегодня у нас будет довольно необычный обзор - на любительскую сборку Windows 11 под названием Tiny 11. Чем же примечательна данная сборка? Да в принципе - ничем, кроме того, что о ней последнее время не пишет только ленивый и она уже успела попасть в ленты новостей и заголовки крупных сетевых изданий.

Нам обещают "облегченную" сборку Windows 11, которая будет способна работать даже на слабых ПК и местами уже слагают оды и поют дифирамбы. А как обстоит ситуация на самом деле? Давайте разбираться.

Начнем с того, что наше личное отношение к сборкам довольно негативное, особенно к сборкам с частично вырезанным функционалом и сделанными непонятно кем. В этом плане Tiny 11 ничем не отличается от ZverCD и его многочисленных "родственников", которых в изобилии на любом торрент-трекере, но, когда нас несколько раз спросили коллеги от том, что мы думаем про Tiny 11 - стало ясно, надо писать обзор.

Как следует из описания создателей сборки, Tiny 11 создана на базе Windows 11 22H2 и из нее вырезаны некоторые компоненты, которые не сильно нужны для работы, благодаря чему и были достигнуты все заявленные особенности. Мы не будем подробно останавливаться на технических моментах сборки, почему - будет ясно после прочтения обзора.

А для того, чтобы выяснить все преимущества и недостатки системы, то не просто посмотрим на нее, а сравним с чистой установкой Windows 11 22H2 в тех же самых лабораторных условиях.

Для сравнения мы взяли две полностью идентичные виртуальные машины с 4 ядрами CPU, 4 ГБ оперативной памяти, а виртуальные диски разместили на недорогом SSD Crucial BX500 240 ГБ. Такая конфигурация примерно соответствует ПК нижней ценовой категории, где Tiny 11 как раз должна раскрыть себя во всей красе.

✅ Читать далее: https://interface31.ru/post/tiny-11---delo-zvercd-zhivet-i-torzhestvuet/

Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory

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

Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.

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

Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».

Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.

При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.

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

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

Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».

Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.

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

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

Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.

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

Samba AD DC – ожидания и реальность
 
Каждый раз обращаясь к этому вопросу можно услышать, что Samba AD DC в целом дорос до продуктивного уровня и если не фонтан, то все основные задачи закрывает примерно как на уровне Windows Server 2008 R2.
 
В общем и целом, это так, Samba предоставляет стабильные возможности домена уровня 2008 R2, поддерживает групповые политики и управляется стандартными Windows оснастками, на первый взгляд – отличная замена Windows AD и хорошая экономия на лицензиях, но это только на первый взгляд.
 
В качестве одиночного контроллера Samba AD DC действительно смотрится неплохо, но как мы помним, базовые правила построения Active Directory требуют наличия минимум двух контроллеров.
 
И это даже не вопрос высокой доступности, это базовый вопрос элементарной устойчивости, если что-то случилось с основным контроллером, скажем физически и невосстановимо вышел из строя, то его функции подхватит второй контроллер, так что даже никто ничего не заметит.
 
Напоминаем, что в современной AD все контроллеры равны, а роли FSMO не нужны для повседневной работы домена (некоторые вообще нужны один два раза в его жизни).
 
А что у нас предлагает Samba, а предлагает она нам интересные моменты – штатной репликации SYSVOL нет и не будет, потому как реализация закрытого протокола DFS-R сопряжена как с техническими, так и с юридическими сложностями.
 
Взамен предлагается ручная репликация любым доступным способом, скажем через rsync, но репликацией это можно назвать с большой натяжкой, так как транзакционная целостность процесса отсутствует, что серьезно осложняет дело.
 
Что это значит? Когда мы создаем новую политику – метаданные от нее записываются в базу AD и штатно реплицируются между контроллерами, а файлы остаются в SYSVOL контроллера и ждут пока мы их не синхронизируем руками.

В итоге получаем, что на каком-то контроллере политика есть, а файлов нет. А у клиента политика то применяется, то не применяется, смотря к какому контроллеру он подключился.
 
Если файлы были изменены сразу в двух местах, то просто наступает ад, какую версию считать главной? В Samba эту проблему решили костылем – контроллер с ролью PDC не может быть целью rsync-синхронизации, только источником и все изменения в AD следует вносить только на нем.
 
Но это только надводная часть айсберга, под водой у нас остался механизм трансляции SID Windows в Linux UID, для этого он на каждом контроллере хранит локальную базу сопоставлений idmap.ldb, которая также не реплицируется.
 
После того, как мы добавили в AD новые объекты, которые являются субъектами безопасности и имеют свой SID нам нужно обновить эту базу на всех контроллерах домена. Причем сделать это можно только с остановкой службы контроллера и потом обязательно перечитать права на SYSVOL.
 
Фактически у нас появляется три отдельных процесса:
 
🔹 Репликация базы AD (автоматически)
🔹 Синхронизация SYSVOL (руками, в одну сторону)
🔹 Синхронизация idmap.ldb (руками, с остановкой службы)
 
Про транзакционную целостность мы даже речи не ведем, нам бы тут ничего не сломать. Поэтому все многоконтроллерные и многосайтовые конфигурации тут же разбиваются об этот кошмар.
 
По сути, Samba предоставляет нам только две более-менее рабочие конфигурации AD.
 
🔸 Один контроллер + бекап (холодный резерв)
🔸 Два контроллера с постоянным ручным контролем процесса
 
Это даже не уровень PDC/BDC NT4, там хотя бы репликация на вторичный контроллер была автоматической. Это история про один контроллер в нетребовательной среде, не более.
 
Хотя каждый может принимать решение самостоятельно, главное осознавать риски и представлять в чем заключается суть проблемы.