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鈥檒l 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

Open
cgwalters opened this Issue Mar 14, 2016 · 49 comments

Comments

Projects
None yet
@cgwalters
Member

cgwalters commented Mar 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Mar 29, 2016

Contributor

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

Contributor

copumpkin commented Mar 29, 2016

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

@cgwalters cgwalters changed the title from Determine support path for RPMs that install into `/opt` to Determine support path for RPMs that install into `/opt`, `/usr/local` etc Apr 1, 2016

@copumpkin

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2016

Contributor

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

Contributor

copumpkin commented Apr 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2016

Contributor

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

Contributor

copumpkin commented Apr 4, 2016

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

@cgwalters

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Apr 4, 2016

Member

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

Member

cgwalters commented Apr 4, 2016

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

@copumpkin

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2016

Contributor

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

Contributor

copumpkin commented Apr 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Apr 4, 2016

Member

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.

Member

cgwalters commented Apr 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2016

Contributor

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

Contributor

copumpkin commented Apr 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Apr 4, 2016

Member

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

Member

cgwalters commented Apr 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 4, 2016

Contributor

Oh, excellent, thanks!

Contributor

copumpkin commented Apr 4, 2016

Oh, excellent, thanks!

@copumpkin

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 12, 2016

Contributor

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.

Contributor

copumpkin commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 12, 2016

Contributor

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.

Contributor

copumpkin commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Apr 12, 2016

Member

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.

Member

cgwalters commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 12, 2016

Contributor

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 馃様

Contributor

copumpkin commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 12, 2016

Contributor

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.

Contributor

copumpkin commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Apr 12, 2016

Member

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.

Member

cgwalters commented Apr 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@copumpkin

copumpkin Apr 21, 2016

Contributor

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.

Contributor

copumpkin commented Apr 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tobiashochguertel

tobiashochguertel Apr 24, 2016

@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 commented Apr 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@tobiashochguertel

tobiashochguertel Apr 24, 2016

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 commented Apr 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tobiashochguertel

tobiashochguertel Apr 25, 2016

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 commented Apr 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tobiashochguertel

tobiashochguertel Apr 26, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters May 28, 2016

Member

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

Member

cgwalters commented May 28, 2016

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 added a commit to cgwalters/rpm-ostree that referenced this issue Feb 13, 2017

importer: Error importing RPMs which install to /opt (outside of /usr)
See projectatomic#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.

rh-atomic-bot added a commit that referenced this issue Feb 13, 2017

importer: Error importing RPMs which install to /opt (outside of /usr)
See #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.

Closes: #624
Approved by: jlebon

rh-atomic-bot added a commit that referenced this issue Feb 13, 2017

importer: Error importing RPMs which install to /opt (outside of /usr)
See #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.

Closes: #624
Approved by: jlebon

cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Feb 13, 2017

importer: Error importing RPMs which install to /opt (outside of /usr)
See projectatomic#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.

rh-atomic-bot added a commit that referenced this issue Feb 14, 2017

importer: Error importing RPMs which install to /opt (outside of /usr)
See #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.

Closes: #624
Approved by: jlebon
@cgwalters

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters May 1, 2017

Member

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)

Member

cgwalters commented May 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Jun 28, 2017

Collaborator

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
Collaborator

dustymabe commented Jun 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Jun 28, 2017

Member

Let's move /boot to #853

Member

cgwalters commented Jun 28, 2017

Let's move /boot to #853

@dustymabe

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Nov 7, 2017

Collaborator

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?

Collaborator

dustymabe commented Nov 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Nov 7, 2017

Collaborator

Why don't I see the Unsupported path: message

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

Collaborator

dustymabe commented Nov 7, 2017

Why don't I see the Unsupported path: message

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

@miabbott

This comment has been minimized.

Show comment
Hide comment
@miabbott

miabbott Dec 4, 2017

Contributor

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
Contributor

miabbott commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Dec 4, 2017

Member

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

Member

cgwalters commented Dec 4, 2017

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

@miabbott

This comment has been minimized.

Show comment
Hide comment
@miabbott

miabbott Dec 4, 2017

Contributor

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

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

Contributor

miabbott commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Dec 4, 2017

Collaborator

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

Collaborator

dustymabe commented Dec 4, 2017

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

@jlebon

This comment has been minimized.

Show comment
Hide comment
@jlebon

jlebon Dec 4, 2017

Member

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

Member

jlebon commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Dec 4, 2017

Member

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)

Member

cgwalters commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jlebon

jlebon Dec 4, 2017

Member

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?

Member

jlebon commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jlebon

jlebon Dec 4, 2017

Member

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

Member

jlebon commented Dec 4, 2017

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

@cgwalters

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Dec 7, 2017

Member

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

Member

cgwalters commented Dec 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Dec 7, 2017

Member

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

Member

cgwalters commented Dec 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Dec 7, 2017

Collaborator

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?

Collaborator

dustymabe commented Dec 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Dec 7, 2017

Collaborator

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/
Collaborator

dustymabe commented Dec 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Dec 12, 2017

Member

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.

Member

cgwalters commented Dec 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Dec 12, 2017

Collaborator

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

Collaborator

dustymabe commented Dec 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Feb 6, 2018

Collaborator

Another example is nessus:

error: Unsupported path: /opt/nessus_agent;

reported by southsys in IRC

Collaborator

dustymabe commented Feb 6, 2018

Another example is nessus:

error: Unsupported path: /opt/nessus_agent;

reported by southsys in IRC

@matthiasclasen

This comment has been minimized.

Show comment
Hide comment
@matthiasclasen

matthiasclasen Feb 9, 2018

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

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

@mklvr

This comment has been minimized.

Show comment
Hide comment
@mklvr

mklvr Feb 11, 2018

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 commented Feb 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Feb 13, 2018

Collaborator

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.

Collaborator

dustymabe commented Feb 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@haecker-felix

haecker-felix Feb 25, 2018

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

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

@dragon788

This comment has been minimized.

Show comment
Hide comment
@dragon788

dragon788 Mar 16, 2018

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

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

@GNOME-IS-LIFE

This comment has been minimized.

Show comment
Hide comment
@GNOME-IS-LIFE

GNOME-IS-LIFE Mar 29, 2018

yup, experiencing this problem with WPS office, Google chrome, and the Hangouts plugin on Fedora Atomic Workstation. Would manually extracting the RPM and copying the files to the directories (such as to /opt) work?

yup, experiencing this problem with WPS office, Google chrome, and the Hangouts plugin on Fedora Atomic Workstation. Would manually extracting the RPM and copying the files to the directories (such as to /opt) work?

@grantcurell

This comment has been minimized.

Show comment
Hide comment
@grantcurell

grantcurell May 8, 2018

Any traction on this? If not, is there something I can help with?

Any traction on this? If not, is there something I can help with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment