cloud-init does not respect declared MIME types in multipart archives
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Critical
|
Unassigned |
Bug Description
In https:/
This means that every part is now assigned its MIME type based on the first line of its content; the declared MIME types are ignored.
In the specific reported case, a "text/cloud-
[0] Specifically, it was expanded to include all the values in the dict at https:/
[Original Report]
In the upstream Kubernetes project Cluster API, specifically the Cluster API AWS Provider, it will download a file securely from AWS Secrets Manager in the cloud-init script, save that file to a well known location, and then restart the cloud-init service through systemd. After the cloud-init script is restarted, it will resolve the secrets file (that had previously not been there) and execute its commands.
This worked fine on versions of cloud-init up until 19.4-33-
Some other information:
- cloud-init is definitely successfully running twice based on systemd and cloud-init-output.
- The /var/lib/
- The "resolved" version of user-data at /var/lib/
Is there another command that is now required if you plan on restarting cloud-init for another execution where files are now present that were previously not?
1. Cloud Provider: AWS
2. Upstream issue: https:/
summary: |
- cloud-init caches files and never checks again + cloud-init does not respect declared MIME types in multipart archives |
description: | updated |
user-data.txt