Не сочтите за грубость или неуважение, но лишняя "вода" и бесконечные повторы одного и того же на разные лады не делают что-то правдивее или наоборот.> Хотя-бы аналог debootstrap покажешь,
> для начала? (у редхатобразных тоже IIRC есть похожий тул). Чтоб этим
> быстро набрать минимальный rootfs (из готовых пакетов) достаточный для запуска пакетника.
> А потом этим пакетником нарулить остальное "как обычно".
Прошу прощения, а сам пакетник чем не угодил? Вон, в соседней ветке привели пример:
https://www.opennet.ru/openforum/vsluhforumID3/108826.html#75
> Еще и рантайм какой-то - "base" на 110 мегабайт. Ого, почти дотнет.
> - у меня весь бутабельный образ демьяна может быть легче чем
> один этот пакет. Это не пакет, это морской контейнер целый.
Очень интересное мнение. Хотя, когда я последний раз интересовался сборкой более-менее минимального (но не совсем вакуумно-сферического) образа для amd64, то без всяких (пере)компиляций баз или доработки конфигурационных файлов, с настройкаи по умолчанию получал на выходе образ размером около 30MБ. А сжимался этот образ до 8МБ.
> И всегда понятно какое файло откуда взялось и кому принадлежит. Потуги юзать пакетник пополам с другими
> тулзами приводят к неуправляемой помойке. Возможность понять откуда и почему взялся
> тот или иной файл - жирная фича. Если этого нет - нафига такой пакетник и такое управление софтом?
Гм, "управление помойкой" как-то больше похоже на лечение симптомов.
А вот если сама система в / и /usr и все что ставится дополнительно, идет в /usr/local, то ощущения помойки как-то не возникает.
Да и сказать, откуда взялся файл мог еще старый "pkg_info -w" лет эдак 15 назад.
> Удобно для обнаружения порушеных или похаканых систем. При том эффективно это обломать хакерам сложно
> даже при помощи руткита - усы будут отклеиваться и довольно заметно.
Всерьез пытаться обнаружить руткиты с помощью пакетника? Гм, удачи Вам.
> Донавесить эффективный rollback например снапшотом btrfs мне как-то сильно проще чем донавесить
> эффективный трекинг всех файлов в системе чем-то вместо пакетного менеджера
Правильно ли я понимаю, что отсутствие этой возможности на самом деле полезнейшая особенность, да и вообще, не очень-то нужно или хотелось? И задействование сторонних утилит теперь совсем не мешает?
Э ... очень пластичное мировозрение и вообще, интересный подход.
> Самое очевидное: RAM,
Вам как, ограничить пользователю в джейле?
rctl -a jail:foo:memoryuse:log=127M/user
rctl -a jail:foo:swapuse:log=127M/user
Или может, отдельному процессу пользователя?
rctl -a user:foo:memoryuse:sigterm=1289M/process
rctl -a user:foo:swapuse:sigterm=1280M/process
Или всему джейлу целиком?
rctl -a jail:foo2:memoryuse:deny=129M/jail
> CPU (в чем-то типа процентов а не абсолютное время,
rctl -a jail/user/process:foo:pcpu:deny=20
man jail
> pcpu %CPU, in percents of a single CPU core
.
> дисковая активность (бандвиз, iops).
> Как в этой штуке IOPS урезать и/или бандвиз диска ограничить?
> А то ваш ман про такие вещи почему-то молчит в тряпочку. Ну или мне нужны очки.
Видимо, к сожалению, вам все же желателен визит к окулисту.
rctl -a user/jail/process:foo:readbps:throttle=1M
rctl -a user/jail/process:foo:writeiops:throttle=20
> Количество процессов в помойке
rctl -a jail:foo:maxproc:deny=10
> В это etc попадают хотя-бы отдельные рулесы фаера для каждого контейнера и
> настройки шейпинга траффика? Или ты это даже не проверял?
Попадают, не извольте беспокоиться.
> Говорю же - не шибко гибко. Во многих линуксных запускалках поверх namespaces (например том же firejail) можно
> файлуху компоновать более продвинуто.
Если вы так говорите, тогда конечно так оно и есть.
> И совсем отдельную, и используя существующую ФС за основу (но например наглухо readonly) и что там еще.
Не расстраивайтесь, но пока ничего более продвинутого, к сожалению, не видно.
> И если например стоит цель отрезать проге только сеть
> - файлуху можно резать менее кардинально. Позволяет балансировать желаемый уровень изоляции vs затраты на подъем контейнера.
jail -U anonymous -c vnet path=/ command=/foo
Хотя да, наверное все же слишком сложно и несколько запутанно.
> А как насчет виртуализации IPC, mounts и прочих имен хоста?
Вам как, разрешить, запретить или может быть разрешить использовать общий для какой-то группы контейнеров?
Кстати, кусочки из /usr/src/sys/kern/vfs_subr.c
/*
* Credential check based on process requesting service, and per-attribute permissions.
int
extattr_check_cred(struct vnode *vp, int attrnamespace, struct ucred *cred,
...
* Do not allow privileged processes in jail to directly manipulate
* system attributes.
switch (attrnamespace) {
или /usr/src/sys/kern/uipc_socket.c
int
socreate(int dom, struct socket **aso, int type, int proto,
...
if (prison_check_af(cred, prp->pr_domain->dom_family) != 0)
return (EPROTONOSUPPORT);
достаточно убедительны?
> ... повторения, как я понимяю — для надежности.
.
>> Вы конечно не поверите, но тот же poudriere (Port build and test
>> system, это то, чем обычно собирают пакеты для реп) вполне себе
> Вы конечно не поверите, но debootstrap вообще надо только указать какой реп
> брать за основу и куда это раскатать.
> ... вариации выше сказанного, видимо для лучшего понимания читателями ...
> Debootstrap вообще ничего не собирает. Качает пакеты и распаковывает куда укажешь.
Преклоняюсь перед дебианщиками — делать репозиторий с пакетами ничего не собирая, а только качая эти пакеты! Мое глубочайшее уважение!
Интересный и очень любопытный подход!
Разрешите полюбопытствовать — если для этой своеобразной сборки пакетов в репозиторий нужно указать репозиторий, то как и кто собирает самый первый репозиторий? И в чем, кроме зеркалирования, смысл такого репозитория, если берутся уже готовые пакеты?
