systemd-филы, объясните простую вещь

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

Заржал)))

В принципе, вся ветка огонь.

./configure –prefix=/usr/local/php7

Это одна программа. А теперь представь, что их 20.

Если пользователь не доверяет бинарнику - надо запускать бинарник от другого пользователя.

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

Пользоваться вместо этого нативного механизма жуткими костылями с пофайловой изоляцией (начиная от докеров и заканчивая всякими selinux-ами кстати) - плохо.

Конечно плохо. Но больше нет нихрена жеж.

./configure --prefix=/usr/local/php7

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

Если у человека нет вкуса, то это неисправимо)

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

Ну для полноты. Для запуска образа в докере так-то тоже права нужны.

Это одна программа. А теперь представь, что их 20.

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

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

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

Откуда 20 программ?

Микросервисная архитектура, она такая.

Это вы еще только про сборку разговариваете, дальше собеседник к запуску перейдет, с лимитами, политиками рестарта и прочим. И у него в compose-файлике на 60 строк все эти сервисы будут как по команде вставать, падать, бегать, прыгать и так далее.

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

Я в самом начале сказал что эта ситуация редкая.

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

Откуда 20 программ?

Да легко: компилятор, пачка линтеров, LSP сервер, ещё немного тулинга.

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

А зачем там 20 докеров? Достаточно одного контейнера со всем нужным софтом.

Вот же диверсант, уже sudo внедрить пытаешься.

Я не пытаюсь, это ты написал про запуск из под другого пользователя.

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

Ага. Это решается быстро через докер. Одной командой.

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

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

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

Микросервисная архитектура, она такая.

Не обязательно. Просто дистры лялекса реально сосут и ничего не могут опакетить нормально. Исключения довольно редки, я только про nixos вот знаю. Например, для установки тулинга в других дистрах приходится использовать либо докер, либо пакетный менеджер от языка (cargo, pip, stack и так далее).

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

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

Почему не сходится? Первый меняет состояние sshd ЗА пределами chroot, второй меняет состояние sshd ВНУТРИ chroot. В этом весь смысл chroot – контейнировать.

Вот это если честно - не уловил.

А.

1. Залогинился в хостовую систему;

2. Зачрутился в гостевую систему;

3. Запустил sshd с ключом. Оно работает, подключения принимает.

Б.

1. Залогинился в хостовую систему;

2. Зачрутился в гостевую систему;

3. Запустил скрипт который должен запустить sshd с ключом.

С хера ли этот скрипт (а идея инита именно такова) меняет состояние sshd за пределами chroot, если я его (скрипт) запустил в chroot?

Тогда получается это systemd дырявый.

Опять же, записать содержимое MBR, сгенерить ядро и прибить систему мы можем и это секюрно. Запустить запускалку программы (которую в большинстве случаев мы и так можем запустить) - несекюрно.

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

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

Нет.

А зачем там 20 докеров? Достаточно одного контейнера со всем нужным софтом.

Тогда /opt генерим на сборочном сервере, засовываем в tar и раздаём всем. Или можно его упаковать в .deb пакет/пакеты и подключить всем как репу.

С хера ли этот скрипт (а идея инита именно такова) меняет состояние sshd за пределами chroot, если я его (скрипт) запустил в chroot?

Потому что sysctemctl - это не скрипт запуска sshd. Это прога отправки команд по сети. А «просто запустить демон через консоль» системг не умеет.

Во-вторых, запрещаемый systemctl start sshd - пошатает систему вне chroot, а вот разрешенный sshd -D /etc/ssh/ssd_config - нет? Шото не сходится.

У тебя сам systemd не запущен с pid 1 внутри chroot. Как ты собираешься им там пользоваться?

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

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

Ну так удалите или запретите chroot.

Если бы удалили chroot, то ты бы кричал как гады ломают linux.

Тогда /opt генерим на сборочном сервере, засовываем в tar и раздаём всем.

Ну то есть, ты изобретаешь докер, только хуже.

Или можно его упаковать в .deb пакет/пакеты и подключить всем как репу.

Нельзя, для deb нужен рут.

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

Проблемы начинаются при обработке триггеров, хотя это и не вина apt'а, а вина dpkg, но ССЗБ. Всегда считал дебильной идеей удаление софта оставлять на откуп удаляемого софта. И ладно если бы только софта, так оно весь процесс работы раком ставит, пока триггер вручную не разрешишь. На редкость мерзкий пм, хуже yum'а.

Ну то есть, ты изобретаешь докер, только хуже.

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

Тогда /opt генерим на сборочном сервере, засовываем в tar и раздаём всем.

ты уже близок к принятию. Осталось придумать как монтировать этот tar не распаковывая, накатывать изменения на него без надобности пересылки всего файла, запускать примонтированное в chroot’е и мы придем к первой реализации docker’а

У контейнеров вообще и докера в частности есть вагон и тележка недостатков, в куб – просто раковни

У всего есть тонна недостатков, но бизнес-валуе затмевает.

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

А что в Docker’е ненативного (ну кроме самого демона)?

Не надо монтировать не распаковывая.

накатывать изменения на него без надобности пересылки всего файла,

Если так то вместо tar можно rsync или svn или другую систему контроля версий.

