See https://github.com/koalaman/shellcheck/wiki/SC2006 for details.
Not only uses this the recommended construct, it also makes the code
more uniform as in many other places the $() construct was already used.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
The 'which' command is deprecated on Debian Sid as it is not POSIX
compliant and it's behavior is therefor not consistent, so replace it
with 'command -v' which is POSIX compliant.
See https://stackoverflow.com/a/677212 for details.
Also replaced a use of backticks (`) as that is deprecated as well.
See https://github.com/koalaman/shellcheck/wiki/SC2006 for details.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
``/proc`` might be mounted with ``hidepid=2``.
This makes ``/proc/1/…`` appear absent for non-root users.
When using the templates or the nvidia hook as a non-root user
(e.g., when creating unprivileged containers) the error
"/proc/1/uid_map: No such file or directory" is printed.
Since the script works correctly despite the error, this error
message might be confusing for users.
Signed-off-by: Lukas Pirl <git@lukas-pirl.de>
The "display" driver capability will expose /dev/nvidia-modeset:
9398d41d9f
The "--ldcache" argument allows overriding the location of the DSO cache:
41656bf9ed
The "--root" argument allows nvidia-container-cli to execute in a different rootfs:
019fdc14e3
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
For a reason that I don't understand, the profile transition needs to
be done on the current process. Changing the attributes for a
subsequent execve(2) (with /proc/self/attr/exec) will cause the kernel
to set AT_SECURE in the auxiliary vector and thus secure_getenv(3)
inside libnvidia-container will return NULL.
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
With LXC, you can override the value of an environment variable to
null, but you can't unset an existing variable.
The NVIDIA hook was previously activated when NVIDIA_VISIBLE_DEVICES
was set to null. As a result, it was not possible to disable the hook
by overriding the environment variable in the configuration.
The hook can now be disabled by setting NVIDIA_VISIBLE_DEVICES to
null or to the new special value "void".
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
- Merge dhclient-start and dhclient-stop into a single hook.
- Wait for a lease before returning from the hook.
- Generate a logfile when LXC log level is either DEBUG or TRACE.
- Rely on namespace file descriptors for the stop hook.
- Use settings from /<sysconf>/lxc/dhclient.conf if available.
- Attempt to cleanup if dhclient fails to shutdown properly.
Signed-off-by: Jonathan Calmels <jcalmels@nvidia.com>
This hook requires the nvidia-container-cli tool provided by libnvidia-container:
https://github.com/nvidia/libnvidia-container
For containers that do not have CUDA_VERSION or NVIDIA_VISIBLE_DEVICES
set in the environment, the hook will be a no-op.
To enable in the configuration file:
lxc.hook.mount = /usr/local/share/lxc/hooks/nvidia
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
Add new hooks leveraging dhclient from the host to automatically
configure the container interfaces. This is especially useful for
application containers which rely on an IPAM driver for network
configuration (e.g. Docker).
Signed-off-by: Jonathan Calmels <jcalmels@nvidia.com>
Previously this hook did not work when cloning containers using an overlayfs snapshot as the LXC_ROOTFS_PATH didn't point to the actual filesystem that the container would see. LXC_ROOTFS_MOUNT should be used instead and in fact lxc.container.conf man page says that you usually would want to use the _MOUNT variant.
Signed-off-by: Matt Keeler <mjkeeler7@gmail.com>
vendor-data is supported in Ubuntu cloud images in trusty and later.
This allows the user to pass it in on create or clone.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
Also fix the comment in lxc-cirros template (which I overlooked last time).
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This is a rather massive cleanup of config/templates/*
As new templates were added, I've noticed that we pretty much all share
the tty/pts configs, some capabilities being dropped and most of the
cgroup configuration. All the userns configs were also almost identical.
As a result, this change introduces two new files:
- common.conf.in
- userns.conf.in
Each is included by the relevant <template>.<type>.conf.in templates,
this means that the individual per-template configs are now overlays on
top of the default config.
Once we see a specific key becoming popular, we ought to check whether
it should also be applied to the other templates and if more than 50% of
the templates have it set to the same value, that value ought to be
moved to the master config file and then overriden for the templates
that do not use it.
This change while pretty big and scary, shouldn't be very visible from a
user point of view, the actual changes can be summarized as:
- Extend clonehostname to work with Debian based distros and use it for
all containers.
- lxc.pivotdir is now set to lxc_putold for all templates, this means
that instead of using /mnt in the container, lxc will create and use
/lxc_putold instead. The reason for this is to avoid failures when the
user bind-mounts something else on top of /mnt.
- Some minor cgroup limit changes, the main one I remember is
/dev/console now being writable by all of the redhat based containers.
The rest of the set should be identical with additions in the per-distro
ones.
- Drop binfmtmisc and efivars bind-mounts for non-mountall based
unpriivileged containers as I assumed they got those from copy/paste
from Ubuntu and not because they actually need those entries. (If I'm
wrong, we probably should move those to userns.conf then).
Additional investigation and changes to reduce the config delta between
distros would be appreciated. In practice, I only expect lxc.cap.drop
and lxc.mount.entry to really vary between distros (depending on the
init system, the rest should be mostly common.
Diff from the RFC:
- Add archlinux to the mix
- Drop /etc/hostname from the clone hook
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
I unfortunately realized that I did not push the latest version of the
file. This fixes an issue in the case where we want to create the proxy
file in the container (not nested).
Signed-off-by: Chris Glass <tribaal@gmail.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This makes the ubuntu and ubuntu-cloud templates automatically aware of apt
proxy settings when the LXC host has "squid-deb-proxy-client" installed. This
makes installations *much* faster when a suitable squid-deb-proxy is
found on the network (or installed on the host).
Signed-off-by: Chris Glass <tribaal@gmail.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
[resending the patch from correct branch]
commit 09ad624693 introduced lxc.include option
to include other config files. This patch uses it in mountcgroups hook otherwise
lxc-start fails with following error message for the nested containers;
root@oOo:/var/lib/lxc/raring# lxc-start -l debug -o l -n raring -d
lxc-start: command get_cgroup failed to receive response
Signed-off-by: S.Çağlar Onur <caglar@10ur.org>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Bug found by Vincent Ladeuil <vila+ci@canonical.com>
Fix suggested by Scott Moser <smoser@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
prior to my enabling of the clone hook, the setting of the hostname
was being done by writing to /etc/hostname. Instead of relying on that
we're now writing 'local-hostname' into the metadata for the instance.
cloud-init then reads this and sets the hostname properly.
We are also writing /etc/hostname with the new hostname explicitly. This is
useful/necessary because on network bringup of eth0, dhclient will submit its
hosname. The updating done by cloud-init occurs to late, and thus
the dhcp request goes out with the un-configured hostname and dns doens't
work correctly.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
the previous 'patch_start' can be vastly simplified now that I better
understand what the bug was. Instead of wrapping 'start', we only
need to ensure that /etc/init exists inside the overlayfs, so that the
directory that upstart watches is guaranteed to be in the overlay, not
the underlay.
The problem is described under bug 1213925.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
upstart depends on inotify, and overlayfs does not support inotify.
That means that the following results in 'tgt' not running. tgt is simply
used here as an example of a service that installs an upstart job and
starts it on package install.
lxc-clone -s -B overlayfs -o source-precise-amd64 -n test1
lxc-start -n test1
..
apt-get install tgt
The change here is to modify /sbin/start inside the container so that when
something explicitly tries 'start', it results in an explicit call to
'initctl reload-configuration' so that upstart is aware of the newly
placed job.
Should overlayfs ever gain inotify support, this should still not cause
any harm.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
--userdata was broken, completely missing an implementation.
This adds that implementation back in, makes 'debug' logic
correct, and then also improves the doc at the top.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
This allows ability to now specify '--userdata' arguments to 'create' or
to 'clone'. So now, the following means very fast start of instances with
different user-data.
$ sudo lxc-create -t ubuntu-cloud -n precise -- \
-r precise --arch amd64
$ sudo lxc-clone -B overlayfs -o precise -s -n ephem1 \
--userdata="my.userdata1"
$ sudo lxc-clone -B overlayfs -o precise -s -n ephem2 \
--userdata="my.userdata2"
Also present here is
* an improvement to the static list of Ubuntu releases. It uses
ubuntu-distro-info if available degrades back to a static list on failure.
* moving of the replacement variables to the top of the create template This
is just to make it more obvious what is being replaced and put them in a
single location.
Signed-off-by: Scott Moser <smoser@ubuntu.com>
