The `NewProxy` function already knows how to deal with `net.UDPAddr`
and `net.TCPAddr`, this patch adds similar support for `vsock.VsockAddr`.
Signed-off-by: David Scott <dave.scott@docker.com>
This patch adds a wrapper around the `net.Conn` to include the
`CloseRead` and `CloseWrite` implementations. This patch also
exposes the `VsockAddr` type, which is similar to `TCPAddr` and
`UDPAddr`.
Signed-off-by: David Scott <dave.scott@docker.com>
We require the frontend to be a `net.Listener` and the `net.Conn`
connection which are established must be type-switched to
`Conn` to support the `CloseRead` and `CloseWrite` methods.
Signed-off-by: David Scott <dave.scott@docker.com>
The TCPProxy can proxy from anything which satisfies this interface:
type Conn interface {
io.Reader
io.Writer
io.Closer
CloseRead() error
CloseWrite() error
}
Signed-off-by: David Scott <dave.scott@docker.com>
This package supports a more normal Go interface, in particular it has:
// Listen returns a net.Listener which can accept connections on the given
// vhan port.
func Listen(port uint) (net.Listener, error)
Signed-off-by: David Scott <dave.scott@docker.com>
Note there is a slight name clash between the final binary 'proxy'
and the library formerly known as 'proxy'. Resolve this by calling
the library 'libproxy'.
Signed-off-by: David Scott <dave.scott@docker.com>
- Trigger a CIFS mount by writing to the "cifsmount" key.
- The value has the format: <mountpoint>;<alias mountpoint>;<options>
with <options> containing username, password and optional domain
- The key is not stored in the KV store (aka the 'registry')
- Trigger an unmount by writing to the cifsumount" key.
- The value has the format: <mountpoint>;<alias mountpoint>
- The 'registry' is also wiped on reboot
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This will make it easier to add a vsock interface as well as a regular
TCP/IP one.
As a side-effect, the server is now able to handle more than one concurrent
request!
Signed-off-by: David Scott <dave.scott@docker.com>
This is makes fast shutdown work on Hyper-V
While at it, also clean up whitespaces. The file was mixed
tabs and spaces. Now it uses spaces.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If bonjour is installed on the host, e.g. via iTunes or some other
program, a lookup for `docker.local` works just like on the Mac.
Just like with LLMNR there seems to be a 4-5 second delay before
Windows decides to do a multicast namelook up, though
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is a bit ugly as we copied and then modified the chronyd init.d
script as shipped in the package.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Busybox ifup does not modify /etc/resolv.conf
Update the hv_set_ifconfig script to overwrite /etc/resolv.conf
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Don't start hv_fcopy_daemon. It seems to exit and we are not
using it anyway. Also, remove it from the initrd
- Move hv_kvp_daemon and hv_vss_daemon to start earlier
(before networking and docker being started)
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
LLMNR is the Windows equivalent of mDNS.
Import the LLMNR daemon from https://github.com/tklauser/llmnrd
It needed some small modification to compile cleanly on Moby
LLMNRD is only started when running inside a Hyper-V VM
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Upstream commit 598881800825 ("vsock: Fix blocking ops call in
prepare_to_wait") was subsequently reverted in 6f57e56a1527, which said:
The commit reverted with this patch caused us to potentially miss wakeups.
Since the condition is not checked between the prepare_to_wait and the
schedule(), if a wakeup happens after the condition is checked but before
the sleep happens, we will miss it. ( A description of the problem can be
found here: http://www.makelinux.net/ldd3/chp-6-sect-2 ).
The underlying issue has been fixed instead with f7f9b5e7f8ec ("AF_VSOCK:
Shrink the area influenced by prepare_to_wait").
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
A future version of the 9P server will shutdown the forward on 9P
clunk, so if this process crashes the forward will be cleaned up
properly.
Signed-off-by: David Scott <dave.scott@docker.com>