Set EC2 cirrus-agent SELinux context to unconfined #163
Conversation
|
@cdoern okay, these AWS images (assuming the build works) should be running the cirrus-agent unconfined. You can confirm this in your PR (after swapping in these images) using the "rerun in terminal" trick. Simply so a |
|
force-push: Fixed woopsie. |
|
Cirrus CI build successful. Found built image names and IDs:
|
|
@cdoern finally it finished. The bits you need to stuff into
and
There should be comments making it fairly clear where the IDs go. Commit and push that in containers/podman#15179 and maybe(?) the results will improve? If not...well...we'll know for sure it's not an SELinux related problem. Also, we probably should have this change in our AWS images anyway, so no biggie. |
|
@cevich in the yml, where do the ami's go? is it |
|
Closing: These EC2 images are broken, the |
|
Force-push: Found a fix that seems to allow cloud-init services to start: Added a custom default |
Long ago, many test failures and other problems were experienced in Cirrus-CI managed google-cloud VMs. None of the problems were reproducible manually. It was discovered that because the cirrus agent starts from a metadata-downloaded script, it was executing with a more restrictive SELinux type. This is not the case when running tests manually, where root sshs in. It's been observed recently, a similar situation may be occurring in EC2. However, in this case, the agent is started by cloud-init, and was observed operating with the type `cloud_init_t`. In case this is the source of trouble now or in the future, fix the setup to match GCP. Signed-off-by: Chris Evich <[email protected]>
|
force-push: 🙄 forgot a package. |
|
Cirrus CI build successful. Found built image names and IDs:
|
|
I'll try these new images see if they do anything |
|
Thanks @cdoern you read my mind.
Hopefully they will at least boot this time 😀 |
|
I'm going to merge this, despite it not fixing containers/podman#15074 since passed all other podman tests and it improves runtime consistency between google and AWS. |
Long ago, many test failures and other problems were experienced in
Cirrus-CI managed google-cloud VMs. None of the problems were
reproducible manually. It was discovered that because the cirrus agent
starts from a metadata-downloaded script, it was executing with a more
restrictive SELinux type. This is not the case when running tests
manually, where root sshs in.
It's been observed recently, a similar situation may be occurring in
EC2. However, in this case, the agent is started by cloud-init, and was
observed operating with the type
cloud_init_t. In case this is thesource of trouble now or in the future, fix the setup to match GCP.
Signed-off-by: Chris Evich [email protected]