Open ghost opened 6 years ago
subzero79
commented
6 years ago Container settings are persistent across restarts (containers) and host reboot. So I don’t know is by restart you mean something else, maybe modify?
Can you give more details on the vpn container?
I see maybe a problem by using two —net switches, could be issue. I would have to test that.
ghost
commented
6 years ago Thanks for the fast response. My settings (of the application container using the vpn network container) seem to change when restarting (or are also visible when i use "modify")
Details on the vpn container:
I use this image https://hub.docker.com/r/dperson/openvpn-client/ with the armhf Tag. name = vpn network = bridge network name = vpn
apart from that I just specify the /vpn directory and which server to use (see readme)
subzero79
commented
6 years ago Look a restart should not change anything, maybe related containers need to be restarted also. The plugin does absolutely nothing on restart, it just literally passes docker restart containerID as command.
When you press modify that's different, then we are passing probably a double argument one as --net=container:vpn and --net:container:$cid as the backend is fetching the current network and the extra argument (that is stored in a label, which is a feature). I can see this when pressing a container like transmission using this flow you described.
I do not know if this is a problem as at the moment i am struggling to access local services through the nginx proxy as described in the hub.
The feature was intended to pass arguments not possible in the frontend. This is a limit case.
subzero79
commented
6 years ago I finally manage to get the three containers working, restarting transmission does do anything at all works ok.
If i restart the vpn then i get into trouble. This is a dependency issue. Your containers need to be started in certain order, i image first vpn then linked network containers.
The current docker doesn't provide anything like this, but docker compose does. Take a look at that see if that solves the issue.
ghost
commented
6 years ago Hi.
I've done some testing now and the "double argument" is the main problem here. It not only happens when modifying a container, but also when the omv box is restarted (which was expected). Afterwards I have to go through all containers using the vpn container manually and reconfigure.
And I observed another glitch regarding a "not intended configuration change": Using e.g. an extra argument --link vpn:application in an nginx container, changes the name of the vpn container to nginx/application.
I will have a look at docker compose within the next one or two weeks.
Thanks, g
subzero79
commented
6 years ago I did not experience problem with double arguments here, you can attempt this in a CLI with double --net same argument or different (none and vpn), both works. If you ever modify vpn container then everything goes down, since then you changed the container id.
An as i mentioned restarting the vpn container kills the network in all dependant containers.
If you have a code solution to solve this you're welcome to submit a PR. ATM the extra arguments are provided for those not available in the menu, this is a especial case an we would need to modify the GUI to provide using other container network.
On your "observed another glitch", can you please explain more in detail?
Hello, I stumbled over the following problem:
But if I restart openmediavault (or docker and/or the container) the extra argument breaks the network configuration in container "application": network mode is set to dcc41bc40de7aabdefa2d729fb77aca8d0fccbe5a3d7bb83970a04c920c30eb0 (which is the container id of container "vpn") host name is set to "vpn"
Unfortunately the network is not working when it is left to these settings. So my wish would be that the settings are not overwritten or reorganized/mapped from "extra arguments" to (in this example) "network"