It was pointed out that the the installation instructions for certbot for Fedora (e.g.: https://certbot.eff.org/lets-encrypt/fedora-apache) recommend installing snapd and then installing certbot via snap
While this is technically possible, there's a lot of downside here - most particularly that Fedora sysadmins do not have any experience with snap, do not understand the autoupdate mechanisms, do not check logs, etc. And learning how to use snap should not be one of the first steps in setting up a Fedora server.
[I personally also think that it's probably a very good idea to have certbot updates go through the normal package update process, so they can get testing with the Fedora specific apache/nginx configuration, but that's not the main point here. Even if the certbot maintainers would like to avoid system packaging, they can't do that with snap on Fedora and expect to get a decent experience for users.]
I'd suggest that FESCO or someone else in an official Fedora role should reach out, explain that while snap is available in the Fedora repositories, it's not part of the normal system experience and will cause confusion. And say that if there are any problems with the Fedora certbot packages, the Fedora project is more than willing to help address them.
I don't think we should suggest Flatpak as an alternative - it's not designed for the CLI, not designed to run as root, not designed to interact with system configuration files, etc.
I'd suggest that FESCO or someone else in an official Fedora role...
I don't think that's necessary. Feel free to reach to them yourself. If that leads nowhere, we could ask @mattdm to back you up as the FPL.
I agree that we should get them comfortable with and happy to recommend Fedora's system packages, especially because Fedora is a leader in modern crypto policies.
It looks like @nb is the maintainer for certbot -- Nick, would you be interested in opening that conversation?
This also might be something of interest to the Fedora Server SIG — having certbot ready to go in Fedora Server would be a nice feature.
It looks like @nb is the maintainer for certbot
Also @fschwarz
Also, step 6 of the certbot installation instructions is pretty outrageous:
sudo ln -s /snap/bin/certbot /usr/bin/certbot
Come on.
There are alternative instructions for installing the system package here, but they come with a big warning on top, and instruct users to install an obsolete python2 package python2-certbot-apache.
python2-certbot-apache
We have a pretty good relationship with upstream so I think we (Fedora) can talk to them without expecting big problems. However I'm currently extremely time-limited so I can drive this.
(Btw @nb we need to get the Python 3 transition for EPEL 7 going. AFAIK there is an open review request assigned to you.)
It seems upstream told the community that they were transitioning to the snap for official support last year:
The intent seems to be pretty clear here, though it might be based on their experience with the Debian/Ubuntu world where it's pretty difficult to get certbot updates through to users...
certbot
Also, step 6 of the certbot installation instructions is pretty outrageous: sudo ln -s /snap/bin/certbot /usr/bin/certbot Come on.
This doesn't even work, since /snap doesn't exist on Fedora systems. I never permitted it for snapd in Fedora.
/snap
🤦
I don't have any problem with them preferring to distribute their own packaging as snap, or however else. However, we need a Fedora-native version that just works, and for people to feel like they can trust that — without getting FUD from the upstream about how distro packaging is probably broken.
The announcements last year don't really register, because, sure, whatever, package as a snap. I think we should be able to get equal billing, though!
Perhaps we can start with this, since it's something we can concretely point out to EFF as a broken/untested step in their installation instructions. (Where do snaps get installed in Fedora?)
Even if /snap existed, attempting to modify under /usr is also not going to work on Fedora CoreOS, which should receive equal consideration as it's designed specifically for cloud servers.
I'll talk to @bmw again.
I talked to him when I noticed the patch changing the docs to recommend snaps. They seem to be doing this because of their experiences with Debian and Ubuntu having older versions, whereas in Fedora, we keep our packages up to date. I tried explaining to him that snapd is not commonly used in Fedora, and that people would really prefer knowing that the packages are available from the normal repositories.
I'll see what he says, if that doesn't work, maybe @mattdm can open a discussion w/him.
Anything left for FESCo to do here?
This doesn't even work, since /snap doesn't exist on Fedora systems. I never permitted it for snapd in Fedora. Perhaps we can start with this, since it's something we can concretely point out to EFF as a broken/untested step in their installation instructions. (Where do snaps get installed in Fedora?)
The path is /var/lib/snapd/snap/bin on Fedora.
/var/lib/snapd/snap/bin
Closing this, feel free to reopen if needed
Metadata Update from @cverna: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
FWIW, the current state is that they're planning to remove the scary warning, and possibly all discussion of different ways to install other than their recommended one. I'm still trying to talk them into actually ... trusting us to do a good job.
Metadata Update from @ngompa: - Issue assigned to mattdm
Will they fix their broken instructions? There are at least two problems:
@mattdm how are things going? I see their installation instructions are still broken.
Some Progress. :)
The main concerns are around EPEL packaging, where it's hard to keep things up to date. Podman / docker could be an answer, but then it's more complicated for the certbot plugins to interact with other applications.
At least with EPEL 8, it seems to be tracking Fedora aggressively, so that should be okay?
Login to comment on this ticket.