This is mainly a food for thought and see if we can try and get it done if possible and if its acceptable.
For any providers, we can't write a configure-openvpn.sh script for that auto-pulls them. Should we zip up their OVPN files and write a mock configure-openvpn.sh for that mostly just unzips that single providers configs?
What I had in mind would be basically the above stated, and have a list of all the providers currently supported by this awesome project and more or less just run through that list and make the changes. Seek assistance from the community, that if anyone with provider "X" for their VPN to check whether or not it's possible to auto-pull the configs like pia and/or Vypr.
Thoughts? -- Just trying to slim down this container since I think last I checked there were like 16k + files which is a lot.
Hey @jsloan117 and thanks for starting a conversation on this. I have also been thinking a bit on this and discussed it with @pkishino. Simulating a provider.zip for those that do not have one publicly accessible is a cleaner and more standardized way of doing it - but I'm not sure how far we will be able to standardize this anyways.
We'll have to see if we can make some common script to use for separate providers but for now each provider has its own quirks that makes it more tricky to have a unified solution. Another benefit of not sharing any code between providers is that we can have trusted people for each provider that can manage the provider scripts independently so that a rewrite one place doesn't break them all.
But this is an exciting space with a lot of potential for future simplification, and I guess I'm just leaning towards seeing how it grows first and then clean up later rather than standardizing first. Not that that is what you're proposing exactly, I'm just trying to explain my view.
So... The way forward. What me and @pkishino have generally agreed on is that we can fork this repo. So I'll create a haugene/openvpn-configs or something that only serves as a repository of .ovpn files. Then this project can treat that as an external source and download from there. This separate project would also be easier to delegate responsibility for each provider and we wouldn't "dirty" the main repo with thousands of revisions of config files but rather focus on the core.
We could either just clone the whole openvpn-config repo and use it directly more or less like we do now, or we could use a tool like https://github.com/MinhasKamal/DownGit to download a zip of a specific folder.
Then we would just need to update the list of supported providers to differentiate between the automatically updated and the manual ones. Maybe try to get a volunteer or two per provider to keep them up to date (both for .ovpn files and the scripted version) and maybe set up a CODEOWNER file so that the responsible parties can easier approve and/or merge changes to the providers. https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners
What do you think? Now that 3.x is out there are three main issues on my agenda and it is this (handling configs), rewriting the documentation (lots of the same questions over and over) and finding a better and cleaner way to handle UFW in the container. Fixing this would free up the most time, so should have high priority :+1:
I like this idea a lot and will be more than glad to assist if I can! We'll just have to refine the finer deals when it gets started.
Allright. I think we're off to the races, barely - but I've created a separate repo as discussed and would love it if you joined the development and discussions on how we'll make this work. Closing this issue though so we'll follow up in #1489.
Most helpful comment
Hey @jsloan117 and thanks for starting a conversation on this. I have also been thinking a bit on this and discussed it with @pkishino. Simulating a provider.zip for those that do not have one publicly accessible is a cleaner and more standardized way of doing it - but I'm not sure how far we will be able to standardize this anyways.
We'll have to see if we can make some common script to use for separate providers but for now each provider has its own quirks that makes it more tricky to have a unified solution. Another benefit of not sharing any code between providers is that we can have trusted people for each provider that can manage the provider scripts independently so that a rewrite one place doesn't break them all.
But this is an exciting space with a lot of potential for future simplification, and I guess I'm just leaning towards seeing how it grows first and then clean up later rather than standardizing first. Not that that is what you're proposing exactly, I'm just trying to explain my view.
So... The way forward. What me and @pkishino have generally agreed on is that we can fork this repo. So I'll create a haugene/openvpn-configs or something that only serves as a repository of .ovpn files. Then this project can treat that as an external source and download from there. This separate project would also be easier to delegate responsibility for each provider and we wouldn't "dirty" the main repo with thousands of revisions of config files but rather focus on the core.
We could either just clone the whole openvpn-config repo and use it directly more or less like we do now, or we could use a tool like https://github.com/MinhasKamal/DownGit to download a zip of a specific folder.
Then we would just need to update the list of supported providers to differentiate between the automatically updated and the manual ones. Maybe try to get a volunteer or two per provider to keep them up to date (both for .ovpn files and the scripted version) and maybe set up a CODEOWNER file so that the responsible parties can easier approve and/or merge changes to the providers. https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners
What do you think? Now that 3.x is out there are three main issues on my agenda and it is this (handling configs), rewriting the documentation (lots of the same questions over and over) and finding a better and cleaner way to handle UFW in the container. Fixing this would free up the most time, so should have high priority :+1: