3 components:
- network: read eht0 and proxy only DHCP traffic
- engine: read DHCP traffic, handle DHCP client state machine, and call the
host actuator to change the host config when a lease is obtained
host system configuration.
- actuator: perform the acutall net syscalls, read and write host configuration
files, etc
These three components can either be linked together in a single binary
(see src/dhcp-client/main.ml) or can be used as 3 binaries communicating
over cap-n-proto.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
pull in newer containerd v1.0.0-alpha0 via updated alpine base, update runc to
429a5387123625040bacfbb60d96b1cbd02293ab which is vendored by that version of
containerd (and also update alpine base for runc)
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
These are not needed, but we are inconsistent. Been waiting for a
quiet moment to fix this since I noticed while doing a presentation...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Lots of boilerplate for now on, will work on upstreaming that in the tool
properly if needed later.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
```
$ fdd init &
$ fdd share /tmp/foo # serve a fresh socketpair on that path
$ fdd test /tmp/foo # read the socketpair and test that it works
```
Instead of `fdd test` (which is only useful for testing), users are expected to
connect to the unix domain socket and call `recvmsg(2)`. They will get one side
of the socketpair. Two different processes can do this and they will be able to
talk to each other.
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
- Use the new style kernel tags with the full kernel version
- Update packages with new alpine base and new/simplified Makefiles.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- IO has been upstreamed in mirage-flow-lwt
- Init.Flow.Fd has been upstreamed in mirage-flow-unix
- Init.Flow.Rawlink has been upstreamed in mirage-flow-rawlink
- Remove some dead-code in unikernel.ml
Signed-off-by: Thomas Gazagnaire <thomas@gazagnaire.org>
Currently it supports only `service start <SERVICE>`, but it could grow e.g.
`stop`, `exec` etc in the future (although you can still use `ctr` for those).
In order to be able to use go-compile.sh the containerd build needs to move
from /root/go to /go as the GOPATH.
The vendoring situation is not ideal, but since this tool wants to be an exact
match for the containerd it seems tollerable to reuse its vendoring.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This doesn't exist with newer ctr or in systems where service containers are
not started using the ctr tool. All it contains today are the stdio FIFOs,
which are not in general useful to access after container creation.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
