▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее
время (обычно беру период в 2 недели), что мне понравились.

⇨ Как я прошёл путь от эникея до Lead DevOps | Моя карьера в IT
Личная история карьеры конкретного человека. Такая первичка, мне кажется, всегда интересна. Но мало кто готов её выкладывать. Так что автору однозначно плюс за то, что сделал это.

🔥TrueNAS решила одну из главных проблем с хранилищами в Proxmox
Авторы ОС для хранилища TrueNAS выпустили плагин для интеграции с PVE. TrueNAS и так часто выбирают для отказоустойчивых хранилищ в том числе под диски виртуальных машин. А с интеграцией стало ещё удобнее. Например, теперь диски VM могут напрямую размещаться в ZFS томах на TrueNAS, и их снепшоты создаются там же. Получается хорошая open source связка продуктов. В видео автор демонстрирует, как всё это вместе работает.

⇨ Домашняя сеть мечты: Wi-Fi 7 + 10Gb от UniFi — ОПРАВДАНО или НЕТ?
Быстрая локальная сеть на богатом. Админка у UniFi контроллера, конечно, топ. Мне лично дома пока 1Гбит/c хватает.

⇨ A Better Way to Run Terminal Agents!
Обзор терминального мультиплексора Herdr. Это что-то типа Tmux, с заточкой под работу с ИИ-агентами. Мне лично понравилось, буду пробовать. Думаю, сделаю заметку по нему.

⇨ TUIOS заставляет Herdr и Tmux выглядеть пережитками прошлого
Предыдущий автор хвалит Herdr, а этот его хоронит и предлагает замену - TUIOS. Похоже на рэп-баттлы прошлого 😁. Этот терминальный менеджер выглядит действительно необычно и функционально, но лично меня не впечатлил. То ли дело клавиатура автора. Ниже обзор похожей клавиатуры.

⇨ Год с эргономичной клавиатурой. Действительно ли удобно?
К сожалению, в видео в основном обзор устройств, а не опыт работы с ними. Тем не менее, я получил представление, что это такое. Навскидку, очень сильно отличается от обычной клавиатуры, придётся долго привыкать. У меня к обычным клавам претензий нет, поэтому для себя не вижу смысла.

⇨ Which Proxmox Storage Should You Use?
База по хранилищам в PVE: локальная директория, LVM и LVM-thin, ZFS, NFS, Ceph. Плюс некоторые советы автора по тому, где и что использовать. Интересно будет только тем, кто с темой не знаком. По сути - пересказ документации с комментариями.

⇨ Mimo 2.6 Flash | Лайт-модель от Xiaomi
Кому интересно, чисто для справки. У Xiaomi тоже есть своя открытая модель. Модель, как модель, ничего особенного. Из-за того, что маленькая, можно спокойно погонять на обычном домашнем компе. Автор привёл примеры, на что она способна.

⇨ Как использовать ИИ-Агенты на МАКСИМУМ | Роадмап
База по современным агентам. Автор хорошо структурирует и рассказывает. Но это чисто теория для тех, кто ещё не в теме. Остальным интересно не будет.

⇨ LiteLLM - Прокси для твоих llm! Зачем? И что он дает?
Обзор популярного в наше время софта для проксирования запросов в LLM в зависимости от условий. Что-то уходит в те или иные облачные модели, что-то в локальные и т.д. Для личного использования не особо актуально, если вы прям не кодите с утра до вечера и не выедаете все лимиты. Хотя я много видел отзывов на эту шутку в том числе и у себя на канале в комментариях. Кто-то использует LiteLLM для обхода ограничения Claude Code при использовании неподдерживаемых моделей.

⇨ БОЛЕЕ 2 МЛРД токенов в день: МОЩНЕЙШАЯ станция NVIDIA DGX от Gigabyte
Обзор рабочей станции за 15 млн. рублей😳, которая выглядит почти как обычный десктоп. Не знаю, насколько реально её у нас купить, но в нескольких магазинах выставлена на продажу. В США она $100 000+ стоит.

⇨ 477к за ИИ-сервер, оно того стоило?
Наш ответ на дорогущие рабочие станции. Автор рассказывает про свои изыскания при построении рабочей станции под локальный AI. Тут уже народные решения на базе Авито. Можно повторить, при желании. Видео, без шуток, интересное, особенно для тех, кто что-то подобное собирает. Тут концентрированный личный опыт и советы автора, а не рассуждения.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#видео

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём:

🔹 как определить RPO и RTO для критичных сервисов;
🔹 как защитить бэкапы от шифровальщика;
🔹 как учесть зависимости систем и ресурсы для восстановления;
🔹 как каналы связи влияют на скорость бэкапа и восстановления;
🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS;
🔹 как подготовить план аварийного восстановления и протестировать его.

🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его

🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления:
— Матрица систем и зависимостей
— Таблица определения и согласования RPO / RTO
— Технический runbook аварийного восстановления
— Отчёт о тестовом восстановлении ИТ-сервиса
— Карта готовности одного критичного сервиса к восстановлению
— Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов»

👉 Приходите, будет полезно. Регистрация тут

Рассказываю про небольшой трюк, который я лично на днях проделал для решения небольшой задачи. Есть одиночная VPS на Debian 12. Задача - обновить её до 13-й версии и попутно обновить версию PHP. Задача довольно простая, но всё равно потенциально опасная. Наживую такие обновления делать не рекомендую. Там бывают проблемы с зависимостями, на разрешение которых уходит некоторое время. Я сталкивался не раз.

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

Но в данном случае это одиночная арендованная VPS без какой-либо обвязки вокруг. С неё даже образ нормально не снять. Я поступил следующим образом. Создал у себя в тестовом контуре VM и добавил к ней второй диск такого же размера, как у VPS. С этой VM сделал следующее:

# ssh -T root@1.2.3.4 'dd if=/dev/sda bs=16M status=none' | dd of=/dev/sdb bs=16M iflag=fullblock status=progress conv=fsync

Прямо наживую запустил посекторное копирование удалённого диска sda на свой локальный sdb. В моём случае диск был 60 ГБ, нормально скопировался примерно за час без единого разрыва. При этом на сервере был запущен сервер MySQL.

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

У этой виртуалки отключил основной диск, а sdb, на который залил копию VPS, сделал загрузочным. После этого успешно загрузился в полной копии VPS. Система ругнулась при запуске, что у неё повреждена файловая система, что ожидаемо. Запустил fsck -y, потом перезагрузил систему. Она при загрузке запустила ещё раз проверку диска, все ошибки исправила, и я получил полностью рабочую копию своей VPS. Даже базу данных не пришлось перезаливать. СУБД запустилась в режиме innodb_force_recovery. Мне этого было достаточно, хотя какие-то таблицы и побились. Я только поменял IP адрес, поправил файрвол под реалии своего тестового контура и отладил обновление.

Выполнил всё, что мне было нужно. Там возникли проблемы. Убедился, что исправил все ошибки, записал команды и воспроизвёл на VPS.

Способ выглядит жутко колхозным и на первый взгляд нерабочим, но на деле я такое проворачивал уже не один раз. Ранее были заметки на эту тему. Он вполне рабочий, система всегда копируется нормально. Иногда только данные бьются, которые изменились в процессе копирования. Но сама система, как правило, приезжает в рабочем состоянии. Конечно, если есть доступ к образу диска, а тем более, к снепшотам, проще копировать его. Причём это можно сделать так же наживую. Тоже побьётся файловая система, но в целом систему можно будет починить и запустить.

Основное преимущество этого способа - не надо останавливать исходную машину вообще. И не надо ставить дополнительное ПО. К примеру, сюда можно было бы установить Veeam Agent for Linux и снять образ с его помощью. Но для разовых задач не хочется ничего лишнего устанавливать. Задача решена и без этого.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux

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

Смысл в том, что все виртуальные блочные устройства ZFS на одной физической машине объединяются в общий пул потоков ZVOL. И если у вас 2 пула - один на быстрых NVME, а второй - на медленных HDD, запросы к ним будут сливаться в общий поток. При нагрузке на пул с HDD и выстраивании очереди запросов к нему, в эту же очередь встают и запросы на пулы с остальными дисками. В итоге, сильно нагрузив ZVOL на одном медленном пуле, вы получаете задержки с ZVOL на других, более быстрых пулах.

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

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

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

Автор решил проблему в лоб самым простым и очевидным способом - вынес NVME диски на LVM-thin, отделив их от общего пула потоков ZFS. Это сразу решило проблему узкого горлышка.

Я немного поспрашивал ИИ на эту тему. Он подтвердил, что это архитектурная особенность ZFS, которую он увидел в исходниках. Там же есть и комментарии разработчиков на этот счёт:

We can have up to zvol_threads concurrent i/o's being processed for all zvols on the system. This is typically a vast improvement over the zvol_request_sync=1 behavior of one i/o at a time per zvol. However, an even better design would be for zvol_request() to initiate the zio directly, and then be notified by the zio_done callback, which would call END_IO().

Каким-то образом обыграть эту ситуацию можно, меняя параметры:
zvol_request_sync = 0 или 1
◽️ 0 - асинхронная обработка через общий пул потоков ZVOL.
◽️ 1 - обработка непосредственно в контексте вызывающего потока, без передачи в общий пул ZVOL.

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

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

Ещё вариант - изменить механизм очереди - zvol_use_blk_mq = 1. Но тут надо тестировать на практике, потому что потоки будут по-прежнему в одном общем пуле, изменится распределение. Не факт, что при нагрузке на медленный пул, запросы к быстрому не будут вставать в очередь.

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

В общем, как я всегда говорил и говорю, ZFS - нишевая файловая система под конкретные задачи и потребности. У неё много возможностей, нюансов и настроек. Ставить её по умолчанию, как ФС общего назначения, не стоит. Преимущества вам могут оказаться не нужны, а все особенности и недостатки вы по умолчанию потянете за собой.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#pve #zfs

Небольшая рекомендация по теме Zabbix. У них есть партнёр - initMAX. Это довольно популярная компания в своей области. Они много всего сделали полезного для Zabbix. Регулярно выступают на Zabbix Summit, пишут инструкции и различные дополнения для Zabbix. Расскажу о наиболее полезных вещах, про которые знаю.

1️⃣ Репозиторий с шаблонами. Тут много хороших шаблонов. Несмотря на то, что шаблонов для Zabbix в целом немало, но все они разного качества. У initMAX они обычно неплохие. Например, я пользуюсь их шаблоном для Synology.

2️⃣ Zabbix MCP Server и Zabbix AI Skills. Качественная обвязка для работы с Zabbix с помощью LLM. Команда Zabbix обещала свой MCP сервер выпустить вместе с релизом 8.0, но я пока ещё не видел информации о нём. Этот MCP сервер наиболее качественный и популярный, особенно в связке со скилами. Всё никак руки не доходят поплотнее поработать с этим. Не придумаю задачу, которую было бы удобно решать с ИИ. Я Zabbix неплохо знаю и обычно довольно быстро там что-то меняю или нахожу. А для деплоя и без MCP всё пишется агентами. Не представляю, где меня ИИ в этих задачах может ускорить. Основная проблема - спам уведомлений из-за некачественных или неоткалиброванных шаблонов. В своих шаблонах я и так знаю, где и что надо подкрутить.

Если используете в работе с Zabbix ИИ и MCP, расскажите, какие задачи с ними решаете. Я планирую проработать момент с обновлением шаблонов после выхода 8-й версии. Вручную это муторно и долго. Тут ИИ должен хорошо помочь и ускорить.

3️⃣ Каталог расширений. Это набор как платных, так и бесплатных модулей для Zabbix, которые меняют или дополняют основную функциональность. Покажу на конкретном примере.

Я изначально не думал, что кого-то, кроме меня, раздражают всплывающие заголовки виджетов во время наведения на них мышки. То есть ты отключаешь отображения заголовка и его нет, высвобождается лишнее место на дашборде, которого часто не хватает. Но если ты наведёшь мышку, то заголовок начинает всплывать. Когда виджетов много, постоянно всплывают эти заголовки во время перемещения мыши по дашборду. Меня это всегда раздражало. И судя по всему, не только меня.

У initMAX есть бесплатный модуль, который это исправляет. Ставится так:

# wget https://repo.initmax.com/zabbix/release/initmax-release-latest_all.deb
# dpkg -i initmax-release-latest_all.deb
# apt update && apt install zabbix-module-hidewidgetheader

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

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#zabbix

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

У меня рабочее место получилось не похоже на всё то, что я где-либо видел. Я сейчас закончил преобразования и остановился на том варианте, что получился. Меня он устраивает, поэтому можно поделиться. Для наглядности записал небольшое видео (смотреть внизу).

Пару лет назад я купил себе монитор 🖥 27'' AOC Q27G2S/EU 2К с частотой 165 Гц. Уже имея приличный опыт работы за ним могу сказать, что как по мне - это оптимальный вариант монитора для типовой работы в браузере и терминале. Я имею ввиду диагональ и разрешение. Всё умещается, всё влезает на масштабе 125%, глаза не устают.

В какой-то момент стало не хватать одного монитора для некоторых задач. Стал подумывать купить второй такой же. Это было бы удобно. Но в продаже уже не нашёл. Подумал немного и решил купить 4К монитор, раз уж одинаковые всё равно не получалось сделать. Место у меня позволяет, поэтому задумал увеличить ещё и диагональ. В итоге взял 🖥 4К 31.5" AOC U32G4U с частотой 160 Гц.

Раньше не придавал внимания частоте, не считал её значимой характеристикой, так как в активные игры, типа шутеров, не играю. Но после того, как поработал на 165 Гц, меньше уже не хотелось. Разница хоть и явно не заметна, но ощущается. С разрешением 4К и диагональю 31.5" это был самый дешёвый монитор с такой частотой, поэтому его и взял. Ну и в целом он мне нравится, похож на предыдущий.

Какого-то ВАУ эффекта или большого удобства от 4К монитора я не увидел. Больше всего понравилось то, что теперь по высоте места хватает и можно убрать панель инструментов Windows вниз, а вкладки браузера - вверх. Последнее время у меня панель была справа, а вкладки слева. Размера экрана теперь достаточно, чтобы расположить рабочие окна по центру, отступив и сверху, и снизу.

С масштабом в 150% против 125% в 2К места на мониторе стало не намного больше. Картинка плюс-минус такая же. Я не могу сказать, что прям шрифты какие-то более гладкие или что-то ещё, что я часто слышал от тех, кто советует брать 4К. У меня оба монитора теперь перед глазами, я могу сравнить. Да, 4К чуть лучше, но он и дороже. Если бюджет ограничен и надо два монитора, я бы лучше купил 2 хороших 2К монитора, нежели 2 похуже, но 4К.

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

Из того, что ещё хотелось бы добавить - заменить стоящий рядом обычный стол на стол с подъёмным механизмом. Для разминки и разгрузки уставших от сидения мышц хотел бы иногда что-то делать стоя, смотря в окно. Оно как раз у меня напротив. От сидения весь день в своей рабочей станции у меня устаёт попа. Раньше на обычных креслах спина или шея уставали, а сейчас мягкое место. Стараюсь 5-7 км в день для разминки ходить.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо

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

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

upstream app {
 server 127.0.0.1:8000;
}
.....
  location /app/ {
.....
    proxy_pass http://app/;
.....
  }

Сервис с дефолтными настройками запускается на http://localhost:8000. Пробую напрямую, всё работает. Через Nginx - никак, 502 ошибка, в логах стандартно - (111: Connection refused) while connecting to upstream. Думаю, что за ерунда. Напрямую же отвечает, почему через Nginx - нет. Ещё и приложение никаких своих логов не даёт, не понятно, что не так.

Разобрался чисто интуитивно. Вспомнил, что 127.0.0.1 и localhost - это не одно и то же. Первый - адрес ipv4, а localhost на современных дистрибутивах резолвится в ipv6 (::1).

Попадались на таком нюансе? Я уже не первый раз. Кстати, не понимаю, для чего localhost перевели на ipv6. В чём смысл? Даже не то, что перевели. В /etc/hosts оставили оба адреса, и ipv4, и ipv6, но по современным RFC адреса v6 имеют приоритет над v4. Поэтому теперь localhost по умолчанию отвечает с адреса ::1, а не 127.0.0.1. Это можно вручную изменить, убрав запись с ::1 из /etc/hosts. Я одно время это делал, потом перестал. Нет смысла бороться с ветряными мельницами. Надо привыкать.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux #ошибка

