Commit 250b14661b ("kernel: Use elfutils-dev instead
of libelf-dev") switched the kernel build to use
elfutils-dev instead of libelf-dev. This caused the kernel
module tests to fail. The still installed libelf-dev and
the dunamically linked objtool (and friends) from the
kernel source package failed to execute.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
With kernel 5.0.6 we start seeing compile errors such as:
HOSTCXX -fPIC scripts/gcc-plugins/randomize_layout_plugin.o
In file included from <stdin>:1:
/usr/include/libelf/libelf.h:28:5: error: "__LIBELF_INTERNAL__" is not defined, evaluates to 0 [-Werror=undef]
#if __LIBELF_INTERNAL__
^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
elutils-dev installs a different version of libelf.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
All our 4.x kernels had CFQ enabled. This was removed
in 5.x and replaced with BFQ. Enable it.
resolves#3308
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
To reduce the number of kernels we maintain, for s390x
and ar64 we only support the latest LTS and newer kernels.
v4.19.x has been out for a while, so lets remove support for
v4.14.x.
resolves#3302
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
See https://github.com/moby/moby/issues/38887
for details. Basically 5.x removed support for
CFQ with f382fb0bcef4 ("block: remove legacy IO
schedulers") and the Moby check still requires it.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Many places where checking for -ge 4 and some minor version.
This will fail for 5.x kernels if their minor version is less.
Fix it.
While at it, also restructure/simplify the code, make it easier
to run against arbitrary kernel configs, and tidy up some
whitespaces.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
This target allowed to locally download the kernel source
tar balls. We haven't used this foir a while and adding
v5.x kernel support for it would add yet another conditional.
Remove it to keep the Makefile simpler.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The build of the perf utility has been quite bothersome,
with different arches and kernel versions failing.
Since we now have the ful kernel source in the package,
factor out the actual build into Dockerfile.perf
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The compile fails with:
[ 30%] Building CXX object src/ast/CMakeFiles/ast.dir/codegen_llvm.cpp.o
[ 30%] Building CXX object src/ast/CMakeFiles/ast.dir/irbuilderbpf.cpp.o
[ 31%] Building CXX object src/ast/CMakeFiles/ast.dir/printer.cpp.o
[ 31%] Building CXX object src/ast/CMakeFiles/ast.dir/semantic_analyser.cpp.o
/bpftrace/src/ast/irbuilderbpf.cpp: In member function 'llvm::CallInst* bpftrace::ast::IRBuilderBPF::CreateProbeReadStr(llvm::AllocaInst*, size_t, llvm::Value*)':
/bpftrace/src/ast/irbuilderbpf.cpp:279:16: error: 'BPF_FUNC_probe_read_str' was not declared in this scope
getInt64(BPF_FUNC_probe_read_str),
^~~~~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/irbuilderbpf.cpp: In member function 'llvm::CallInst* bpftrace::ast::IRBuilderBPF::CreateProbeReadStr(llvm::Value*, size_t, llvm::Value*)':
/bpftrace/src/ast/irbuilderbpf.cpp:294:16: error: 'BPF_FUNC_probe_read_str' was not declared in this scope
getInt64(BPF_FUNC_probe_read_str),
^~~~~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/irbuilderbpf.cpp: In member function 'llvm::CallInst* bpftrace::ast::IRBuilderBPF::CreateGetCurrentCgroupId()':
/bpftrace/src/ast/irbuilderbpf.cpp:422:16: error: 'BPF_FUNC_get_current_cgroup_id' was not declared in this scope
getInt64(BPF_FUNC_get_current_cgroup_id),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/irbuilderbpf.cpp: In member function 'llvm::CallInst* bpftrace::ast::IRBuilderBPF::CreateGetCurrentTask()':
/bpftrace/src/ast/irbuilderbpf.cpp:461:16: error: 'BPF_FUNC_get_current_task' was not declared in this scope
getInt64(BPF_FUNC_get_current_task),
^~~~~~~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/irbuilderbpf.cpp: In member function 'llvm::CallInst* bpftrace::ast::IRBuilderBPF::CreateGetStackId(llvm::Value*, bool)':
/bpftrace/src/ast/irbuilderbpf.cpp:497:16: error: 'BPF_FUNC_get_stackid' was not declared in this scope
getInt64(BPF_FUNC_get_stackid),
^~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/semantic_analyser.cpp: In member function 'int bpftrace::ast::SemanticAnalyser::create_maps(bool)':
/bpftrace/src/ast/semantic_analyser.cpp:871:68: error: 'BPF_MAP_TYPE_STACK_TRACE' was not declared in this scope
bpftrace_.stackid_map_ = std::make_unique<bpftrace::FakeMap>(BPF_MAP_TYPE_STACK_TRACE);
^~~~~~~~~~~~~~~~~~~~~~~~
/bpftrace/src/ast/semantic_analyser.cpp:885:64: error: 'BPF_MAP_TYPE_STACK_TRACE' was not declared in this scope
bpftrace_.stackid_map_ = std::make_unique<bpftrace::Map>(BPF_MAP_TYPE_STACK_TRACE);
^~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [src/ast/CMakeFiles/ast.dir/build.make:89: src/ast/CMakeFiles/ast.dir/irbuilderbpf.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [src/ast/CMakeFiles/ast.dir/build.make:115: src/ast/CMakeFiles/ast.dir/semantic_analyser.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:276: src/ast/CMakeFiles/ast.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The wireguard package has some sub-packages which are
now dependencies. Include them in the alpine base.
Also include openresolv, which is required by one
of the wireguard packages.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
* wg-quick: freebsd: allow loopback to work
FreeBSD adds a route for point-to-point destination addresses. We don't
really want to specify any destination address, but unfortunately we
have to. Before we tried to cheat by giving our own address as the
destination, but this had the unfortunate effect of preventing
loopback from working on our local ip address. We work around this with
yet another kludge: we set the destination address to 127.0.0.1. Since
127.0.0.1 is already assigned to an interface, this has the same effect
of not specifying a destination address, and therefore we accomplish the
intended behavior. Note that the bad behavior is still present in Darwin,
where such workaround does not exist.
* tools: remove unused check phony declaration
* highlighter: when subtracting char, cast to unsigned
* chacha20: name enums
* tools: fight compiler slightly harder
* tools: c_acc doesn't need to be initialized
* queueing: more reasonable allocator function convention
Usual nits.
* systemd: wg-quick should depend on nss-lookup.target
Since wg-quick(8) calls wg(8) which does hostname lookups, we should
probably only run this after we're allowed to look up hostnames.
* compat: backport ALIGN_DOWN
* noise: whiten the nanoseconds portion of the timestamp
This mitigates unrelated sidechannel attacks that think they can turn
WireGuard into a useful time oracle.
* hashtables: decouple hashtable allocations from the main device allocation
The hashtable allocations are quite large, and cause the device allocation in
the net framework to stall sometimes while it tries to find a contiguous
region that can fit the device struct. To fix the allocation stalls, decouple
the hashtable allocations from the device allocation and allocate the
hashtables with kvmalloc's implicit __GFP_NORETRY so that the allocations fall
back to vmalloc with little resistance.
* chacha20poly1305: permit unaligned strides on certain platforms
The map allocations required to fix this are mostly slower than unaligned
paths.
* noise: store clamped key instead of raw key
This causes `wg show` to now show the right thing. Useful for doing
comparisons.
* compat: ipv6_stub is sometimes null
On ancient kernels, ipv6_stub is sometimes null in cases where IPv6 has
been disabled with a command line flag or other failures.
* Makefile: don't duplicate code in install and modules-install
* Makefile: make the depmod path configurable
* queueing: net-next has changed signature of skb_probe_transport_header
A 5.1 change. This could change again, but for now it allows us to keep this
snapshot aligned with our upstream submissions.
* netlink: don't remove allowed ips for new peers
* peer: only synchronize_rcu_bh and traverse trie once when removing all peers
* allowedips: maintain per-peer list of allowedips
This is a rather big and important change that makes it much much faster to do
operations involving thousands of peers. Batch peer/allowedip addition and
clearing is several orders of magnitude faster now.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
These tests expect a $TMPDIR which supports user xattrs, which the tmpfs on
/tmp does not. Redirect it to the persistent disk which does.
Signed-off-by: Ian Campbell <ijc@docker.com>
... from the old-skool label scheme.
No semantic change intended. Some keys are in different orders and the "mounts"
entry gained an empty "destination" key, neither of which makes a practical
difference.
Signed-off-by: Ian Campbell <ijc@docker.com>
* tools: curve25519: handle unaligned loads/stores safely
This should fix sporadic crashes with `wg pubkey` on certain architectures.
* netlink: auth socket changes against namespace of socket
In WireGuard, the underlying UDP socket lives in the namespace where the
interface was created and doesn't move if the interface is moved. This
allows one to create the interface in some privileged place that has
Internet access, and then move it into a container namespace that only
has the WireGuard interface for egress. Consider the following
situation:
1. Interface created in namespace A. Socket therefore lives in namespace A.
2. Interface moved to namespace B. Socket remains in namespace A.
3. Namespace B now has access to the interface and changes the listen
port and/or fwmark of socket. Change is reflected in namespace A.
This behavior is arguably _fine_ and perhaps even expected or
acceptable. But there's also an argument to be made that B should have
A's cred to do so. So, this patch adds a simple ns_capable check.
* ratelimiter: build tests with !IPV6
Should reenable building in debug mode for systems without IPv6.
* noise: replace getnstimeofday64 with ktime_get_real_ts64
* ratelimiter: totalram_pages is now a function
* qemu: enable FP on MIPS
Linux 5.0 support.
* keygen-html: bring back pure javascript implementation
Benoît Viguier has proofs that values will stay well within 2^53. We
also have an improved carry function that's much simpler. Probably more
constant time than emscripten's 64-bit integers.
* contrib: introduce simple highlighter library
This is the highlighter library being used in:
- https://twitter.com/EdgeSecurity/status/1085294681003454465
- https://twitter.com/EdgeSecurity/status/1081953278248796165
It's included here as a contrib example, so that others can paste it into
their own GUI clients for having the same strictly validating highlighting.
* netlink: use __kernel_timespec for handshake time
This readies us for Y2038. See https://lwn.net/Articles/776435/ for more info.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This also fixes up test/cases/020_kernel/110_namespace/common.yml
and test/cases/040_packages/032_bcc/test.yml to use the 4.19.x
kernel. I missed these when making the 4.19 kernel the default.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
4.19.x is the new LTS kernel and has been out for a while. Switch
all examples and tests to using it instead of the 4.14.x kernel.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The kernel config was derived from the 4.19.13 kernel config
run through the 'make oldconfig' with all defaults accepted,
except for:
- NET_VENDOR_MICROCHIP (defauly 'y', set to 'n')
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
We already have 4.9.x, 4.14.x, and 4,19.x as LTS releases.
4.9.x has a longer lifetime as 4.4.x as well and fewer security
fixes can be backported to 4.4.x. Remove it.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Sort the list of mount points by destination. This makes the list
deterministic for reproducible builds and also ensures that, e.g.,
the mount for /dev happens before the mount for /dev/pts.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Currently 'docker export' is used to convert a linuxkit entry
in the YAML file to a tar file of the root filesystem. This
process creates a number of files and directories which have
the timestamp of when the 'docker export' is run. Fix 'em up.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
When creating files for the "intermediate" tar ball,
fix the ModTime. This reduces the difference between
LinuxKit images build from identical inputs.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
packet.net will soon have x86 and arm64 machines with NFPs.
Enable the driver for it.
The 4.9 kernel only has support for the NFP VF driver,
so don't enable it there.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Support plain gzip'ed files, as used on arm64, and bzImage with
embedded gzip'ed kernel, as used on x86.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Add the '-vmlinux' flag to build and pass it all
the way to the kernel filter.
Note, this commit only adds the flag but does not
yet perform the decompression. This will be added
with the next commit.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Stash the kernel image in a local buffer and
flush it out once done.
This is preparation work for supporting uncompressed
kernels in the next commit.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Please add your use cases here. There are many adopters that I know about but have not
documented here, please fill this in.
I divided this into production users, and also linked a selection of open source projects
that I know about here.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
A previosu commit removed suppoer for 4.18.x kernels for
arm64 and s390x but did not remove the config files. Fix it.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Needed for containerd v1.2.0 otherwise:
$ ctr run -t docker.io/library/hello-world@sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f test
[ 1311.667587] overlayfs: failed to resolve '/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/5/fs': -2
ctr: failed to mount /tmp/containerd-mount111658703: no such file or directory
Signed-off-by: Ian Campbell <ijc@docker.com>
On Linux a key in `~/.docker/config.json` indicates if a credentials helper is
in use (and which), if one is then the method is identical to the Darwin case
so refactor to support that.
Signed-off-by: Ian Campbell <ijc@docker.com>
If the YAML does not specify a kernel, kernel commandline
or any containers, don't create empty files. Note, an
initrd file is still created if the kernel image contains
CPU ucode.
This only applies to kernel+initrd and tar-kernel-initrd
output formats.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The logic for perf became too complex. Just build for latest LTS
and latest stable.
Disable for arm64 for now as it is broken for 4.19 due to a header
mismatch:
In file included from /linux/tools/arch/arm64/include/uapi/asm/unistd.h:20:0,
from libbpf.c:36:
/linux/tools/include/uapi/asm-generic/unistd.h:754:0: error: "__NR_fcntl" redefined [-Werror]
In file included from /usr/include/sys/syscall.h:4:0,
from /linux/tools/perf/perf-sys.h:7,
from libbpf.c:35:
/usr/include/bits/syscall.h:26:0: note: this is the location of the previous definition
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The kernel configs were constructed by running the 4.18.x config
through the 4.19 oldconfig process.
The 4.19.x has a new option, RANDOM_TRUST_CPU, which indicates
if the CPUs random instruction is to be trusted. It defaults to
"no" and this default was accepted.
Most of the defaults were accepted, except for:
BLK_CGROUP_IOLATENCY=y
NFT_TUNNEL=y
NFT_OSF=y
NFT_TPROXY=y
NETFILTER_XT_MATCH_SOCKET=y
NET_VENDOR_CADENCE=n
NET_VENDOR_NETERION=n
NET_VENDOR_PACKET_ENGINES=n
We also disallow CIFS for insecure legacy servers:
CIFS_ALLOW_INSECURE_LEGACY=n
For arm64, the following changes were made to the default:
SENSORS_RASPBERRYPI_HWMON=y
CRYPTO_DEV_QCOM_RNG=m
CRYPTO_DEV_HISI_SEC=m
For s390x, the additional changes were made to the default:
KERNEL_BZIP2 (default is gzip)
GCC_PLUGINS=y
GCC_PLUGIN_STRUCTLEAK=y
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
GCC_PLUGIN_RANDSTRUCT=y
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE=y
Running the 4.18 and 4.19 kernel config through
./scripts/kconfig-split.py yields the following 4.19.x
only config options for x86_64:
The x86_64 kernel difference to 4.18 for
CONFIG_ARCH_SUPPORTS_ACPI=y
CONFIG_BLK_CGROUP_IOLATENCY=y
CONFIG_BNXT_HWMON=y
CONFIG_BUILD_SALT=""
CONFIG_CONSOLE_LOGLEVEL_QUIET=4
CONFIG_CRASH_CORE=y
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y
CONFIG_HAVE_RELIABLE_STACKTRACE=y
CONFIG_MEMCG_KMEM=y
CONFIG_MLX5_EN_ARFS=y
CONFIG_MLX5_EN_RXNFC=y
CONFIG_NETFILTER_NETLINK_OSF=y
CONFIG_NETFILTER_XT_MATCH_SOCKET=y
CONFIG_NFT_OSF=y
CONFIG_NFT_TPROXY=y
CONFIG_NFT_TUNNEL=y
CONFIG_NF_SOCKET_IPV4=y
CONFIG_NF_SOCKET_IPV6=y
CONFIG_XEN_SCRUB_PAGES_DEFAULT=y
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
After 'make oldconfig' we check that that the kernel config
is as we expect and error if they don't. We used to print
the default 'diff' output on a mismatch but a unified diff
is easier to read.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Using filepath primitives instead of manipulating file paths manually takes care of platform specific formats.
Signed-off-by: Mathieu Champlon <mathieu.champlon@docker.com>
This cherry picks:
- b6fe0440c637 ("bridge: implement missing ndo_uninit()")
- b1b9d366028f ("bridge: move bridge multicast cleanup to ndo_uninit")
The fix is in b1b9d366028f ("bridge: move bridge multicast cleanup
to ndo_uninit") but it requires b6fe0440c637 ("bridge: implement missing
ndo_uninit()"). Furthermore, b1b9d366028f needed some manual resolution
of a cherry-pick conflict because the surrounding code had changed.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
We want to compile BCC for the latest LTS and the latest
stable and missed the update to 4.18 when enabling it. Do
it now.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
support SPI in container environment (introduced Linux 4.12 2017-06-02).
Abstraction define interface EP for CAN module in containered environment. This
namespace is available and introduced with Linux Kernel 4.12 by M. Kicherer
and later O. Hartkopp, to allow containers bridging such device.
@see linux-kernel/net/can@fc4c581
Although KSPP did not explicilty noted `CAN` as secure kernel flag, this
would aim to bring such conclusion. As for security concerns, CAN protocol did
not yield any user-land or host-level vulnerabilities since introduced as
SocketCAN module in Linux Kernel. Lower-layer [protocol] standards is not
secured by default since applications are supposed to implement their own
security mechanism.
This global abstraction currently supports CAN raw, proc and af_can
codes. Does not support GW and BCM. Namespace uses _NEWNET on pseudo-file
system. Allows modprobe to environment, works by recv `pnet` for the given
interface.
Signed-off-by: Halis Duraki <duraki@linuxmail.org>
Note, this update skips 4.18.2/4.17.16/4.14.64/4.9.121/4.4.149
as the change was a single patch, a bug fix.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
In setup_net() there are a few particularly slow subsystems that
contribute more than 140ms of time to the new net namespace creation
path. The docker daemon doesn't depend on these, and won't modprobe
them into the kernel. Convert these to modules to reduce the amount of
time it takes for docker to start a container. This change takes an
additional ~120 ms of time off container start time.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
While investigating performance problems around 'docker run' times, it
was observed that a large amount of time was spent in network namespace
creation. Of that time, a large portion involved waiting for RCU grace
periods to elapse. Increasing HZ causes the periodic timer to check for
quiesced periods more frequently, which consequently reduces the amount
of time RCU callers spend waiting for grace periods and in barrier
waits.
By itself, this change took the amount of time to execute a 'docker run
hello-world' down to 570ms from over 2000ms on 4.14, and down to 390ms
from 1260 on 4.17 and 4.18.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
The kernel config was derived from the 4.17.x kernel config
and then tweaked a little. Specifically:
- Enable XDP_SOCKETS
- Enable NFT_CONNLIMIT
- Enable IP_VS_MH
- Enable BPFILTER (as module)
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
The 4.14.63 contains important security fixes in particular
against L1TF (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) and
userspace-userspace SpectreRSB.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
linuxkit/vsudd:98e554e4f3024c318e42c1f6876b541b654acd9f
linuxkit/host-timesync-daemon:613dc55e67470ec375335a1958650c3711dc4aa6
linuxkit/test-virtsock:57883002c2bc824709efa6cd3818e1ff51a11889
linuxkit/test-ns:a21f996641f391d467a7842e85088a304d24fae5
Signed-off-by: David Scott <dave.scott@docker.com>
In addition to bug fixes, this removes the special protocol used
for `shutdown` needed by old Windows builds < 14393.
Signed-off-by: David Scott <dave.scott@docker.com>
Note: this patch introduces an incompatibility in the
`linuxkit run vbox` arguments.
It wasn't impossible to specify more than one network adapter
to the `linuxkit run vbox` command.
This patch allows to specify more than one `-networking` argument to specify
different network adapters.
For instance:
~~~sh
linuxkit run vbox -networking type=nat -networking type=hostonly,adapter=vboxnet0
~~~
will setup the VM with 2 NICs.
It is also possible to get rid of the `type` argument.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
VirtualBox hardware (like physical hardware) has only a limited number
of IDE device on an IDE Controller.
Unfortunately when using an additional drive, it was given the port
value of 2, which doesn't exists in VirtualBox IDE controllers (as
only 0 and 1 are permitted).
This change makes use of the SATA Controller which can host much
more drives, to hook the additional drives.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
While processing the content of a tar image, linuxkit's moby tool is
blindly reusing the original tar format.
Moreover it locates the files under a new prefix, so if the original
file was stored as USTAR in the original archive, the filename length
and new prefix could be greater than the USTAR name limit leading
to a fatal error.
The fix is to always enforce PAX format on all copied files from the
original image archive.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
When building the build context, symlink need special
treatment as the link name needs to be added when
building the tar.FileInfoHeader. This code does that.
We may also need to add a special case for hard links
as the moby/moby package 'archive' does, but this
should for now
fixes#3142
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
This is the final piece. If 'sources' are defined, tar up
the sources and rewrite them accordingly. Pass it as build
build context to 'docker'.
This allows building from something like this:
├── etc
│ ├── foo
└── foo
├── Dockerfile
├── build.yml
└── main.go
With 'build.yml':
image: foo
extra-sources:
- ../etc:etc
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This commit adds the ability to add a build context to
docker for the package build. The build context is passed
on stdin to the docker process.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If the build.yml specifies 'extra-sources', ie sources
outside the package directory, calculate the hash based on
the tree hash of all source directories and the package
directory.
Note, this requires the source directories to be under
git revision control.
Also clean up the src and dst of the path and stash the
result in the Pkg structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
In e8786d73bb the logwrite package will
automatically append .log to every log.
In 5201049f2c the init package will send
stderr of a service `s` to a log named `s` and the stdout to `s.out`.
Therefore the files we create on disk are `s.log` and `s.out.log`.
This patch modifies the memlogd `logwrite` command-line wrapper to use
the same convention.
Note there is a confusing name clash between `pkg/logwrite` and `cmd/logwrite`
in `memlogd` modified here.
Signed-off-by: David Scott <dave.scott@docker.com>
This commit adds support for authentication for image pulls for
'linuxkit build'. For each image reference we look up credentials
via the docker CLI configuration and use it if defined for
a given registry server. The code caches credentials to avoid
lookups for every image.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
A subsequent commit will enable support for private repositories.
This requires some functions from 'github.com/docker/cli' which
in turn relies on some newer versions of some of the vendored
packages here.
In this commit, update all packages used here to the versions
used by 'github.com/docker/cli' release 18.06 (the latest stable).
This requires vendoring a bunch of additional packages, such
as prometheus
Also run 'sort' over 'vendor.conf' to keep things in order.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- use the mkimage hashes that we had in LinuxKit as more up to date than tool.
- update docs
- move the code from moby under src/cmd/linuxkit
Signed-off-by: Justin Cormack <justin@specialbusservice.com>
These must have fallen through the crack during various
kernel updates. Move everything to the latest 4.14.x kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
When logging directly to files (the not-using-memlogd case) the onboot
services must log to /run/log because /var/log might be overmounted
by a persistent disk. Therefore we create a symlink at the end of
the onboot section.
When logging via memlogd, all logs are buffered until a logwrite service
starts, so no symlink is needed.
Signed-off-by: David Scott <dave.scott@docker.com>
Also simplify the code by directly storing the path to
the log file in the LogFile structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Update the the firmware packages to the latest commit
of the upstream linux-firmware repository.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This process connects to memlogd and streams logs to individual files,
one per log. It keeps track of how many bytes have been written to each
file and rotates when the file size exceeds a defined threshold.
By default the maximum size of each file before rotation is 1MiB and
we keep up to 10 files per log.
Signed-off-by: David Scott <dave.scott@docker.com>
Looks like brtfs-prog v4.17 as shipped with alpine:3.8 requires
a loopback device of 109MB while the containerd tests only
create a 100MB device. This causes the test to fail.
Disable it until https://github.com/containerd/containerd/issues/2447
is fixed.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
This simplifies the example by adding a service which writes to the
log every 1s and a getty for introspection.
To see the logs:
/proc/1/root/usr/bin/logread -F
Signed-off-by: David Scott <dave.scott@docker.com>
Switch to a more formally-specified `kmsg`-style format for reading
the logs.
- update the spec in docs/logging.md
- check for bad names in pkg/memlogd with unit test
Signed-off-by: David Scott <dave.scott@docker.com>
- check writing to the log does not block
- check the log doesn't expand -- it should be finite
- check that client connections don't buffer arbitrary amounts of
data if the client is slow
Signed-off-by: David Scott <dave.scott@docker.com>
Previously we had a per-connection
bytes.Buffer // to be written to the connection
sync.Cond // to allow us to Wait for more data
This had the major disadvantage that the buffer was unbounded and so
a slow client could cause memory exhaustion in the server. This patch
replaces these with a single
chan *logEntry
which is naturally bounded and supports blocking read. We make write
non-blocking using select i.e. we drop messages rather than allocate
more space.
Signed-off-by: David Scott <dave.scott@docker.com>
This is an example external logging service which can be enabled by
adding it to the `init` section of the .yml, for example:
...
init:
- linuxkit/init:35866bb276c264a5f664bfac7456f4b9eeb87a4d
- linuxkit/runc:v0.4
- linuxkit/containerd:f2bc1bda1ab18146967fa1a149800aaf14bee81b
- linuxkit/ca-certificates:v0.4
- linuxkit/memlogd:cc035e5c9e4011ec1ba97a181a6689fc90965ce9
onboot:
...
Signed-off-by: David Scott <dave.scott@docker.com>
If external logging is enabled, this patch sets the stdout and stderr
of the `runc` invocations to one end of a socketpair and the other end is
sent to the logging service. Otherwise we log to files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
An external logging system exists if the socket
/var/run/linuxkit-external-logging.sock
exists.
If an external logging system is enabled then create FIFOs for
containerd and send the other end of the FIFOs to the logging service.
Otherwise use /var/log files as before.
Signed-off-by: David Scott <dave.scott@docker.com>
Previously memlogd would always run in the foreground. This patch
adds a `-daemonize` option which binds the /var/run sockets, forks
and execs itself and immediately returns. Therefore the program won't
block (important for an init.d script) but guarantees the sockets will
be available for any program started afterwards.
This also removes the alpine base from the memlogd image as `init`
"containers" are treated as simple file overlays.
Signed-off-by: David Scott <dave.scott@docker.com>
We will place the control sockets in the root /var/run and then share
with all services who need access.
Signed-off-by: David Scott <dave.scott@docker.com>
Since I struggled to understand and find information about how to
troubleshoot a running linuxkit instance, I propose to add these two
FAQ entries.
The first one explains why it is possible to not see the `containerd` or
`init` outputs at boot in the console.
The second one gives a few `ctr` example to list containers, running
containers or how to open a shell in a given container.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
These were being added to the incorrect directory.
Also move config file to /etc to be more standard.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The previous commit updated to 4.16.18, which is the last
4.16.x kernel. The 4.16.18 kernel was compiled and pushed
but we may as well now remove it as it has been EOLed.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When dealing with apk, `uname -m` doesn't always match the architecture
name that apk uses. Instead `apk --print-arch` is used.
Signed-off-by: Alan Raison <alanraison@users.noreply.github.com>
DNS lookups fail in qemu-user when it is built on Alpine: https://bugs.alpinelinux.org/issues/8131
Until this is resolved, we fetch the binaries from Debian and use those instead. The final stage
of the Dockerfile is still based on scratch.
We can revert this once the Alpine issue is fixed.
Signed-off-by: Justin Barrick <jbarrick@cloudflare.com>
For some reason, bind mounting does not always seem to work,
sometimes the filesystem is empty. Mounting a fresh copy seems
a better solution, and simplifies things. The container does
need `CAP_SYS_ADMIN` but only on boot.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This attempts to work around a CI issue where we're running out of disk
space when rebuilding the init package.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
When busybox's reboot processing occurs in init, it runs all SHUTDOWN
actions that are defined in inittab. Once those are complete, it will
trigger either a halt, poweroff, or reboot, depending upon what signal
is received. The mechanism that's used to shell out through inittab
does not allow us to pass through exactly which invocation was
requested.
Due to the way that rc.shutdown works, it invokes the poweroff action
for any and all SHUTDOWN callbacks, whether they're a reboot, poweroff,
or halt. Instead of handling the reboot(2) syscall in rc.shutdown,
return after killing and unmounting and let busybox's init process
decide which reboot(2) action to use.
Signed-off-by: Krister Johansen <krister.johansen@oracle.com>
With PR #3030 the behaviour of poweroff/halt is changed. This
test relies on on-shutdown containers to be executed to display
the test result (service containers have their stdout redirected).
Use 'poweroff' (note, no '-f') to ensure that:
- the machine actually powers off
- the on-shutdown container is executed
Note, there are subtle differences between 'poweroff' and 'halt'
between hypervisors. With HyperKit, 'halt' actually works, but with
qemu/kvm, with 'halt' the process does not exit.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Previously name and image were always the same so running two hosts
from one image was not possible!
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
While we can re-create the kernel source code we don't have it
handily available in one place. This commit stashes the kernel
and the WireGuard source as /src/linux.tar.xz and
/src/wireguard.tar.xz in the kernel package.
This increases the size of the hub image by around 100MB.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Trying to keep the number of kernels we compile for these
platforms small and 4.16 is likely to be EOLed soon anyway.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The kernel configs are the 4.16.x configs run through
a 'make defconfig && make oldconfig' cycle.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Originally, Memorizer kernel fed inputs to add boot printouts from a debug tool, however, it creates unnecessary output. Remove the kernel boot option parameter.
Signed-off-by: Nathan Dautenhahn <ndd@cis.upenn.edu>
Note, we skip 4.14.45 because 4.14.46 only has 3 patches
in it which unbreak 'perf' compilation.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The default Go tar has restrictions on filename length for example.
PAX is recommended over GNU.
Requires Go 1.10
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
For the initrd we only want to extract kernel, cmdline, and
the ucode CPIO archive. Skip whatever is left in ./boot
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This output produces a kernel and a root filesystem
in squashfs format. squashfs is a read-only, compressed
filesystem.
The 'kernel+squashfs' output can be used in a similar way as
the default 'kernel+initrd' output format with the benefit
that the rootfs does not consume any memory.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We currently hardcode the Linuxkit/mkimage- images. This has the
unfortunate consequence that, if we update the LinuxKit image used
to generate the output, we have to update the Moby tool and then
vendor it back into the LinuxKit repository.
This commit introduces UpdateOutputImages() which allows a client
of the Moby tools package to selectively overwrite the packages
used to generate the outputs.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
It is quite confusing that from the host or another container that
binds `/containers` you cannot see the bind mounts, you have to enter
the container namespace. I think `rshared` is a better default. You
can always be explicit and add `private` if you want a private bind mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a namespace field to override the LinuxKit containerd
default namespace, in case you want to run a container in another
namespace.
Needs a patch in LinuxKit to implement this that I will open soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Annotations do not do anything by default but get passed through to the runtime,
which can be useful. I never metadata I didn't like...
Also fix sysctl to be a map in the validation, not an array. I can't see any
examples using this in LinuxKit, but this matches OCI so is correct.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This prepends 'ucode.cpio' to the initrd if present. Padding
should not be necessary as the ucode.cpio should be padded
to the right size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For now the backends for the different formats do not yet
use the extracted ucode cpio archive, but '// TODO' are
placed for the backends which should eventually handle it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This extends the kernel filter to also look for the CPU microcode
file if specified in the YAML. If found, the ucode cpio archive
is placed into the intermediate tar file as '/boot/ucode.cpio'.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This optional option will allow users to specify a CPU
microcode cpio archive to be prepended to the initrd file.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
User specified mounts should be able to rely on the rootfs being mounted, in
particular for a writeable container they should expect the writeable overlay
to already be in place.
Signed-off-by: Ian Campbell <ijc@docker.com>
Since that bumps to gogo protobuf v0.5 too do the same.
Note that there are no actual containerd changes here, although there are some
gogo proto ones.
Signed-off-by: Ian Campbell <ijc@docker.com>
Rather than queueing up into a `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) compared with the previous patch from 2.8G to 110M. The
tar output case goes from 2.1G to 110M also. Overall allocations are ~715M in
both cases.
Signed-off-by: Ian Campbell <ijc@docker.com>
All of the `output*` functions took a `[]byte` and immediately wrapped it in a
`bytes.Buffer` to produce an `io.Reader`. Make them take an `io.Reader` instead
and satisfy this further up the call chain by directing `moby.Build` to output
to a temp file instead of another `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) from 6.7G to 2.8G and overall allocations from 9.7G to
5.3G. When building a tar (output to /dev/null) the Maximum RSS fell slightly
from 2.2G to 2.1G. Overall allocations remained stable at around 5.3G.
Signed-off-by: Ian Campbell <ijc@docker.com>
Following https://golang.org/pkg/runtime/pprof/. When attempting to build
images in https://github.com/linuxkit/kubernetes CI the process is mysteriously
being SIGKILL'd, which I think might be down to OOMing due to the resource
limits placed on the build container.
I haven't done so yet but I'm intending to use these options to investigate and
they seem potentially useful in any case, even if this turns out to be a
red-herring.
Signed-off-by: Ian Campbell <ijc@docker.com>
The syntax used for the yaml definitions is changed by the need to include the
substruct in the struct literal.
For the label switch to `ImageConfig` directly, which is actually more correct
in that it avoids spurious `name` and `image` fields in the label.
Signed-off-by: Ian Campbell <ijc@docker.com>
Where "config-related" here means "ones you might find in the
"org.mobyproject.config" label on an image.
By making this new struct an anonymous member of the existing Image struct the
Go json parser does the right thing (i.e. inlines into the parent) when parsing
a complete image (from a yml assembly) by default. The Go yaml library which we
use requires a tag on the anonymous field to achieve the same.
Signed-off-by: Ian Campbell <ijc@docker.com>
It appears that the `$GOPATH` in `working_directory` is being treated as a literal
`GOPATH` at least when processing the `state_artifacts.path`. Inlining it seems
to have worked, at the cost of some duplication.
Signed-off-by: Ian Campbell <ijc@docker.com>
Solv: Updated documentation to point out limits of
files section regarding /var, /run, and /tmp dirs.
Signed-off-by: Tristan Slominski <tristan.slominski@gmail.com>
Looks like a6b89f1137 ("Update linuxkit/mkimage-*") updated to a
non-existing tag.
linuxkit pkg show-tag tools/mkimage-iso-bios
linuxkit/mkimage-iso-bios:165b051322578cb0c2a4f16253b20f7d2797a502
and docker pull of that image works.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These versions were created by https://github.com/linuxkit/linuxkit/pull/2607
which enables content trust, so drop the sha256 from all of them and ensure
DOCKER_CONTENT_TRUST is unconditionally set when running, since these
references are hardcoded we know they must be signed.
Signed-off-by: Ian Campbell <ijc@docker.com>
AFAICT none of the callers (which all involve one of `linuxkit/mkimage-*`) have
any reason to hit the network.
Signed-off-by: Ian Campbell <ijc@docker.com>
If the YAML file contains:
- path: etc/linuxkit.yml
metadata: yaml
in the fil section, the image was build with content trust,
then the linuxkit.yml file image contains fully qualified
image references (including the sha256).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Instead of passing the image name as string use the a reference
to a containerd reference.Spec. This allows us, for example,
to update the reference in place when verifying content trust
with more specific information, such as the sha256
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When constructing a Moby structure from a YAML also
extract a containerd reference.Spec for each image
and the kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We want to modify some of the content of the Image structure
and thus have to pass them by reference.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is a tarball of the kernel, initrd and cmdline files, suitable for
sending to the mkimage images that expect this format.
Note you can't currently stream this output format using `-o` will clean this
up in future commits.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The next commit will start using some components of containerd
so vendor the latest version.
The latest vndr also removed some un-needed files previously vendored.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We are going to phase out the LinuxKit build option, in favour of keeping Docker
or a native Linux build option for CI use cases, as it is faster. So the
hyperkit option that only worked in one very limited use case is not needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously any Runtime specified in yml would completely override anything from
the image label, even if they set distinct fields. This pushes the merging down
to the next layer, and in the case of BindNS down two layers.
Most of the fields involved needed to become pointers to support this, which
required a smattering of other changes to cope. As well as the local test suite
this has been put through the linuxkit test suite (as of cc200d296a).
I also tested in the scenario which caused me to file #152.
Fixes#152.
Signed-off-by: Ian Campbell <ijc@docker.com>
This puts the build side in charge of the runtime layout, which enables
additional optimisations later, like sharing the rootfs if it is
used multiple times.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This could be used in LinuxKit now, as there are some examples, eg
https://github.com/linuxkit/linuxkit/blob/master/blueprints/docker-for-mac/base.yml#L33
which are creating containers to do a mount.
The main reason though is to in future change the ad hoc code that generates
overlay mounts for writeable containers with a runtime config which does
the same thing; this code needs to create both tmpfs and overlay mounts.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a `runtime` section in the config that can be used
to move network interfaces into a container, create directories,
and bind mount container namespaces into the filesystem.
See also https://github.com/linuxkit/linuxkit/pull/2413
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than using an initrd, unpack full filesystem for ISO BIOS.
Stream docker output direct to file rather than via a buffer, to save
memory.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
When we converted these to cpio we were not noticing that they
were invalid as they had incorrect paths as we converted the
path to a symlink anyway. Only the busybox images have hard links
in, the Alpine ones are symlinks anyway, which is why it was
less visible too.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do some code cleanup.
Related to #131 we need to read the OCI config to find if the container
is read only, not rely on the yaml, as it may just be set in the label.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
To work with truly immutable filesystems, rather than ones
we sneakily remount `rw`, we are going to use overlay for
writeable containers. To leave the final mount as `rootfs`,
in the writeable case we make a new `lower` path for the read
only filesystem, and leave `rootfs` as a mount point for an
overlay, with the writable layer and workdir mounted as a tmpfs
on `tmp`.
See https://github.com/linuxkit/linuxkit/issues/2288
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Unfortunately there are a lot of issues with resolv.conf as we
cannot actually write it into the image from any docker image, as docker will
always have something bind mounted in.
In addition, normally we expect the filesystem to br read only for images
that moby generates, so the actual etc/resolv.conf is likely not to be writeable.
Previously we were adding in a default resolv.conf into every image pointing at
Google's name servers but that is really a bad idea.
Instead, normal images now get an empty default, while images in the `init`
section will get a symlink, currently hard coded to `/run/resolvconf/resolv.conf`
but you can override this with the `files` section to be static or a different
link.
In future, if we have an easy way to build and extract images with user control
of this, we can drop this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Some of these are arbitrary and just syncing for the sake of it, however the
image- and runtime-spec are relevant. Interesting changes:
- runtime spec:
- LinuxRLimit is now POSIXRLimit.
- Specs.Config is now a pointer.
- LinuxResources.DisableOOMKiller moved to
LinuxResources.LinuxMemory.DisableOOMKiller
- image spec:
- Platform.Features is removed (unused here).
Signed-off-by: Ian Campbell <ijc@docker.com>
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
Fix https://github.com/linuxkit/linuxkit/issues/1988
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Currently this supports "yaml" as the only option, which will output
the yaml config (as JSON) into the file specified in the image.
Fix#107
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously I was forcing them to be strings, which is horrible. Now you
can either specify a numeric uid or the name of a service to use the
allocated id for that service.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes the `lint` dependency from building Moby.
I've also added ineffassign to check ineffecutal assignments alongside
checks to ensure that both it and golint are installed.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This includes https://github.com/moby/moby/pull/34040 which fixes Windows build
issues.
Note that this pulls in more than 500 (non merge) commits as well as the fix we
are interested in. A couple of new deps are pulled in, versions taken from
vendor/github.com/docker/docker/vendor.conf.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Continue to allow onboot to have duplicates as we do not run simultaneously
so that is ok (and we number them anyway), but services are run together
so we will get a runtime error if duplicated as this is the containerd/runc
id.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We were pulling in this whole stack of packages just for `trust.ReleasesRole`.
Just define it locally.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Note that various fields have changed moved around in the JSON as a result:
* `Platform` has been removed.
* `Process` is now a pointer.
* `OOMScoreAdj` has moved into `Process`, from `Linux.Resources` (resolving a
TODO here).
Also updates golang.org/x/sys which is less critical.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This adds the OCI parts needed into the yaml, but there are still
permissions issues in practise so marked as experimental.
It may just need further documentation to resolve the issues.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In order to support not running containers as root, allocate
each of them a uid and gid, a bit like traditional Unix system
service IDs. These can be referred to elsewhere by the name of
the container, eg if you wish to create a file owned by a
particular esrvice.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Allow setting ambient capabilities, as a seperate option to the standard
ones. If you are running as a non root user you should use these.
Note that unless you add `CAP_DAC_OVERRIDE` and similar permissions you
need to be careful about file ownership. Added support to set ownership
in the `files` section to help out with this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than build the image and have something weird happen, let's check
that the capabilities specified are actually valid capabilities.
Signed-off-by: Tycho Andersen <tycho@docker.com>
- this is pretty much the smallest change to split this out and it
exposes a few things that can be improved later
- no change to logging yet
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- enable the hyperkit option by default on MacOS
- use it for creating raw disk images
fix#68
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This disables the code in LinuxKit's `/bin/rc.init` which attempts to detect an
unconfigured hostname and generate a unique (ish) version from the MAC address.
Anyone who wants a specific fallback hostname can populate `etc/hostname`
through the `files` stanza in their `yml` file.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
In the WIP code in `moby` we now have a standard base tarball format,
that includes the kernel and cmdline as files in `/boot` so that the
entire output of the yaml file can default to a single tarball. Then
this can be split back up by LinuxKit into initrd, kernel and cmdline
as needed. This will probably become the only output of the `moby build`
stage, with a `moby package` stage dealing with output formats.
We may remove the output format specification from the yaml file as well,
and just have it in the command.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Instead, make a hard link a symlink. This isn't much better, but it allows
some cases (e.g. installing GCC on moby via alpine) to work.
Signed-off-by: Tycho Andersen <tycho@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also keep track of directory creation there, so you can explicitly
set directory permissions if required, and to avoid duplicates.
We should really keep track of files created elsewhere in the build
as well as we still might create some extras, but at least you can
set the write permisisons.
We can add uid, gid support too if required...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This will add a Dockerfile which will build the contents into an
image and then call `tinit` to start it.
This is fairly experimental, but is a prototype for other non
LinuxKit outputs. The container will need to run as `privileged`
as `runc` needs quite a few capabilities and `containerd` needs to
mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- generally people refer to a plain disk image as `raw`
- `gcp` is shorter and it is the only image type supported
- remove `img-gz` as it is not needed. It does not really save space
as you have to build the full image and compress it anyway. On
many platforms the `raw` image will be a sparse file anyway,
even on the Mac soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a little ugly in terms of the validation now, but it is a move towards
splitting "build" and "package".
The "tar" output (and soon others) can output direct to a file or to stdout.
Obviously you can only build a single output format like this.
The LinuxKit output formats that build disk images cannot stream as they
have to build whole images. These allow multiple outputs.
In future we will probably change to
```
moby build | moby package
```
or similar, but that is a bit ugly, so currently have a compromise where
there are essentially two output types.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP does not recognise the images, even though they appear identical to those made
by libguestfs and work on qemu fine. Their validation code does not like them for some
reason.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Each section will be appended in order of the CLI, other then
kernel where last specified one wins.
This is useful if you eg want to have a base version for (say)
AWS and GCP and then add your own image on top.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- does not require docker if user has qemu natively, will still fall back to docker
- allow specifying size for fixed size disk images
- add a raw disk output format
- more dogfooding
- marginally slower, but can be improved later
The images used to do the build are cached to make the process quicker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Default to sharing net, ipc, uts namespaces between containers in config.
This makes most sense, as this is normal other than if we want to specifically
isolate system containers, in which case we will specify in config.
- explicitly support the value "new" if you want to isolate
- support the synonym "root" for "host" as in non LinuxKit setups it may
not actually be the host, it will be the current namespace.
- only support "none" as a synonym for "new" for network namespace where it is
carried over from Docker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes outputs from yaml, instead you can do
```
moby build -output tar -output qcow2 file.yaml
```
or alternative syntax
```
moby build -output tar,qcow2 file.yaml
```
In future we may change this to be available in a `moby package`
step, but lets try this for now.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Using the label `org.mobyproject.config` will use that JSON
(or yaml, but it is very hard to get yaml into a label as newlines are
not respected) for parameters that are not explicitly set in the yaml file.
Had to change parameter definitions so override behaves as expected.
fix#16
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a fairly generic bootable disk with syslinux. Should
work if you dd it onto a USB stick, and should also work for AWS.
You need to uncompress it of course! Default size is 1G.
Will add cli option to set the size once I split out `moby build`
and `moby package` shortly.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Due to a missing else the tool would previously terminate with an error
message showing that the kernel or init image didn't exist, even if it
was pulled successfully. Invoking the tool again would continue to the
next image.
Signed-off-by: Magnus Skjegstad <magnus@skjegstad.com>
Add a canonical single tarball output format. This
adds kernel and cmdline to `/boot` where LinuxKit output
formats will find them.
Make the other output formats use that as a base.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
`docker create` will not pull an image so we need an additional fallback.
Rework the pull and trust code so it is in one place to facilitate this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do not require `tar` to be in container, use the standard
image export code that we already have and find the files we
want.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This currently only changes the `gcp` target, but is the new
model - the `build` command will only do things locally, then
you need to `push` to an image store such as GCP or other ones
in order to `run` for platforms that cannot boot directly from
a local image.
Fix#1618
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP defines some "standard" environment variables for project and
zone. Use them for 'moby run gcp'. Change the other environment
variables to follow the same pattern.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This uses the Packet.net API and iPXE to boot a Moby host.
There are several enhancements coming soon, such as SSH key
customisation, but this PR is sufficient to boot a host and
then use the web interface to get console access.
The user must currently upload the built artefacts to a public
URL and specify it via --base-url, e.g.:
moby run packet --api-key <key> --project-id <id> \
--base-url http://recoil.org/~avsm/ipxe --hostname test-moby packet
See #1424#1245 for related issues.
Signed-off-by: Anil Madhavapeddy <anil@docker.com>
This makes gcp behave in a similar way to the qemu backend.
The minimum size on GCP 1GB, whereas qemu uses 256MB.
Without this, the LTP tests fail on GCP.
Signed-off-by: Dave Tucker <dt@docker.com>
Adds an "access config" with a type of "ONE_TO_ONE_NAT" that
allows an instance to obtain an ephemeral IP address and access the
internet
Signed-off-by: Dave Tucker <dt@docker.com>
As suggested by @shykes these are clearer
- onboot for things that are run at boot time to completion
- services for persistent services
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This allows overriding the name used of the file in google storage,
image name or instance name. This will vary depending on how much `moby
run` is doing which is goverened by whether the positional argument
contains an `.img.tar.gz` or not.
For example:
`moby run gcp -img-name test-ea34d1 test` creates an instance called
`test-ea34d1` from the image `test`
`moby run gcp -img-name test-ea34d1` test.img.tar.gz` will upload the
file as `test-ea34d1.tar.gz`, create image `test-ea34d1` and create an
instance called `test-ea34d1`.
The use case for this is for CI to be able to spawn many concurrent test
machines and provide it's own name for them.
Signed-off-by: Dave Tucker <dt@docker.com>
- masked paths
- readonly paths
- allow attaching to existing namespaces, eg if bind mounted by a system container
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Pass version and git commit hash from the Makefile
into main.go. Add a 'version' subcommand to print
the information.
While at it also tweak the help output to only print the
command name and not the entire path.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Something like "moby-4.10.yml" did not work when invoked
like "moby build moby-4.10".
While at it, also allow .yaml as an extension.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This refactors the mount handling, without changing any defaults.
Any specification of a mount destination will override the default,
so if you want to make `sysfs` read only you can add
```
mounts:
- type: sysfs
options: ["ro"]
```
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit implements `moby run gcp` which allows for testing of moby
images on the Google Cloud Platform
This backend attaches (via SSH) to the serial console.
It generates instance-only SSH keys and adds the public key to the
image metadata. These are used by the `moby` tool only.
It will also automatically upload a file and creates an image if the prefix
given to `moby run` is a filename
Signed-off-by: Dave Tucker <dt@docker.com>
This commit uses the older GCP API as it supports both compute and
storage. As a result, we can now use either Application Default
Credentials that are generated using the `gcloud` tool or by supplying the
service account credentials in JSON format
Signed-off-by: Dave Tucker <dt@docker.com>
This adds every capability. We had this before the OCI changes as we
passed these values to Docker. Makes fully privileged containers less verbose.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In the riddler change I changed "command" in the yaml to "args"
but did not change the files. In fact we basically used the
default command everywhere so this did not actually break.
Remove the unnecessary "command" lines to simplify yaml.
Revert the command to args change for now as I think I prefer
command, but its easier to switch now. Need to think if the
entrypoint/command distinction matters before finalizing.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We are generally outputting to stdout pipe which the log driver does
not cope with very well; always did this in older builds.
Saves another 5% of build time.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Generated largely from the specified config; small parts taken from `docker image inspect`,
such as the command line.
Renamed some of the yaml keys to match the OCI spec rather than Docker Compose as
we decided they are more readable, no more underscores.
Add some extra functionality
- tmpfs specification
- fully general mount specification
- no new privileges can be specified now
For nostalgic reasons, using engine-api to talk to the docker cli as
we only need an old API version, and it is nice and easy to vendor...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is compatible with containerd 8353da59c6ae7e1933aac2228df23541ef8b163f
which was picked up by d2caae4c1a.
This required jiggering with riddler output some more to update to new OCI
config.json format for capabilities.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Add a -data option to the HyperKit "run" backend. This either
adds a string or a file to a ISO which is attached to the VM.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Separating command line option parsing from executing hyperkit
makes the code awkward with many parameters passed between functions.
Having everything in one function makes the code simpler.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This provides a consistent UX between build and run:
moby build foo # build from foo.yml
moby run foo # boot, e.g., foo-bzImage, foo-initrd.img
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Some users seem to have Docker for Mac/hyperkit in a non-standard
path. Allow them to specify the path to the hyperkit executable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Move HyperKit code into a separate file. It should be compilable
on all supported OSes now.
- Add a (optional) subcommand to "moby run" to select a backend
i.e., "moby run hyperkit [options] [prefix]"
- On macOS the default is "hyperkit" so that:
"moby run [options] [prefix]"
just works
- Add enough command line parsing to make it easy to add new
backends to the run command
Update help messages.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This formatter strips the prefix from Info() events to
make the default output of "moby build" more readable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This adds log.Info() to the main steps of the "moby build"
process. By default the Info() output is shown to the user
so it provides some idea of progress and what is happening.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
docker-compose and other utilities use the .yml extension.
For consistency rename all .yaml to .yml
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- this removes the use of riddler to extract the rootfs, use code
we were using for rootfs. riddler now just geenrates the config,
next stage is to generate this ourselves
- change the naming of the daemons so no longer include number as we
do not guarantee ordering as they start up simultaneously
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Corrected naming from vmware->vmdk and fixed Makfile
Fixed mistake outputting a vhd instead of a vmdk in output.go
Build vmdk image and added to Docker Hub, corrected link in output.go
Modified directories to confirm to standard mkimage-<imgType>
Signed-off-by: Dan Finneran <dan@thebsdbox.co.uk>
Removing the left over indirect creates that use the Docker socket
and run in containers not directly.
See #1347
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
'moby run' will use the kernel and initrd image produced
by 'moby build' and, on macOS, will run it inside a
hyperkit VM. This assumes that you have a recent version
of Docker for Mac installed as it re-uses the hyperkit
and VPNKit from it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Trying to find the relevant yaml file was an issue as we now support
`--name` and it might be in a different directory, so although it is
a bit verbose outputing a whole file at least it is more consistent.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- this needs improvements to make it more "platform native", in
particular GCP supports multiple users and more ssh key mangement
options.
- at present you can login as root with any platform ssh key
- add support for uts=host and ipc=host
- set the hostname from the metadata as well
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- the `public` option was not previously implemented
- add `replace` only for GCP images which will error otherwise. Only
recommended for use in development, in production use the `--name` option
to provide a different name eaxch time. Note only applies to GCP images,
will document these options properly soon.
- add a `family` option; this allows you to upload many images and the
user can select the latest using the `family` option instead of a specific
image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This sets the base name of the built images which otherwise
defaults to the basename of your yaml file. This allows
building different versions easily eg adding git sha to the
output names.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This requires switching to the dosfstools from alpine:edge since neither the
busybox nor alpine:3.5 dosfstools supports the -C option (in fact alpine:3.5
only has mkfs.fat and not mkfs.vfat).
The 511k slack seems like a lot to me, but 256k was somehow not enough.
Fixes#1304.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
- the image upload uses the cloud API
- currently auth and image creation need the `gcloud` CLI tool.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- VHD is uncompressed VHD. Currently hard coded at 1GB, which may need to change. Use `format: vhd`
- GCE is the GCE compressed tarred raw image. Use `format: gce-img` - reserving `gce` for actually
uploading the image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
from:
2017/03/07 09:59:30 Failed to extract kernel image and tarball
to
2017/03/07 10:06:04 Failed to extract kernel image and tarball: Unable to find image 'mobylinux/kernel:7fa748810d7866797fd807a5682d5cb3c9c98111' locally
Signed-off-by: Tycho Andersen <tycho@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Note that the EFI ISO is not yet automatically sized, and the
kernel command lines are currently hard coded in the builders.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- split out config processing a bit
- just use `capabilities` not `cap-add` and `cap-drop`
- allow use of CAP_ prefix on capabilities, as this is what `runc` uses
- add nginx to example config
- fix bind mounts
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
_This list is currently under construction. Please add your use cases to this with a PR. Thanks!_
# Production Users
**_[Docker Desktop](https://www.docker.com/products/docker-desktop)_** - Docker Desktop for Mac and Windows uses LinuxKit to provide an embedded, invisible virtual machine in order to run Linux containers and to run Kubernetes. There are currently millions of active users.
**_[TagHub](https://www.taghub.net)_** - TagHub is a SaaS product for doing asset management. We use LinuxKit to have small and secure linux nodes powering our multi-cloud infrastructure. TagHub is made by [Smart Management](http://www.smartm.no/).
# Projects Using LinuxKit
**_[LinuxKit Nix](https://github.com/nix-community/linuxkit-nix)_** aims to provide a Linux Nix VM for macOS.
**_[cfdev](https://github.com/cloudfoundry-incubator/cfdev)_** A fast and easy local Cloud Foundry experience on native hypervisors, powered by LinuxKit with VPNKit
**_[dm-linuxkit](https://github.com/dotmesh-io/dm-linuxkit)_** A dotmesh controller for LinuxKit persistent storage management.
**_[Zenbuild](https://github.com/zededa/zenbuild)_** Linuxkit based IoT Edge Operating System (Zenix)
@@ -10,12 +10,13 @@ LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.
- Completely stateless, but persistent storage can be attached
- Easy tooling, with easy iteration
- Built with containers, for running containers
- Designed to create [reproducible builds](./docs/reproducible-builds.md) [WIP]
- Designed for building and running clustered applications, including but not limited to container orchestration such as Docker or Kubernetes
- Designed from the experience of building Docker Editions, but redesigned as a general-purpose toolkit
- Designed to be managed by external tooling, such as [Infrakit](https://github.com/docker/infrakit) or similar tools
- Includes a set of longer-term collaborative projects in various stages of development to innovate on kernel and userspace changes, particularly around security
LinuxKit currently supports the `x86_64`, `arm64`, and `s390x` architectures on a variety of platforms, both as virtual machines and baremetal (see [below](#booting-and-testing) for details.
LinuxKit currently supports the `x86_64`, `arm64`, and `s390x` architectures on a variety of platforms, both as virtual machines and baremetal (see [below](#booting-and-testing) for details).
## Subprojects
@@ -24,6 +25,7 @@ LinuxKit currently supports the `x86_64`, `arm64`, and `s390x` architectures on
- [linux](https://github.com/linuxkit/linux) A copy of the Linux stable tree with branches LinuxKit kernels.
- [virtsock](https://github.com/linuxkit/virtsock) A `go` library and test utilities for `virtio` and Hyper-V sockets.
- [rtf](https://github.com/linuxkit/rtf) A regression test framework used for the LinuxKit CI tests (and other projects).
- [homebrew](https://github.com/linuxkit/homebrew-linuxkit) Homebrew packages for the `linuxkit` tool.
## Getting Started
@@ -58,8 +60,6 @@ linuxkit build linuxkit.yml
to build the example configuration. You can also specify different output formats, eg `linuxkit build -format raw-bios linuxkit.yml` to
output a raw BIOS bootable disk image, or `linuxkit build -format iso-efi linuxkit.yml` to output an EFI bootable ISO image. See `linuxkit build -help` for more information.
Since `linuxkit build` is built around the [Moby tool](https://github.com/moby/tool) the input yml files are described in the [Moby tool documentation](https://github.com/moby/tool/blob/master/docs/yaml.md).
### Booting and Testing
You can use `linuxkit run <name>` or `linuxkit run <name>.<format>` to
@@ -117,7 +117,7 @@ To customise, copy or modify the [`linuxkit.yml`](linuxkit.yml) to your own `fil
generate its specified output. You can run the output with `linuxkit run file`.
The yaml file specifies a kernel and base init system, a set of containers that are built into the generated image and started at boot time. You can specify the type
of artifact to build with the `moby` tool eg `linuxkit build -format vhd linuxkit.yml`.
of artifact to build eg `linuxkit build -format vhd linuxkit.yml`.
If you want to build your own packages, see this [document](docs/packages.md).
@@ -131,7 +131,7 @@ The yaml format specifies the image to be built:
-`services` is the system services, which normally run for the whole time the system is up
-`files` are additional files to add to the image
For a more detailed overview of the options see [yaml documentation](https://github.com/moby/tool/blob/master/docs/yaml.md)
For a more detailed overview of the options see [yaml documentation](docs/yaml.md)
## Architecture and security
@@ -156,7 +156,11 @@ This is an open project without fixed judgements, open to the community to set t
## Development reports
There are weekly [development reports](reports/) summarizing work carried out in the week.
There are monthly [development reports](reports/) summarising the work carried out each month.
## Adopters
We maintain an incomplete list of [adopters](ADOPTERS.md). Please open a PR if you are using LinuxKit in production or in your project, or both.
In the packages section you can find an image to setup dm-crypt encrypted devices in [linuxkit](https://github.com/linuxkit/linuxkit)-generated images.
The above will map `/dev/sda1` as an encrypted device under `/dev/mapper/dm_crypt_name` and mount it under `/var/secure_storage`
The `dm-crypt` container by default bind-mounts `/dev:/dev` and `/etc/dm-crypt:/etc/dm-crypt`. It expects the encryption key to be present in the file `/etc/dm-crypt/key`. You can pass an alternative location as encryption key which can be either a file path relative to `/etc/dm-crypt` or an absolute path.
Providing an alternative encryption key file name:
Note that you have to also map `/dev:/dev` explicitly if you override the default bind-mounts.
The `dm-crypt` container
* Will create an `ext4` file system on the encrypted device if none is present.
* It will also initialize the encrypted device by filling it from `/dev/zero` prior to creating the filesystem. Which means if the device is being setup for the first time it might take a bit longer.
* Uses the `aes-cbc-essiv:sha256` cipher (it's explicitly specified in case the default ever changes)
* Consequently the encryption key is expected to be 32 bytes long, a random one can be created via
```shell
dd if=/dev/urandom of=dm-crypt.key bs=32 count=1
```
If you see the error `Cannot read requested amount of data.` next to the log message `Creating dm-crypt mapping for ...` then this means your keyfile doesn't contain enough data.
### Examples
There are two examples in the `examples/` folder:
1. `dm-crypt.yml` - formats an external disk and mounts it encrypted.
2. `dm-crypt-loop.yml` - mounts an encrypted loop device backed by a regular file sitting on an external disk
### Options
|Option|Default|Required|Notes|
|---|---|---|---|
|`-k` or `--key`|`key`|No|Encryption key file name. Must be either relative to `/etc/dm-crypt` or an absolute file path.|
|`-l` or `--luks`||No|Use LUKS format for encryption|
|`<dm_name>`||**Yes**|The device-mapper device name to use. The device will be mapped under `/dev/mapper/<dm_name>`|
@@ -30,3 +30,49 @@ of dependencies and functionality that we do not need. At present we are using t
`init` process, and a small set of minimal scripts, but we expect to replace that with a small
standalone `init` process and a small piece of code to bring up the system containers where the
real work takes place.
## Console not displaying init or containerd output at boot
If you're not seeing `containerd` logs in the console during boot, make sure that your kernel `cmdline` configuration doesn't list multiple consoles.
`init` and other processes like `containerd` will use the last defined console in the kernel `cmdline`. When using `qemu`, to see the console you need to list `ttyS0` as the last console to properly see the output.
## Troubleshooting containers
Linuxkit runs all services in a specific `containerd` namespace called `services.linuxkit`. To list all the defined containers:
```sh
(ns: getty) linuxkit-befde23bc535:~# ctr -n services.linuxkit container ls
CONTAINER IMAGE RUNTIME
getty - io.containerd.runtime.v1.linux
```
To list all running containers and their status:
```sh
(ns: getty) linuxkit-befde23bc535:~# ctr -n services.linuxkit task ls
Image to setup a loop device backed by a regular file in a [linuxkit](https://github.com/linuxkit/linuxkit)-generated image. The typical use case is to have a portable storage location which can be used to persist settings or other files. Can be combined with the `linuxkit/dm-crypt` package for protection.
## Usage
The setup is a one time step during boot:
```yaml
onboot:
- name:losetup
image:linuxkit/losetup:<hash>
command:["/usr/bin/loopy","-c","/var/test.img"]
```
The above will associate the file `/var/test.img` with `/dev/loop0` and will also create it if it's not present.
The container by default bind-mounts `/var:/var` and `/dev:/dev`. Usually the loop-file will reside on external storage which should be typically mounted under `/var` hence the choice of the defaults. If the loop-file is located somewhere else and you need a different bind-mount for it then do not forget to explicitly bind-mount `/dev:/dev` as well or else `losetup` will fail.
### Options
|Option|Default|Required|Notes|
|---|---|---|---|
|`-c` or `--create`||No|Creates the file if not present. If `--create` is not specified and the file is missing then the loop setup will obviously fail.|
|`-s` or `--size`|10|No|If `--create` was specified and the file is not present then this sets the size in MiB of the created file. The file will be filled from `/dev/zero`.|
|`-d` or `--dev`|`/dev/loop0`|No|Loop device which should be associated with the file.|
|`<file>`||**Yes**|The file to use as backing storage.|
@@ -37,6 +37,7 @@ A package source consists of a directory containing at least two files:
-`image`_(string)_: *(mandatory)* The name of the image to build
-`org`_(string)_: The hub/registry organisation to which this package belongs
-`arches`_(list of string)_: The architectures which this package should be built for (valid entries are `GOARCH` names)
-`extra-sources`_(list of strings)_: Additional sources for the package outside the package directory. The format is `src:dst`, where `src` can be relative to the package directory and `dst` is the destination in the build context. This is useful for sharing files, such as vendored go code, between packages.
-`gitrepo`_(string)_: The git repository where the package source is kept.
-`network`_(bool)_: Allow network access during the package build (default: no)
-`disable-content-trust`_(bool)_: Disable Docker content trust for this package (default: no)
* You have to set `root=/dev/vda` in the `cmdline` to have the right device set on boot
* The metadata package is not only used to set the metadata, but also to signal Scaleway that the instance has booted. So it is encouraged to use it (dhcpcd must be set before)
## Push image
You have to do `linuxkit push scaleway scaleway.iso` to upload it to your Scaleway images.
By default the image name is the name of the ISO file without the extension.
It can be overidden with the `-img-name` flag or the `SCW_IMAGE_NAME` environment variable.
**Note 1:** If an image (and snapshot) of the same name exists, it will be replaced.
**Note 2:** The image is region specific: if you create an image in `par1` you can't use is in `ams1`.
### Push process
Building a Scaleway image have a special process. Basically:
* Create an `image-builder` instance with an additional volume, based on Ubuntu Xenial (only x86_64 for now)
* Copy the ISO image on this instance
* Use `dd` to write the image on the additional volume (`/dev/vdb` by default)
* Terminate the instance, create a snapshot, and create an image from the snapshot
**Note 1:** An image is linked to a snapshot, so you can't delete a snapshot before the image.
**Note 2:** You can specify an already running instance to act as the image builder with the `-instance-id` flag. But if you don't specify the `-no-clean` flag it will be destroyed upon completion.
## Create an instance and connect to it
With the image created, we can now create an instance.
```
linuxkit run scaleway scaleway
```
By default, the instance name is `linuxkit`. It can be overidden with the `-instance-name` flag.
If you don't set the `-no-attach` flag, you will be connected to the serial port.
You can edit the Scaleway example to allow you to SSH to your instance in order to use it.
git commit -a -s -m "pkgs: Update packages to the latest linuxkit/alpine"
git push $LK_REMOTE rel_$LK_RELEASE
```
Most of the packages are build from `linuxkit/alpine` and source code
in the `linuxkit` repository, but some packages wrap external
tools. The time of a release is a good opportunity to check if there
have been updates. Specifically:
-`pkg/cadvisor`: Check for [new releases](https://github.com/google/cadvisor/releases).
-`pkg/firmware` and `pkg/firmware-all`: Use latest commit from [here](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git).
-`pkg/node_exporter`: Check for [new releases](https://github.com/prometheus/node_exporter/releases).
- Check [docker hub](https://hub.docker.com/r/library/docker/tags/) for the latest `dind` tags. and update `examples/docker.yml`, `examples/docker-for-mac.yml`, `examples/cadvisor.yml`, and `test/cases/030_security/000_docker-bench/test.yml` if necessary.
The build/push the packages:
```sh
cd$LK_ROOT/pkg
make OPTIONS="-release $LK_RELEASE" push
```
Note, the `OPTIONS` argument. This adds the release tag to the
git commit -a -s -m "Update package tags to $LK_RELEASE"
```
### Final preparation steps
- Update AUTHORS by running `./scripts/generate-authors.sh`
- Update the `VERSION` variable in the top-level `Makefile`
- Create an entry in `CHANGELOG.md`. Take a look at `git log v0.3..HEAD` and pick interesting updates (of course adjust `v0.3` to the previous version).
- Create a PR with your changes.
## Releasing
Once the PR is merged we can do the actual release.
- Update your local git clone to the lastest
- Identify the merge commit for your PR and tag it and push it to the main LinuxKit repository (remote `upstream` in my case):
```
git tag $LK_RELEASE master
git push upstream $LK_RELEASE
```
Then head over to GitHub and look at the `Releases` tab. You should see the new tag. Edit it:
- Add the changelog message
- Head over to the Circle CI page of the master build (try the Circle CI badge in the top level `README.md`)
- Download the artefacts and SHA256 sums file.
- Add the downloaded binaries to the release page (drag-and-drop below the editor window)
- Add the `sha256` sums to the release notes on the release page
Hit the `Publish release` button.
This completes the release, but you are not done, one more step is required.
## Post release
Create a PR which bumps the version number in the top-level `Makefile`
to `$LK_RELEASE+` to make sure that the version reported by `linuxkit
The `linuxkit build` command assembles a set of containerised components into in image. The simplest
type of image is just a `tar` file of the contents (useful for debugging) but more useful
outputs add a `Dockerfile` to build a container, or build a full disk image that can be
booted as a linuxKit VM. The main use case is to build an assembly that includes
`containerd` to run a set of containers, but the tooling is very generic.
The yaml configuration specifies the components used to build up an image . All components
are downloaded at build time to create an image. The image is self-contained and immutable,
so it can be tested reliably for continuous delivery.
Components are specified as Docker images which are pulled from a registry during build if they
are not available locally. The Docker images are optionally verified with Docker Content Trust.
For private registries or private repositories on a registry credentials provided via
`docker login` are re-used.
The configuration file is processed in the order `kernel`, `init`, `onboot`, `onshutdown`,
`services`, `files`. Each section adds files to the root file system. Sections may be omitted.
Each container that is specified is allocated a unique `uid` and `gid` that it may use if it
wishes to run as an isolated user (or user namespace). Anywhere you specify a `uid` or `gid`
field you specify either the numeric id, or if you use a name it will refer to the id allocated
to the container with that name.
```
services:
- name: redis
image: redis:latest
uid: redis
gid: redis
binds:
- /etc/redis:/etc/redis
files:
- path: /etc/redis/redis.conf
contents: "..."
uid: redis
gid: redis
mode: "0600"
```
## `kernel`
The `kernel` section is only required if booting a VM. The files will be put into the `boot/`
directory, where they are used to build bootable images.
The `kernel` section defines the kernel configuration. The `image` field specifies the Docker image,
which should contain a `kernel` file that will be booted (eg a `bzImage` for `amd64`) and a file
called `kernel.tar` which is a tarball that is unpacked into the root, which should usually
contain a kernel modules directory. `cmdline` specifies the kernel command line options if required.
To override the names, you can specify the kernel image name with `binary: bzImage` and the tar image
with `tar: kernel.tar` or the empty string or `none` if you do not want to use a tarball at all.
Kernel packages may also contain a cpio archive containing CPU microcode which needs prepending to
the initrd. To select this option, recommended when booting on bare metal, add `ucode: intel-ucode.cpio`
to the kernel section.
## `init`
The `init` section is a list of images that are used for the `init` system and are unpacked directly
into the root filesystem. This should bring up `containerd`, start the system and daemon containers,
and set up basic filesystem mounts. in the case of a LinuxKit system. For ease of
modification `runc` and `containerd` images, which just contain these programs are added here
rather than bundled into the `init` container.
## `onboot`
The `onboot` section is a list of images. These images are run before any other
images. They are run sequentially and each must exit before the next one is run.
These images can be used to configure one shot settings. See [Image
specification](#image-specification) for a list of supported fields.
## `onshutdown`
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
## `services`
The `services` section is a list of images for long running services which are
run with `containerd`. Startup order is undefined, so containers should wait
on any resources, such as networking, that they need. See [Image
specification](#image-specification) for a list of supported fields.
## `files`
The files section can be used to add files inline in the config, or from an external file.
```
files:
- path: dir
directory: true
mode: "0777"
- path: dir/name1
source: "/some/path/on/local/filesystem"
mode: "0666"
- path: dir/name2
source: "/some/path/that/it/is/ok/to/omit"
optional: true
mode: "0666"
- path: dir/name3
contents: "orange"
mode: "0644"
uid: 100
gid: 100
```
Specifying the `mode` is optional, and will default to `0600`. Leading directories will be
created if not specified. You can use `~/path` in `source` to specify a path in the build
user's home directory.
In addition there is a `metadata` option that will generate the file. Currently the only value
supported here is `"yaml"` which will output the yaml used to generate the image into the specified
file:
```
- path: etc/linuxkit.yml
metadata: yaml
```
Because a `tmpfs` is mounted onto `/var`, `/run`, and `/tmp` by default, the `tmpfs` mounts will shadow anything specified in `files` section for those directories.
## `trust`
The `trust` section specifies which build components are to be cryptographically verified with
[Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) prior to pulling.
Trust is a central concern in any build system, and LinuxKit's is no exception: Docker Content Trust provides authenticity,
integrity, and freshness guarantees for the components it verifies. The LinuxKit maintainers are responsible for signing
`linuxkit` components, though collaborators can sign their own images with Docker Content Trust or [Notary](https://github.com/docker/notary).
-`image` lists which individual images to enforce pulling with Docker Content Trust.
The image name may include tag or digest, but the matching also succeeds if the base image name is the same.
-`org` lists which organizations for which Docker Content Trust is to be enforced across all images,
for example `linuxkit` is the org for `linuxkit/kernel`
## Image specification
Entries in the `onboot` and `services` sections specify an OCI image and
options. Default values may be specified using the `org.mobyproject.config` image label.
For more details see the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md).
If the `org.mobylinux.config` label is set in the image, that specifies default values for these fields if they
are not set in the yaml file. You can override the label by setting the value, or setting it to be empty to remove
the specification for that value in the label.
If you need an OCI option that is not specified here please open an issue or pull request as the list is not yet
complete.
By default the containers will be run in the host `net`, `ipc` and `uts` namespaces, as that is the usual requirement;
in many ways they behave like pods in Kubernetes. Mount points must already exist, as must a file or directory being
bind mounted into a container.
-`name` a unique name for the program being executed, used as the `containerd` id.
-`image` the Docker image to use for the root filesystem. The default command, path and environment are
extracted from this so they need not be filled in.
-`capabilities` the Linux capabilities required, for example `CAP_SYS_ADMIN`. If there is a single
capability `all` then all capabilities are added.
-`ambient` the Linux ambient capabilities (capabilities passed to non root users) that are required.
-`mounts` is the full form for specifying a mount, which requires `type`, `source`, `destination`
and a list of `options`. If any fields are omitted, sensible defaults are used if possible, for example
if the `type` is `dev` it is assumed you want to mount at `/dev`. The default mounts and their options
can be replaced by specifying a mount with new options here at the same mount point.
-`binds` is a simpler interface to specify bind mounts, accepting a string like `/src:/dest:opt1,opt2`
similar to the `-v` option for bind mounts in Docker.
-`tmpfs` is a simpler interface to mount a `tmpfs`, like `--tmpfs` in Docker, taking `/dest:opt1,opt2`.
-`command` will override the command and entrypoint in the image with a new list of commands.
-`env` will override the environment in the image with a new environment list. Specify variables as `VAR=value`.
-`cwd` will set the working directory, defaults to `/`.
-`net` sets the network namespace, either to a path, or if `none` or `new` is specified it will use a new namespace.
-`ipc` sets the ipc namespace, either to a path, or if `new` is specified it will use a new namespace.
-`uts` sets the uts namespace, either to a path, or if `new` is specified it will use a new namespace.
-`pid` sets the pid namespace, either to a path, or if `host` is specified it will use the host namespace.
-`readonly` sets the root filesystem to read only, and changes the other default filesystems to read only.
-`maskedPaths` sets paths which should be hidden.
-`readonlyPaths` sets paths to read only.
-`uid` sets the user id of the process.
-`gid` sets the group id of the process.
-`additionalGids` sets a list of additional groups for the process.
-`noNewPrivileges` is `true` means no additional capabilities can be acquired and `suid` binaries do not work.
-`hostname` sets the hostname inside the image.
-`oomScoreAdj` changes the OOM score.
-`rootfsPropagation` sets the rootfs propagation, eg `shared`, `slave` or (default) `private`.
-`cgroupsPath` sets the path for cgroups.
-`resources` sets cgroup resource limits as per the OCI spec.
-`sysctl` sets a map of `sysctl` key value pairs that are set inside the container namespace.
-`rmlimits` sets a list of `rlimit` values in the form `name,soft,hard`, eg `nofile,100,200`. You can use `unlimited` as a value too.
-`annotations` sets a map of key value pairs as OCI metadata.
There are experimental `userns`, `uidMappings` and `gidMappings` options for user namespaces but these are not yet supported, and may have
permissions issues in use.
In addition to the parts of the specification above used to generate the OCI spec, there is a `runtime` section in the image specification
which specifies some actions to take place when the container is being started.
-`cgroups` takes a list of cgroups that will be created before the container is run.
-`mounts` takes a list of mount specifications (`source`, `destination`, `type`, `options`) and mounts them in the root namespace before the container is created. It will
try to make any missing destination directories.
-`mkdir` takes a list of directories to create at runtime, in the root mount namespace. These are created before the container is started, so they can be used to create
directories for bind mounts, for example in `/tmp` or `/run` which would otherwise be empty.
-`interface` defines a list of actions to perform on a network interface:
-`name` specifies the name of an interface. An existing interface with this name will be moved into the container's network namespace.
-`add` specifies a type of interface to be created in the containers namespace, with the specified name.
-`createInRoot` is a boolean which specifes that the interface being `add`ed should be created in the root namespace first, then moved. This is needed for `wireguard` interfaces.
-`peer` specifies the name of the other end when creating a `veth` interface. This end will remain in the root namespace, where it can be attached to a bridge. Specifying this implies `add: veth`.
-`bindNS` specifies a namespace type and a path where the namespace from the container being created will be bound. This allows a namespace to be set up in an `onboot` container, and then
using `net: path` for a `service` container to use that network namespace later.
-`namespace` overrides the LinuxKit default containerd namespace to put the container in; only applicable to services.
An example of using the `runtime` config to configure a network namespace with `wireguard` and then run `nginx` in that namespace is shown below:
command: ["sh", "-c", "ip link set dev wg0 up; ip address add dev wg0 192.168.2.1 peer 192.168.2.2; wg setconf wg0 /etc/wireguard/wg0.conf; wg show wg0"]
runtime:
interfaces:
- name: wg0
add: wireguard
createInRoot: true
bindNS:
net: /run/netns/wg
services:
- name: nginx
image: nginx:alpine
net: /run/netns/wg
capabilities:
- CAP_NET_BIND_SERVICE
- CAP_CHOWN
- CAP_SETUID
- CAP_SETGID
- CAP_DAC_OVERRIDE
```
### Mount Options
When mounting filesystem paths into a container - whether as part of `onboot` or `services` - there are several options of which you need to be aware. Using them properly is necessary for your containers to function properly.
For most containers - e.g. nginx or even docker - these options are not needed. Simply doing the following will work fine:
```yml
binds:
- /var:/some/var/path
```
Please note that `binds` doesn't **add** the mount points, but **replaces** them.
You can examine the `Dockerfile` of the component (in particular, `binds` value of
`org.mobyproject.config` label) to get the list of the existing binds.
However, in some circumstances you will need additional options. These options are used primarily if you intend to make changes to mount points _from within your container_ that should be visible from outside the container, e.g., if you intend to mount an external disk from inside the container but have it be visible outside.
In order for new mounts from within a container to be propagated, you must set the following on the container:
1.`rootfsPropagation: shared`
2. The mount point into the container below which new mounts are to occur must be `rshared,rbind`. In practice, this is `/var` (or some subdir of `/var`), since that is the only true read-write area of the filesystem where you will mount things.
Thus, if you have a regular container that is only reading and writing, go ahead and do:
```yml
binds:
- /var:/some/var/path
```
On the other hand, if you have a container that will make new mounts that you wish to be visible outside the container, do:
- * @mode: timer mode, HRTIMER_MODE_ABS or HRTIMER_MODE_REL
+ * @mode: timer mode
*
* Make the current task sleep until the given expiry time has
* elapsed. The routine will return immediately unless
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
