Прекращена поддержка Debian 11

31 августа 2026 года поддержка дистрибутива Debian 11 прекращена. Репозитории официально переведены в архив, обновлений безопасности больше не будет. Одновременно с ним во вторую стадию поддержки перешел Debian 12.

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

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

Справедливости ради следует сказать, что существует еще Extended LTS, которая осуществляется энтузиастами и силами компании Freexian и будет поддерживать Debian 11 до 30 июня 2031 года.

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

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

Debian или Ubuntu

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

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

1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве, и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.

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

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

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

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

За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией, а точнее ее спонсорами.

2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.

Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив в части разделов main и restricted,  и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.

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

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

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

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

В первом случае отсутствует строгий релизный цикл и поддержка осуществляется по принципу 3 + 2, это означает что по истечении первых 3 лет дистрибутив фактически замораживается и начинает получать только обновления безопасности на критически важные пакеты (но не на весь дистрибутив).

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

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

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

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

Протоколы быстрого роуминга Wi-Fi 802.11k/v/r

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

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

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

Чтобы избежать этих ситуаций были разработаны и внедрены протоколы 802.11k/v/r, которые используются совместно, как минимум в связке 802.11k/v.

🔹 802.11k: Radio Resource Measurement - позволяет точкам и клиентам динамически обмениваться информации о состоянии среды передачи, что позволяет клиенту быстрое и проще понять куда можно переподключиться.

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

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

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

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

🔹 802.11v: Wireless Network Management – протокол, используемый в связке с 802.11k и позволяющий проактивно управлять беспроводной сетью.

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

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

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

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

🔹 802.11r: Fast BSS Transition – протокол быстрого переключения, который позволяет ускорить этот процесс за счет предварительной аутентификации и генерации сессионных ключей.

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

Это может занимать до 0,7 – 1 с, что приводит к разрывам VoIP соединений, зависанию видеоконференций, лагам в онлайн-играх и т.д.

802.11r предлагает выполнять предварительную аутентификацию и генерацию ключей для подключения к другой точке еще до разрыва старого подключения, что позволяет радикально сократить время переключения до 15-50 мс.

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

Когда vSphere уже «трофейная», а продлевать нечего 🙃

24 сентября в 11:00 (МСК) CNS и Orion Soft проводят вебинар про
zVirt, российскую платформу виртуализации на замену VMware
vSphere и Hyper-V.

Покажем на живом демо-стенде, в реальном интерфейсе:
▫️ живую миграцию ВМ
▫️ гиперконвергенцию
▫️ SDN
▫️ DR и катастрофоустойчивость
▫️ управление всем этим из одной консоли, без «зоопарка»

Отдельно для тех, у кого КИИ: сертифицированная ФСТЭК редакция и реестр отечественного ПО, то есть что показать безопасникам и регулятору.

👉 Регистрация: Здесь
#реклама
О рекламодателе

​​Спрашивают – отвечаем. Какой утилитой можно посмотреть какой процесс сколько занимает памяти.

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

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

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

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

Всего колонок четыре, коротко разберем что они обозначают:

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

🔸 PSS – пропорциональный объем памяти, наиболее интересное с практической точки зрения число, так как объем памяти разделяемых библиотек делится пропорционально между процессами, например, если у нас три процесса используют одну и ту же библиотеку, то занимаемый ею объем памяти поделится на троих.

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

🔸 Swap – объем сброшенных в подкачку страниц памяти процесса.

Сразу запоминаем полезные ключи программы:

▫️ -t - выводит снизу результирующую строку по всем колонкам
▫️ -p – представляет значение в процентах от общего объема памяти, а не в килобайтах
▫️ -а – подстраивает ширину колонок под текущий размер окна терминала

Как мы уже говорили, сортировка ведется по возрастанию колонки PSS, т.е. самые «жирные» процессы будут внизу.

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

Например, чтобы посмотреть кто использует Swap в процентах по убыванию значений, используйте:

smem -tap -r swap

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

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

smem -tpa -P postgres -r pss

Или все процессы пользователя 1С:Предприятия:

smem -tpa -U usr1cv8  -r pss

Что еще можно посмотреть с ее помощью? Использование памяти в разрезе пользователей с ключом -u или по всей системе с ключом -w.

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

Сеанс двоичной магии с разоблачением

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

Начнем с просто примера: 192.168.1.100 с маской 255.255.255.0 или /24

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

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

128 | 64 | 32 | 16 | 8 | 4 | 2 | 1

Теперь берем первый октет, проверяем, помещается ли первое число 128 в 192? Помещается, ставим 1. Затем вычитаем из 192 число 128, получаем 64. Проверяем со вторым числом, помещается, снова ставим 1 и вычитаем из остатка 64.

У нас остался ноль, в который не помещаются остальные числа, там проставляем ноли.

В итоге адрес 192.168.1.100 мы запишем как

11000000 10101000 00000001 01100100

Теперь маска, также переводим ее в двоичный вид. Но если с 255.255.255.0 все понятно, то как понимать /24? А просто, 24 обозначает что маска содержит 24 единицы, т.е. вам даже не нужно ничего переводить:

/24  = 255.255.255.0 = 11111111 11111111 11111111 00000000

А теперь начинается настоящая двоичная магия, записываем адрес и маску друг под другом:

11000000 10101000 00000001 01100100
11111111 11111111 11111111 00000000

Те части адреса, которые покрываются маской являются номером (префиксом) сети, а те, которые не попадают в маску – номером узла.

Таким образом у нас адрес сети (все что не попадает под маску меняем нолями):

11000000 10101000 00000001 00000000

Что соответствует 192.168.1.0

Минимальным адресом сети будет:

11000000 10101000 00000001 00000001 = 192.168.1.1

Максимальным:

11000000 10101000 00000001 11111110 = 192.168.1.254

А последний доступный адрес в сети является широковещательным:

11000000 10101000 00000001 11111111 = 192.168.1.255

Теперь поменяем маску на /23 или 255.255.254.0 и посмотрим, что изменится:

11000000 10101000 00000001 01100100
11111111 11111111 11111110 00000000

Адрес сети у нас та часть, которая покрывается маской, остальное заменяем нулями:

11000000 10101000 00000000 00000000 = 192.168.0.0

Минимальный адрес:

11000000 10101000 00000000 00000001 = 192.168.0.1

Максимальный адрес:

11000000 10101000 00000001 11111110 = 192.168.1.254

Широковещательный адрес:

11000000 10101000 00000001 11111111 = 192.168.1.255

А теперь вернемся к примеру из пятничного вопроса:

5.6.7.0/23

00000101 00000110 00000111 00000000
11111111 11111111 11111110 00000000

Адрес сети:

00000101 00000110 00000110 00000000 = 5.6.6.0

Минимальный адрес:

00000101 00000110 00000110 00000001 = 5.6.6.1

Максимальный адрес:

00000101 00000110 00000111 11111110  = 5.6.7.254

Широковещательный адрес:

00000101 00000110 00000111 11111111  = 5.6.7.255

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

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

Почему? Расписываем в двоичном виде адрес и маску и понимаем, что сети с адресами 5.6.6.0/23 и 5.6.8.0/23 существовать могут, а вот сеть с адресом 5.6.7.0/23 – нет.

Что такое SRV-записи DNS и для чего они нужны

В комментариях к нашим заметкам по DNS уже не раз спрашивали: что такое SRV-записи и для чего они нужны.

Начнем немного издалека. Все знают, что основная задача DNS сервера – это разрешение имен, т.е. преобразование понятных человеку доменных имен в IP-адреса. Для этого используется запись типа А, которая прямо сопоставляет имя и IP-адрес. Например:

pc-petya   IN A 192.168.121.156

Она говорит, что узел сети с именем pc-petya имеет адрес 192.168.121.156.

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

С этим понятно, если мы знаем имя узла, то DNS всегда поможет нам узнать его адрес. Но как быть, если имя узла мы не знаем?

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

Что мы будем делать в реальном мире? Правильно, спросим: а где тут почта?

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

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

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

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

Но благодаря этому одним типом записи мы можем закрыть все текущие службы и новые, которые могут появиться в будущем. Достаточно лишь знать название службы, а остальное нам сообщит наша универсальная справочная (DNS-сервер).

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

Давайте посмотрим на реальные SRV-записи, например, служб Яндекса. Начнем с такой:

_xmpp-server._tcp 21600 IN SRV 20 0 5269 domain-xmpp.yandex.net.

Имя записи: _xmpp-server._tcp – т.е. межсерверное общение XMPP-серверов по протоколу TCP.

Далее идет TTL – 21 600 сек (6 часов) и тип записи IN SRV, после чего указан ее приоритет – 20 (здесь как в MX – чем ниже, тем предпочтительнее) и вес 0 (используется для выбора нескольких записей с одинаковым приоритетом), затем порт – 5269 и узел, на котором располагается данная служба - domain-xmpp.yandex.net.

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

А вот еще запись:

_xmpp-client._tcp 21600 IN SRV 20 0 5222 domain-xmpp.yandex.net.

Она отличается только именем _xmpp-client._tcp и сообщает куда должны подключаться XMPP-клиенты через TCP. Также можем увидеть здесь другой порт.

Таким образом если вы запускаете XMPP-клиент, то при наличии SRV-записей он автоматически найдет XMPP-сервер и попробует к нему подключиться.

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

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

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

Не застревайте в прошлом — учитесь новым навыкам и ИИ

Чтобы успевать за требованиями рынка, освойте новую профессию и нейросети в Практикуме. До 30 сентября действует скидка 16% на все курсы.

Выбрать курс

Как всё устроено:

— нейросети уже в каждом курсе: учим профессиям сразу с ИИ, чтобы ваше резюме было заметнее, а трудоустройство — увереннее;

— эксперты — практики, которые двигают ИИ-индустрию: перенимайте опыт у профи из Яндекса, Сбера, Т-Банка и других бигтех-компаний;

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

Начните учиться бесплатно и получите скидку 16% — она автоматически появится в личном кабинете.

Учиться!

Реклама. ООО "ЯНДЕКС". ИНН 7736207543.

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

Например, такие:

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

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

opredelenie_suda.pdf («Определение суда»);
Rekvizity_schyota.pdf («Реквизиты счёта»);
Недостатки_v2.docx и ПОЧТА - 01.04.2025...;
Таблицы РЗН_2026_3.xlsx (похоже на закупки или документацию по Росздравнадзору) и Сети общий.xlsx (вероятно, карта инфраструктуры и подсетей).

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

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

Договоры и юридические документы: снизу открыт Zettlr с файлом Zettlr - ДОГОВОР №.... Рядом окно проводника и предпросмотр документа: ДОГОВОР №... с развернутым текстом условий, реквизитов и сумм. Внизу в проводнике открыта папка Формы заявлений.

Битрикс24 и корпоративные задачи: Открыт портал Битрикс24 со списком внутренних задач и лидов, а в Word открыт документ Задачи - январь 2026.docx с подробным планом и служебными отчетами.

Личные переписки и контакты: В WhatsApp открыто рабочее окно со списком чатов, аватарок и фамилий собеседников. Рядом висит Telegram-чат.

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

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

В общем – будьте бдительны и думайте что вы выкладываете на всеобщее обозрение.

Про РКН и MikroTik

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

Что же произошло на самом деле?

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

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

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

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

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

А если даже не заметят? Значит, MikroTik им попросту не нужен. Зачем держать в сети сложный настраиваемый маршрутизатор, если он пылится на полке в роли копеечной мыльницы из супермаркета?

Популярные мифы про Docker
 
Встречался третьего дня с одним коллегой, у того серьезная головная боль – куда пойти-податься с Zimbra, ящиков 300+, почты более 1,5 ТБ. Причем требуется что-то опенсорсное, лишних денег у компании нет.
 
Ну возьми, говорю, Mailcow – быстро, просто и актуальный набор возможностей, чтобы не только почта в клиенте была, но и инструмент совместной работы.
 
Реакция меня удивила, мол да ладно тебе, он же в Docker, он не потянет мои 300+ ящиков и 1,5 ТБ почты.
 
На мой вопрос, почему он так считает, последовал ожидаемый ответ – мол Docker – это же кубики для разработчиков, быстро поднял, быстро протестировал. Он же не тянет серьезные нагрузки!
 
Кто он? Выясняется, что он – это сам Docker и в представлении многих наших коллег именно он выполняет код в контейнерах, являясь прослойкой между ними и хостом. Поэтому опасение по поводу еще одного слоя вполне обоснованны.
 
