Make upgrade checks and installations faster/cheaper/better

[tlhackque]

trafficstars

The current upgrade checks are slow, and only upgrade getssl proper, (not the dns_scripts or other_scripts directories). In addition, they check against and fetch master/HEAD - which may not have passed the CI checks.

The checks are slow because they fetch getssl from the code repository, then parse the code to find the version.

A better approach would be for the release process to post a TXT record in a well-known domain that contains the current version of each component. If a suitable domain isn't available, this could even use one of the free dynamic DNS providers. e.g.

version.getssl.duckdns.org TXT "getssl:2.41 godaddy:1.0.3 cpanel: ..."

Then the upgrade check becomes a DNS lookup & parsing the text record. Ideally, the checks for scripts would be restricted to those in use. This may require an extra parameter (e.g. --check-support-scripts=godaddy,nsupdate,freedns), since they are selected in the per-host configuration files.

getssl could still parse the new code for the change history - but only after the TXT record announces a new version.

Since the common case is 'no update is available', each invocation saves: creating a tempfile, fetching getssl, parsing it for the version, and deleting the tempfile.

In addition, the current upgrade check simply fetches the HEAD of the master branch. This may not have passed all tests. If the TXT record were updated only when the tests pass, and the upgrade used the specified version tag for its fetch, this window for the escape of a bad version would be closed.

Installation - instead of just running install on getssl, the upgrade should fetch and use the Makefile (or at least attempt to), since the Makefile knows how to install all the components. If you don't want to require make, the equivalent bash scripting to replace it iin this application s pretty simple.

Finally, note that currently, when a new version is installed, it repeats all the upgrade checks. This is wasteful - when the new version is run, the --nocheck flag should be added to the command and --upgrade removed.

[timkimber]

@tlhackque thanks for these notes, the update process is definitely something that could be improved.

Alternative to using a TXT record to announce the latest version is using the github api to get the current release: https://stackoverflow.com/questions/18995854/how-can-i-use-github-api-to-get-all-tags-or-releases-for-a-project

[tlhackque]

@tlhackque thanks for these notes, the update process is definitely something that could be improved.

Alternative to using a TXT record to announce the latest version is using the github api to get the current release: https://stackoverflow.com/questions/18995854/how-can-i-use-github-api-to-get-all-tags-or-releases-for-a-project

The problem with that is that for the upgrade tests to pass, the tag has to be created. But if the tag is created, it will look like a release...

We could use a "test release" code in the version number/tag, but that's the entrance to a maze of twisty passages. I believe a TXT record is a better - probably optimal - choice.

A TXT record is used by other software for this purpose. It will be cached by the DNS. Even a cache miss is faster than opening a https connection to github and the API exchange of messages necessary to get the tags/releases...

The main drawback is the need for a domain name. Dynamic is "good enough", but a static domain name would certainly look better. Either way, it has good performance, and it allows for versioning the support scripts as well.

The other concern for any method is that it should work for forks. E.g. when I test in my fork, the "latest release" should be that of my fork's repo, not the srvrco repo. With a TXT record, it's pretty easy - add the repo name, as in version.repo.getssl.duckdns.org TXT "getssl:2.41 godaddy:1.0.3 cpanel: ...". The github api obviously does that (with my pending changes to CODE_LOCATION) automagically...