-
Notifications
You must be signed in to change notification settings - Fork 196
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
Determine support path for RPMs that install into /opt
, /usr/local
etc
#233
Comments
I'd support the /usr/lib/opt approach! |
/opt
/opt
, /usr/local
etc
@cgwalters any hints about what I can do in the meantime to get a sensible /opt to work? I was thinking of manually putting things into /usr/lib/opt during my install script, and then setting up a bind mount to /opt in my /etc/fstab, but I don't know if that'll be incompatible with the existing mount mechanism under OSTree. Is there a better way to weasel my way into the standard OSTree mount mechanism? |
(the issue here is proprietary software with hardcoded assumptions about being in /opt, by the way; otherwise I'd just patch it) |
We can change rpm-ostree to do this postprocessing automatically. |
@cgwalters yeah, sorry, I realize that; was just asking about what to do between now and having native support for /opt in |
The only thing I can think of is to postprocess the RPM outside of rpm-ostree, basically RPMs are just It might sound complex at first but it'd probably be a 4 line script + 15 line spec file. |
@cgwalters but then I also need something to add an /opt bind mount back at runtime, right? The RPMs are still hardcoded to think they're in /opt. Would I have my RPM-wrangler add an entry to fstab as well? |
Add a systemd tmpfiles.d file which creates the symlink |
Oh, excellent, thanks! |
Ah, it looks like https://github.com/projectatomic/rpm-ostree/blob/master/src/libpriv/rpmostree-postprocess.c#L102 is already putting a symlink for |
Turns out even with |
I don't think you want to replace the full
or so. In the current model, the |
Ah yes, I just figured out the immutable bit on /. The reason I was trying to redirect all of /opt, rather than just subdirectories within it is that I have a few different packages that want to put things into /opt, and I was just going to have a general purpose "/opt fixer" in my postprocessing script rather than teaching my individual RPMs how to add to tmpfiles. So my postprocess script currently just copies /opt into /usr/lib/opt and adds a tmpfiles.d entry that (tries to) symlink /opt to /usr/lib/opt. I can do it for individual packages, but that starts putting a lot more burden on different subprojects, so I was hoping to avoid that 😔 |
Interesting effect of having |
Yeah, this would all be better if rpm-ostree handled it internally. I'll get around to this at some point if no one else does. |
How would you envision the "ostree-native" version of this working? My concern with the obvious thing is that a lot of programs use it to store all their files, including ones they expect to mutate. Simply making a symlink from |
@cgwalters I would suggest an migration of I'm not sure if the way to say we drop all files from
What do you think? |
I hope this will help others to workaround until there is an solution, thanks to @cgwalters and @copumpkin Rebuild puppet-agent rpm with new pathRegular Expression to change /opt/ -to-> /var/opt:
Copy Conent from /opt/ to the new location: /var/opt/
File:
Start Custom Yum repository:
via rpm-ostree upgrade I've got the changes in ostree and /opt/puppetlabs -> /var/opt/puppetlabs e.g. I can run now puppet agent on centos-atomic host. The above documented solution is upgradeable. I have no blog or website where I can put this and link from here. HTH |
by the way this does not work with rpm-ostree -> I get the following log error: https://nopaste.me/view/dd563d20 A test installation of my rpmrebuild rpm on my ostree-build system was just fine, files & binaries are located in Can someone help? |
After some research I was able to understand that I have to modify my custom rpm so that is will be located under I changed the regular expression from above to: As next I have to add or change the tmpfiles.d file (system.d tmpfiles.d) of puppet-agent rpm (my custom rpm) before
On my testing centos-atomic-host it is now possible to start the puppet-agent systemd service, the original location of There are some addtional adjustments todo at the custom rpm - which are not yet done by me, but the informations here are already useful so I hope. HTH |
Thanks for providing the workarounds. I would like to support this better, however, it would touch a lot of code that is in flux for other work (e.g. the just-landed package layering). |
See coreos#233 - for RPMs which place files in e.g. `/opt`, we have different behavior in the treecompose case (silently drop it) versus package layering (does the wrong thing). Since the unpacker right now is only used in the layering case, this just ensures we'll get a consistent error there.
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Is there a timeframe for this feature coming to "next" stream ?😢 |
This thread is super long and I admit to have not read it all. |
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of coreos#233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: coreos#233
Obviously, this alone is not enough to expose that content but it's a start. Currently as is, it'll get nuked when we replace `/usr/local` by a symlink in postprocessing. A future patch will address that part. Part of #233.
This solves the `/opt` problem by using the new state overlay concept in OSTree: an overlay filesystem is mounted on top of `/usr/lib/opt` and the upper dir is automatically "rebased" whenever new content comes in. Concretely, this means that app state is carried forward, all while allowing the (OSTree-managed) package contents to be updated. We also solve the `/usr/local` problem the same way. The app state issue isn't really present there, but `/usr/local` has traditionally been system state. We want to keep supporting dropping files there all while also supporting shipping OSTree-owned content. See also: ostreedev/ostree#3113 Fixes: #233
When `/opt` packages get moved to `/usr/lib/opt`, they're not being labeled properly; they get the `lib_t` label instead of `usr_t` (or e.g. `bin_t` for `/opt/bin`). This apparently works for e.g. Google Chrome (for which the `/usr/lib/opt` translation was added). But with state overlays, the goal is to support all `/opt` packages and things will break without proper labeling. Add an equivalency rule so that `/usr/lib/opt` is labeled like `/opt. This fixes the SELinux issues that occur when layering Puppet in coreos#233 (comment). This should probably be upstreamed to SELinux (along with the `/usr/etc` equivalency rule just above). Side note: in the status quo model where `/opt` is a symlink to `/var/opt`, everything is *also* mislabeled (it gets `var_t`). To be conservative, we don't fix this since presumably this works right now for people writing files there via e.g. Ignition/cloud-init and anyway all that would go away if we move over to state overlays by default in the future.
well, apparently upstream has a different solution, where things for /opt are installed into /usr/lib/opt coreos/rpm-ostree#233 the problem is that the brave package has, for example, a symlink in /usr/bin/brave-browser-stable -> /opt/brave.com/brave/brave-browser so the /usr/bin/brave-browser-stable doesn't work and so doesn't the .desktop file 🤔
This issue has been closed but the problem is still there. |
The fix for this is part of the bootable containers initiative. There is no magic switch; it requires judgement. See coreos/fedora-coreos-tracker#1681 (comment) and links there for more information. |
RPMs like Puppet and Google Chrome go in
/opt
.For the package layering case, in this PR we made it an obvious error.
The core problem here is: OSTree defines
/opt
(really/var/opt
) as system administrator territory - it's never rolled forward/backwards etc. Content in there isn't protected by thero
bind mount covering/usr
right now.One approach would be to - for these RPMs, automatically rewrite the content into
/usr
. Chrome I don't believe actually stores any persistent state in/var
, so simply rewriting/opt/google/chrome
->/usr/lib/opt/google/chrome
with a compatibility symlink would likely work.Puppet probably stores state in
/var
and hence would be harder.The text was updated successfully, but these errors were encountered: