Зачем они варят пингвина в котле?

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

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

Скоро будет обзор.

Mageia 10 - такое волшебство нам не нужно!

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

Один из них - это Mandrake, позже Mandriva, первый реализовавший работающую концепцию "Linux с человеческим лицом". Но все проходит и современный Linux с его стандартизацией и унификацией, давно уже не тот и старые подходы в нем больше не работают.

Немного истории: Mandrake Linux появился в 1998 году (версия 5.1) и стал во многом революционным, если не сказать культовым, так как одним из первых предложил пользователям простые графические утилиты для управления системой и доказал, что Linux может быть простым и дружелюбным к простому человеку.

Разработкой занималась французская фирма, которая пыталась найти пути извлечения коммерческой прибыли из дистрибутива. Затем произошло объединение с бразильской Conectiva и дистрибутив был переименован в Mandriva.

В 2010 году из-за финансовых трудностей компания сократила подразделение разработчиков Mandriva, которые приняли решение о создании собственного форка системы - Mageia (от греческого - магия), в дальнейшем остальные права на Mandriva, после банкротства компании, перешли к российской РОСА.

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

✅ Читать далее: https://interface31.ru/post/mageia-10-takoe-volshebstvo-nam-ne-nuzhno/

Настраиваем политику паролей в Linux

Во многих дистрибутивах Linux (а более подробно мы будем говорить о Debian / Ubuntu) политика паролей по умолчанию не установлена, и никто не помешает нам установить слабый пароль, даже «123».

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

apt install libpam-pwquality

После чего откроем файл /etc/security/pwquality.conf, который отвечает за политику паролей. Опции будут перечислены в порядке их перечисления в файле со значениями по умолчанию:

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

difok = 1 

Минимальная длина пароля

minlen = 8 

При составлении пароля учитываются классы символов, их четыре: прописные буквы, строчные буквы, цифры и специальные символы.

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

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

dcredit = 0 – цифры
ucredit  = 0 – прописные буквы
lcredit = 0 – строчные буквы
ocredit = 0 – специальные символы

Таким образом, если мы установим dcredit = 1, то пароль pass123 получит 10 кредитов, что будет эквивалентно его длине в 10 символов.
Если же мы установим количество кредитов меньше нуля, то это будет требованием минимального количества символов данного класса, например, ocredit = -2 – не менее двух специальных символов в пароле.

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

minclass = 0

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

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

maxrepeat = 0

Рядом есть другая опция, которая задает максимальное количество повторения символов одного класса:

maxclassrepeat = 0

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

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

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

gecoscheck = 0

При установке значения в единицу при нахождении в пароле данных GECOS он не будет пропущен.
Также мы можем осуществлять проверку по словарям cracklib (ставятся по зависимостям):

dictcheck = 1

Следующая проверка исключает использование имени пользователя в пароле:

usercheck = 1

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

usersubstr = 0

Если установить его равным трем, то сочетание ivanov:ivan123 будет запрещено, равно как vano456, а iva123 будет пропущен.

Следующая опция устанавливает количество попыток ввода пароля:

retry = 3

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

enforce_for_root

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

И еще немного про алиасы в PowerShell

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

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

Это как раз решает проблему многословности PowerShell при интерактивном использовании.

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

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

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

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

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

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

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

Selectel обновил пользовательское соглашение. А что там? Правильно:

6.4. Исполнитель не несет ответственности за убытки Заказчика, возникшие в связи с нарушением Соглашения Исполнителем вследствие:

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

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

В общем, спасение утопающих - дело рук самих утопающих.

Авторское право – не пустой звук

Сегодня с одним нашим коллегой и молодым автором произошел крайне неприятный случай. Он имел неосторожность использовать для КДПВ (картинки для привлечения внимания) стоковое изображение не озаботившись уточнить авторские права и лицензию.

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

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

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

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

А юридически претензия говорит, что мы зафиксировали нарушение авторского права на вашем сайте при помощи сервиса автоматической фиксации доказательств «ФИКСАТОР». Т.е. факт нарушения есть и зафиксирован. Пойти в отрицалово здесь не получится.

Идем далее. Обычно тут спрашивают, а автор или сток вообще в курсе? С какого перепуга какое-то ООО Рога и Копыта предъявляет претензии? А по договору цессии (уступки требования). Это распространенная практика, когда автора за фиксированную сумму или процент передает право требования компенсации третьим лицам.

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

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

А что у нас там еще осталось? Пусть докажут? Так презумпция невиновности есть только в уголовном праве. В гражданском праве есть принцип состязательности. Если коротко, то если вы заявили какое-то обстоятельство, то именно вы должны его доказать и никак иначе.

Возвращаясь к нашему делу – тут есть фиксация правонарушения через «ФИКСАТОР», т.е. истцу ничего доказывать не нужно. Наоборот, нужно доказать отсутствие факта правонарушения ответчиком.

Ну и реальные перспективы:

Ответчик морозится, булькнул в тину. Дело уходит в суд, суд удовлетворяет требования, плюс вешает на ответчика пошлину и юридические издержки истца: 55 + 10 + 20 = 85 тыс. руб.

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

Итог: требования истца удовлетворены частично: 10 + 10 +20 (компенсация + пошлина + юридические услуги).

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

А что тут делать?

Ну в общем и целом не размещать у себя картинки, защищенные авторским правом. А если попали, то торговаться. Мол есть 15 тыс. руб. сейчас, а иначе попробуйте что-то с меня через приставов взять, активы я на жену вывел.

Там тоже понимают, что лучше живые деньги сейчас, чем исполнительный лист когда-то потом. Поэтому если договорились на 20-25 тыс. – то это нормально.

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

В чем сходство и в чем различие 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

Сакральная желтая бумажка

С завидным постоянством наблюдем необъяснимое, можно даже сказать – сакральное отношение некоторых пользователей к пин-кодам программных лицензий 1С:Предприятие.

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

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

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

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

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

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

Также та же самая поддержка рекомендует:

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

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

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

Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы.

Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?

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-кеш.

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

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

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

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

Статья 1274. Свободное использование произведения в информационных, научных, учебных или культурных целях
 
1. Допускается без согласия автора или иного правообладателя и без выплаты вознаграждения, но с обязательным указанием имени автора, произведение которого используется, и источника заимствования:

1) цитирование в оригинале и в переводе в научных, полемических, критических, информационных, учебных целях, в целях раскрытия творческого замысла автора правомерно обнародованных произведений в объеме, оправданном целью цитирования…

 
А вот это тот самый спасательный круг, который держит на плаву весь блогинг и журналистику, авторов обучающих материалов и т.д. и т.п. Но учтите – вы обязаны указать имя автора и ссылку на источник.
 
Что это значит? А это значит, что вы можете использовать чужое, защищенное авторским правом изображение в информационных целях абсолютно законно, но в объеме, оправданном целью цитирования.
 
Если говорить просто, то вы, в процессе написания обзора на мини-ПК вполне можете взять чужое фото, чтобы показать его внутри, потому что не хотите разбирать свой гарантийный экземпляр. Это как раз оправданный объем и понятная цель.
 
Но когда вы построите свой материал на чужом фото и добавите от себя два дежурных абзаца, то цитированием тут уже не пахнет, чужой объект стал ключевым элементом вашей публикации, а это нарушение.
 
А теперь пройдемся по самым частым случаям. Скриншоты интерфейса программ. Несмотря на то, что сами программы – объект авторского права их интерфейс таковым не является (исключая шрифты, иконки и т.п.), иначе авторы того же MS Office давно бы засудили альтернативные пакеты, которые повторяют интерфейс практически один в один.
 
Поэтому скриншоты можно публиковать смело, никто никаких претензий вам не предъявит. Исключение – чужой обработанный скриншот, на который нанесены надписи, стрелочки, рамочки – это уже результат чужого творческого труда и использовать его вы можете только в части цитирования.
 
Изображения комплектующих и готовых устройств. Здесь ситуация еще тоньше. Многие юристы вполне обоснованно считают, что если у нас есть вид устройства с некоторого стандартного ракурса (спереди, сзади, сверху, вид на разъемы), то результатом творческого труда это изображение не является.
 
Эта позиция находит поддержку в судах, но мы не будем лишний раз дергать тигра за усы, а снова возьмем 1274 ГК РФ. Если вы пишете статью об устройстве или в тексте используете это устройство как пример, то будет абсолютно правомерно привести тут его изображение.
 
Чужие логотипы и прочие элементы брендирования. Самая сложная тема, так как она учитывает множество факторов, в частности коммерческое применение. Так в условиях партнерских программ многие бренды прямо запрещают использование официальной символики.
 
Но это касается именно коммерческой деятельности. В информационных, научных или учебных целях вы полностью в праве использовать чужие логотипы и элементы корпоративного стиля, тем более что практически все производители публикуют брендбуки и на этом настаивают.
 
Если вы пишете статью про Ubuntu или RHEL, то абсолютно логично проиллюстрировать ее официальным логотипом. Это нормально и не является нарушением. Но если вы разместите в этой статье некоторые партнерские ссылки, ситуация может тут же развернуться на 180 градусов.
 
Объем заметки не позволяет разобрать все ситуации, поэтому к этой теме мы еще вернемся.

Авторское право – не пустой звук. Часть 3
 
В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.
 
Статья 1274 ГК РФ прямо говорит, что допустимо использование:

правомерно обнародованных произведений и отрывков из них в качестве иллюстраций … в объеме, оправданном поставленной целью

 
А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.
 
Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.
 
А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.
 
Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.
 
С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.
 
Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.
 
Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.
 
Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.
 
Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.
 
Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.
 
Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.
 
Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.
 
Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.
 
Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.
 
Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.

Тонкая настройка systemd-journald

Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.

Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.

Прежде всего посмотрим текущие настройки, это можно сделать командой:

cat  /etc/systemd/journald.conf

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

Создадим для этого директорию:

mkdir -p /etc/systemd/journald.conf.d

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

Начнем с места хранения логов. Для сохранения на диск используйте:

Storage=persistent

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

Storage=volatile

Затем проверьте опции:

Compress=yes 
Seal=yes

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

Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:

SystemMaxUse=1G
SystemKeepFree=2G

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

Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:

RuntimeMaxUse=64M
RuntimeKeepFree=256M

Опции

SystemMaxFileSize= 
SystemMaxFiles=100

Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.

Для хранения в оперативной памяти аналогичные опции:

RuntimeMaxFileSize= 
RuntimeMaxFiles=100

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

MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug

Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.

ForwardToSyslog=no
ForwardToKMsg=no 
ForwardToConsole=no 
ForwardToWall=yes

Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).

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

RateLimitIntervalSec=30s
RateLimitBurst=10000

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

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

AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox

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

apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"

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

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

В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума.

Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:

journalctl -f

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

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

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

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

Начнем:

systemctl stop rsyslog 
systemctl mask rsyslog

Затем создадим директорию

mkdir -p /etc/systemd/journald.conf.d

А в ней создадим и откроем на редактирование файл:

nano /etc/systemd/journald.conf.d/00-journal.conf

В который внесем следующее содержимое:

[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no

Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).

Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие.

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

Сохраняем содержимое файла и перезапускаем службу:

systemctl restart systemd-journald

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

Принцип Питера
 
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
 
Принцип Питера гласит:
 

В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.

 
Следствия принципа Питера:
 

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

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

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

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

PHP2Shell
 
Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.
 
Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.
 
Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».  
 
Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.
 
Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.
 
Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.
 
А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.
 
Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.
 
В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая промежуточный 26.10. Пользователи 14.04 LTS, 16.04 LTS, 18.04 LTS и 20.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).
 
В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.
 
В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.
 
Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.
 
А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.
 
Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.

Про помогаторов

На фоне последних событий рассмотрим еще один феномен – помогаторство.

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

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

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

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

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

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

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

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

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

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

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

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

Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?

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

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

Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.

Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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