Eric Leblond [Wed, 4 Mar 2015 16:22:52 +0000 (17:22 +0100)]
macvlan: add 'passthru' mode
In setup where we want to sniff with an IDS from inside a container
we can use the 'passthru' mode of macvlan. This was not accessible
from the config and this patch fixes the issue.
Use POSIX-compliant function names in bash completion
When running in posix mode (for example, because it was invoked as `sh`,
or with the --posix option), bash rejects the function names previously
used because they contain hyphens, which are not legal POSIX names, and
exits immediately.
This is a particularly serious problem on a system in which the
following three conditions hold:
1. The `sh` executable is provided by bash, e. g. via a symlink
2. Gnome Display Manager is used to launch X sessions
3. Bash completion is loaded in the (system or user) profile file
instead of in the bashrc file
In that case, GDM's Xsession script (run with `sh`, i. e., bash in posix
mode) sources the profile files, thus causing the shell to load the bash
completion files. Upon encountering the non-POSIX-compliant function
names, bash would then exit, immediately ending the X session.
Fixes #521.
Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
Cyril Bitterich [Sat, 9 May 2015 19:57:14 +0000 (21:57 +0200)]
lxc-debian.in: Fixed errors if dbus is not installed
The lxc-debian template debootstraps a minimum debian system which does not contain dbus.
If systemd is used this will result in getty-static.service to be used instead of getty@ .
The systemd default files uses 6 tty's instead of the 4 the script creates.
This will lead to repeated error messages in the systemd journal.
Martin Pitt [Thu, 7 May 2015 11:38:50 +0000 (13:38 +0200)]
Call /lib/apparmor/profile-load directly instead of the wrapper
AppArmor ships /lib/apparmor/profile-load. /lib/init/apparmor-profile-load is
merely a wrapper which calls the former, so just call it directly to avoid the
dependency on the wrapper.
Kien Truong [Mon, 6 Apr 2015 16:20:43 +0000 (17:20 +0100)]
Properly free memory of sorted cgroup settings
We need to use lxc_list_for_each_safe, otherwise de-allocation
will fail with a list size bigger than 2. The pointer to the head
of the list also need freeing after we've freed all other elements
of the list.
Signed-off-by: Kien Truong <duckientruong@gmail.com>
Kien Truong [Sun, 5 Apr 2015 23:46:22 +0000 (23:46 +0000)]
Sort the cgroup memory settings before applying.
Add a function to sort the cgroup settings before applying.
Currently, the function will put memory.memsw.limit_in_bytes after
memory.limit_in_bytes setting so the container will start
regardless of the order specified in the input. Fix #453
Signed-off-by: Kien Truong <duckientruong@gmail.com>
c/r: check for criu images in the checkpoint directory
CRIU can get confused if there are two dumps that are written to the same
directory, so we make some minimal effort to prevent people from doing this.
This is a better alternative than forcing liblxc to create the directory, since
it is mostly race free (and neither solution is bullet proof anyway if someone
rsyncs some bad images over the top of the good ones).
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
This updates lxc-net with the following changes:
- Better recover from crashes/partial runs
- Better error detection and reporting
- Less code duplication (use the stop code on crash)
- Better state tracking
- Allow for restart of all of lxc-net except for the bridge itself
- Only support iproute from this point on (ifconfig's been deprecated
for years)
V2: Use template variables everywhere
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Make lxc-checkconfig work with kernel versions > 3
(1) Add test for kernel version greater 3.
(2) Use && and || instead of -a and -o as suggested in
http://www.unix.com/man-page/posix/1p/test/.
lxc-checkconfig will currently report "missing" on "Cgroup memory controller"
for kernel versions greater 3. This happens because the script, before checking
for the corresponding memory variable in the kernel config, currently will test
whether we have a major kernel version greater- or equal to 3 and a minor kernel
version greater- or equal to 6. This adds an additional test whether we have a
major kernel version greater than 3.
Signed-off-by: Christian Brauner <christianvanbrauner@gmail.com>
Particularly when using the go-lxc api with lots of threads, it
happens that if the open files limit is > 1024, we will try to
select on fd > 1024 which breaks on glibc.
logs: introduce a thread-local 'current' lxc_config (v2)
The logging code uses a global log_fd and log_level to direct
logging (ERROR(), etc). While the container configuration file allows
for lxc.loglevel and lxc.logfile, those are only used at configuration
file read time to set the global variables. This works ok in the
lxc front-end programs, but becomes a problem with threaded API users.
The simplest solution would be to not allow per-container configuration
files, but it'd be nice to avoid that.
Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible",
but would be a huge complication as there are many functions, including
struct member functions and callbacks, which don't have that info and
would need to get it from somewhere.
So the approach I'm taking here is to say that all real container work
is done inside api calls, and therefore the API calls themselves can
set a thread-local variable indicating which log info to use. If
unset, then use the global values. The lxc-* programs, when called
with a '-o logfile' argument, set a global variable to indicate that
the user-specified value should be used.
In this patch:
If the lxc container configuration specifies a loglevel/logfile, only
set the lxc_config's logfd and loglevel according to those, not the
global values.
Each API call is wrapped to set/unset the current_config. (The few
exceptions are calls which do not result in any log actions)
Update logfile appender to use the logfile specified in lxc_conf if (a)
current_config is set and (b) the lxc-* command did not override it.
Changelog (2015-04-21):
. always re-set current_config to NULL at end of an API
call, rather than storing the previous value. We don't
nest API calls.
. remove the log_lock stuff which wasn't used
. lxc_conf_free: if the config is current_config, set
current_config to NULL. (It can't be another thread's
current_config, or we wouldn't be freeing it)
. lxc_check_inherited: don't close fd if it is the
current_config->logfd. Note this is only called when
starting a container, so we have no other threads at
this point.
Changelog (2015-04-22)
. Unset the per-container logfd on destroy
.
. Do so before we rm the containerdir. Otherwise if the logfile is set
. to $lxcpath/$name/log, the containerdir won't be fully deleted.
Add an additional template parameter for SSH support in the container. Currently
this can be implemented using the Dropbear or OpenSSH utility. The respective
tool needs to be available on the host Linux.
If the parameter is omitted, the template will look for the Dropbear utility on
the host and install it if it is available (legacy behavior).
Adding OpenSSH support has been done following the model in the lxc-sshd
template.
If we don't re-open these after clone, the init process has a pointer to the
parent's /dev/{zero,null}. CRIU seese these and wants to dump the parent's
mount namespace, which is unnecessary. Instead, we should just re-open
stdin/out/err after we do the clone and pivot root, to ensure that we have
pointers to the devcies in init's rootfs instead of the host's.
v2: Only close fds if the container was daemonized. This didn't turn out as
nicely as described on the list because lxc_start() doesn't actually have
the struct lxc_container, so it cant see the flag. Instead, we just pass it
down everywhere.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
As of criu 1.5, the --veth-pair argument supports an additional parameter that
is the bridge name to attach to. This enables us to get rid of the goofy
action-script hack that passed bridge names as environment variables.
This patch is on top of the systemd/lxcfs mount rework patch, as we probably
want to wait to use 1.5 options until it has been out for a while and is in
distros.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
CRIU now supports autodetection of external mounts via the --ext-mount-map auto
--enable-external-sharing --enable-external-masters options, so we don't need
to explicitly pass the cgmanager mount or any of the mounts from the config.
This also means that lxcfs mounts (since they are bind mounts from outside the
container) are autodetected, meaning that c/r of containers using lxcfs works.
A further advantage of this patch is that it addresses some of the ugliness
that was in the exec_criu() function. There are other criu options that will
allow us to trim this even further, though.
Finally, with --enable-external-masters, criu understands slave mounts in the
container with shared mounts in the peer group that are outside the namespace.
This allows containers on a systemd host to be dumped and restored correctly.
However, these options have just landed in criu trunk today, and the next
tagged release will be 1.6 on June 1, so we should avoid merging this into any
stable releases until then.
v2: remount / as private before bind mounting the container's directory for
criu. The problem here is that if / is mounted as shared, even if we
unshare() the /var/lib/lxc/rootfs mountpoint propagates outside of our
mount namespace, which is bad, since we don't want to leak mounts. In
particular, this leak confuses criu the second time it goes to checkpoint
the container.
v3: whoops, we really want / as MS_SLAVE | MS_REC here, to match what start
does
v4: rebase onto master for revert of logging patch
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
In the past, lxc-cmd-stop would wait until the command pipe was closed
before returning, ensuring that the container monitor had exited.
Now that we accept the actual success return value, lxcapi_stop can
return success before the monitor has fully exited.
So explicitly wait for the container to stop, when lxc-cmd-stop returned
success.
1. When we stop a container from the lxc_cmd stop handler, we kill its
init task, then we unfreeze the container to make sure it receives the
signal. When that unfreeze succeeds, we were immediately returning 0,
without sending a response to the invoker.
2. lxc_cmd returns the length of the field received. In the case of
an lxc_cmd_stop this is 16. But a comment claims we expect no response,
only a 0. In fact the handler does send a response, which may or may
not include an error. So don't call an error just because we got back a
response.
Since attach asks the restore process what the clone flags were, if we forgot
to set them then the attach command ran in the hosts namespaces instead of the
containers, which is a Very Bad Thing :). Instead, we remember to set the clone
flags in the restore process' handler, so that we report them correctly to any
attach processes who ask.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Tycho Andersen [Fri, 20 Mar 2015 16:17:31 +0000 (10:17 -0600)]
lxcapi_restore shouldn't steal the calling process
Previously, lxcapi_restore used the calling process as the lxc monitor process
(and just never returned), requiring users to fork before calling it. This, of
course, would cause problems for things like LXD, which can't fork.
Now, restore() forks the monitor as a child of the process that calls it. Users
who want to daemonize the restore process need to fork themselves.
lxc-checkpoint has been updated to reflect this behavior change.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Fix incomplete destruction of unprivileged ephemeral containers
If an unprivileged ephemeral container is started as follows,
lxc-start-ephemeral -o trusty -n test_ephemeral
Then an empty directory remains upon exit from the container,
~/.local/share/lxc/test_ephemeral/tmpfs/delta0
(The tmpfs filesystem is successfully unmounted, but we seem to lack
permission to delete the delta0 directory).
This issue arose following commits 4799a1e and dd2271e .
The following patch resolves the issue. It has been tested on ubuntu
14.04 with the lxc-daily ppa.
Since gmail screws up the formatting of the patch via line-wrapping
etc, please copy the patch from the issue-tracker rather than from
this email.
Serge Hallyn [Mon, 16 Mar 2015 17:02:12 +0000 (17:02 +0000)]
lxc-destroy: actually work if underlying fs is overlayfs
One of the 'features' of overlayfs is that depending on whether a file
is on the upper or lower dir you get back a different device from stat.
That breaks our lxc_rmdir_onedev.
So at lxc_rmdir_ondev check the device of the directory being deleted.
If it is overlayfs, then skip the device check.
Note this is unrelated to overlayfs snapshots - in those cases when you
delete a container, /var/lib/lxc/$container/ does not actually have an
overlayfs under it. Rather, to reproduce this you would
Serge Hallyn [Wed, 18 Mar 2015 00:02:18 +0000 (19:02 -0500)]
cgmanager: put unprivileged containers under $(curcgroup)/lxc/$(container0
Currently if we are in /user.slice/user-1000.slice/session-c2.scope,
and we start an unprivileged container t1, it will be in cgroup
3:memory:/user.slice/user-1000.slice/session-c2.scope/t1. If
we then do a 'lxc-cgroup -n t1 freezer.tasks', cgm_get will
first switch to 3:memory:/user.slice/user-1000.slice/session-c2.scope
then look up 't1's values. The reasons for this are
1. cgmanager get_value is relative to your own cgroup, so we need
to be sure to be in t1's cgroup or an ancestor
2. we don't want to be in the container's cgroup bc it might freeze us.
But in Ubuntu 15.04 it was decided that
3:memory:/user.slice/user-1000.slice/session-c2.scope/tasks should
not be writeable by the user, making this fail.
Therefore put all unprivileged cgroups under "lxc/%n". That way
the "lxc" cgroup should always be owned by the user so that he can
enter.
Serge Hallyn [Wed, 11 Mar 2015 22:10:55 +0000 (22:10 +0000)]
logs: introduce a thread-local 'current' lxc_config
The logging code uses a global log_fd and log_level to direct
logging (ERROR(), etc). While the container configuration file allows
for lxc.loglevel and lxc.logfile, those are only used at configuration
file read time to set the global variables. This works ok in the
lxc front-end programs, but becomes a problem with threaded API users.
The simplest solution would be to not allow per-container configuration
files, but it'd be nice to avoid that.
Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible",
but would be a huge complication as there are many functions, including
struct member functions and callbacks, which don't have that info and
would need to get it from somewhere.
So the approach I'm taking here is to say that all real container work
is done inside api calls, and therefore the API calls themselves can
set a thread-local variable indicating which log info to use. If
unset, then use the global values. The lxc-* programs, when called
with a '-o logfile' argument, set a global variable to indicate that
the user-specified value should be used.
In this patch:
If the lxc container configuration specifies a loglevel/logfile, only
set the lxc_config's logfd and loglevel according to those, not the
global values.
Each API call is wrapped to set/unset the current_config. (The few
exceptions are calls which do not result in any log actions)
Update logfile appender to use the logfile specified in lxc_conf if (a)
current_config is set and (b) the lxc-* command did not override it.
This patch enables seccomp support for LXC containers running on PowerPC
architectures. It is based on the latest PowerPC support added to libseccomp, on
the working-ppc64 branch [1].
Libseccomp has been tested on ppc, ppc64 and ppc64le architectures. LXC with
seccomp support has been tested on ppc and ppc64 architectures, using the
default seccomp policy example files delivered with the LXC package.
projects / thirdparty / lxc.git / log
