Open Aubermean opened 2 months ago
github-actions[bot]
commented
2 months ago @qdm12 is more or less the only maintainer of this project and works on it in his free time. Please:
qdm12
commented
2 months ago Which route are you using to (re)start wireguard through the control server? Also can you share some logs, for example in the latest image to see how it misbehaves? Thanks!
Aubermean
commented
2 months ago Hi Quentin, latest behaves the same as log above, but attaching full log using latest for your reference. v1 is generally quite an (ahem) 'anti-pattern' API, but also very useful! v2 one day would be great. <3
> curl -X PUT http://localhost:8005/v1/openvpn/status -H "Content-Type: application/json" -d '{"status": "stopped"}'
{"outcome":"stopped"}
> curl -X PUT http://localhost:8005/v1/openvpn/status -H "Content-Type: application/json" -d '{"status": "running"}'
{"outcome":"crashed"}The documentation was a bit wrong, this is fixed in https://github.com/qdm12/gluetun-wiki/commit/4a0075784796908ad13f316225643ee8bd06dc0e
There are routes defined in the code but not documented, because they are subject to change without notice (notably #2238):
/v1/vpn/status (GET and PUT) which works for both wireguard and openvpn/v1/vpn/settings (GET and PUT) which works for both wireguard and openvpnThese are likely to stay, but default no-access-without-user-defined-authentication might be set on them soon, and the settings JSON object might change in the future, as long as these routes are not documented still. Once it's documented it will stay retro-compatible.
Aubermean
commented
2 months ago Hi, so the endpoint was renamed from /v1/openvpn to /v1/vpn?
Since you made the wise choice of starting off with api versioning, if you change the API it would really make sense to use v2 and leave the old endpoints so things don't break. Otherwise I have to integrate testing on my side to make sure new releases don't break the API client library I have written.
Also #2238 doesn't make sense I think there is a typo?
github-actions[bot]
commented
2 months ago Closed issues are NOT monitored, so commenting here is likely to be not seen. If you think this is still unresolved and have more information to bring, please create another issue.
This is an automated comment setup because @qdm12 is the sole maintainer of this project which became too popular to monitor issues closed.
joejose97
commented
2 months ago In spirit of easier maintainability, asking for backwards compatibility for undocumented api is a bit much don't you think? @Aubermean I think you should have a test suite on your end to make sure your needs are served well.
Aubermean
commented
2 months ago In spirit of easier maintainability, asking for backwards compatibility for undocumented api is a bit much don't you think? @Aubermean I think you should have a test suite on your end to make sure your needs are served well.
You are mistaken, the API has never been undocumented. The API /v1/ had its endpoints changed completely and silently and the documentation was not updated.
Speaking of easier maintainabilitiy, the solution is definitely not everyone having 'a test suite on their end'. The solution is:
Is this urgent?
Yes
Host OS
No response
CPU arch
aarch64
VPN service provider
Custom
What are you using to run the container
docker-compose
What is the version of Gluetun
2024-03-07T12:32:25.391Z (commit 3254fc8)
What's the problem 🤔
Using the Control Server, trying to 'start' a wireguard server results in some bug whereby it switches over to openvpn and the container needs restarting.
This version works: 2024-03-07T12:32:25.391Z (commit 3254fc8)
the latest, v3.39, v3.38, v3.37 tags do not work.
I don't use OpenVPN, I never have. The commit tag above works fine, this log I am adding is from the latest versions so you can see it decides to switch to openvpn after i stop-start via control server.
Share your logs (at least 10 lines)
Share your configuration