Записки IT специалиста

Как правильно определить количество свободной памяти в Linux

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

Сегодня снова задали такой вопрос, мол если верить Proxmox, то памяти еще хватает (занято 70%), но Zabbix начал сигналить о катастрофической нехватке памяти (занято свыше 90%). Кто не прав?

Чтобы это понять выполним в консоли команду:

 free – h 

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

▫️ total: Общее количество установленной физической памяти.

▫️ used: Количество памяти, которое в настоящее время используется.

▫️ free: Свободная физической памяти, доступная для немедленного использования.

▫️shared: Память, которая разделяется между процессами, например, библиотеки, которые могут быть использованы несколькими процессами одновременно.

▫️ buffers/cache: Память, которая используется в качестве буферов для операций ввода-вывода и в качестве кэша для операций

▫️ available: Количество памяти, которая доступна для использования, учитывая, что часть памяти, используемая как buffers/cache может быть освобождена при необходимости.

Если сравнить то, что показывает Proxmox, системный монитор и т.д., то он показывает именно available. Так может нечего переживать? Все норм и Zabbiх зря нагоняет панику?

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

И система, если процесс попросит памяти больше, чем free еще десять раз подумает, а сбрасывать ли буфер?

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

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

На нашей практике примерно в такой же ситуации регулярно выключалась неактивная виртуалка. И администратор долго не мог понять почему, пока не посмотрел на вывод free, а не дашборды Proxmox.

Поэтому не следует верить тому, что показывают графики или индикаторы, все, на что вы можете железобетонно рассчитывать – это free, а available – это то, что могут дать, а могут догнать и еще раз дать. Учитывайте это.

И Zabbix в этом случае не нагоняет жути, а по сути прав, так как учитывает описанные выше особенности.

А на закуску можем посоветовать почитать наши статьи:

🔹 Что такое пространства подкачки и как они работают

🔹 Что такое OOM Killer и как он работает

ZRAM и ZSWAP в Proxmox VE

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

Поэтому мы отдельно остановимся на популярном средстве виртуализации Proxmox VE.

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

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

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

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

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

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

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

Поэтому Proxmox не рекомендует использовать ZSWAP, а предлагает, неожиданно, ZRAM.

Но как так, спросит внимательный читатель, ведь только что вы писали, что ZRAM плохо влияет на производительность, особенно для виртуализации и СУБД.

Все верно, но это в том случае, если мы используем его в качестве расширителя объема ОЗУ.

Но если у нас достаточно памяти, то мы можем создать ZRAM устройство исключительно на замену swap. При этом, в Proxmox это отдельно подчеркивают, использование подкачки является временной мерой для защиты от OOM-Killer и использовать ее в качестве расширения памяти категорически не рекомендуется.

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

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

Ну и совершенно понятно, что выделять в таком случае под ZRAM не следует ни 25%, ни, тем более 50% ОЗУ. Исходим из того, сколько реально подкачки нам надо и делим на коэффициент сжатия. Для LZ4 это 2,5, для ZSTD около 4.

Таким образом, если у нас есть хост с 64 ГБ ОЗУ, то отрезав всего 4 ГБ при помощи ZRAM и zstd мы спокойно организовываем пространство подкачки на 16 ГБ. Причем – быстрой подкачки.

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

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

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

В чем сходство и в чем различие ZRAM и ZSWAP

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

1️⃣ Начнем с ZRAM. Эта технология создает в оперативной памяти блочное устройство и использует его в качестве пространства подкачки. Выделенная оперативная память сразу резервируется и не может быть использована системой.

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

Средний коэффициент сжатия для LZ4 – 2,5, это значит, что, выделив для ZRAM 1 ГБ оперативной памяти мы получаем в свое распоряжение 2,5 ГБ очень быстрого swap, что позволяет достаточно эффективно решить вопрос нехватки ОЗУ.

Например, для машины с 4 ГБ ОЗУ, что по нынешним временам критический минимум, мы можем, разделив память пополам получить эквивалент 6-8 ГБ ОЗУ что радикально поменяет в лучшую сторону пользовательский опыт работы с системой.

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

▫️Обычная RAM ~80–120 нс
▫️ZRAM (LZ4) ~1–5 мкс
▫️NVMe swap ~50–150 мкс
▫️SATA SSD swap ~200–500 мкс
▫️HDD swap миллисекунды

Как видим, ZRAM дает существенный рост латентности (в 10-50 раз), но все еще остается самым быстрым пространством подкачки, потому что даже при использовании быстрого NVMe разница будет уже на порядок.

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

Но если средняя латентность растет относительно незначительно, то вот рост tail latency (Tail latency (p95 / p99)) оказывается гораздо более высоким, что может приводить к заметным фризам и каскадному росту задержек.

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

2️⃣ Теперь перейдем к ZSWAP, это Write Back кеш для пространств подкачки, общего с ZRAM у него только то, что он тоже использует сжатую память. В остальном это совершенно другая технология.

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

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

Например, в системе с 16 ГБ памяти для ZSWAP по умолчанию резервируется 20% или 3,2 ГБ, что эквивалентно (для LZ4) примерно 8 ГБ несжатой памяти. Т.е. получаем неплохой такой раздел подкачки прямо в ОЗУ.

Что касается латентности, то она ничем не отличается от ZRAM, но в случае ZSWAP это только плюс, так как латентность сжатой памяти в 50-100 раз ниже, чем латентность быстрых NVME и на порядок лучше обычных дисков.

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

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

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

‼️ Что касается совместного применения ZRAM и ZSWAP, то это не только лишено всякого смысла, но и серьезно ухудшает латентность, а также увеличивает нагрузку на CPU за счет двойного сжатия, потому что в этом случае у нас получится цепочка:

RAM – ZSWAP – ZRAM – SWAP

Поэтому так делать не нужно. А рекомендации просты:

🔹Мало памяти, нет особых требований к латентности – ZRAM

🔹Достаточно памяти, но требуется сгладить пики и улучшить производительность - ZSWAP

​​Как на самом деле работает KSM sharing, ожидание и реальность.

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

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

При расчетах исходили из того, что в среднем одна нода имеет 16 ГБ оперативной памяти и 6 виртуальных машин с потреблением ОЗУ примерно на уровне 10 ГБ. Все виртуальные машины однотипны.

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

Сразу скажем – он не подвел и при запущенных 9 виртуальных машинах потребление памяти не превысило 12 ГБ при уплотненном объеме в районе 3 ГБ.

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

Как выяснилось, он ожидал, что KSM sharing как сейчас все оптимизирует, да как все освободит, ну даром что ли у нас 9 одинаковых виртуалок. А он всего лишь поджал память к лимитам.

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

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

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

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

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

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

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

https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html

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

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

Настраиваем ZSWAP для улучшения производительности системы

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

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

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

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

Скажем у нас есть ПК с 2 ГБ ОЗУ, мы оставляем 1 ГБ, а на еще 1 ГБ создаем устройство ZRAM. Памяти остается мало, и система начинает свопить на устройство ZRAM. Но это та же оперативная память, поэтому происходит это практически также быстро, как доступ в память напрямую.

Но за счет сжатия мы можем поместить туда больше данных, так при типичном коэффициенте сжатия 2-3 мы получаем аналог ПК с 3-4 ГБ ОЗУ, что существенно улучшает быстродействие.

🔹 Теперь о ZSWAP, это именно сжатый горячий кеш дискового пространства подкачки в ОЗУ, и работает он именно как кеш. Холодные данные из него разжимаются и сбрасываются на диск.

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

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

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

cat /boot/config-`uname -r` | grep -i zswap

В выводе будет что-то вида:

CONFIG_ZSWAP=y
# CONFIG_ZSWAP_DEFAULT_ON is not set
CONFIG_ZSWAP_SHRINKER_DEFAULT_ON=y
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_DEFLATE is not set
CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZO=y
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_842 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4HC is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD is not set
CONFIG_ZSWAP_COMPRESSOR_DEFAULT="lzo"
CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC=y
CONFIG_ZSWAP_ZPOOL_DEFAULT="zsmalloc"

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

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

Теперь включим сам ZSWAP, для этого откроем /etc/default/grub и найдем там строку GRUB_CMDLINE_LINUX_DEFAULT, обычно в ней уже есть параметры, например:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Через пробел добавим еще несколько, приведя строку к виду:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=10 zswap.zpool=zsmalloc"

Разберем добавленные параметры:

▫️zswap.enabled=1 – включает ZSWAP
▫️zswap.compressor=zstd – выбирает механизм компрессии, в нашем случае zstd
▫️zswap.max_pool_percent=10 – указывает доступный процент памяти для использования, по умолчанию 20
▫️zswap.zpool=zsmalloc – определяет используемый аллокатор, в нашем случае можно не указывать, так как zsmalloc стоит по умолчанию.

После чего обновляем параметры загрузчика ядра:

update-grub

И перезагружаем компьютер.

Проверяем:

cat /sys/module/zswap/parameters/enabled
cat /sys/module/zswap/parameters/compressor
cat /sys/module/zswap/parameters/max_pool_percent
cat /sys/module/zswap/parameters/zpool

В ответ должны получить Y, zstd, 10 и zsmalloc.

Посмотреть использование и эффективность можно командой:

grep -i zswap /proc/meminfo

Указанные параметры – не догма, вы можете (и должны) их выбирать исходя из реальных параметров и показателей вашей системы.

Сегодня как никогда актуально

Улучшаем производительность Linux при помощи zRam

Оперативная память сегодня недорога и доступна, снова становится достаточно дефицитным ресурсом.

Но, если вы используете Linux, есть способ выйти облегчить себе жизнь улучшить производительность системы при помощи zRam.

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

И вот здесь у многих читателей может возникнуть непонимание: как же так, системе и так не хватает памяти, а мы создаем в ней какие-то RAM-диски, да еще подключаем их как подкачку.

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

🔹 Linux - начинающим. Что такое пространства подкачки и как они работают

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

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

✅ Читать далее

Что ждет рынок компьютерных комплектующих в 2026 году?

Ответим сразу – ничего хорошего. Причина одна – бум искусственного интеллекта и связанный с ним дефицит памяти.

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

А бренд Crucial, на минуточку, был запущен в 1996 году и благополучно просуществовал на рынке 30 лет, заработав отличную репутацию, но сегодня резко оказался не нужен.

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

Значительные объемы производства также уже выкуплены у Samsung и SK Hynix, хотя последние полностью уходить с потребительского рынка не планируют, хотя и рассматривают его как нечто второстепенное.

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

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

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

Все это вылилось в резкий рост цен на память и твердотельные накопители, а в дальнейшем, по мере распродажи запасов нас ждет еще и товарный дефицит.

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

Но если бы дело касалось только памяти и накопителей. В реальности нас ожидают каскадные проблемы для всей отрасли в целом.

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

А это прямое следствие дефицита памяти, кому нужна материнская плата, если память для нее стоит неподъемных денег?

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

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

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

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

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

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

Linux - начинающим. Учимся работать со Snap

Snap - это универсальный формат пакетов, созданный компанией Canonical первоначально для Ubuntu, но получивший широкое распространение и в других дистрибутивах. Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.

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

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

Перед тем, как рассматривать работу со snap мы сделаем краткое отступление и рассмотрим причины, приведшие к появлению snap и аналогичных ему форматов, таких как flatpak или appimage. Традиционно софт в Linux распространяется по принципу конструктора, когда все зависимости приложения являются отдельными пакетами или библиотеками и распространяются отдельно.

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

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

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

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

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

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

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

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

✅ Читать далее

Уязвимости в MySQL и VirtualBox

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

1️⃣ Наиболее критичными являются уязвимости MySQL, которых набралось 14 штук, две из них могут использоваться удаленно:

▫️ CVE-2025-6965 – уровень опасности 9,8. Связана с уязвимостью в библиотеке SQLite, которая используется во вспомогательных инструментах продукта.

▫️ CVE-2025-9230 -уровень опасности 7,5. Переполнение буфера в библиотеке OpenSSL.

