anaconda
anaconda copied to clipboard
rhinstaller
rpm-ostree: set untrusted ostree pull flag
By default ostree validate checksum when pulling from remote repos, but not for local repos. Set the untrusted ostree pull flag to always validate files.
For a bit more context, at my job we have an 'appliance' based on Alma 8 / rpm-ostree and out of maybe 200 deployments, we had the ISO corrupted once during transfer, the install still worked, but was unusable.
Hi, it is necessary to update these unit tests:
PullRemoteAndDeleteTaskTestCase.test_run_success
PullRemoteAndDeleteTaskTestCase.test_run_failure
The opts.unpack() call returns {"refs": ["ref"], "flags": OSTree.RepoPullFlags.UNTRUSTED}.
@poncovka sorry about that, should be fixed now, can you approve the CI again ?
Not opposed to this, but I think what you want to do instead is run ostree fsck.
Also, doesn't Anaconda already have infrastructure to self-validate the ISO integrity? Are you not using that?
Not opposed to this, but I think what you want to do instead is run
ostree fsck.
It would be a bit slower as it needs to read back from the disk, instead of just validating data while reading from the iso, and trusting the disk when it says write is ok, but if it's really the preferred way I can do that, I just don't want to have a corrupted install without errors.
Also, doesn't Anaconda already have infrastructure to self-validate the ISO integrity? Are you not using that?
Right now I'm just appending data and patching a Alma 8 boot iso with mkksiso, I don't think it updates the hash that can be used to validate the iso, and this validation step is opt in, and means reading twice the full ISO which can be slow depending on how the iso is mounted (virtual CD over VPN).
Are the RPMs checksums validated when they are local ? If yes that makes ostree behavior more consistent, if not I'm fine keeping this as a local patch
It would be a bit slower as it needs to read back from the disk, instead of just validating data while reading from the iso, and trusting the disk when it says write is ok, but if it's really the preferred way I can do that, I just don't want to have a corrupted install without errors.
Yeah, fair. It's a tricky balance as this will slow down installs for everyone doing an ISO install to catch low-probability failures.
An entirely different approach here would be for Anaconda to use dm-verity - and as a bonus, this would also cover the integrity of other data, including Anaconda itself. I've been thinking about doing this for the Fedora CoreOS Live ISO.
Right now I'm just appending data and patching a Alma 8 boot iso with mkksiso, I don't think it updates the hash that can be used to validate the iso, and this validation step is opt in, and means reading twice the full ISO which can be slow depending on how the iso is mounted (virtual CD over VPN).
Oh wow, virtual CD over VPN sounds flaky. Any reason you're not doing a "minimal ISO" and fetching the target OS content over HTTP?
Are the RPMs checksums validated when they are local ? If yes that makes ostree behavior more consistent, if not I'm fine keeping this as a local patch
I think they are actually, so this argues for this patch as is.
In the end, installation speed doesn't matter that much, and gaining a bit of reliability is helpful to ensure the first boot works.
fetching the target OS content over HTTP
BTW, in case you didn't see, https://fedoraproject.org/wiki/Changes/OstreeNativeContainer and more recently https://lists.fedoraproject.org/archives/list/[email protected]/thread/4XSCGIDMIFMP3DU6AYQOBZBMIHZ7J75Y/
An entirely different approach here would be for Anaconda to use dm-verity - and as a bonus, this would also cover the integrity of other data, including Anaconda itself. I've been thinking about doing this for the Fedora CoreOS Live ISO.
always on validation that doesn't cost too much would be nice
Right now I'm just appending data and patching a Alma 8 boot iso with mkksiso, I don't think it updates the hash that can be used to validate the iso, and this validation step is opt in, and means reading twice the full ISO which can be slow depending on how the iso is mounted (virtual CD over VPN).
Oh wow, virtual CD over VPN sounds flaky. Any reason you're not doing a "minimal ISO" and fetching the target OS content over HTTP?
My use case is a bit exotic, I work for a software editor and 99% of our deployments can't access internet, so everything (base OS, our drivers and software) is in the ISO, and the upgrade package is also the ISO (small script bind mount the ISO, run ostree pull-local --untrusted, and finally rpm-ostree upgrade --cache-only).
"virtual CD over VPN" is an extreme example, but we deploy on our customers servers using what we can / what we are provided by our customers.
Disconnected isn't exotic at all. A really key sub-reason we're doing the "container native" ostree is so that these cases users/customers can mirror the OS updates into a disconnected registry.
So instead of doing updates via attaching a virtual media ISO, it's just rpm-ostree upgrade (or rebase) to a container image mirrored into that environment.
But anyways, this PR looks fine to me. The extra CPU usage might be noticeable in environments like OpenQA but if it matters at some point we can investigate adding something like inst.ostree.checksums=0 or so.
Disconnected isn't exotic at all. A really key sub-reason we're doing the "container native" ostree is so that these cases users/customers can mirror the OS updates into a disconnected registry.
So instead of doing updates via attaching a virtual media ISO, it's just
rpm-ostree upgrade(orrebase) to a container image mirrored into that environment.
Sadly in my use case it's often 2 servers per site with no extra infrastructure to have an http server or a registry, and no VPN to a central location. We push updates to the servers instead of pulling, when rpm-ostree always pull.
Sorry I missed this! Tested with the silverblue image, works ok. Merging.