При этом данный коллега вполне себе использует LXC и именно потому, что там нет накладных расходов. Пришлось провести краткий ликбез и пояснить, что и Docker, и LXC используют один и тот же механизм (namespaces и cgroups), а сама служба Docker – просто менеджер, которая только запускает и тушит контейнеры и обеспечивает их обвязом, ни более, ни менее.
 
Да, многим странно такое читать и слышать в 2026 году, но увы, это суровая реальность. А некоторые вообще агрессивно отрицают Docker, мол только пакеты, только руками. При том, что многие проекты уходят в вариант – только Docker или вон там лежит исходный код  - собирайте сами.
 
Другой популярный миф – контейнер как черный ящик, в нем даже консоли нормальной нет. Но в этом и есть основной смысл контейнеризации Docker (а точнее OCI) – контейнер является точным слепком образа и иммутабелен. Даже если с ним что-то случилось, то просто перезапусти и получишь систему в идеальном исходном состоянии.
 
Да и кто может собрать и настроить свой продукт лучше, чем сами разработчики? Поэтому официальный образ в любом случае будет лучше любой кастомной установки. Потому что подводит под нее готовую и твердую базу.
 
При этом никто не снимает вопрос доверия. Потому что одно дело использовать официальный образ от разработчика, а совсем другое – образ третьего лица, пусть даже и популярную.
 
В классической парадигме с пакетами все тоже самое – или вы ставите пакеты только из официального репозитория, либо на свой страх и риск подключаете сторонние источники, а то и руками ставите левые бинарники.
 
Но даже в этом случае Docker на порядок безопаснее, потому что замыкает процессы внутри контейнера и даже при закладке или уязвимости поражен будет только контейнер, из которого надо еще постараться сбежать.
 
 А в современном мире, когда ИИ пачками находит уязвимости везде и всюду некоторые стеки так и просятся в Docker, тот же веб-сервер. Потому что пока мейнтейнеры проверят, обновят, завезут вас сто раз сломают и переломают.
 
Дистрибутивы в этой гонке катастрофически не успевают, а вот контейнеры позволяют быть на первом крае и вовремя получать изменения и обновления, без оглядки на дистрибутив.
 
Морали снова не будет, каждый должен думать сам. Потому что Docker не серебряная пуля и не панацея, это просто еще один способ запуска рабочей нагрузки, попутно предлагающий ряд серьезных преимуществ. А дальше каждый решает самостоятельно.

☝️ Не все умеют правильно пользоваться командами su и sudo.

Команда su производит замену пользователя и имеет синтаксис:

su [опции] имя_пользователя

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

Если же использовать:

su - (-l, --login)

То будет загружен контекст root, как будто бы он вошел в систему.

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

Чтобы изменить поведение используйте:

sudo -s

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

Альтернативный вариант:

sudo -i

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

Ой, а что это случилось? Куда делась лицензия? Программные лицензии 1С - полное дно!!!

На самом деле процессор на данном хосте заменили еще в конце июля, а выстрелило в середине сентября.

Хотя все причастные со стороны заказчика знали, что замена процессора требует переактивации лицензии.

Но не слетело же сразу? Поэтому благополучно забили. А когда работа стала колом посреди рабочего дня - сказали, что это же 1С...

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

Ностальгия… Ностальгия…

- Мы тут тебе старенький компьютер привезем…

Старенький, что сейчас под этим подразумевают? Ну какой-нибудь Core первых поколений, куда уж старее…

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

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

А дальше пошли сплошные сложности. Данный ПК коптил небо не просто так, а в составе некоторого медицинского оборудования. Софт на современные ОС не ставится, точнее поставить в режиме совместимости можно, но нет драйвера для взаимодействия с прибором через COM-порт.

Все что есть – работает только под Windows 2000/XP, производитель его с рынка ушел, бывший дистрибьютор разводит руками и предлагает купить новый прибор за много-много денег.

Опытным путем выяснили, что прибор нормально переваривает переходник COM-USB на классическом PL-2303, а значит жить немного проще.

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

Подобные проекты уже были, мы ставили на современные в то время машины с Windows 7 виртуалки с Windows 98 и PDF принтером в ней, чтобы была возможность быстро и безболезненно перегнать в PDF архив сканов в формате AWD, который использовался в Windows 9.x для сканов по умолчанию, а потом был выпилен даже на чтение.

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

Как провайдер определит, что у меня Mikrotik
 
Таким вопросом задаются многие читатели и очень часто дают неправильные ответы. Поэтому мы собрали все доступные провайдеру способы определить ваше устройство, от самых простых до самых неочевидных.
 
🔹 Открытые порты: если у вас на устройстве открыты 8291 (WinBox) и/или 8728 (API), то тут и ничего угадывать не надо.
 
🔹 Включенный веб-интерфейс. Простой curl сразу покажет много интересного, например <title>RouterOS</title> в первой же строчке заголовка HTML или <img src="mikrotik_logo.svg" alt=""> чуть подальше.
 
🔹 MNDP/CDP (Neighbor Discovery). Если обнаружение включено на внешнем интерфейсе, а по умолчанию это так, то роутер сам шлет прямым текстом имя хоста, версию RouterOS, платформу, софтверный ID и архитектуру железа.
 
🔹 FTP или SSH. Если какая-либо из этих служб торчит наружу, то определить систему однозначно можно по специфичному баннеру: MikroTik router ftpd 7.19.2 или MikroTik RouterOS sshd protocol 2.0.
 
🔹 OUI MAC-адреса. Банально и просто, MAC-адреса устройств однозначно закреплены в IEEE за MikroTikls SIA. Многие из вас меняют MAC-адрес на внешнем интерфейсе?
 
🔹 DHCP Option 12 (Host Name). Если вы не меняли имя хоста в System -> Identity, то провайдеру в DHCP-запросе прямым текстом летит – MikroTik.
 
🔹 DHCP Option 138 (CAPWAP Access Controllers) в Option 55. Крайне редкая и экзотическая опция для абонентского оборудования. Запрос контроллеров точек доступа CAPWAP — фактически фирменная «визитная карточка» RouterOS.
 
🔹 Сигнатура Option 55 (Parameter Request List). Точная комбинация и последовательность запрашиваемых опций (1, 121, 3, 33, 6, 42, 138, 43), помноженная на дублирование MAC в Option 61 (clientid/clientid_duid) и выставленный флаг Broadcast (0x8000) составляют отчетливый сетевой отпечаток характерный именно для RouterOS.
 
И это только то, что лежит на поверхности и видно операторскому оборудованию при первом же рукопожатии. Добавьте сюда дефолтный Cloud DDNS (*.sn.mynetname.net), проверки обновлений и пассивный TCP/IP-фингерпринтинг на DPI.
 
Поэтому спрятать свой Mikrotik от провайдера можно, пожалуй, только вытащив его из розетки.

Старое железо – путь в никуда

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

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

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

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

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

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

Ну это если вас не угораздило перепродать железо заказчику самому. Потому что при современной маржинальности в 2-5% и разным регуляторным сложностям вроде прослеживаемости или грядущей маркировки заниматься этим делом экономически бессмысленно.

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

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

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

Хотя есть вариант купить с документами у какого-нибудь небольшого продавца, типа компьютерной комиссионки. Но это снимет только одну головную боль – с оплатой.

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

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

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

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

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

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

Как легко и просто «сломать» информационную базу 1С:Предприятие, не снимая «замочка» и ничего не понять?

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

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

А если нет? Ну так любой инструмент несет в себе такие же опасности: молотком можно забить гвоздь, а можно отбить пальцы.

Так что не так с расширениями? У расширений есть три типа назначения, про них в документации написано следующее:

Расширение с назначением Исправление предназначено для исправления ошибок в конфигурации. Поэтому оно применяется к конфигурации первым.

Затем применяется расширение с назначением Адаптация. Оно содержит доработки конфигурации при внедрении у конкретного заказчика.

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

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

Ключевая фраза - мешать друг другу, с оговоркой – предполагается.

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

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

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

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

Если дополнение конфликтует с доработками (адаптация), то откажется работать дополнение. Но в жизни все может быть совсем по-другому. И дополнение с типом адаптация, добавленное первым, может спокойно при обновлении сломать ваши доработки.

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

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

Если же решались на доработку, то занимался этим какой-никакой, но специалист.

Зато теперь – полная свобода самовыражения. Пошли на Инфостарт, накачали расширений и давай «прокачивать» базу. И никаких программистов не надо. Даже конфигуратор открывать не придется.

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

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

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

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