Provide an endpoint that lists the download URL for your latest access server

[thelamer]

From your own upgrade guide:

look up the installation file on our software packages download page on our main website.

At a minimum can we get a json endpoint or key listing from your object storage and parse it ourselves ?

I went down the rabbit hole of hitting the AWS marketplace api for the version information but it is impossible to embed this in a Dockerfile as it requires authentication for rate limiting.

Even better would be real software repos for your debs and rpms on linux , the file structure is not too complex and really just needs proper folders and package references. There are multiple helper packages on both fronts that will work with your current hosting provider as it is just an http endpoint:
https://wiki.debian.org/DebianRepository/Setup

I am trying to ingest your latest version number and properly tag our docker images for LinuxServer.io. Right now we hard code it in the Dockerfile.

[novaflash]

Actually both ideas are on the agenda, but it will be some time before they are implemented. By that I mean, both a fixed endpoint and a repo.

[thelamer]

What about a massive simplification for it's initial implementation?
When you upload a new version update a file in the root storage directory called latest.txt or latest.json that simply contains the version number or the number and a bit of metadata?

[thelamer]

I want to point out that our image has close to 9 million pulls, it may not be the largest install base for this application, but surely it warrants some kind of collaboration.

All I am asking is if it possible to upload a text file that contains "2.6.1" at http://swupdate.openvpn.org/as/latest.txt . When you update, upload a new file with the version number.

Please let me know if something like this would be possible.

[aptalca]

Just to add,

we maintain the docker image: https://hub.docker.com/r/linuxserver/openvpn-as

It has the highest number of pulls among the openvpn-as images on there. We are just trying to implement downstream automation via our jenkins.

Thanks

[novaflash]

It's implemented. Or at least the fixed 'latest' endpoint URL is.

[thelamer]

It's implemented. Or at least the fixed 'latest' endpoint URL is.

Can you elaborate on that ?

Do you have a specific link?

[thelamer]

Nevermind Got it https://openvpn.net/downloads/openvpn-a ... amd_64.deb, cool we can read the 301 redirect and parse the value from there.

Consider this one resolved.

[novaflash]

We're still going to do a repository, as that just makes eminently more sense. But this has been something we've wanted to do for a long time anyways, and now it's there. Glad to have been of assistance.

[aptalca]

@novaflash

Just noticed that the latest url contains "amd_64" as with all previous releases, both latest and versioned. But the versioned urls for 2.7.2 contain "amd64" (previous versions used "amd_64"). This threw our builder off. Can you comment on whether it was an intentional change and we should expect that structure moving forward or it was a simple oversight for this time?

Here are the urls we are seeing:
https://openvpn.net/downloads/openvpn-a ... amd_64.deb
https://swupdate.openvpn.org/as/openvpn ... .amd64.deb
https://swupdate.openvpn.org/as/openvpn ... amd_64.deb

[novaflash]

Sorry about that, but that's how our build system produces it now. So from now on it should be the new format.

[novaflash]

You know what, we talked it over internally and we're going to stick to the old format. Sorry for any inconvenience.

Oh, and a repository is being made at the moment, so in the near future, we will be offering it on a repository. Much better that way.