ISD — новый способ управления systemd

А, ну так это очередной ansible. Ну так может быть...

Нет :-) Ansible - это массовой управление конфигурацией через декларативный конфиг, а тут оперативное управление через мышетык плюс мониторинг.

Я бы не стал рассчитывать на cockpit в организации, где больше 20 компов, а вот микроофис рулить очень даже.

Дежурно напоминаю, что вопящим про неюниксвейность systemd следует посмотреть в man inittab, чтобы обнаружить там кейворды wait, once, powerfail и respawn, которые четко показывают, что init задумывался средством для спауна и слежения за процессами, а баш-лапша была навернута поверх него позже, потому что изначальный init получился слишком дубовым. Так что systemd - это развитие идей, изначально заложенных в SysV init.

одмины локалхоста и 1С опять сагрились на systemd

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

А вот админить 2-3-5-10 серверов в свободное от основных обязанностей время задача не из лёгких. И именно здесь важны лёгкость, простота и самое главное преемственность, то есть совместимость с уже устоявшимися принципами, чтобы не тратить время на обучение и перенастройку.

python 👎
вот было бы на go 👍

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

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

Звучит как план!)))

Если ты не «администратор локалхоста» в виде старого синкпэда с помойки, а ворочаешь какую-либо инфраструктуру, хотя бы несколько десятков baremetal-серваков

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

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

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

Я писал не про системде, мой пост не имеет отношения к системде вс другие системы инициализации. Я отвечал на пренебрежительное отношение к админам вне ынтерпрайза, так называемых «одминах локахоста». По-моему мнению, как раз на них и следует ориентироваться прежде всего, любым системам инициализации, хоть системде, хоть сисвеиниту. Важно чтобы ОС на основе Линукс были ориентированы и дружелюбны для этой категории пользователей. Ынтерпрайз на то и кровавый, что он прожуёт и выплюнет весь этот Линукс, вместе со всеми системами инициализации.

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

Я всё же надеюсь, что альтернативы системде останутся и у нас будет выбор.

И вы считаете, что приоритет в направлении развития СПО стоит отдавать нуждам крупного бизнеса, а не пользователя со старым синкпадом?

