-
Notifications
You must be signed in to change notification settings - Fork 247
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
ZIP support #867
Comments
Thanks for the report. |
I'm not sure how I feel about archive support. DEFLATE support is fine by me if it's useful to people. Archive support can be used as a "poor-man's-package-manager" which isn't ideal, but also has legitimate uses. Then there's the question of which formats to support. Is there a particular use case you had in mind? |
To be clear, gzip is DEFLATE plus headers, so we wouldn't support DEFLATE standalone. There also isn't a universal interchange tar format or zip format; there are different flavors. Zip in particular is underspecified and has redundant headers (central directory and individual file headers), so there's plenty of room for incompatibilities. I've seen multiple writer/reader pairs where a particular reader can't consume the output of a particular writer. |
I'd be interested in this (though more generally speaking, supporting directory creation from archive types). The reason why is that it makes it incredibly easier to provision things like CNI plugins directly from release tarballs (e.g. https://github.com/containernetworking/plugins/releases/). Right now the alternative is to have automation (terraform) download the archive, extract it locally, then populate the entire tree inline, then use the result; or deploy some service in the middle that provides the extracted files individually and populate the tree from their URLs. This is incredibly tedious, and wastes resources generating a large json file that then needs to ultimately be uploaded, fetched, and parsed. That said, seeing #541, I'm not exactly sure I should be working on this if it's going to end up rejected. @lucab what would it take, if I were to implement this, to get it accepted/merged? My general plan for this would be:
{
"directories": [
{
"path": "/foo",
"contents": {
"archive": "tar"
"source": "http://example.com/archive.tar",
"verification": {
"hash": "sha256-98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4"
}
}
},
{
"path": "/bar",
"contents": {
"archive": "tar"
"compression": "gzip"
"source": "http://example.com/archive.tar.gz"
}
},
{
"path": "/baz",
"contents": {
"archive": "zip"
"compression": "deflate"
"source": "http://example.com/archive.zip"
}
}
]
}
Note that I'm mainly interested in tarballs, so if zip is causing issues with its format as noted in earlier comments, I'm happy to just drop it for now, and just do tar. |
I've had the need to get binaries into FCOS instances before and another option I used was to create a container image with the content that I need and then to use podman to fetch and copy the content on first boot: https://github.com/travier/fedora-coreos-nomad/blob/main/common.bu#L31. |
Right; as far as alternatives go the simplest way to pull and expand a tarball would be to use curl and tar in a systemd oneshot service, though this has the same caveats around symlinks. I ended up going that route (which is simpler than expanding each file in the ignition config), but it still feels out of place. |
Feature Request
Support zip compression.
Desired Feature
Configuration Specification v2.3.0 says that a file content can be compressed or not.
It would be nice to support zip too, as it is quite common.
The text was updated successfully, but these errors were encountered: