Comments 63
Я так и не понял, зачем это нужно. Автор хотел сделать откат апдейтов, в итоге отказался. Также я не понял, зачем нужен KDE Linux, без менеджера пакетов. Для чего они нужны объективно?
Разве для всего этого уже не существуют разные Gentoo и подобные ему дистрибутивы? Тот же Arch можно собрать с нуля.
Он не отказался, откат апдейтов работает, он планирует в будущем перейти на EROFS, но чтобы откат апдейтов по-прежнему работал. Arch чудесен, но можно сделать ещё лучше
Можно сделать тот же арч лучше, причём бесплатно. Btrfs с настоящими снапшотами (которые можно делать по pacman хуку\расписанию\самому факту успешной загрузки) и загрузчик с возможностью грузиться с этих снапшотов уже делают то же самое, при этом не ограничивая пользователя в свободной модификации системы.
Классические дистрибутивы Linux теряют свою консистентность в общем смысле сразу после установки на файловую систему.
Современные дистрибутивы стремятся так или иначе перенять подход мобильных систем: чтобы был некий rootfs, поставляемый дистрибутивом, который монтируется в неизменяемом виде, поверх него при необходимости монтируются overlay-файловые системы (с драйверами и другими системными изменениями), либо же «разработческий» слой при необходимости внесения изменений в rootfs.
Приложения все устанавливаются в пользовательские директории. Конфигурационные файлы хранятся на отдельной ФС (покрывающей /etc и /var), либо же у пользователя.
Преимущества: возможность нормального аудита, возможность сброса настроек как на телефонах, атомарные обновления, понимание состояния/консистентности системы.
Самое толковое видение, что я читал — у Леннарта Поттеринга, разрабтчика systemd: https://0pointer.net/blog/fitting-everything-together.html
Мне кажется, что Поттеринг тяготеет к монструозным переусложненным решениям. То, что он предлагает, является образцом еще одного подобного решения. ИМХО.
Вы переусложнением считаете что-то конкретное?
В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.
Это всё маркетинг, что линуксу не хватает безопасности. Стратегия линукса в плане безопасности - повышение IQ пользователей)
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
Кого вы в данном случае имеете в виду под конкурентами?
Десктопы: macOS, Windows (в плане защиты ядра). Смартфонные Android и iOS давно впереди любой десктопной ОС, про них и говорить не стоит.
Мы сейчас говорим про безопасность только с точки зрения возможности откатиться на предыдущее состояние или более широко?
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Мне кажется главное слабое место подобного подхода, что когда утекает ключ, которым подписывались компоненты загрузки, то все старые системы (полагающиеся на этот ключ) оказываются уязвимы с очень низкими шансами на то, что это исправят. Или я не прав?
Вы про Secure Boot?
Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md
Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
Я прошу прощения, но я не понимаю как это поможет старым системам. Можно попросить вас раскрыть мысль?
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical.
Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Пользователю и не нужна возможность свободной модификации, идейно неизменяемая файловая система очень даже подходит
Про каких пользователей идёт речь?
Современным основным пользователям линуксов на десктопах - разным айтишникам - обычно как раз-таки нужна.
Ну, я их и имею в виду, а не домохозяек. Ставить и обновлять пакеты - нужно, а произвольным образом изменять системный раздел - нет
Почему нет?
Так а что конкретно будет в этом неизменяемом системном разделе, а что - вне его?
Бинарники, библиотеки, хедеры. Вне его, конечно, фотки
Так и чем это отличается от текущего состояния дел в линуксовых дистрибутивах? Тем, что для того чтобы туда что-то записать, помимо повышения прав, нужно будет ещё перемонтировать раздел?
Принципиально - ничем
Просто всё будет лучше работать и быстрее
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
П. 2 в сочетании с п.1 выглядит стремновато по сравнению с классическими апдейтами, где тупо файлы переписываются - если что-то пойдёт не так, то я останусь с поломанной файловой системой.
Если я хочу позаниматься каким-то экспериментами, которые могут серьёзно поломать систему, то я просто беру chroot/Docker/VirtualBox и делаю всё там.
В целом подход интересный, но на практике большинство, видимо, выбирает дистрибутивы по каким-то другим преимуществам.
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
Чем плох подход с использованием снэпшотов (к примеру zfs)? grub позволяет вам загрузиться с любого снэпшота. Так что можно экспериментировать и в случае проблем откатиться даже не на один шаг, а на несколько.
Это разные инструменты.
Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива).
В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
Как у нас с вами может один и тот же набор файлов, если, к примеру, вы занимаетесь разработкой и вам нужны компиляторы и иде, а я видеомонтажем и мне нужны совершенно другие программы и библиотеки? Или вы предлагаете сразу ставить все, что есть в репозитории?
Это пользовательское ПО и оно устанавливается в домашнюю директорию (или какую-то общую директорию с ПО), а не в систему.
В Ubuntu Core это Snap'ы.
Если я хочу использовать один display manager, а вы - другой, значит ли это, что они тоже должны устанавливаться в привязке к конкретному пользователю?
Это системный компонент, поэтому нет. Полагаю, он будет в составе слоя "такой-то-desktop", который монтируется поверх rootfs.
Ubuntu'вский Snap подходит и для системных компонентов (он может «добавлять» симлинки в /usr/bin и подобные системные директории на свои snap'ы)
Ваш исходный тезис был, что в случае пакетов для траблшутинга сложно добиться идентичного окружения. Но если у нас несколько слоев, то мы приходим ровно к такой же ситуации.
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Если вы обновляете слой и у вас запущены бинарники из предыдущей версии слоя как мне кажется атомарного обновления не получится, если только мы не монтируем новый слой после перезагрузки.
Если вы не знаете, то, грубо говоря, stateless означает, что пакеты - это просто файлы и конфигурация и не содержат произвольные скрипты для установки.
Если пакет обновляет работающий сервис, то как можно без скриптов перезапустить этот сервис после обновления?
нужно добавить этот сервис в конфигурацию и после обновления всего дистрибутива понять, что она изменилась
Т.е. post install скрпит есть, но он является частью системы, а не пакета?
Да
Пакетов много, package scripts у них очень разные, вряд ли получится упихать логику всех скриптов в один универсальный.
В AerynOS получилось) Там это называется триггеры
Можно посмотреть на реализацию?
Конечно! https://github.com/AerynOS/os-tools
Вижу в документации
AerynOS supports the use of triggers, or actions, that run at the end of package installations.
Значит ли это, что перед установкой пакета ничего сделать нельзя? Обычно при обновлении сервиса preinstall останавливает сервис, postinstall запускает его опять.
Скорее всего
Вы случайно не знаете почему разработчики пошли на такое ограничение, которое сильно снижает возможности системы при установке пакетов по сравнению с другими дистрибутивами?
А вот и не снижает
Можно попросить вас привести аргументы?
я думаю, то, о чём мы спорим, не принципиально, в любом случае, триггеры выполняются после успешной транзакции
как быть с ситуацией, когда какие-то действия надо выполнить до обновления файлов пакета?
.
По следам AerynOS: как выглядит современный дистрибутив