On Thu, Mar 7, 2019, at 10:53 AM, Florian Weimer wrote: > > > The %transfiletriggerpostun would've probably fixed it if it used -p > > <lua> instead of shell. > > We switched to the shell for the benefit of rpm-ostree.
Short answer: https://github.com/projectatomic/rpm-ostree/issues/749#issuecomment-470926180 (Let me know if that would help something, here or in the issue; it wouldn't be hard for us to implement) Slightly longer answer: There are *multiple* layers of defenses in rpm-ostree against exactly this sort of problem. The reason we don't implement Lua is (as the later linked issue spells out in more detail) is to ensure we can reliably construct a *new* root filesystem in a transactional model without having any potential effects on your running filesystem. The fact that with rpm-ostree you always have a "base image" that is constructed on the server side is the first primary line of defense; we won't ship you a new image (ostree commit) that isn't known good. The second line of defense is that *client side* rpm-ostree always runs a "sanity check" in the new deployment: https://github.com/projectatomic/rpm-ostree/pull/892 The third line of defense is that somehow even if you do get a broken tree, you always have the previous one in the bootloader. But we do support both layering and overrides - you can engage the package system side. Now personally if I wanted to test a new glibc I'd first do it in a disposable clone of my development podman container, rather than replacing the one on the root filesystem of my host. But let's assume for whatever reason we do need to test an updated glibc on the host system; rpm-ostree supports that too: [root@localhost ~]# rpm-ostree status State: idle AutomaticUpdates: disabled Deployments: ● ostree://fedora-atomic:fedora/29/x86_64/atomic-host Version: 29.20190306.2 (2019-03-06T23:32:07Z) Commit: 57297da7779ed8b7b7b9a0f39f6f12a703000a40cf451770fe23749a5558f60d GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4 ostree://fedora-atomic:fedora/29/x86_64/atomic-host Version: 29.20190219.0 (2019-02-19T04:52:26Z) Commit: d00adf110907f93f6cdd05deda0e2878c9bd71c74e0c4c2e9a5250d2f4cc8868 GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4 [root@localhost ~]# rpm -q glibc glibc-2.28-26.fc29.x86_64 (Here I browse to https://koji.fedoraproject.org/koji/packageinfo?packageID=57 and find the previous glibc built for f29): [root@localhost ~]# rpm-ostree override replace https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-{common-,}2.28-25.fc29.x86_64.rpm Downloading 'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-common-2.28-25.fc29.x86_64.rpm'... done! Downloading 'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-2.28-25.fc29.x86_64.rpm'... done! Checking out tree 57297da... done Enabled rpm-md repositories: updates fedora fahc rpm-md repo 'updates' (cached); generated: 2019-03-07T20:40:34Z rpm-md repo 'fedora' (cached); generated: 2018-10-24T22:20:15Z rpm-md repo 'fahc' (cached); generated: 2019-03-07T05:41:31Z Importing rpm-md... done Resolving dependencies... done error: Could not depsolve transaction; 2 problems detected: 0. nothing provides glibc-langpack = 2.28-25.fc29 needed by glibc-2.28-25.fc29.x86_64 1. nothing provides glibc-langpack = 2.28-25.fc29 needed by glibc-2.28-25.fc29.x86_64 Hmm. Oh right, this is libsolv's way of telling me I forgot a package probably... Ah, yep, I need to also take in glibc-all-langpacks: [root@localhost ~]# rpm-ostree override replace https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-{common-,all-langpacks-,}2.28-25.fc29.x86_64.rpm Downloading 'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-common-2.28-25.fc29.x86_64.rpm'... done! Downloading 'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-all-langpacks-2.28-25.fc29.x86_64.rpm'... done! Downloading 'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-2.28-25.fc29.x86_64.rpm'... done! Checking out tree 57297da... done ... Applying 3 overrides Processing packages... done Running pre scripts... done Running post scripts... done Writing rpmdb... done Writing OSTree commit... done Staging deployment... done Freed: 227.0 MB (pkgcache branches: 3) Downgraded: glibc 2.28-26.fc29 -> 2.28-25.fc29 glibc-all-langpacks 2.28-26.fc29 -> 2.28-25.fc29 glibc-common 2.28-26.fc29 -> 2.28-25.fc29 Run "systemctl reboot" to start a reboot [root@localhost ~]# rpm-ostree status State: idle AutomaticUpdates: disabled Deployments: ostree://fedora-atomic:fedora/29/x86_64/atomic-host Version: 29.20190306.2 (2019-03-06T23:32:07Z) BaseCommit: 57297da7779ed8b7b7b9a0f39f6f12a703000a40cf451770fe23749a5558f60d GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4 ReplacedBasePackages: glibc-all-langpacks glibc-common glibc 2.28-26.fc29 -> 2.28-25.fc29 ● ostree://fedora-atomic:fedora/29/x86_64/atomic-host Version: 29.20190306.2 (2019-03-06T23:32:07Z) Commit: 57297da7779ed8b7b7b9a0f39f6f12a703000a40cf451770fe23749a5558f60d GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4 ostree://fedora-atomic:fedora/29/x86_64/atomic-host Version: 29.20190219.0 (2019-02-19T04:52:26Z) Commit: d00adf110907f93f6cdd05deda0e2878c9bd71c74e0c4c2e9a5250d2f4cc8868 GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4 [root@localhost ~]# Now, I also can see we executed the transfiletriggerin in question: [root@localhost ~]# journalctl -b -r -u rpm-ostreed | grep transfiletriggerin | head -1 Mar 08 13:36:37 localhost.localdomain rpm-ostree[1753]: Executed %transfiletriggerin(glibc-common) for lib, lib64, usr/lib, usr/lib64 in 203ms; 24842 matched files So yes, I would need to reboot to test it now, but on the flip side rpm-ostree carefully maintained the integrity of my system, and didn't touch my booted deployment. This property relies on not executing arbitrary lua code in the context of the daemon. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
