I never tried Docker (looking around now), but the approach is extremely dirty for a few reasons.
1. Process supervision should be handled in Docker (or something that is designed to do supervision), not in the `while true` loop. Idea on hanging on *.log files is terrible. Maybe there is a reason to stop the container when application stops?
2. There must be a better way to handle docker logs of multiple programs. If not, run both instances in different containers.
3. The thing serves configuration files to arbitrary clients that ask for them. It doesn't even log multiple downloads of the same key (though serves the private keys over SSL, which makes it hilarious on the purpose of SSL here).
Point 3 is openvpn specific and can be acceptable for example (though I am still lost why bother with SSL). However, points 1 and 2 show how to seriously misuse Docker. Either Docker or the setup is flawed (I suspect the latter).
Please do not take this article as an example how to do things in Docker. There must be better way, in more or less every step.
1. Process supervision is kept very simple, because there are many other tutorials and demos out there using Supervisor and other systems. I'd love to know what is inherently wrong with using `while true` and hanging on logs. Personally, replacing Supervisor (or monit, or god, or $yourfavoriteprocessmonitor) with 3 lines of shell script is fine with me, especially as the focus is to show that Docker can now run OpenVPN.
2. Handle multiple log streams: indeed! I considered running two separate containers, and the only reason why I didn't do it is to simplify the setup process. I also explored the other option (using two separate containers for TCP and UDP connections), and it works almost the same; it looks like:
docker run openvpn genkeys
docker run -volumes-from $CID openvpn tcp
docker run -volumes-from $CID openvpn udp
docker run -volumes-from $CID openvpn serveconfig
Hopefully, the way the project is laid out makes it fairly trivial for someone to change it to run each openvpn process in its own container.
3. Here again, it's a (not-so-good) trade-off. In many cases, you need something simple and straightforward to move the configuration file to the device, e.g. when the device is a phone or tablet. Downloading a combined file over HTTPS is the simplest solution I found (even if in the Android case, it is slightly crippled by the Download Manager bug). It uses SSL to prevent eavesdropping. It protects against a system which would passively record e.g. WiFi traffic. It doesn't protect against a system which would actively detect such a transfer, and immediately initiate the same transfer, before you have the opportunity to stop the `serveconfig` container. I considered adding some HTTP basic auth, but that would have required a "real" HTTP server in `serveconfig` (or to hack further with socat, but I'm already quite ashamed of the current hack, TBH).
I agree that the setup can be greatly improved (what can't?), but I disagree with "there must be better way in every step". This is certainly not the setup that you want if you have a large number of clients, or if you are in an extremely compromised network (then again, it's only a concern during key exchange), but I don't see why it can't be acceptable for 99% of the personal users out there.
Comments
I never tried Docker (looking around now), but the approach is extremely dirty for a few reasons.
1. Process supervision should be handled in Docker (or something that is designed to do supervision), not in the `while true` loop. Idea on hanging on *.log files is terrible. Maybe there is a reason to stop the container when application stops?
2. There must be a better way to handle docker logs of multiple programs. If not, run both instances in different containers.
3. The thing serves configuration files to arbitrary clients that ask for them. It doesn't even log multiple downloads of the same key (though serves the private keys over SSL, which makes it hilarious on the purpose of SSL here).
Point 3 is openvpn specific and can be acceptable for example (though I am still lost why bother with SSL). However, points 1 and 2 show how to seriously misuse Docker. Either Docker or the setup is flawed (I suspect the latter).
Please do not take this article as an example how to do things in Docker. There must be better way, in more or less every step.
Thanks for your feedback!
Agreed, the approach is far from perfect.
1. Process supervision is kept very simple, because there are many other tutorials and demos out there using Supervisor and other systems. I'd love to know what is inherently wrong with using `while true` and hanging on logs. Personally, replacing Supervisor (or monit, or god, or $yourfavoriteprocessmonitor) with 3 lines of shell script is fine with me, especially as the focus is to show that Docker can now run OpenVPN.
2. Handle multiple log streams: indeed! I considered running two separate containers, and the only reason why I didn't do it is to simplify the setup process. I also explored the other option (using two separate containers for TCP and UDP connections), and it works almost the same; it looks like:
docker run openvpn genkeys docker run -volumes-from $CID openvpn tcp docker run -volumes-from $CID openvpn udp docker run -volumes-from $CID openvpn serveconfig
Hopefully, the way the project is laid out makes it fairly trivial for someone to change it to run each openvpn process in its own container.
3. Here again, it's a (not-so-good) trade-off. In many cases, you need something simple and straightforward to move the configuration file to the device, e.g. when the device is a phone or tablet. Downloading a combined file over HTTPS is the simplest solution I found (even if in the Android case, it is slightly crippled by the Download Manager bug). It uses SSL to prevent eavesdropping. It protects against a system which would passively record e.g. WiFi traffic. It doesn't protect against a system which would actively detect such a transfer, and immediately initiate the same transfer, before you have the opportunity to stop the `serveconfig` container. I considered adding some HTTP basic auth, but that would have required a "real" HTTP server in `serveconfig` (or to hack further with socat, but I'm already quite ashamed of the current hack, TBH).
I agree that the setup can be greatly improved (what can't?), but I disagree with "there must be better way in every step". This is certainly not the setup that you want if you have a large number of clients, or if you are in an extremely compromised network (then again, it's only a concern during key exchange), but I don't see why it can't be acceptable for 99% of the personal users out there.