Открытый проект OptimizerDuck позволяет очистить Windows 10/11 от мусора и бесполезных процессов (телеметрию, рекламу, Copilot, все фоновые сервисы и ненужные приложения):
оптимизирует ПК для работы и игр, настраивает GPU и производительность процессора, работает с менеджером автозагрузки, удаляет встроенный bloatware, чистит систему.
может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.
работает без установки, без ограничений и полностью локально.
Обновил вчера Ubuntu 25.10 на 26.04. В последние два года я обновляю Ubuntu при каждом новом выпуске, начиная с 23.10 насколько помню. И никаких проблем ни во время обновления, ни после него до этого не возникало. Вчера же столкнулся с несколькими неприятностями:
Объём загружаемых пакетов вырос с обычных 2 Гб до 4 Гб! Вероятно у вас будет меньше, ведь это зависит от установленных вами пакетов, но если судить относительно прежнего объёма, то скачёк потребления трафика с учётом мобильного доступа не радует. Скаченные пакеты я сохранил, чтобы на других ноутбуках с Ubuntu не пришлось снова качать 4 Гб. Раньше я так не делал.
Во время установки пакетов рабочий стол заблокировался с сообщением, что у меня нет прав root, чтобы что-то сделать, что именно не написано. Причём нажатие на Отмена блокировку не снимало, и окно сообщения оставалось открытым. Похоже на какой-то баг Gnome, Resolute или где-то глубже в системе. Дождался, когда индикатор диска и вентилятор успокоятся, в надежде, что обновление закончилось успешно, переключился на консоль и сделал reboot.
После первой загрузки и входа в Gnome рабочий стол завис. Снова переключение в консоль и reboot. После второй перезагрузки Gnome заработал. Это ещё один явный баг.
Теперь после каждого включения с нуля или после сна, не важно, запускается какой-то процесс localsearch, который интенсивно работает с диском и греет процессор. Причём процесс ветвится. Как отключить не понятно. Подождав полчаса сделал kill по номеру процесса localsearch. И вынужден делать это каждый раз.
В остальном пока вроде всё нормально. Особых нововведений не заметил. Пиктограммы программ в главном меню стали меньше. В строке статуса появился значёк режима нагрузки процессора.
В предыдущих выпусках был ещё баг с thumbnailer, который при открытии в Nautilus папки с большим количеством фото, выжирал остатки памяти, что приводило к торможению всей системы намертво и последующего принудительного жёсткого отключения питания (известный баг Linux, который за десять или более лет так и не исправлен). Как я понял, в 26.04 thumbnailer был заменён на что-то другое, и я пока ещё не поимел проблем с большими папками с фото. Но посмотрим…
UPD Посмотрел, что это за localsearch. Похоже, что это часть Gnome. Поэтому стандартными средствами управления сервисами его не отключить. Запускается при входе в Gnome. Как эту ненужную мне и вредную с точки зрения энергопотребления и шумозагряднения штуку выключить в Gnome?
Резюме Ещё до обновления я начал искать альтернативы Ubuntu, понимая что запросы системы к процессору и памяти растут, Ubuntu всё больше походит на bloatware и corporate, а переходить на более новое железо я не собираюсь. Пока в качестве альтернатив рассматриваю: antiX, Devuan, Gentoo, Void, Guix, NetBSD, OpenBSD. Этот набор обусловлен тем, что мне нужно, чтобы система поддерживала 32-разрядность. И я хочу иметь на 32- и 64-разрядных системах одинаковый опыт и навыки работы с ними. А какие альтернативы Ubuntu используете вы? Что скажете про мой список альтернатив? Кстати, до полного перехода на Ubuntu я также работал в последние годы с ElementaryOS, Manjaro, Fedora. Пробовал antiX, Void, NixOS и Guix. По большому счёту они отвергнуты были в том числе по тем же причинам, что теперь и Ubuntu, Кроме antiX, Void и Guix. Это особый случай, и это отдельная тема для разговора.
(с) 2026, Евгений Симоненко
Что не так с DeFi и почему там до сих пор происходят взломы
Со стороны DeFi выглядит как будущее финансов: кошелёк вместо банка, смарт-контракт вместо посредника, а код вместо правил “по договорённости”.
Но в реальности DeFi это не одно приложение, а связка протоколов, смарт-контрактов, пулов ликвидности, оракулов, мостов, токенов управления и внешних интерфейсов. Пользователь видит кнопку Swap или Deposit, но под капотом может запускаться целая цепочка вызовов между контрактами. И чем больше таких зависимостей, тем больше поверхность атаки.
Одна из главных проблем - composability. В DeFi протоколы часто строятся друг поверх друга: lending-протокол использует один токен, DEX даёт ликвидность, оракул поставляет цену, мост переносит актив между сетями, а поверх всего этого работает ещё один интерфейс. Это удобно для разработки, но опасно для безопасности. Ошибка в одном элементе может стать проблемой для всей цепочки.
Отдельный риск - смарт-контракты. В традиционной системе подозрительную операцию можно остановить, откатить или вручную проверить. В DeFi логика другая: если транзакция валидна и контракт позволяет выполнить действие, сеть его выполнит. Поэтому баг в коде, ошибка в проверке прав, неправильная работа с балансами или уязвимость в математике протокола могут стоить не “небольшого сбоя”, а сразу миллионов долларов.
При этом атаки давно не сводятся к классическому “взлому”. Часто злоумышленник не ломает сервер, а использует экономическую механику протокола. Например, через flash loan можно взять огромный объём ликвидности в рамках одной транзакции, временно исказить цену в пуле, повлиять на расчёт залога или ликвидации, а затем вернуть заём до завершения блока. Формально всё может пройти по правилам контракта, но результат будет разрушительным.
Большая зона риска - оракулы. DeFi-протоколам нужно откуда-то получать цены активов. Если протокол берёт цену из слабого источника, например из тонкого пула с низкой ликвидностью, этой ценой можно манипулировать. Дальше начинается цепочка: неверная цена → неправильная оценка залога → ошибочная ликвидация или вывод средств.
Ещё одна больная точка - кроссчейн-мосты. Мосты соединяют разные сети и часто хранят или контролируют большие объёмы ликвидности. Это делает их идеальной целью. Проблема в том, что мост должен одновременно доверять событиям в одной сети и корректно выпускать или разблокировать активы в другой. Любая ошибка в валидации сообщений, подписях, мультисиге или логике relayer-ов может привести к катастрофе.
Есть и governance-риск. Многие DeFi-протоколы управляются через DAO и governance-токены. На практике это означает, что изменение параметров протокола, обновление контрактов или управление казной может зависеть от голосований, делегатов и концентрации токенов. Если управление плохо защищено, атакующий может повлиять не на код напрямую, а на правила игры.
Парадокс DeFi в том, что он создавался как trustless-система, где не нужно доверять посредникам. Но на практике пользователь всё равно доверяет: аудитам, разработчикам, оракулам, мостам, мультисигам, фронтенду, governance-механике и экономической модели протокола.
То есть доверие не исчезло. Оно просто переехало из банка в инфраструктуру.
Именно поэтому DeFi до сих пор остаётся одновременно самой интересной и самой уязвимой частью крипторынка. Чем больше открытости, автоматизации и связности между протоколами, тем сложнее сделать систему безопасной не только на уровне кода, но и на уровне экономики, ликвидности и пользовательского сценария.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
Hostname srv-10-79.rtk.company.com
Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
ProxyJump gate-10-1+yota
Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*"
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*"
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
Если вы сидите на MacOS / iOS и у вас VPN на VLESS+XTLS‑Reality, то при очередном обновлении системы/VPN-клиента с высокой вероятностью всё сломается или уже сломалось. Это не баг Shadowrocket и не баг xray-core. Apple ввела квантово-безопасное шифрование TLS 1.3 по умолчанию в iOS 26 / macOS 26, которое увеличивает размер TLS ClientHello на ~1216 байт. REALITY-сервер xray-core не может корректно прочитать такое большое сообщение — отсюда firstLen = 0 и отсутствие соединения. Windows это не затронуто. Простого/универсального решения нет, т.к. откат на предыдущую версию в экосистеме Apple — тот ещё квест. Если ваше клиентское приложение VPN позволяет настроить TLS → Fingerprint, тогда там необходимо выбрать firefox или Crome110 — для которых ещё не было поддержки X25519MLKEM768. В этом случае всё легко чинится.
Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов
Системное администрирование давно не ограничивается «поднять сервер и настроить доступы». Сегодня инфраструктура живёт в контейнерах, кластерах, пайплайнах, распределённых системах и мониторинге, который должен подсказать о проблеме раньше, чем её заметят пользователи.
В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.
Если хотите закрыть базу по Linux и автоматизации
18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.
4 июня, 20:00. «Продвинутый Bash».
Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.
22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».
Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)
Если работаете с контейнерами и Kubernetes
2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.
28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.
18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.
Если отвечаете за стабильность систем
1 июня, 20:00. «Мониторинг распределенных систем».
На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.
16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.
3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.
Если зона ответственности включает защиту инфраструктуры
16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.
Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.
GitOps без романтики: эксплуатация, советы, решения
Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.
В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.
Что на повестке
Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.
Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.
Смотрите видео на площадках:
🔵 VK Видео
📺 YouTube
📌 RuTube
Ⓜ️ Mave
Седьмая локация для облачных серверов
Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.
Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.
Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.
Уже доступно в панели, проверяйте →
Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент
Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.
И книга оказалась просто 10 из 10.
Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.
Что внутри:
Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.
Большой блок посвящён коду. Код описан через примеры и советы, но так же описаны типовые ошибки, подводные камни и наследие старых версий, которое всё ещё можно встретить в живых инфраструктурах, но лучше заменить. Не всегда код из книги отрабатывал корректно, нужны были мелкие правки, может это из за версий, а может задумка автора, чтобы ты немного прикладывал голову.
Отдельно понравилось, что есть главы про архитектуру использования Puppet, серверную часть, конфигурирование, тонкую настройку, логирование, мониторинг и эксплуатацию. То есть это не только книга для тех, кто пишет Puppet-код, но и для тех, кто потом будет держать всю эту систему в работоспособном состоянии.
Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.
Так же в этих главах становится понятно что автор не просто пользуется Puppet, а является частью его команды разработки. Отсюда и такой уровень погружения в разные аспекты инструмента.
По итогу:
Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.
Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.
Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.
Представлен аналог Discord — открытый проект GoofCord, который:
быстрее официального клиента, не глючит и не тормозит;
внутри заблокирована вся слежка и сбор данных о пользователе;
переписка шифруется паролем;
демонстрация экрана в любом разрешении и с любой частотой кадров;
можно выбирать, звук какого приложения стримить;
игры, музыка или видео встают в ваш статус автоматически;
плагины для кастомизации Vencord, Equicord и Shelter работают из коробки;
глобальные хоткеи работают даже со свёрнутым окном;
можно стримить со звуком на Linux, работает также на Windows и macOS.
Открытый проект Go Interview Practice содержит обширный репозиторий для подготовки к собеседованиям на Go:
внутри — целая интерактивная платформа с задачами всех уровней. Могут готовиться как новички, так и профи.
ИИ‑интервьюер проверяет решения и сразу дает подсказки.
есть таблица лидеров, чтобы соревноваться с топами и видеть свой прогресс.
можно задать вопросы коммьюнити, если задача оказалась слишком трудной.
Почему у Bitcoin несколько типов адресов и в чём их отличие
Большинство пользователей просто копируют Bitcoin-адрес и отправляют средства, не особо задумываясь, почему одни адреса начинаются на 1A1zP1..., другие на 3J98t1..., а третьи выглядят как длинный набор символов вроде bc1qw508....
На практике это не “разные виды биткоина”, а результат эволюции самой сети Bitcoin. Каждый новый формат адресов появлялся как попытка решить конкретные проблемы: высокие комиссии, ограниченную пропускную способность, сложность транзакций или недостаточную эффективность сети.
Самые старые Bitcoin-адреса - это Legacy-адреса. Обычно они начинаются на 1. Это первый массовый формат адресов в сети Bitcoin, который использовался ещё задолго до появления современных обновлений. Главный минус таких адресов сегодня - менее эффективная структура транзакций, из-за чего комиссии обычно выше.
Позже появился формат SegWit. Чаще всего такие адреса начинаются на 3. Его главная задача была довольно практичной: уменьшить размер транзакций и снизить нагрузку на сеть. Благодаря этому комиссии стали ниже, а сама сеть - эффективнее. По сути, SegWit стал одним из самых важных обновлений Bitcoin за последние годы.
Следующий этап - Native SegWit или Bech32. Именно эти адреса начинаются на bc1. Сейчас они считаются более современным вариантом для обычных переводов. Такие адреса занимают меньше места в блоке, ещё сильнее снижают комиссии и лучше подходят для современной инфраструктуры Bitcoin. Именно поэтому всё больше кошельков и сервисов по умолчанию используют формат bc1.
Но эволюция на этом не остановилась. После обновления Taproot в сети появились и новые типы адресов bc1p..., которые уже связаны не только с экономией комиссий, но и с более сложными возможностями сети. Например, Taproot улучшил эффективность multisig-транзакций, частично повысил приватность некоторых сценариев и подготовил основу для более гибких механизмов работы Bitcoin в будущем.
Из-за этого сегодня в сети одновременно существуют сразу несколько форматов адресов. Старые варианты никуда не исчезли, потому что Bitcoin очень осторожно относится к совместимости: сеть должна продолжать работать даже с кошельками и сервисами прошлых поколений.
Именно поэтому один пользователь может отправлять BTC на адрес формата 1A1zP1..., другой на 3J98t1..., а третий на bc1qw508... - и все они всё равно работают внутри одной сети Bitcoin.
Если упростить, разные типы Bitcoin-адресов - это не хаос и не путаница, а следствие того, как сама сеть постепенно развивалась, пытаясь сделать транзакции дешевле, эффективнее и технологически гибче.
Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.
Добрый день, уважаемые коллеги!
Прошу прощения за задержку тары сообщения, но новость о прекращении разработки и сопровождения pgbackrest более неактуальна: https://github.com/pgbackrest/pgbackrest#maintenance-update
Спасибо @Harliff: https://habr.com/ru/articles/820349/#comment_29976278
Нужна ли кувалда, чтоб вынуть один кривой гвоздь?
Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.
Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.
И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.
Полный откат – не всегда ответ
С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.
Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.
Не «всё умерло», а:
– удалили одну важную группу;
– изменили атрибут у тысяч пользователей;
– сломали членства;
– неверно применили политику;
– после миграции обнаружили хвосты в объектах;
– интеграция записала в каталог не то, что должна была.
Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.
А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.
Почему полное восстановление неудобно
Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».
Для аварии это нормально.
Для точечной ошибки – не всегда.
Если откатить каталог целиком, можно вернуть не только испорченные данные, но и потерять корректные изменения, которые появились после бэкапа. Новые пользователи, изменения групп, обновлённые атрибуты, свежие правки политик – всё это тоже часть реальной жизни каталога.
Получается выбор без хорошего варианта:
1️⃣ откатить больше, чем нужно;
2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;
3️⃣ вручную разбирать, что именно поменялось.
Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.
Что хочется иметь на практике
В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».
А что именно изменилось между текущим состоянием каталога и снимком:
– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.
И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.
Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.
Кувалда нужна, когда стена рухнула. Но если надо достать один криво забитый гвоздь, кувалда внезапно становится странным выбором.
Где здесь РЕД АДМ 2.1 и Granulex Recovery
В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.
Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.
Для крупных инфраструктур это особенно важно. Чем больше пользователей, групп, политик, интеграций и зависимых сервисов, тем опаснее становится подход «ну сейчас быстро откатим всё назад».
Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.
Финальный вывод простой: резервная копия спасает от тяжёлого сбоя. Но логические ошибки в каталоге часто нужно не откатывать целиком, а аккуратно вынимать пинцетом.
Так получилось, что мне приходится работать с достаточно древними серверами (причины оставаться на старом железе и софте разные, но достаточно веские). Я и так стараюсь держаться на два шага позади переднего края (чаще всего это Debian oldoldstable), но иногда приходится делать резкий шаг вперёд (обновляться до oldstable, который скоро oldoldstable станет).
Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).
К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:
Host old-server
Hostname 1.2.3.4
. . .
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
KexAlgorithms +diffie-hellman-group14-sha1
Напрямую или через бот-платформу: как лучше интегрировать чат-боты
От выбора зависит не только сложность внедрения, но и дальнейшая поддержка. Разбираем плюсы и минусы подходов на примере интеграции с сервис деск системой.
1. Прямая интеграция с каналом
➕ Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖ Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.
2. Интеграция через Botmother
➕ Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖ Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.
3. Интеграция через Fasttrack
➕ Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖ Сложнее в настройке сценариев в отличие от того же Botmother.
Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.
Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.
K2 Cloud курирует трек “Облака” на ДевФест 21-22 мая
21-22 мая в Омске пройдёт ДевФест 2026, партнером которого стал K2 Cloud. Мы будем на площадке оба дня: со стендом, спикерами и целым тематическим треком “Облака”, который курируем в программе конференции.
В треке поговорим про архитектуру, безопасность, CI/CD, бесшовные релизы, dogfooding, облако в облаке, BI-конструкторы и федеративное обучение. За доклады отвечают эксперты из K2 Cloud, Авроры/ОМП и Битрикс24.
И приятный бонус для тех, кто уже открыл вкладку с билетами: промокод BESTCLOUDEVER даст 10% скидки.
Сам ДевФест пройдет 21 и 22 мая с 10:00 до 18:00, а наш облачный трек – в оба дня с 11:00 до 14:00. Программу конференции можно посмотреть на сайте, а расписание трека дополнительно вынесем сюда:
21 мая
11:00 – JWT в геораспределённой архитектуре: аутентификация пользователей веб-консоли мультирегионального облака (Никита Трунов, K2 Cloud)
Никита разрабатывает инфраструктурные сервисы K2 Cloud на Python и работает с логированием, мониторингом, безопасностью и управлением пользователями. В докладе он разберёт, как устроить аутентификацию в мультирегиональном облаке: где JWT помогает, какие сложности появляются при синхронизации и в каких случаях стоит смотреть в сторону альтернативных или комбинированных подходов.
12:00 – Бесшовные релизы глазами разработчика: обновляем код Облака без отключения API (Игорь Анохин, K2 Cloud)
Игорь как руководитель платформенной разработкой в нашем облаке расскажет про особенности обновления высоконагруженной системы без остановки API. В фокусе будут эволюция релизных подходов от Big Bang до Rolling-Out, требования к коду, миграциям и контрактам, а ещё компромиссы, без которых бесшовность не работает.
13:00 – CI/CD Flutter-приложений для ОС Аврора (Ирина Житницкая, Аврора/ОМП)
Ирина занимается тестированием и CI/CD-процессами публичных проектов ОС Аврора. Она покажет, как перевести сборку Flutter-приложений под ОС Аврора из ручного процесса в прозрачный pipeline, какие архитектурные решения помогают сделать его воспроизводимым и где чаще всего возникают проблемы.
22 мая
11:00 – Архитектура BI-конструктора Битрикс24 (Александр Сербул, Битрикс24)
Александр занимается архитектурой и разработкой высоконагруженных отказоустойчивых проектов в Битрикс24. На примере BI-конструктора он разберёт путь от проектирования до запуска облачного сервиса: архитектурные решения, масштабирование, развитие команд и практическое применение Python и Kubernetes.
12:00 – Ешь, молись, люби своё облако: Dogfooding как драйвер развития (Александр Чернев, K2 Cloud)
Александр участвовал в запуске KaaS и PaaS-платформ K2 Cloud, работал над релизными процессами, тестированием и стабилизацией платформы. В докладе он расскажет, как мы используем собственное облако для разработки и тестирования: зачем нужен dogfooding, как работает “облако в облаке” и как внутреннее использование продукта помогает быстрее находить слабые места.
13:00 – Сломанные веса: как разное железо мешает федеративному обучению и что мы можем с этим сделать (Максим Мухамедов, K2 Cloud)
Максим – Python-разработчик в K2 Cloud, который до разработки успел поработать с инфраструктурой датацентра на физическом уровне модели OSI. Он разберёт, как особенности железа, сенсоров и версий ОС искажают данные в федеративном обучении ИИ, почему возникает system-induced bias и какие подходы помогают отличить проблему данных от проблемы устройства.
Если будете в это время Омске, обязательно заглядывайте к нам: будем ждать вас на стенде и докладах!
VDI в Termit на базе zVirt: как оптимизировать рутинные операции по работе с ВРМ
19 мая Orion soft проведет технический вебинар с демонстрацией функциональности VDI в платформе виртуализации рабочих столов и приложений Termit. Системный инженер Дмитрий Руссу покажет, как выполнять рутинные операции в Termit максимально быстро и эффективно.
На вебинаре подробно рассмотрим:
- Как развернуть виртуальное рабочее место Windows и Linux
- Как подготовить золотой образ и экономить время на создании ВРМ
- Как объединять ВРМ в ресурсные группы и управлять ими
- Как создать каталог и работать с ним
Только для участников вебинара — проведем опрос о пожеланиях по функциональности следующих релизов Termit. Лучшие предложения реализуем, а их авторам подарим эксклюзивные паки мерча Orion soft.
Также ответим на все интересующие вас вопросы. Присоединяйтесь, чтобы научиться новым лайфхакам в работе с Termit и оптимизировать свою рутину.
Кому будет интересно:
- Системные администраторы
- Инженеры (по виртуализации, VDI, ИТ-инфраструктуре, ИБ, технической поддержке и др.)
- Архитекторы (виртуальной инфраструктуры, рабочих мест и др.)
Сервер для PyTorch: как выбрать конфигурацию под обучение и инференс
PyTorch запустится почти на любом сервере, но между «запустится» и «работает стабильно под нагрузкой» — большая разница. Частая ошибка — выбирать VRAM по размеру модели, но видеопамять занимают контекст, KV-cache, размер батча и служебные расходы фреймворка.
В новой статье разобрали, когда хватает CPU и в каких сценариях нужен GPU. Показали, как заранее проверить совместимость драйвера NVIDIA и версии CUDA, как эмпирически измерить фактическое потребление VRAM и сколько RAM закладывать под DataLoader с несколькими воркерами. И собрали ориентиры по конфигурациям — от прототипирования и небольшого инференса до обучения на 2–4 GPU и больших моделей.
Все подробности — в блоге Рег.облака.