Determine support path for RPMs that install into `/opt`, `/usr/local` etc

[cgwalters]

RPMs like Puppet and Google Chrome go in /opt. For the treecompose right now, we actually silently discard the content 😢.

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 the ro 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.

[copumpkin]

I'd support the /usr/lib/opt approach!

[copumpkin]

I'd support the /usr/lib/opt approach!

[copumpkin]

@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?

[copumpkin]

@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?

[copumpkin]

(the issue here is proprietary software with hardcoded assumptions about being in /opt, by the way; otherwise I'd just patch it)

[copumpkin]

(the issue here is proprietary software with hardcoded assumptions about being in /opt, by the way; otherwise I'd just patch it)

[cgwalters]

We can change rpm-ostree to do this postprocessing automatically.

[cgwalters]

We can change rpm-ostree to do this postprocessing automatically.

[copumpkin]

@cgwalters yeah, sorry, I realize that; was just asking about what to do between now and having native support for /opt in rpm-ostree

[copumpkin]

@cgwalters yeah, sorry, I realize that; was just asking about what to do between now and having native support for /opt in rpm-ostree

[cgwalters]

The only thing I can think of is to postprocess the RPM outside of rpm-ostree, basically RPMs are just cpio blobs with metadata and scripts. One could rpm2cpio foo.rpm to unpack it, then mv opt/foo usr/lib/foo, then turn it into a "source" tarball and make a binary-only RPM from that.

It might sound complex at first but it'd probably be a 4 line script + 15 line spec file.

[cgwalters]

The only thing I can think of is to postprocess the RPM outside of rpm-ostree, basically RPMs are just cpio blobs with metadata and scripts. One could rpm2cpio foo.rpm to unpack it, then mv opt/foo usr/lib/foo, then turn it into a "source" tarball and make a binary-only RPM from that.

It might sound complex at first but it'd probably be a 4 line script + 15 line spec file.

[copumpkin]

@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?

[copumpkin]

@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?

[cgwalters]

Add a systemd tmpfiles.d file which creates the symlink /opt/foo -> /usr/lib/foo. This is pretty similar to what rpm-ostree automatically generates for directories in /var. See also https://github.com/projectatomic/rpm-ostree/blob/master/src/app/tmpfiles-ostree-integration.conf#L18

[cgwalters]

Add a systemd tmpfiles.d file which creates the symlink /opt/foo -> /usr/lib/foo. This is pretty similar to what rpm-ostree automatically generates for directories in /var. See also https://github.com/projectatomic/rpm-ostree/blob/master/src/app/tmpfiles-ostree-integration.conf#L18

[copumpkin]

Oh, excellent, thanks!

[copumpkin]

Oh, excellent, thanks!

[copumpkin]

Ah, it looks like https://github.com/projectatomic/rpm-ostree/blob/master/src/libpriv/rpmostree-postprocess.c#L102 is already putting a symlink for /opt -> /var/opt, so I think I need to use an L+ tmpfiles entry.

[copumpkin]

Ah, it looks like https://github.com/projectatomic/rpm-ostree/blob/master/src/libpriv/rpmostree-postprocess.c#L102 is already putting a symlink for /opt -> /var/opt, so I think I need to use an L+ tmpfiles entry.

[copumpkin]

Turns out even with L+, systemd-tmpfiles-setup.service doesn't have the power to unlink /opt. Not does root. I'm confused what kind of thing /opt is to prevent me from changing it like this, given that it's on a RW filesystem and isn't a special mount point or anything weird.

[copumpkin]

Turns out even with L+, systemd-tmpfiles-setup.service doesn't have the power to unlink /opt. Not does root. I'm confused what kind of thing /opt is to prevent me from changing it like this, given that it's on a RW filesystem and isn't a special mount point or anything weird.

[cgwalters]

I don't think you want to replace the full /opt symlink, just create a sub-symlink inside it, no? I.e your tmpfiles.d snippet should be

L /opt/appname - - - - ../usr/share/appname

or so.

In the current model, the /opt -> /var/opt symlink is part of the ostree commit (see the init_rootfs() function), it isn't created on boot. The reason you're getting EPERM is because of the immutable bit.

[cgwalters]

I don't think you want to replace the full /opt symlink, just create a sub-symlink inside it, no? I.e your tmpfiles.d snippet should be

L /opt/appname - - - - ../usr/share/appname

or so.

In the current model, the /opt -> /var/opt symlink is part of the ostree commit (see the init_rootfs() function), it isn't created on boot. The reason you're getting EPERM is because of the immutable bit.

[copumpkin]

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 😔

[copumpkin]

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 😔

[copumpkin]

Interesting effect of having /opt -> /var/opt and then using tmpfiles.d to populate /opt: I need to ensure that my tmpfiles.d conf file sorts lexicographically later than rpm-ostree-autovar.conf (or tmpfiles-ostree-integration.conf, which also defines the same entry) because otherwise tmpfiles.d tries to create my /opt/myapp while /opt is still a broken link, before /var/opt has been created.

[copumpkin]

Interesting effect of having /opt -> /var/opt and then using tmpfiles.d to populate /opt: I need to ensure that my tmpfiles.d conf file sorts lexicographically later than rpm-ostree-autovar.conf (or tmpfiles-ostree-integration.conf, which also defines the same entry) because otherwise tmpfiles.d tries to create my /opt/myapp while /opt is still a broken link, before /var/opt has been created.

[cgwalters]

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.

[cgwalters]

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.

[copumpkin]

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 /opt/foo to /usr/lib/opt/foo will work until the program tries to mutate one of those, and then we'll run into other issues. What I'm doing today with my horrible hack is copying stuff from /usr/lib/opt into /opt, which ostree sets up to point to /var/opt so it's mutable anyway. This leads to some duplication and more runtime mutability than I'd like, but I don't have a cleaner solution in mind other than handling /opt entries on a case-by-case basis.

[copumpkin]

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 /opt/foo to /usr/lib/opt/foo will work until the program tries to mutate one of those, and then we'll run into other issues. What I'm doing today with my horrible hack is copying stuff from /usr/lib/opt into /opt, which ostree sets up to point to /var/opt so it's mutable anyway. This leads to some duplication and more runtime mutability than I'd like, but I don't have a cleaner solution in mind other than handling /opt entries on a case-by-case basis.

[tobiashochguertel]

@cgwalters I would suggest an migration of /opt to /usr/lib/opt 233#issue-140670748. From treefile we can set remove-from-packages to remove files.

I'm not sure if the way to say we drop all files from /opt/ except for the following files and directories which are definied from treefile option include-from-opt (Array)*.The Entries from include-from-opt are moved to /usr/lib/opt. The previous behavior of rpm-ostree does not change (version compatibility).

*New treefile option introduction: include-from-opt (Array).

What do you think?

[tobiashochguertel]

@cgwalters I would suggest an migration of /opt to /usr/lib/opt 233#issue-140670748. From treefile we can set remove-from-packages to remove files.

I'm not sure if the way to say we drop all files from /opt/ except for the following files and directories which are definied from treefile option include-from-opt (Array)*.The Entries from include-from-opt are moved to /usr/lib/opt. The previous behavior of rpm-ostree does not change (version compatibility).

*New treefile option introduction: include-from-opt (Array).

What do you think?

[tobiashochguertel]

I hope this will help others to workaround until there is an solution, thanks to @cgwalters and @copumpkin

Rebuild puppet-agent rpm with new path

Regular Expression to change /opt/ -to-> /var/opt:

:%s/"\/opt/"\/var\/opt/g

Copy Conent from /opt/ to the new location: /var/opt/

cp -rfa /opt/puppetlabs /var/opt/puppetlabs
rpmrebuild -e puppet-agent

   opens vi/vim, run the regular expression... and write close the change ( !wq ).

ls -lha /root/rpmbuild/RPMS/x86_64/puppet-agent-1.4.1-1.el7.x86_64.rpm

yum install createrepo
createrepo --database /root/customrpms

File: sig-atomic-buildscripts/puppetlabs-pc1.repo

[puppetlabs-pc1]
name=Puppet Labs PC1 Repository el 7 - $basearch
#baseurl=http://yum.puppetlabs.com/el/7/PC1/$basearch
baseurl=http://192.168.99.102:6060
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabs-PC1

Start Custom Yum repository:

• http-server: ( npm install -g http-server )

cd /root/customrpms/
http-server -p 6060

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
Tobias

[tobiashochguertel]

I hope this will help others to workaround until there is an solution, thanks to @cgwalters and @copumpkin

Rebuild puppet-agent rpm with new path

Regular Expression to change /opt/ -to-> /var/opt:

:%s/"\/opt/"\/var\/opt/g

Copy Conent from /opt/ to the new location: /var/opt/

cp -rfa /opt/puppetlabs /var/opt/puppetlabs
rpmrebuild -e puppet-agent

   opens vi/vim, run the regular expression... and write close the change ( !wq ).

ls -lha /root/rpmbuild/RPMS/x86_64/puppet-agent-1.4.1-1.el7.x86_64.rpm

yum install createrepo
createrepo --database /root/customrpms

File: sig-atomic-buildscripts/puppetlabs-pc1.repo

[puppetlabs-pc1]
name=Puppet Labs PC1 Repository el 7 - $basearch
#baseurl=http://yum.puppetlabs.com/el/7/PC1/$basearch
baseurl=http://192.168.99.102:6060
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabs-PC1

Start Custom Yum repository:

• http-server: ( npm install -g http-server )

cd /root/customrpms/
http-server -p 6060

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
Tobias

[tobiashochguertel]

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 /var/opt/puppetlabs/. With sudo rpm-ostree-toolbox treecompose -c ~/sig-atomic-buildscripts/config.ini --ostreerepo /srv/repo/ -p hochguertel.local and testing the custom ostree via virtualmachine shows me that there something went wrong. /var/opt/puppetlabs and directory structure and even some files are there - but also files are missing, binaries are missing.

Can someone help?

[tobiashochguertel]

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 /var/opt/puppetlabs/. With sudo rpm-ostree-toolbox treecompose -c ~/sig-atomic-buildscripts/config.ini --ostreerepo /srv/repo/ -p hochguertel.local and testing the custom ostree via virtualmachine shows me that there something went wrong. /var/opt/puppetlabs and directory structure and even some files are there - but also files are missing, binaries are missing.

Can someone help?

[tobiashochguertel]

After some research I was able to understand that I have to modify my custom rpm so that is will be located under /usr/ instead /var/. /var stays empty in ostree. After changing the location to /usr/opt things went fine and I was able to get the complete content of the custom rpm on my custom ostree.

I changed the regular expression from above to: :%s/"\/opt/"\/var\/opt/g.

As next I have to add or change the tmpfiles.d file (system.d tmpfiles.d) of puppet-agent rpm (my custom rpm) before rpmrebuild it.

cat <<EOF > /usr/lib/tmpfiles.d/puppet-agent.conf
d /var/run/puppetlabs 0755 root root -
d /tmp/puppetlabs 0755 root root -
d /tmp/puppetlabs/puppet 755 root root -
d /tmp/puppetlabs/puppet/cache 755 root root -
L+ /usr/opt/puppetlabs/puppet/cache - - - - /tmp/puppetlabs/puppet/cache
L+ /opt/puppetlabs - - - - /usr/opt/puppetlabs
EOF

On my testing centos-atomic-host it is now possible to start the puppet-agent systemd service, the original location of /opt/puppetlabs is a symLink to /usr/opt/puppetlabs.

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
Tobias

[tobiashochguertel]

After some research I was able to understand that I have to modify my custom rpm so that is will be located under /usr/ instead /var/. /var stays empty in ostree. After changing the location to /usr/opt things went fine and I was able to get the complete content of the custom rpm on my custom ostree.

I changed the regular expression from above to: :%s/"\/opt/"\/var\/opt/g.

As next I have to add or change the tmpfiles.d file (system.d tmpfiles.d) of puppet-agent rpm (my custom rpm) before rpmrebuild it.

cat <<EOF > /usr/lib/tmpfiles.d/puppet-agent.conf
d /var/run/puppetlabs 0755 root root -
d /tmp/puppetlabs 0755 root root -
d /tmp/puppetlabs/puppet 755 root root -
d /tmp/puppetlabs/puppet/cache 755 root root -
L+ /usr/opt/puppetlabs/puppet/cache - - - - /tmp/puppetlabs/puppet/cache
L+ /opt/puppetlabs - - - - /usr/opt/puppetlabs
EOF

On my testing centos-atomic-host it is now possible to start the puppet-agent systemd service, the original location of /opt/puppetlabs is a symLink to /usr/opt/puppetlabs.

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
Tobias

[cgwalters]

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).

[cgwalters]

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).

[cgwalters]

See also https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-December/msg00026.html

[cgwalters]

See also https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-December/msg00026.html

[cgwalters]

I briefly looked at the Google Chrome case. They do a fair bit in %post, which actually calls into at to work around the inability to import their GPG key at install time. The other fix for this is (for Fedora) to put it in /etc/pki/rpm-gpg where libdnf will auto-import it. (This whole story of 3rd party repos and how they get configured and GPG keys is a mess)

[cgwalters]

I briefly looked at the Google Chrome case. They do a fair bit in %post, which actually calls into at to work around the inability to import their GPG key at install time. The other fix for this is (for Fedora) to put it in /etc/pki/rpm-gpg where libdnf will auto-import it. (This whole story of 3rd party repos and how they get configured and GPG keys is a mess)

[dustymabe]

hit this today with the fwupd package (more specifically fwupdate-efi) :

[root@dhcp137-98 ~]# rpm-ostree install fwupd
...
error: Unpacking fwupdate-efi-8-2.fc26.x86_64: Unsupported path: /boot/efi; See https://github.com/projectatomic/rpm-ostree/issues/233

[dustymabe]

hit this today with the fwupd package (more specifically fwupdate-efi) :

[root@dhcp137-98 ~]# rpm-ostree install fwupd
...
error: Unpacking fwupdate-efi-8-2.fc26.x86_64: Unsupported path: /boot/efi; See https://github.com/projectatomic/rpm-ostree/issues/233

[cgwalters]

Let's move /boot to #853

[cgwalters]

Let's move /boot to #853

[dustymabe]

another example of this is trying to package layer cuda from nvidia. The cuda-license package has files in /usr/local/:

Overlaying... error: Checking out cuda-license-9-0-9.0.176-1.x86_64: openat: No such file or directory

Why don't I see the Unsupported path: message here if I'm using rpm-ostree-client-2017.6-6.atomic.el7.x86_64 which should include that code with the helpful error message?

[dustymabe]

another example of this is trying to package layer cuda from nvidia. The cuda-license package has files in /usr/local/:

Overlaying... error: Checking out cuda-license-9-0-9.0.176-1.x86_64: openat: No such file or directory

Why don't I see the Unsupported path: message here if I'm using rpm-ostree-client-2017.6-6.atomic.el7.x86_64 which should include that code with the helpful error message?

[dustymabe]

Why don't I see the Unsupported path: message

PR to resolve that here: https://github.com/projectatomic/rpm-ostree/pull/1090/files

[dustymabe]

Why don't I see the Unsupported path: message

PR to resolve that here: https://github.com/projectatomic/rpm-ostree/pull/1090/files

[miabbott]

Hit this today with the riot Copr:

https://copr.fedorainfracloud.org/coprs/taw/Riot/

$ sudo rpm-ostree install riot             
Checking out tree e824ec1... done                   
Enabled rpm-md repositories: updates fedora rpmfusion-nonfree rpmfusion-nonfree-updates rpmfusion-free rpmfusion-free-updates taw-Riot                                                                             
rpm-md repo 'updates' (cached); generated: 2017-12-03 17:30:49                                           

rpm-md repo 'fedora' (cached); generated: 2017-11-05 05:51:47                                            

rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2017-11-13 19:15:57                                 

rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2017-11-27 16:42:42                         

rpm-md repo 'rpmfusion-free' (cached); generated: 2017-11-27 14:03:16                                    

rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2017-11-27 16:33:16                            


Updating metadata for 'taw-Riot': [=========================] 100%
rpm-md repo 'taw-Riot'; generated: 2017-12-04 08:08:05                                                   


Importing metadata [======================] 100%
Resolving dependencies... done                      
Will download: 2 packages (60.3 MB)                 

  Downloading from taw-Riot: [======================] 100%

  Downloading from fedora: [======================] 100%
error: Unpacking riot-0.13.1-0.taw.fc27.x86_64: Unsupported path: /opt/riot; See https://github.com/projectatomic/rpm-ostree/issues/233

[miabbott]

Hit this today with the riot Copr:

https://copr.fedorainfracloud.org/coprs/taw/Riot/

$ sudo rpm-ostree install riot             
Checking out tree e824ec1... done                   
Enabled rpm-md repositories: updates fedora rpmfusion-nonfree rpmfusion-nonfree-updates rpmfusion-free rpmfusion-free-updates taw-Riot                                                                             
rpm-md repo 'updates' (cached); generated: 2017-12-03 17:30:49                                           

rpm-md repo 'fedora' (cached); generated: 2017-11-05 05:51:47                                            

rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2017-11-13 19:15:57                                 

rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2017-11-27 16:42:42                         

rpm-md repo 'rpmfusion-free' (cached); generated: 2017-11-27 14:03:16                                    

rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2017-11-27 16:33:16                            


Updating metadata for 'taw-Riot': [=========================] 100%
rpm-md repo 'taw-Riot'; generated: 2017-12-04 08:08:05                                                   


Importing metadata [======================] 100%
Resolving dependencies... done                      
Will download: 2 packages (60.3 MB)                 

  Downloading from taw-Riot: [======================] 100%

  Downloading from fedora: [======================] 100%
error: Unpacking riot-0.13.1-0.taw.fc27.x86_64: Unsupported path: /opt/riot; See https://github.com/projectatomic/rpm-ostree/issues/233

[cgwalters]

I'm using the flatpak for it from flathub myself.

[cgwalters]

I'm using the flatpak for it from flathub myself.

[miabbott]

I'm using the flatpak for it from flathub myself.

Of course! That wasn't immediately obvious in any of the docs I found. :(

[miabbott]

I'm using the flatpak for it from flathub myself.

Of course! That wasn't immediately obvious in any of the docs I found. :(

[dustymabe]

Fixing (or working around) this problem sooner than later will be advantageous to us, especially if more people start using atomic workstation.

[dustymabe]

Fixing (or working around) this problem sooner than later will be advantageous to us, especially if more people start using atomic workstation.

[jlebon]

Yeah, it shouldn't be too hard now to go the translate path + symlink approach. Will try to take a look at this soon!

[jlebon]

Yeah, it shouldn't be too hard now to go the translate path + symlink approach. Will try to take a look at this soon!

[cgwalters]

Yeah, it shouldn't be too hard now to go the translate path + symlink approach

But how will we deal with apps that actually have data in /opt? I'm not sure this should be on top of our list, the complexity seems really high versus the gain, since we want people to containerize most of these apps anyways right? (Puppet is perhaps an exception)

[cgwalters]

Yeah, it shouldn't be too hard now to go the translate path + symlink approach

But how will we deal with apps that actually have data in /opt? I'm not sure this should be on top of our list, the complexity seems really high versus the gain, since we want people to containerize most of these apps anyways right? (Puppet is perhaps an exception)

[jlebon]

But how will we deal with apps that actually have data in /opt?

Yeah, those will just error out at runtime, I guess. Depending on how common it is in those RPMs to only have code in /opt but still keep data in /var, it might still be worth doing the easy thing, no? E.g. it seems like this should fix Chrome at least, right?

[jlebon]

But how will we deal with apps that actually have data in /opt?

Yeah, those will just error out at runtime, I guess. Depending on how common it is in those RPMs to only have code in /opt but still keep data in /var, it might still be worth doing the easy thing, no? E.g. it seems like this should fix Chrome at least, right?

[jlebon]

(But true, you'd want to use flatpak there -- although it doesn't seem like there's an official one out yet).

[jlebon]

(But true, you'd want to use flatpak there -- although it doesn't seem like there's an official one out yet).

[cgwalters]

My feeling here is that there's two types of /opt things - those which put content into /usr (let's call this "mixed") and those that don't.

For Chrome, which is mixed, I'll reiterate that I think the most sustainable path is to get them to change their RPM upstream to move into e.g. /usr/lib/google/chrome or whatever. /opt isn't buying them much here as far as avoiding clashes.

For the "non-mixed" i.e. pure /opt RPMs...it would be a lot of work but we could probably make those "non-transactional". The problem is maintaining coherence for the rpmdb. Maybe what we could do is have /opt/rpm-ostree/rpmdb, and basically union that data with the final rpmdb in the tree whenever the host tree changes. And changes to opt-RPMs always behave traditionally, i.e. updates to them are live and not offline? Or perhaps for offline updates (i.e. the rpm-ostree default), we do updates to them at shutdown time (ugh)?

[cgwalters]

My feeling here is that there's two types of /opt things - those which put content into /usr (let's call this "mixed") and those that don't.

For Chrome, which is mixed, I'll reiterate that I think the most sustainable path is to get them to change their RPM upstream to move into e.g. /usr/lib/google/chrome or whatever. /opt isn't buying them much here as far as avoiding clashes.

For the "non-mixed" i.e. pure /opt RPMs...it would be a lot of work but we could probably make those "non-transactional". The problem is maintaining coherence for the rpmdb. Maybe what we could do is have /opt/rpm-ostree/rpmdb, and basically union that data with the final rpmdb in the tree whenever the host tree changes. And changes to opt-RPMs always behave traditionally, i.e. updates to them are live and not offline? Or perhaps for offline updates (i.e. the rpm-ostree default), we do updates to them at shutdown time (ugh)?

[cgwalters]

Hm, no that wouldn't quite work, since at the moment rollback in order to be ultra-reliable is a simple swap of bootloader entries. We'd have to change it to re-union the DB. Hmm. Probably the most reliable thing would be resynthesizing a unioned rpmdb at boot time. Or of course drive db unioning into librpm. Or try to detect non-coherence dynamically. And all of this would not play nicely with ostree admin unlock + rpm -Uvh some-pure-opt.rpm since the overlay wouldn't cover /opt, but would cover /usr where we store the db...

[cgwalters]

Hm, no that wouldn't quite work, since at the moment rollback in order to be ultra-reliable is a simple swap of bootloader entries. We'd have to change it to re-union the DB. Hmm. Probably the most reliable thing would be resynthesizing a unioned rpmdb at boot time. Or of course drive db unioning into librpm. Or try to detect non-coherence dynamically. And all of this would not play nicely with ostree admin unlock + rpm -Uvh some-pure-opt.rpm since the overlay wouldn't cover /opt, but would cover /usr where we store the db...

[dustymabe]

let's take a step back I definitely don't want complicated uniondb without it being necessary. Is it possible to allow someone to layer packages into /opt/ (using package layering), but if they do this they are giving up write access to /opt/. i.e. if you install this package via package layering you give up write access to /opt/ (y/n). It would also require that /opt/ be empty before the package layering operation.

If this is a possible solution, then what about the same thing for /usr/local?

[dustymabe]

let's take a step back I definitely don't want complicated uniondb without it being necessary. Is it possible to allow someone to layer packages into /opt/ (using package layering), but if they do this they are giving up write access to /opt/. i.e. if you install this package via package layering you give up write access to /opt/ (y/n). It would also require that /opt/ be empty before the package layering operation.

If this is a possible solution, then what about the same thing for /usr/local?

[dustymabe]

we could even implement this as two operations:

rpm-ostree seal /opt/  --> requires $dir to be empty
rpm-ostree install rpm-with-opt-contents.rpm

If they change their mind later:

rpm-ostree uninstall rpm-with-opt-contents.rpm
rpm-ostree unseal /opt/

[dustymabe]

we could even implement this as two operations:

rpm-ostree seal /opt/  --> requires $dir to be empty
rpm-ostree install rpm-with-opt-contents.rpm

If they change their mind later:

rpm-ostree uninstall rpm-with-opt-contents.rpm
rpm-ostree unseal /opt/

[cgwalters]

If we were going to go that way I think it'd be simpler to have the "seal" operation be:

rmdir /var/opt && ln -sfr /usr/opt /var/opt

or so. But the hard part is investigating whether this is actually compatible with the RPMs that install in /opt.

[cgwalters]

If we were going to go that way I think it'd be simpler to have the "seal" operation be:

rmdir /var/opt && ln -sfr /usr/opt /var/opt

or so. But the hard part is investigating whether this is actually compatible with the RPMs that install in /opt.

[dustymabe]

rmdir /var/opt && ln -sfr /usr/opt /var/opt

Sounds easy, would that satisfy the requirements? Is there a way that we could make this a 'generic solution' such that other top level directories could be included or excluded from the tree? If say another company had some top level directory they used that was specific to them /abccompany/ and they wanted to install rpm that owned files there, could we allow them to create this directory and include it in the tree with a 'seal' operation.

or so. But the hard part is investigating whether this is actually compatible with the RPMs that install in /opt.

Only one way to find out: rpm-ostree ex :)

[dustymabe]

rmdir /var/opt && ln -sfr /usr/opt /var/opt

Sounds easy, would that satisfy the requirements? Is there a way that we could make this a 'generic solution' such that other top level directories could be included or excluded from the tree? If say another company had some top level directory they used that was specific to them /abccompany/ and they wanted to install rpm that owned files there, could we allow them to create this directory and include it in the tree with a 'seal' operation.

or so. But the hard part is investigating whether this is actually compatible with the RPMs that install in /opt.

Only one way to find out: rpm-ostree ex :)

[dustymabe]

Another example is nessus:

error: Unsupported path: /opt/nessus_agent;

reported by southsys in IRC

[dustymabe]

Another example is nessus:

error: Unsupported path: /opt/nessus_agent;

reported by southsys in IRC

[matthiasclasen]

would be good to figure some fix for the existing chrome rpm, indeed

[matthiasclasen]

would be good to figure some fix for the existing chrome rpm, indeed

[mklvr]

SpiderOak ONE is also affected by this (one Project Atomic Workstation):
error: Unsupported path: /opt/SpiderOakONE; See https://github.com/projectatomic/rpm-ostree/issues/233

[mklvr]

SpiderOak ONE is also affected by this (one Project Atomic Workstation):
error: Unsupported path: /opt/SpiderOakONE; See https://github.com/projectatomic/rpm-ostree/issues/233

[dustymabe]

Random Idea:

Another possibility would be to have a readonly /usr/opt and a read/write /opt/. Files that were owned by rpms would get placed into both, but the rpm owned files in /opt/ maybe have the immutable bit set (chattr +i) and an ostree fsck would verify the files had not changed.

[dustymabe]

Random Idea:

Another possibility would be to have a readonly /usr/opt and a read/write /opt/. Files that were owned by rpms would get placed into both, but the rpm owned files in /opt/ maybe have the immutable bit set (chattr +i) and an ostree fsck would verify the files had not changed.

[haecker-felix]

Another example is citrix receiver.
error: Unsupported path: /opt/Citrix

[haecker-felix]

Another example is citrix receiver.
error: Unsupported path: /opt/Citrix

[dragon788]

The Keybase.io Fedora client also attempts to install into /opt/keybase/Keybase and errors out.

[dragon788]

The Keybase.io Fedora client also attempts to install into /opt/keybase/Keybase and errors out.