Mount points are now made dynamically if either the leaf doesn't exist
or the leaf has no children. Any proper prefix of the target mount point may
or may not exist prior to mounting.
Signed-off-by: David Sheets <dsheets@docker.com>
The VPN interface is configure with a routing metric of 199. If VPN mode
is enabled and we have static IP address configured (which is what we do
on Windows) then all traffic would still go via eth0 and not, as expected,
via the VPN interface.
With this PR we set the metric for eth1 to 200, thus, if VPN mode enabled
traffic will be routed over the VPN interface.
This fix is a bit Uggh, but it's the simplest way to apply this late in the
release cycle without requiring re-run of all OS X tests.
We should fix this properly after this release.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Allow the host to configure a static IP address for eth0 by setting the
following DB keys:
- net/config: "static" (default or not set -> dhcp)
- net/address: IP address
- net/netmask: netmask in dot notation
- net/gateway: default gateway
Also allow overwriting/setting "/etc/resolve.conf" by writing to
the "etc/resolv.conf" key.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
On both Mac and Windows we have one well-known port and a SOCKS-like
port to tunnel connections through it. This was necessary on Windows
where ports have well-known GUIDs, but we might as well do it the same
way on both platforms for consistency.
This patch removes the dynamic binding of vsock ports, which fails on
a Windows Moby anyway.
Signed-off-by: David Scott <dave.scott@docker.com>
Added a patch to reduce verbosity of vmbus for unknown GUIDs.
Thes happen on every Hyper-V socket connection.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When running in VPN mode eth0 and eth1 have default routes, but
eth1 has the lowest metric. However the host CIFS server can
only be contacted via eth0, so always use the eth0 address.
Signed-off-by: David Scott <dave.scott@docker.com>
We now tell the 9P server
proto1:ip1:port1:<address for forwarding>
which means please listen on proto1:ip1:port1, then connect to the port
proxy in Moby and tell it the connection is for <address for forwarding>.
Note this requires a corresponding change in hostnet/vpnkit.
Signed-off-by: David Scott <dave.scott@docker.com>
On a Hyper-V system we can only register one listening endpoint (with
a GUID), so we need to accept connections, read a header and then
start the proxy.
If the binary has argv[0] == "proxy-vsockd" then run this new frontend.
Signed-off-by: David Scott <dave.scott@docker.com>
