Skip to content
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

Make it easier to link in or bind folders to root directory? #1711

Open
mstewartgallus opened this issue Dec 10, 2018 · 3 comments
Open

Make it easier to link in or bind folders to root directory? #1711

mstewartgallus opened this issue Dec 10, 2018 · 3 comments

Comments

@mstewartgallus
Copy link

mstewartgallus commented Dec 10, 2018

Not sure if this is precisely a project atomic issue or a rpm-ostree issue.
But maybe rpm-ostree can make this slightly easier.

For snap classic one needs to setup a symlink from /snap to/ var/lib/snapd/snap in the root directory but of course the root is readonly.

I made a documentation issue on the snap forums https://forum.snapcraft.io/t/installing-snap-on-fedora/6755/4 but this isn't something rpm-ostree should directly care about I think.

I don't think this is going to be a snap only issue and probably a few other apps will need awkward symlinks like this.

What I'm wondering is if the best way to do this sort of thing is to make a bind mount in the fstab or systemd mount file or if there is an easier way or rpm-ostree can make this sort of thing easier?

Host system details

Provide the output of rpm-ostree status.

State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20181209.0 (2018-12-09T01:05:12Z)
                BaseCommit: ab52579b9965a871e3db1987c6e0a256fecaeb03a3d72df1a8b76baaf2406d8d
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
           LayeredPackages: SDL SDL_image SDL_ttf chromium deja-dup docker emacs libGLU
                            libvirt-daemon-config-network libvirt-daemon-kvm powertop
                            qemu-kvm virt-install virt-manager virt-top virt-viewer

  ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20181209.0 (2018-12-09T01:05:12Z)
                BaseCommit: ab52579b9965a871e3db1987c6e0a256fecaeb03a3d72df1a8b76baaf2406d8d
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
           LayeredPackages: SDL SDL_image SDL_ttf chromium deja-dup docker emacs libGLU
                            libvirt-daemon-kvm powertop qemu-kvm

Expected vs actual behavior

# sudo ln -s /var/lib/snapd/snap /snap
ln: failed to create symbolic link '/snap': Operation not permitted

Expected:

Success!

Would you like to work on the issue?

This is more of a meta or documentation issue of how system administrators are supposed to handle ad-hoc changes like this. Ideally fedora would probably just ship a package snap-classic that installs such a symlink for this specific case but I think other cases like this will probably happen. I know rpm-ostree already has the machinery inside it to merge /etc with /usr/etc and with var.

Not sure what I'm supposed to modify or add a hook to for adding in the ad-hoc change of a symlink. Telling system admins to modify the fstab is okay but a big problem with that is that it is easy to mess up and make the system unbootable (as I did and then had to recover and recovery was annoying because I had to navigate the ostree directory structure.)

@lucab
Copy link
Contributor

lucab commented Dec 11, 2018

For snap classic one needs to setup a symlink from /snap to/ var/lib/snapd/snap in the root directory but of course the root is readonly.

Ideally fedora would probably just ship a package snap-classic that installs such a symlink

That should indeed be it. The OS fs is supposed to be immutable and content provided in a declarative way (i.e. via rpms).
Additionally, bind-mounting won't help as the target path (/snap, in your case) must exist beforehand.

@cgwalters
Copy link
Member

Big picture of course we generally don't want software creating new toplevel directories. Of course both ostree and snap see themselves as "owning" the system and other software is inside it.

There's an old thread that I can't find right now that came up early in Project Atomic where some sysadmins have e.g. NFS mounts at /data or /mycorp or whatever and it would be hard for them to change.

If it's just about creating a mount point, clearly that's fairly harmless. One can just chattr -i / && mkdir -p /snap && mount --bind /var/lib/snap /snap or whatever.

That said today rpm-ostree detects and rejects RPMs defining content outside of /usr basically.

Maybe we could define a special /etc/rootmounts.conf which would be a simple newline-separated list of empty mount points, processed by a systemd unit that runs very early, before even mounts have begun. Ideally we'd mark them chattr +i too, so that they could only be used as a mount point, not to store data.

This would allow sysadmins to make local mount points, and for software like snap to define new toplevel dirs which are redirected under /var (normally).
`

@dustymabe
Copy link
Member

Maybe we could define a special /etc/rootmounts.conf which would be a simple newline-separated list of empty mount points, processed by a systemd unit that runs very early, before even mounts have begun. Ideally we'd mark them chattr +i too, so that they could only be used as a mount point, not to store data.

That would be nice. I think we had the same idea over in #337 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants