-
Notifications
You must be signed in to change notification settings - Fork 192
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
sealing /etc + config management integration #702
Comments
I see this as an incremental step towards "fully sealed" systems, like "pure dm-verity". See also https://blog.verbum.org/2017/06/12/on-dm-verity-and-operating-systems/ |
For Fedora CoreOS we're going to use Ignition. It might be interesting to have Ignition support providing this metadata with the config. Some little bit of extra metadata in the JSON, and rpm-ostree could learn to pull that out of |
do you mind providing a more complete proposal? I think I like it :) - basically what we are saying is that any changes to /etc/ have been defined by ignition configs and we otherwise seal |
Dumping here a random idea I had the other day. As we continue on the path of sealing the system (making
/boot
readonly e.g.), I'd like to support doing this for/etc
too.For the "site specific ostree compose" case, it makes a lot of sense to do the config management on the server side. However for the "OS vendor golden image" case (e.g. Fedora Atomic Host), one thing I think would be cool is a mode where one can configure rpm-ostree to run a set of configuration management scripts.
In other words, in this model,
/etc
would only be written by e.g.ansible-playbook
. Rather than the default/etc
merge logic, every time we upgrade, we copy the defaults and rerun the playbook (or config management script). This hence means/etc
is no longer subject to Hysteresis.And further, I'd like to inject metadata from the playbook run, saying which exact git commit of ansible it came from. Something like:
The text was updated successfully, but these errors were encountered: