Installation advice in README doesn't necessarily get a stable release

[tlhackque]

trafficstars

As noted in #702: The README's "1 line install" advice instructs the user to get (only) getssl from HEAD, even if it's not a stable release.

I don't have a simple 1-line equivalent to get the file from latest.

I'd like to simply recommend going to https://github.com/srvrco/getssl/releases, getting the tarball & executing a make install.

But as that's a major change, and some might think it inconvenient, it should be discussed first.

The 1-line install is convenient, but it omits the support scripts for cpanel and dns. It also grabs the HEAD of master, potentially before the regression tests pass. Or while other changes are in process. This can result in issues with the users, that can't be reproduced.

I don't think these are worth the convenience of the initial install.

An alternative might be to have a bootstrapping script that gets the latest release. That's one more thing to maintain, though. Something like this is as close to "1-line" as I can easily get - I suppose it could go in the README to be copied/pasted:

Thoughts?

#!/bin/bash
mkdir getssl-install && \
cd getssl-install && \
curl -L --no-progress-meter \
    "$(curl  --no-progress-meter -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/srvrco/getssl/releases/latest | grep '"tarball_url"' | sed -e's/^.*: "\([^"]*\)".*/\1/')" | \
    tar --strip-components 1 -xz && make install && cd .. && rm -rf getssl-install

[pfdint]

I am one of the people who was convinced to use getssl on the spot because it was literally 1 file. And literally 1 file with a command I could write from memory. It's a critical difference in the character of the project that lets it stand out against its competitor certbot. Yes eventually as I learned to use it I had to download/create more files for dns but that's fine, the frog was boiled slowly. So there's way more value to it than merely convenience, it's the front door of the establishment, the cover of the book on which nearly all sales are made.

A good point though is that the actual file retrieved may not be stable. The simplest and most in-character solution I can think of using only 1 repository is to have a getssl_unstable file which is only copied over to the getssh file when considered stable. Or to have the readme's command updated often to point to a particular commit of the getssh.

[tlhackque]

I wouldn't describe certbot as a competitor; it's an alternative. getssl's main advantage is that it only requires bash (and a few commands); certbot requires Python, which in turn has a lot of dependencies. Python is more widely available than it was, but apparently there are hosting providers that don't provide it, or don't provide the right version, or don't support snaps/containers, or charge extra for one of these. bash is everywhere, and getssl is tested with many versions. And certbot installer and authenticator plugins are somewhat less approachable.

I agree that keeping getssl approachable is important. I don't think that "it's just one file" is true in the majority of cases; DNS authenticaion and/or CPanel seem to be popular. Only DNS can support wildcard certificates. And http generally requires setting up some alternative access -- FTP, SSH, DAV, etc. Not bundling the support scripts is not only inconvenient, it creates the opportunity for version skew. I think it works against the goal of approachability.

I'd like to say that the "quick install" also omits the README - but the current Makefile also doesn't install it. We probably ought to fix that, and perhaps generate & distribute a man page from the markdown. (e.g., with ronn or similar) But that's another issue.

With a bootstrapping script along the lines of the one above, the extra work to provide a stable and complete version is hidden.

Either we ask the user to copy and paste the few lines, or we might provide an installer, in which case the 1 command in the README becomes:

curl -s https://raw.githubusercontent.com/srvrco/getssl/install/install_getssl >install_getssl && chmod 700 install_getssl && ./install_getssl && rm ./install_getssl

Where install is a fork that holds the current (and very stable) install_getssl. An advantage of this approach is that we could provide better error messages if things go wrong.

Once installed, getssl can keep itself up-to-date. There's an open PR that teaches getssl to update itself from the latest stable release.

[timkimber]

I've updated the README to use the latest tag instead of master so it downloads the latest release instead of the head version. Agreed that an installation script is probably needed for people who don't want to clone the git repo but need the dns and other scripts