запускать примонтированное в chroot’е и мы придем к первой реализации docker’а

Во-первых, не надо в chroot-е.

Во-вторых, докер это не chroot. Если бы он был chroot-ом, претензий к нему было бы на одну меньше (но все равно много). А так это очередное проявление дефекта мозга его авторов. Файловая система адекватных контейнеров действительно делается chroot-подобным способом.

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

претензий к нему было бы на одну меньше (но все равно много)

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

Пользуюсь rootless podman. Оно работает, как ни странно. Права не нужны.

У всего есть тонна недостатков, но бизнес-валуе затмевает.

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

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

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

докер – это обёртка над tar и линуксовыми неймспейсами. И то и другое нативнее некуда.

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

Не понял вопрос.

Если из докера вырезать всё ненативное то получится unshare(1). Если его совместить с chroot-ом то получится более-менее вменяемый контейнер. Но костыльный. Но и так лучше докера, думаю.

Обёртка которая жирнее того над чем она обёртка?

В плане «жирнее»? Докер явно не жирнее линуксового ведра, ведро лялекса – просто чемпион мирового класса по ожирению.

Вот сейчас посмотрел - /usr/bin/docker, установленный в убунте 20.04 в 2023 году, весит 50мбайт. /usr/bin/dockerd - 84мбайта.

При этом /boot/vmlinuz-5.4.0-204-generic весит 14мбайт.

Вот сейчас посмотрел - /usr/bin/docker, установленный в убунте 20.04 в 2023 году, весит 50мбайт. /usr/bin/dockerd - 84мбайта.

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

При этом /boot/vmlinuz-5.4.0-204-generic весит 14мбайт.

А если распаковать? А если учесть модули?

Мне не надо.

тогда не спорь.

А

Ничего не работает, подключений нет:

$ sudo chroot /var/empty
$ chroot: failed to run command ‘/bin/bash’: No such file or directory

С хера ли этот скрипт (а идея инита именно такова) меняет состояние sshd за пределами chroot, если я его (скрипт) запустил в chroot?

С того что chroot абьюзят. chroot это про файловую систему и только про файловую систему.

Опять же, записать содержимое MBR, сгенерить ядро и прибить систему мы можем и это секюрно. Запустить запускалку программы (которую в большинстве случаев мы и так можем запустить) - несекюрно.

Не можем, если ты не смонтировал все это внутрь chroot’а. Ты пытаешься делать вид что chroot это VM, но это не так. Это всего лишь смена области видимости файловой системы, которую начали абьюзить в качестве средства изоляции. Получилось плохо. Лялекс придумал namespaces, FreeBSD придумали jail, OpenBSD придумали pledge + unveil.

Буду. Скажи, Microsoft барыжит перепакованным шляпиксом?

Если пользователь не доверяет бинарнику - надо запускать бинарник от другого пользователя. Пользоваться вместо этого нативного механизма жуткими костылями с пофайловой изоляцией (начиная от докеров и заканчивая всякими selinux-ами кстати) - плохо.

А как им пользоваться, если он теперь моих файлов не видит?

Только на правах рекламы своих курсов и мастер классов. Барыжит облаком на основе своего Линукс. И барыжит вендой, в состав которой входит его графический компонент.

Если из докера вырезать всё ненативное то получится unshare(1). Если его совместить с chroot-ом то получится более-менее вменяемый контейнер. Но костыльный. Но и так лучше докера, думаю.

Возьми podman, это буквально то, что ты хочешь.

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

Это архитектурные проблемы. Кроме кубика есть и другие оркестраторы, но k8s - сейчас промышленный стандарт и многие хостеры предлагают managed kubernetes.

Если из докера вырезать всё ненативное то получится unshare(1). Если его совместить с chroot-ом то получится более-менее вменяемый контейнер. Но костыльный. Но и так лучше докера

Мыши плакали, кололись, но продолжали есть ёлку кактус

Возьми podman, это буквально то, что ты хочешь.

Да он не хочет. Он хочет чтобы все было как в 90-тые. К сожалению.

на основе своего Линукс

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

Куб актуален в основном для крупных деплоев

Ну, там и начинается бузинес, баблишко, хех.

Хуже того, иногда софт сразу проектируют с расчётом на микросервисы и куб

Есть такое, ложное чувство, будто точно все уже понял.

Для простых задач compose-файлами пусть обходятся.

Лялекс придумал namespaces, FreeBSD придумали jail, OpenBSD придумали pledge + unveil.

На самом деле все началось с зон (zones) в solaris 8 (2000 год)

Да он не хочет. Он хочет чтобы все было как в 90-тые. К сожалению.

Почему к сожалению? Он дарит нам массу лулзов.

Ознакомься с содержанием моих курсов, выбери нужный, оплати их и получай знания, которые тебе «нинужны». https://en.wikipedia.org/wiki/Azure_Linux Дальше либо оплачивай, либо самъ. Никто не сможет тебе помочь, если ты не можешь гуглить.

На самом деле все началось с зон (zones) в solaris 8 (2000 год)

Да, но она уже умерла.

Да, но она уже умерла.

Да, но идеи живут и развиваются.

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

Да, но идеи живут и развиваются.

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