-
Notifications
You must be signed in to change notification settings - Fork 304
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
prepare-root: Add support for root.transient #3114
Conversation
This function doesn't exist anymore.
This doesn't matter at all, but I just noticed this while working on the code.
Closes: ostreedev#3113 It'd greatly improve compatibility with things like RPMs that install in `/opt` if we supported a full "original docker" style model where `/` is a transient overlayfs. We'd still keep our semantics for `/etc` and `/var` by default, but e.g. we'd stop recommending `/opt` ➡️ `/var/opt`, in this model, so `/opt` would be on the overlayfs. Note this all aligns with composefs, where we'd actually be making `/` a *read-only* overlayfs by default; it'd be really nice of course to *implement* this by just making the composefs overlayfs writable, but I am not sure we can hard require composefs for this right now. So this change adds support for `root.transient = true` in `/usr/lib/ostree/prepare-root.conf`. The major downside is that people could be surprised if files they write to e.g. `/opt` don't persist across upgrades. But, that's already again how it works since Docker started. Note as part of the implementation of this, we need to add a whole new "backing" directory distinct from the deployment directories. (Tangentially related to this, it's tempting to switch to always using a *read-only* overlay mount by default.
Skipping CI for Draft Pull Request. |
So this seems to work well:
Then I did A next step here is to change rpm-ostree to detect this configuration and stop doing the opt ➡️ var/opt link (edit: done in coreos/rpm-ostree#4719 ) |
This pairs with ostreedev/ostree#3114 Basically we want to detect the case where the OS has opted-in to this new mode and *not* symlink things. I originally thought we could implement this by just moving all the toplevel directories, but then I hit on the fact that because the `filesystem` package is creating all the toplevel directories in lua script which we ignore...that doesn't work. So we need to keep making them by hand.
This pairs with ostreedev/ostree#3114 Basically if ostree has an overlayfs (whether writable or a readonly composefs), we're safe to handle non-`/usr` content. However, we still *always* drop content from the "API filesystems" like `/run`, `/dev` etc. Because really, no one should be adding stuff there.
This also wants ostreedev/ostree-rs-ext#570 |
This turns on the functionality added in ostreedev/ostree#3114
BTW this change also requires coreos/coreos-installer#1203 for FCOS for the same reason as composefs. |
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -3360,6 +3407,9 @@ sysroot_finalize_deployment (OstreeSysroot *self, OstreeDeployment *deployment, | |||
if (!selinux_relabel_var_if_needed (self, sepolicy, os_deploy_dfd, cancellable, error)) | |||
return FALSE; | |||
|
|||
if (!sysroot_initialize_deployment_backing (self, deployment, sepolicy, error)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be gated on root.transient
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right to call this out, but this was semi-intentional because one thing I want to do is change usroverlay
to write here instead of the /var/tmp
it does today - because that would just be better; the content would be clearly "lifecycle bound" to the deployment and we wouldn't need that hacky tmpfiles.d
snippet we carry:
# https://github.com/ostreedev/ostree/issues/393
R! /var/tmp/ostree-unlock-ovl.*
(That said to do that note we'd need to also change some logic to ensure the overlay content for it is actually removed on reboot by default)
This all said, yes we could still create it dynamically in either case. I think we actually should have logic here in ostree to do what is being replicated in ostree-rs-ext and rpm-ostree around querying the initramfs config. Then we could drop the ex-integrity.composefs
repo config.
@@ -3078,6 +3078,10 @@ sysroot_initialize_deployment (OstreeSysroot *self, const char *osname, const ch | |||
if (!require_stateroot (self, osname, error)) | |||
return FALSE; | |||
|
|||
g_autofree char *stateroot_backing = g_strdup_printf ("ostree/deploy/%s/backing", osname); | |||
if (!glnx_shutil_mkdir_p_at (self->sysroot_fd, stateroot_backing, 0700, cancellable, error)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this too.
This pairs with ostreedev/ostree#3114 Basically we want to detect the case where the OS has opted-in to this new mode and *not* symlink things. I originally thought we could implement this by just moving all the toplevel directories, but then I hit on the fact that because the `filesystem` package is creating all the toplevel directories in lua script which we ignore...that doesn't work. So we need to keep making them by hand.
This pairs with ostreedev/ostree#3114 Basically if ostree has an overlayfs (whether writable or a readonly composefs), we're safe to handle non-`/usr` content. However, we still *always* drop content from the "API filesystems" like `/run`, `/dev` etc. Because really, no one should be adding stuff there.
This builds on top of the test image using ostreedev/ostree#3114 and related PRs.
This builds on top of the test image using ostreedev/ostree#3114 and related PRs.
This pairs with ostreedev/ostree#3114 Basically we want to detect the case where the OS has opted-in to this new mode and *not* symlink things. I originally thought we could implement this by just moving all the toplevel directories, but then I hit on the fact that because the `filesystem` package is creating all the toplevel directories in lua script which we ignore...that doesn't work. So we need to keep making them by hand.
This pairs with ostreedev/ostree#3114 Basically we want to detect the case where the OS has opted-in to this new mode and *not* symlink things. I originally thought we could implement this by just moving all the toplevel directories, but then I hit on the fact that because the `filesystem` package is creating all the toplevel directories in lua script which we ignore...that doesn't work. So we need to keep making them by hand.
BTW for people seeing this now, it's also worth looking at #3120 |
It's unclear to me reading the commit message and the issues here what exactly happens when we turn this knob on. Could you write a bit of docs about it? Thanks |
sysroot: Drop unused prototype
This function doesn't exist anymore.
prepare-root: Add an autofree
This doesn't matter at all, but I just noticed this while working
on the code.
prepare-root: Add support for root.transient
Closes: #3113
It'd greatly improve compatibility with things like RPMs that install
in
/opt
if we supported a full "original docker" style model where/
is a transient overlayfs. We'd still keep our semantics for/etc
and
/var
by default, but e.g. we'd stop recommending/opt
➡️/var/opt
, in this model,so
/opt
would be on the overlayfs.Note this all aligns with composefs, where we'd actually be making
/
a read-only overlayfs by default; it'd be really nice of courseto implement this by just making the composefs overlayfs writable,
but I am not sure we can hard require composefs for this right now.
So this change adds support for
root.transient = true
in
/usr/lib/ostree/prepare-root.conf
.The major downside is that people could be surprised if files they
write to e.g.
/opt
don't persist across upgrades. But, that'salready again how it works since Docker started.
Note as part of the implementation of this, we need to add a whole
new "backing" directory distinct from the deployment directories.
(Tangentially related to this, it's tempting to switch to always
using a read-only overlay mount by default.