> читать учимся, госпадин.
>>когда еще sd был сервисным менеджеромВ нем с САМОГО НАЧАЛА были замашки на
1) Нормальный логгинг без более 9000 проблем предшественников. Еще и tamper proof, братец Лени целый тезис задвинул, тот не долго думая заимплементил это в journald.
2) Интеграция с пакетниками. С четкими регламентами где дефолты, где оверрайды админа.
3) Обзор и диагностирумеость. Буквально 2 приблуды (systemctl и journalctl) показывают ключевые аспекты сервисов в системе и логинг.
А те в пролете как раз потому что вместо этого из достоинств - "более быстрые лошади". Сапопикал уже пробовал это. И тут их обошли на повороте.
> и рассматриваем все в этой парадигме.
ИМХО мир лучше всего рассматривать - таким какой он есть. Системд с самного начала был амбициознее и перспективнее. Это многим нравится. Совместимость с д@рьмом из 70-х прошлого века сомнительное достоинство. "Отборный овес, свежая вода в корытах"? Удачи бензоколонке с таким позиционированием.
> резать операции Вашим сервисам - задача MACa/
Их настраивать канительно - за что и выпали из фавора. Предпочитаю чтбы в защитах надолго увязали - атакующие, а не админы.
> контейнеров.
1) Прелесть системды в том что он это и делает несколькими директивами.
2) Это все равно откуда-то запускаться должно.
3) настраивать это где-то еще - не логично.
> стартовать контейнер - задача сервисного менеджера.
Зачем мне конфигурация 1 действа в 2 местах? Это очень не практично. И это 1 из основных претензий юниксвею.
> Вам явно в призму ткнули в сообщении - можете эту тираду про
> "доступ в шелл" можете сунуть обратно в карман.
Потому что вам нечем крыть с тем лоскутным одеялом? :)
> хотя, именно касаемо отношения системы разганичений привелегий к серв. менеджеру я не
> уверена. в openrc подобному мешает только большая разница в реализации ядра
> этого механизма на разных платформах.
1) Линух я юзаю не для того чтобы получать фичесет какой-нибудь нетбсд или чего там.
2) Думаю что мешает еще и тот факт что при радикальной изоляции утилитки и баш - останутся "где-то там". Изолируемому сервису их вызывать как раз - не надлежит. Иначе не такой уж он и изолированный.
> давайте список ?
> и костылей, и подпорок.
Вы сами за меня это сделали. Рассказами про совместимость. Почему меня в 2025 году совместимость с барахлом из 1970х вообще должна колыхать? Я не вижу причин скучать по runlevel'ам и прочему антикваирату.
Не, systemd не оперирует внутри таким бредом. У него есть "target" - это намного более мощный superset идеи. И его логгинг мне куда как. И systemd.timers - намного логичнее крона. И главное смотрятся 1 утилиткой оптом. Как обзор системы.
> 2 года в openrc багфиксы отправляла, писала политику tomoyo под все компоненты оного.
> поэтому могу разьяснить вот буквально по каждому файлу, что в поставке идет.
Мне на уровне концепций ваши более быстрые лошади и совместимость с окаменелым барахлом из прошлого века ценой нормального системного менеджмента - не ок. А вот это вам - не завозили.
И я могу себе представить сколько вы времени убили на настройку tomoyo. Именно поэтому я буду достигать сравнимых целей в цать раз быстрее, контейнерами вообще и системдой в частности, а то и VM где суровее изоляция нужна. У системды и для этого есть полезные утилсы, machniectl тот же. А в этом вашем openrc - более быстрые лошали.
> а еще писала политику tomoyo под современную систему с sd .. так
> что, выкладывайте карты, давайте сравним )
А какого характера карты вы хотите? Ну вот например... в случае s-d я могу посомтреть дельту относительно дефолтов дистра 1-2 командами. Как относится к безопасности? Элементарно: я могу быстро понять на что обратить внимание в первую очередь. Какие тут кастомные сервисы, какие параметры сервисов сменили.
Или во:
...
[Service]
User=someprog
Group=someprog
Restart=always
RestartSec=5
# Hardening
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=strict
ProtectControlGroups=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictNamespaces=yes
LockPersonality=yes
ReadOnlyPaths=/run
RuntimeDirectory=run
NoNewPrivileges=yes
...
Смена юзера не самое интересное. Интереснее что они получают "лысую" ФС, в которой минимальный /dev и бесполезный /home, зарубается возможность менять системное файло, операции с модулями и tunables ядра, никаких новых привилегий, форсированный W^X и все такое прочее, типа запрета реалтайм шедулеров (зачем они обычной проге?).
А как вы все это сдалеате с вашими парадигмами и сколько это займет? Это копипаст из стандартной болванки, на самом деле можно еще подзакрутить - man systemd.exec и там все что Restrict/Protect. Скажем SystemCallFilter=<список разрешенных сисколов>. С пресетами даже. Или NoExecPaths=/ (тогда сервис вообще не сможет запускать программы из фс).
Для важных штук можно OOMScoreAdjust=<something>. Чтоб их не прибило по ерунде. Там же и вещи типа affinity на энный проц, если надо. Или например IO scheduling. Не про безопасность, но рядом - стабильность системы. Если сервис может дико жрать проц с реалтайм шедулингом, остальное сможет почти-умереть икая адскими таймаутами на все вообще.
> а я, говоря, что openrc функционалу сервисной части sd не уступает, не
> голословила.
> rc-status.
> и тоже будет статус по всем сервисам, с к.-вом рестартов, временами падения,
> временами работы и др. логов, разве что, именно эта команда не выведет.
Может там еще и показ всей "периодики" и "активации через сокет" будет? Чтобы знать кто откуда лезет - по настоящему? Или даже аналог systemd-delta найдется? Ибо первое что меня интересует на "вон той машине" - а чем это отличается от дефолтов дистро, которые я более-менее знаю?
> тем не менее, openrc все будет логировать, куда Вы ему скажете. по
> умолчанию все в /dev/log идет. и Вы просто смотрите в своем
> демоне логирования лог, где в качестве источника указано имя сервиса openrc.
Я рад за него. А s-d таки указывает в качестве источника - то что реально источником было. Если он сам - себя, если сервис - сервиса. На самом деле настраиваемо.
И я рад что у s-d есть свой демон логирования - который сразу нормально работает. Т.е. не выжрет все место при runaway какого-то флудера, и не надо logrotate каждой фигне лично тыкать, вместо этого нарулив общесистемную политику сколько какому журналу можно максимум жрать.
> openrc делает вот ровно то же самое, от имени supervise-daemon с меткой сервиса.
К сожалению, если кто будет вот тут размахивать совместимостью с огромными простынками sysv - там с этим полный швах. А меня с практической точки зрения волнует - чтобы у меня таких подарков не было.
Нет ничего более деморализуюшего чем когда запустил стартовый скрипт под рутом, все сработало ок, но при рестарте сервака/вм/чего там - опа. Тишина. Угадай что не так. И тут вы таеие говорите что совместимость с этим Г фича. Ага. Щас. Это не фича, это лишний раз получить вон той граблей в лоб. То что это проще (и значит будет случаться чаще) - никак не фича.
> касаемо логротейта - так поставьте себе нормальную реализацию сислога. у меня на
> роутере, напр., давно логи в sqlite.
Вот системд это и делает - предоставляя нормальное штатное решение для этого. А кому надо нечто этакое заменит journald на что он там хотел, или дополнит. И тоже сможет в скулайт или куда там складировать. Если это надо. Меня и journald устраивает в общем случае.
А еще s-d умеет рюхать coredumps по дефолту, так что они и как бы есть, но и как бы неконтролируемое место и вечно - в проде не сожрут. Удобно и прагматично. Конечно в идеале падать не должно, но раз в год и палка стреляет.
> и я просто делаю logread -u serviceName, чтобы посмотреть, почему у меня
> сервис упал.
А я смотрю systemctl status <SERVICE> первым делом. Упал он там или что еще - вопрос номер два.
И между нами - я только что закатал шикарный комит с фиксом нестартуюшего в проде сервиса благодаря тому что sd заметил что сервис наворачиваеится при старте и собрал мне coredump в характерную локацию. Откуда я его взял, подивился что оно раз в год о как умеет - да и навесил фикс.
>>3) Тулинг для типовых задач. Хочется рулить контейнеры или виртуали?
> идете и ставите себе контейнер.
> про это я в самом начале написала.
Агаблин. И получаю еще в цать раз больше оверинженерии и конфиги в разных местах. А это точно EPIC WIN?
Знаете, если ваш тул заставляет вас хватать энтерпрайзные логгеры, управляторы и проч даже для неэнтерпрайзных задач - может, не такой уж тул и хороший?
> с тем же успехом можно во все дистрибутивы по дефолту прям весь
> софт на свете пихать. и всех версий обязательно.
Как минимум в репы - его и пихают. А так размер системды - по сравнению с размером списка пакетов моего дистра - просто не заметен. Дебиан его на субпакеты нарезал. И кстати он не есть жесткий depends минимального дебиан. На минималках debian бутстрапается и совсем без init. Но это малость неудобно :)
> чтоб исошники под миллиарды ТБ были. вдруг юзеру захочется !!
У дебиана исошки можно скачать воооон там. Не знаю, нарезает ли их кто в таком количестве, но так можно было. Мне проще - делать миррор репы на вооон тот терабайтник. Так тоже можно было.
>>Включает в себя трек успеха загрузки и информирование бутлоадера, реакцию на сбои сервисов, работу с аппаратным вачдогом и проверку что сервисы которых оно супервизит реально живы, а не плймали локап неделю назад при всеобщем пофиге на все и вся, как вон там.
> по порядку ..
> openrc реагирует на падение сервисов, как Вы ему скажете в конфиге.
И что ему можно сказать? В системд можно при failure энного юнита - запустить вон тот юнит. Как этакий "exception handler" фэйла (ре)старта критичного юнита.
> openrc инициализирует вотчдог.
И дальше что? Вот есть у меня сервис. Он через полчаса работы - повис. Или он стартовал, стартовал, и задумался навечно, не закончив старт. Как об этом openrc узнает?
> "реально живы".
Как это нечто узнает что сервис - живой? Вон тот видите ли может и через апи нотификаций видеть что процесс реально в состоянии подать признаки жизни. А самого вачдогователя мониторит хардварный или хотя-бы ядерный вачдог.
> касаемо бутлодера - это Вы приврали.
> boot counting сейчас не работает из коробки НИГДЕ. вот буквально.
Тем не менее в системд есть готовые facilities для этого. И у GRUB обвес для этого.
> много там эмбедщины на sd-boot ? :)
sd-boot вообще ортогонален boot counting и uki как таковым, ВНЕЗАПНО. Так что я не понял этот реверанс.
> учимся, говорю, читать, увОжаемый.
> "сервисный" != "системный".
Это пересекающиеся множества. Скажем startup или shutdown - не сервиса, а системы вообще. А рюхается - вот этим софтом опять же.
> за сервисами openrc следит.
> а 90% компонентов для системного менеджмента sd, в крупных дистрибутивах(и нет, речь
> не о Вашей федоре на десктопе. а о rhel, ubuntu и debian.
Чего там в моем дебиане - нет? Там майнтайенеры не только tor сделали с инстансами (openrc кстати умеет инстанциируемые сервисы?) так что можно запустить 5 вариантов тора с разными конфигами одной левой, а при желании перманентно заоверловадив кому-то из - и изменяния юнитов системды, но и урезали ему привилегии и доступы сразу по дефолту.
А с openrc кто вообще что-то стравнимое вообще делает чтобы сервис out of the box был порезан на манер примера выше - сразу опосля инсталла?
> про эмбедщины вообще молчу - там часто alpine либо что-то
> кастомное) не используются по дефолту.
Ни разу не видел alpine в эмбедщине. И лично я это практикую, с дебианом обычным. Неплохо катит. Альпин это вообще головняка кусок! С их musl и его загонами на тему мелкого размера стека по дефолту. Половина софта - особенно кастомного - там зачастую тупо ПАДАЕТ. И при том не всегда - сразу. Что как бы подстава. Но если хочется помучаться и поавралить, отличный выбор.
> грамматика уровня 4го класса; странная аналогия, не применимая к сфере ПО; непонимания
> основ проектирования ПО в целом. мда.
Вы пока ни 1 user visible достоинства вашего openrc относительно s-d не привели. Только какие-то подгоны решения под ответ.
Но мне нет никагого смысла обманывать себя. Будем честны. Правильный way имхо - тот который упрощает мою жизню и делает то чем я занимаюсь быстрее и эффективнее.
> к счастью, это 99% контейнеров, некоторое к.-во встраиваемых систем и внушительное к.-во
> серверов.
> google://alpine linux
Безблагодатная набивка для энтерпрайзных контейнеров. Больше нигде не встречается. Ибо грабель кусок с их musl. И кроме как для запуска CI которые никто не видит - нафиг не вперся никому.
> полностью супервизию сервиса со стороны openrc это не отключит.
Он умеет в эту фактическую сурпервизию, для начала? С вот реально чеком живости сервиса через какое-нибудь апи взаимодействия?
>>В системд если ОЧЕНЬ надо - можно в ExecStart(Pre, Post) и шелскрипт запустить.
> вот не поверите - в openrc также.
Ну я поздравляю, дошло.
> и способы с бинарями в init.d и шелл-скриптами явно помечены, как нерекоммендуемые,
А зачем тогда вы педалировали это как достоинство? Чтобы оказать своему объекту обожания медвежью услугу? Это получилось, поздравляю. Ибо ни 1 достоинства относительно sd я не увидел, а вот недостатков - есть.
> в документации. и так никто не делает.
> но зачем Вам вникать-то в матчасть, когда можно повторить список странных и
> давно избитых аргументов.
А еще ... на всех серверах с которыми я имею дело были дебианы и убунты. И там системд. При том дебиан достаточно универсален чтобы быть и на моем десктопе, и на вон тех vm, и в вон тех контейнерах, и вон тех одноплатниках. Ну или убунта - на серверах которые не лично мои но в проектах которые мне не пофиг и где я вписался. И мне удобно ворочать выводками ОДНОЙ технологии. А вы можете колупаться с вашим альпином. Но я посмотрю как вы ЭТО себе на десктоп поставите. Или вгрузите 3-4 копии разных знаний делания одного и того же.
И вот тут мы посмотрим кто кого сделает. Я более менее углубленно знающий "свои" технологии или вы с метанием между альпинами и чем там? Если что для меня вон то - побочное тезническое зло. А реальные цели и задачи - вовсе не администрирование систем. Я это умею потому что для одноплатников косплею нечто типа OEM Lite да и самообслуживание в опенсорсе в моде. Как special perk я вон тем VM нагенерил под специфичную проблематику.
Таки то что sd в майнстримовых дистрах повышает ценность этого знания.
Вариант для распечатки
