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>
3.10 kernel comes with proper hierarchical enforcement of devices
cgroup. To keep that code somewhat sane, certain things are not
allowed. Switching from default-allow to default-deny and vice versa
are not allowed when there are children cgroups. (This *could* be
simplified in the kernel by checking that all child cgroups are
unpopulated, but that has not yet been done and may be rejected)
The mountcgroup hook causes lxc-start to break with 3.10 kernels, because
you cannot write 'a' to devices.deny once you have a child cgroup. With
this patch, (a) lxcpath is passed to hooks, (b) the cgroup mount hook sets
the container's devices cgroup, and (c) setup_cgroup() during lxc startup
ignores failures to write to devices subsystem if we are already in a
child of the container's new cgroup.
((a) is not really related to this bug, but is definately needed.
The followup work of making the other hooks use the passed-in lxcpath
is still to be done)
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
This hook script updates the hostname in various files under /etc in the
cloned container. In order to do so, the old container name is passed in
the LXC_SRC_NAME environment variable.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
1. deeper hierarchy has steep performance costs
2. init may be under /init, but containers should be under /lxc
3. in a nested container we like to bind-mount $cgroup_path/$c/$c.real
into $cgroup_path - but task 1's cgroup is $c/$c.real, so a nested
container would be in $c/$c.real/lxc, which would become
/$c/$c.real/$c/$c.real/lxc when expanded
4. this pulls quite a bit of code (of mine) which is always nice
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
We've been shipping those two hooks for a while in Ubuntu.
Yesterday I reworked them to use the new environment variables and
avoid hardcoding any path that we have available as a variable.
I tested both to work on Ubuntu 13.04 but they should work just as well
on any distro shipping with the cgroup hierarchy in /sys/fs/cgroup and
with ecryptfs available.
Those are intended as example and distros are free to drop them, they
should however be working without any change required, at least on Ubuntu.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
