Users on OpenVZ/LXC need non-snap instructions

[alexzorin]

I think we might want to carve something out in the instruction generator to account for OpenVZ and LXC Linux environments.

Both technologies get used for "container-based VMs". I think the only difference is that OpenVZ is out-of-tree and predates LXC by quite some time. But I do know that LXC servers are quite popular thanks to Proxmox. I am a heavy user myself because of the low overhead compared to KVM, great when you're the only tenant on the physical host. They are also common in the "low end VPS" scene.

Unfortunately snaps do not work at all because some required syscalls are blocked by the host.

The problem with the instruction generator right now is that we have fully replaced many instructions with snap and there is no fallback: https://certbot.eff.org/lets-encrypt/ubuntufocal-nginx

Further complicating things, users might have no idea they are running on a container and not a real server. So if we just list LXC/OpenVZ in the dropdown, some users probably won't realize to click it.

@bmw talked in this comment about potentially providing alternate instructions for users who cannot use snaps. If that does happen, it would mean we could add a "Click here if you cannot use snaps" to the instruction generator.

We've had a couple of threads in 2 weeks: https://community.letsencrypt.org/search?q=openvz%20snap

[bmw]

Do you have a suggestion for how our instructions would help users figure out if they can't use snaps?

I've been putting off writing alternate instructions since it's a bit of work and I think/hope most people can use snaps, but we may have to do it sooner rather than later if there are common issues like this.

[alexzorin]

Do you have a suggestion for how our instructions would help users figure out if they can't use snaps?

snapd itself installs successfully. The first sign of trouble is the System does not fully support snapd: cannot mount squashfs image using "squashfs" error that occurs when you try to install a snap.

I think we could just have a short link near the top that says?

Does your system not support snaps?

---

Somewhat related, just reading the snapcraft forums this morning, I realized that snapd itself carves out an exception for container environments.

However, it is quite involved.

1. I had to apt install fuse squashfuse
2. For some reason, /dev/fuse was missing, so I had to mknod -m 666 /dev/fuse c 10 229 (stolen from here)
3. When I finally went to run Certbot, /snap/bin was not in $PATH (related to the way I login to the CT)
4. When I finally went to run Certbot, snap connections was not available in my snap binary, which breaks plugin detection: error: unknown command "connections", see 'snap help'. (I should have done step 5 first)
5. When I went to install the core snap, it complains about udev rules. Managed to make that go away somehow, and finally had a working Certbot snap.

So it probably not worth offering to container users unless snapd changes substantially to make this easier.

[bmw]

Especially since the error message from snapd is so clear, I think that suggestion works!

Thanks for digging into how to make snapd work in those environments. If this becomes a common problem, we could potentially submit PRs to snapd ourselves to improve that process.

[Balls0fSteel]

I would like to just chime in that the instructions posted by alexzorin did not work on Proxmox for me. It would be great if the main website would just link https://certbot.eff.org/docs/install.html this page. It took me a while even with Google to find the deb package. (The auto installer script also failed on Proxmox + Ubuntu 20.04 CT.)

[sorcer1122]

It took me a while even with Google to find the deb package. (The auto installer script also failed on Proxmox + Ubuntu 20.04 CT.)

Do you mind sharing the link to this deb package?

[alexzorin]

The pip instructions have been available for quite some time, closing.