Уязвимости устранены в выпусках MySQL Community Server 9.6.0 и 8.0.45.

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

2️⃣ Второй уязвимый продукт – VirtualBox, уязвимостей тоже 14, пять из них опасные (уровень 8,2), одна может использоваться удаленно. Характер уязвимостей не раскрывается.

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

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

Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu

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

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

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

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

Каких-то существенных требований к железу Apt-Cacher NG не предъявляет и прекрасно работает в виртуальной машине или контейнере. Все что вам нужно - это выделить достаточное место для хранилища кеша пакетов.

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

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

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

Первоначально Apt-Cacher NG поддерживал только DEB-пакеты, сегодня это универсальный прокси, который можно использовать с любыми пакетными системами, но это выходит за рамки данной статьи и ниже мы будем рассматривать его применение исключительно в среде Debian или Ubuntu.

✅ Читать далее

Перенос почтовых ящиков между серверами при помощи imapsync

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

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

Основное преимущество imapsync - это то, что ее не нужно устанавливать на почтовый сервер и, скажем больше, мы не советуем этого делать. Почему? Утилита написана на Perl и для работы требует достаточно много библиотек и зависимостей, засорять которыми сервер очень не хотелось бы, тем более что задача, по сути, одноразовая.

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

✅ Читать далее

Отправка системной почты через внешний почтовый сервер

В Linux системах вы будете постоянно сталкиваться с необходимостью отправки почты системных пользователей внешнему получателю. Исторически для этих целей был предназначен Sendmail – старейший MTA – агент отправки почты.

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

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

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

Для этого нам нужно будет передать системную почту специальному почтовому клиенту (MUA), который, с одной стороны, будет имитировать стандартный Sendmail, а на самом деле работать в роли почтового клиента, отправляя почту через внешние сервера.

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

Установим его:

apt install ssmtp mailutils

Затем откроем файл /etc/ssmtp/ssmtp.conf и приступим к редактированию параметров, благо их немного.

Сначала укажем получателя для системной почты (все пользователи с идентификаторами < 1000):

root = admin@examlpe.com

Если вы не хотите выполнять перенаправление, то оставьте эту опцию пустой.

Разрешим изменять отправителя в поле From, для этого раскомментируйте и приведите к следующему виду опцию:

FromLineOverride=YES

Если этого не сделать, то система будет отправлять письма от имени root@hostname, которые будут отклоняться почтовым сервером.

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

Это были общие параметры, а теперь настроим работу с почтовыми службами.

В общем виде настройка выглядит так:

mailhub=smtp.example.com:587

AuthUser=my_account@example.com
AuthPass=mY_pa$$word_1
UseTLS=YES
UseSTARTTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt

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

Теперь создадим алиасы, чтобы системные пользователи могли отправлять почту через ssmtp. Для этого откроем /etc/ssmtp/revaliases и внесем туда следующую строку:

root:my_account@example.com:smtp.example.com:587

Это означает что пользователю root соответствует аккаунт my_account@example.com на сервере smtp.example.com:587 и отправку почты следует производить через него.

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

Для проверки выполните:

echo "Test" | mail  -s "Test" admin@example.com

После чего вы должны получить на указанную почту тестовое письмо.

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

 echo "Test" | ssmtp -v -s "Test" admin@example.com

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

❓Вопрос: будет ли работать PPP-туннель с такой адресацией?

✅ Ответ: будет, причем без всяких оговорок.

Почему? Потому что PPP (Point-to-Point Protocol) — двухточечный протокол канального уровня. Канального, т.е. L2 модели OSI. Поэтому для его работы, точно также как и для работы Ethernet IP-адреса не нужны.

IP-адреса – это уже следующий уровень модели OSI – L3 (сетевой). Поэтому любой кадр (именно кадр, а не пакет) попавший на одну сторону PPP-туннеля будет просто доставлен на другой, вне зависимости от его полезной нагрузки.

Таким образом для работы туннелей PPP нет никакой необходимости в IP-адресах вообще.

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

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

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

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

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

Что случилось с Мистой?

Форум mista.ru, он же «Волшебный форум», он же «Мистинский зверсовхоз» представлять не нужно, он нем знает любой, кто хоть немного погружен в тему 1С.

Это одно из старейших и крупнейших неофициальных сообществ по 1С:Предприятие в Рунете, которое ведет свою историю с далекого и светлого 2003 года.

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

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

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

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

Я не участник этого сообщества, но время от времени находил там интересующую меня информацию. А информации много не бывает, особенно если она не в пересказе, а из первых рук практикующих 1С-специалистов.

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

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

И тут самое время обратиться к событиям ноября 2025 года, когда владелец Мисты получил претензию от АО «КМ» (представитель 1С по защите прав), которая требовала удалить все страницы с упоминанием торговой марки 1С.

По факту это означало закрытие форума, так как если на форуме про 1С убрать любое упоминание 1С, то что там останется? Курилка и флудилка?

Проигнорировать? Ну тоже такое себе, потому как штрафы там до 5 млн. руб. и платить их придется владельцу форума из своего кармана.

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

А тут раз и убили крупнейшее сообщество лояльных компании пользователей…

Хотя, возможно, мы чего-то не знаем. Возможно цель – это взятие под контроль информационного поля. Потому что после ухода Мисты крупных независимых комьюнити не остается.

Инфостарт на 50% принадлежит компании 1С и колеблется вместе с линией партии, все остальное по масштабам недотягивает.

Но несмотря ни на что, надеемся, что Миста, какая бы она не была, к нам вернется. Иначе нас ждет сильно нехороший прецендент. Хотя, если честно, они уже были и тот же Инфостарт в свое время выдавливал конкурентов далеко не рыночными способами.

Но это уже совсем другая история…

Вопрос: будет ли работать PPP-туннель с такой адресацией?

🔻 Ответы в опросе ниже 🔻

Токены как хранилища ключевой информации

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

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

🔹 Начнем с самого простого – пассивного носителя ключевой информации, его характерный представитель – Rutoken Lite.

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

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

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

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

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

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

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

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

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

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

Дополнительный плюс таких токенов – они не требуют программного криптопровайдера. Типичный пример активного токена - Рутокен ЭЦП 3.0.

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

Они делятся на два вида:

▫️ PKCS#11 – международный стандарт неизвлекаемых подписей, широко поддерживается всеми видами ПО.

▫️ ФКН (функциональный ключевой носитель) – отечественный стандарт, более современный чем PKCS#11 и по многим параметрам его превосходит.

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

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

Let's Encrypt представила короткоживущие сертификаты и сертификаты для IP-адресов

В начале января Let's Encrypt представила короткоживущие сертификаты со сроком действия 160 часов (чуть более 6 дней). Использование таких сертификатов позволяет существенно повысить безопасность и не требует использования механизмов отзыва.

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

Такие сертификаты прежде всего удобны для тестовых и динамических сред, где этот процесс полностью автоматизирован. Ввод короткоживущих сертификатов в качестве основных пока не планируется, хотя Let's Encrypt объявил о сокращении времени жизни сертификатов в ближайшие годы с 90 до 45 дней.

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

Получить короткоживущие сертификаты или сертификаты для IP можно с помощью последних версий ACME-клиента, мы рассмотрим процесс для Certbot. Напоминаем, что официальный пакет распространяется для Linux через Snap.

✅ Ниже инструкция для DEB-based систем.

Прежде всего удалим certbot из репозитория (если установлен):

apt remove certbot
apt autoremove

Если у вас еще не установлен Snap, установим его:

apt install snapd

Установим Certbot:

snap install --classic certbot

Создадим символическую ссылку на бинарный файл утилиты:

ln -s /snap/bin/certbot /usr/bin/certbot

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

--preferred-profile shortlived

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

--required-profile shortlived

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

Полный пример команды может быть таким:

certbot certonly --apache --required-profile shortlived

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

Наташ, ты спишь? Мы там все уронили и мониторинг твой не сработал…

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

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

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

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

В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.

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

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

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

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

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

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

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

Но первичны у нас именно сервисы, помните об этом!