Хостинг без сложностей 👋

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

Если как раз ищете такие условия, заглядывайте в ИХЦ 😏

У нас есть решения для самых разных задач:

🟡Виртуальный хостинг — от 123 ₽/мес с бесплатным тестированием в течение 7 дней.

🟡VPS в России — от 317 ₽/мес с возможностью попробовать сервер бесплатно в течение 3 дней.

🟡VPS в Европе — от 290 ₽/мес с оплатой в рублях.

🟡Выделенные серверы — для проектов, которым нужны собственные вычислительные мощности.

🟡Дополнительные услуги — регистрация доменов, SSL-сертификаты, резервное копирование и другие полезные инструменты.

Гарантируем круглосуточную русскоязычную поддержку, защиту от DDoS на всех тарифах и вознаграждения до 50% от платежей по партнерской программе.

В общем, если в ваших планах есть запуск нового проекта или смена хостинг-провайдера, рекомендуем заглянуть к нам в ИХЦ. Возможно, подходящее решение уже ждёт вас 😉

👉 Посмотреть тарифы и попробовать ihc.ru

Весёленький вчера выдался денёк. Точнее вечерок. Разом насыпало целый ворох уязвимостей. Экстренно обновлял все подопечные сервера.

1️⃣ Начну с самой эпичной уязвимости PHP, про которую вы все уже скорее всего слышали - PHP2Shell. Не буду повторяться, а сразу приведу ссылку, где есть вся необходимая информация - php2shell.ru. Там всё подробно, по-русски.

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

; php2shell
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0

На 100% это не защищает, но и область атаки сильно сужает. Надеюсь в ближайшее время появятся какие-то более надёжные методы защиты старых версий PHP. Я уверен, это очень актуально для огромного числа пользователей. Что-то должно появиться.

2️⃣ Была какая-то критичная уязвимость в MariaDB. Про неё даже ФСТЭК написал. В Debian новые пакеты приехали совсем недавно. Пару недель назад я их ещё не видел. И всё бы ничего, но на части серверов у меня обновление тупо зависало и вешало сервис mariadb намертво.

Конкретно у меня это воспроизводилось на части серверов с Debian 12. В момент обновления с версии 10.11.18 на 10.11.19 какой-то скрипт из нового пакета выключал службу и запускал заново. И этот первый пуск в рамках работы менеджера пакетов apt намертво зависал. Я ждал минут 20, думал, может таблицы обновляет или ещё что-то делает. Боялся прерывать. Но дольше уже не мог ждать, надо было что-то решать.

Если отправить сервер в reboot, то завершение работы подвисает, ожидая ответа от службы mariadb. Потом по окончании таймаута минут в 10, всё же перезапускается и нормально работает. Каким-то образом штатно остановить службу не получалось. Она ни на что не реагировала. В логах пусто, никаких ошибок. Приходилось тушить через SIGKILL. Слава богу, ни один сервер не умер от таких манипуляций.

Разбираться с этой проблемой не было времени. Раз зависнув, это больше не повторялось. Это явно какая-то проходная ошибка, возникающая на конкретных версиях пакетов. В Debian 13 я с этим не столкнулся.

В итоге на части серверов я получил развлечение в виде зависшего процесса с apt и упавшей СУБД, чего никак не ждёшь от обновлений безопасности (передаю привет тем, кто их ставит автоматически ✋😃). Вкупе с невозможностью обновить на некоторых серверах PHP, это добавило лишних переживаний.

3️⃣ Про компрометацию ключей удостоверяющего центра eMudhra, думаю, вы тоже уже слышали. Повсюду новость разлетелась. Соответственно, в дистрибутивы прилетело обновление пакета ca-certificates.

Вот эти три вещи по идее обязательны к обновлению, причём экстренному, что я вчера и сделал. ❓А у вас какие отношения с обновлениями? Обновились внепланово или пока ждёте? Были проблемы?

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#security #debian