А админу локалхоста не насрать? Мне вот, в данный момент админу локалхоста - совершенно пофиг что там внутри... Я даже не задумываюсь. Все потребности просто гуглю и применяю нагугленные команды. Давно уже не админил парк серверов... Впрочем и дома у меня вот 5 компов... На одном сейчас ЯД - синкает 2Т облако. Сравнивет локальную копию с облаком. Подозреваю что N4000 будет это дольше суток делать, и не понятно кто тормозит... ЯДерщики, порядочные криволапки. Это как надо писать чтобы 2Т чекать более суток? Зачем после каждой перезагрузки считать контрольные суммы всего пула? (Видимо этим он и занимается). Вот дочекает, перенесу этот винт на N5350 и сравню скорость чека.
На (Penryn) Intel(R) Celeron(R) CPU E3400 @ 2.60GHz RAM8Gb - Чекалось как раз 24 часа и 20 минут.
[@#$^%$#] - Не прокатило. МикроПК с N4000 - перегрелся, придётся включать ему вентилятор и рестартовать.
Решил дать ему шанс, прогнать ЯД без вентилятора. Не прокатило...

А лично вас что побуждает с таким энтузиазмом отстаивать интересы «адекватных» и «общественно-полезных» бизнес структур, но не косматых хиппи? Как вы пришли к такому выбору?

ИМХА - Лохматый троллинг...

services.msc в Линукс всё ещё не завезли? Даже в Haiku это есть.

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

Работа быстро прочищает мозги от застоев.

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

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

Нужно тебе внести изменения в юнит? Пожалуйста, вот эдит создай и положи в etc. Обновил систему? Изменения не перезатрутся. Надо тебе ридонли-систему? Пожалуйста, весь systemd-стек дружественен для этого. Хочешь убрать логи, чтобы не насиловать диск? Пожалуйста, пишем в память не больше 100 мегабайт только с одной опцией. Надо запустить что-то сложное с кучей зависимостей? Вообще не проблема, решается двумя строчками в INI.

И так далее, и в том же духе.

Корпорации активно проталкивают архитектуру нулевого доверия - Zero trust architecture (Wikipedia, researchsquare.com - Zero trust security approach with FIDO2 (pdf), pubs.opengroup.org - Zero trust commandments, learn.microsoft.com). Она подразумевает (из Wikipedia):

• единственный сильный источник идентификации пользователя {в идеале - с применением биометрии}*;
• аутентификацию пользователя {в идеале - с применением биометрии};
• аутентификацию устройства {в идеале с каким-нибудь установленным производителем устройства несменяемым hardware-id, наподобие IDevID/IAK из TPM (trustedcomputinggroup.org - TPM 2.0 keys for device identity and attestation (pdf)) или какого-нибудь своего root of trust в прошивке видеокарты (news.ycombinator.com - The GPU, not the TPM, is the root of hardware DRM)};
• дополнительный контекст, такой как соблюдение правил (policy compliance) и здоровье устройства {в частности Secure Boot, TPM, UEFI, защита целостности кода ядра ОС при помощи виртуализации, контроль со стороны приложений за соблюдением цепочки доверия - имеется в виду что банковские приложения могут не работать на root’ованных телефонах, WebAuthn};
• правила авторизации для доступа к приложениям;
• правила управления доступом внутри приложений.

(* - то, что в фигурных скобках, добавлено мной).

Zero trust означает нулевое доверие со стороны сильных мира сего (в частности производителей устройств, создателей операционных систем) к пользователям. В корпоративной среде подход zero trust со стороны работодателя к наемным работникам на служебных устройствах можно только приветствовать. Но если частный пользователь хочет хоть какой-то приватности на каком-либо из своих устройств, то тут ему с zero trust совсем не по пути.

Если сравнивать степень продвижения по пути внедрения архитектуры zero trust, то будет что-то типа: Android/iOS на смартфонах –> Windows/MacOS –> Linux –> OpenBSD.

Такие штуки, как Systemd (systemd.io - System and service credentials) и Wayland (usercomp.com - Wayland security model overview) вполне можно рассматривать как создание технологической базы для последующего внедрения архитектуры zero trust (с учетом их подходов к управлению правами доступа, приведенным по ссылкам; «цифровизация» со стороны Systemd логов ОС - тоже шаг в этом направлении, видимо для оптимизации машинной обработки для целей телеметрии / установления контроля и управления доступом к логам со стороны Systemd). Туда же можно отнести попытки взятия корпорациями контроля за источниками установки стандартного софта в ОС (Snap в Ubuntu).

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

Отчасти развитие. Отчасти деградация. Если сравнение с баш-лапшой – это основной довод, то это значит, что похвастать особо нечем.

Админам двух разных систем один и тот же скрипт может не подойти. А файлик для Системдэ подойдёт одинаково.

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

Как-то очень долго Вы пытались объяснить, что корпорации пытаются поиметь пользователя. Это известно давно.

Но тут нельзя выиграть. Или свобода®™, или комфорт. У корпораций комфорт. Он побеждает.

Любая система менее удобная гарантированно сливает на дистанции.

В особенности подрывает этот аспект отсутствие гибкости, навязываемое радикальными адептами свободного®™ ПО.

В Баше понятны только:

1. commandname
2. echo, и то, пока там простая строка и не нужно задействовать переменные окружения
3. | grep something

Всё остальное – бесконечное убожество. Не заслуживающее внимания.

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

Так systemd не только про управление сервисами.

Там куча всего.

Ну и отлично. В кои-то веки у нас есть интегрированное единообразное решение.

Да. Баш - корень зла.

остальные вымрут сами и проблема исчезнет

Какая именно проблема исчезнет?

Тогда уж веб-интерфейс, зачем TUI?

Тебе жмёт, но в обратную сторону. Вакуум же. (%

Так-то, если юнит не самописныЙ, то лучше делать systemctl edit unitname.

Если юнит был изменён, то и зависимости могут поехать, а их надо пересчитать.

ИМХО, это всё равно, что жаловаться на пакетный менеджер, который без обновления кэша не видит новых версий.

лучше-бы вы аватарку на старую поменяли, душевная она была у вас!

Каковы причины ИСПОЛЬЗОВАТЬ SystemD?

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

это де-факто стандарт управления сервисами и много чем еще и прекрасно рулиться через ansible и разные балалайки к нему, типа awx/semaphore ну и т.д. и т.п.

Раз уж разговор зашел, может знаешь как лучше сделать на самописной страничке на nodejs\vue, вывод состояния нескольких служб systemd и запуск\перезапуск их по необходимости? Ещё и логи бы их во вкладочке показывать.

В тексте по ссылке описан какой-то дилетантизм:

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

Что ты хотел этим сказать?

знать 300+ опций systemd

Зачем их знать? Всё можно найти тогда, когда оно понадобилось, а знать надо те же 20 базовых, как и в баше.

Зачем их знать? Всё можно найти тогда, когда оно понадобилось

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

на домашней генте и на федоре случайной и на альте рабочем и на дебиане на впске

разве нет?

(systemd в этом плане деградирует админа, лишая его регулярной практики

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

Вот в том то и дело, что systemctl status bla-bla-bla.service, теперь везде одинаковый, а не разный на разных системах, как раньше. Ещё бы сервисы называли одинаково в разных дистрах, вообще лафа была бы, а то кто в лес, кто по дрова.

Ну и одно дело гуглить\смотреть в мане опции используемые раз в год, а другое гуглить\смотреть в мане то что нужно всегда.

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

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

Пока я писал тебе ответ, ты удалил свой камент вот с этим:

В тексте по ссылке написано следущее:

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

В тексте по ссылке описан какой-то дилетантизм:

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

Итак, отвечаю на твой первый вариант: в тексте написано абсолютно иное.

Далее.

Некто не осилил кросс-компиляцию

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

попытался компилировать свой софт в эмуляторе

Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть, сильно более поздняя стадия сборки ОС.

обвинил в своей неудаче программу qemu

И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:

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

Новый камент:

Что ты хотел этим сказать?

Ответом на это будет «прочитай статью целиком».

Удаленный камент:

Ты хочешь провести какую-то аналогию с systemd?

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

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

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

Ещё бы сервисы называли одинаково в разных дистрах

но тогда напрашивается выход: устанавливать везде один и тот же wind^W дитсрибутив, и вам будет совсем удобно. разве не так?

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

разве не так?

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

А вот использование одной системы инициализации везде, мне ничем не мешает, т.к. никакой киллерфичи в других инитах нет(если конечно не считать за киллерфичу «зато не системд»).

PS: Единый формат бинарных пакетов тоже бы не помешал, но его ещё не разработали.

Оправдание длинное и скучное, о чём оно?

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

Напрасно я ожидал от тебя какого-то внятного ответа.

Де чего уж там говорить. Никому из разработчиков этого поделия не приходило в голову, что dpkg называется dpkg, а не debianpackages. Или dmesg, а не dumpmessages (или как там правильно). Странно, что они не назвали его systemdaemonscontrollerawesometheone. Ну, для полноты картины. Хотя админы и это оправдали бы, я уверен.

Вот это - да. Название ужасное, а ужасное в нём то, что после s нельзя нажать tab и дополнить, и даже после sys и system нельзя, это худшее что можно было сделать. Ну нет бы сделать по умолчанию алаис вроде sd(ещё и клавиши были бы рядом). Да, можно и самому алаис, но это же на каждой системе, на каждой сраной виртуалке делать придется.

Что ты не понял,

Пожалуйста, не нужно ничего отвечать. Но можешь бежать репортить.

Мне от тебя ничего не нужно, чего ты пристал, прилипала.

«цифровизация» со стороны Systemd логов ОС

Так это можно было делать и ранее, с помощью того же syslog-ng например.

Мне от тебя ничего не нужно

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

переименуйте в services.msc

задал мне вопрос, получил на него ответ

И всё. Диалог закончился. Или тебе памятник теперь поставить. Или что ты от меня хочешь.

Тебе ещё пять раз написать?

Пожалуйста, не нужно ничего отвечать. Но можешь бежать репортить.

Дежурно напоминаю, что вопящим про неюниксвейность systemd следует посмотреть в man inittab

Это же почти «а зато у вас негров вешают».

Баш-инит в 2025 году и впрямь не особо актуален, а вот на какой-нибудь openrc в качестве альтернативы systemd я бы посмотрел.