Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to not overwrite existing images to download subcommand #1442

Open
napaalm opened this issue Mar 30, 2024 · 2 comments
Open

Add option to not overwrite existing images to download subcommand #1442

napaalm opened this issue Mar 30, 2024 · 2 comments

Comments

@napaalm
Copy link

napaalm commented Mar 30, 2024

Feature Request

Desired Feature

When running CoreOS as a VM on QEMU, I might want to automatically download the latest version of the system image before provisioning it. The problem is that I don't want an existing image to be overwritten if I already have the latest version, because another (running) VM might be using it as a backing_store.

Other Information

I'm currently writing an automated script to deploy Fedora CoreOS virtual machines on RHEL 9.3 using (among other tools) coreos-installer 0.17.0.

@napaalm
Copy link
Author

napaalm commented Mar 30, 2024

I guess enabling this option could still verify the signature to ensure the existing file is correct.

@jlebon
Copy link
Member

jlebon commented Apr 15, 2024

coreos-installer download already knows to not re-download an image if it already exists and in that case goes straight to signature verification.

However, that logic does not work if the image has already been decompressed (either manually or via the -d option) because signature verification is against the compressed artifact. So it redownloads, reverifies and redecompresses, happily clobbering any existing file.

We have access to the expected checksum so we could instead checksum the existing file, but our metadata isn't currently signed. We could add a e.g. --no-clobber flag though it'd be awkward that it only applies to the decompressed case. I think the proper fix is to just sign our metadata (which we should do anyway).

For now though, if you're scripting this anyway, you could also query the stream metadata and compare the filename or version yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants