The following patch fixes the bug where the clone_children compatibility
flag is available with the ns_cgroup subsystem. The 2.6.37 kernel version
should be the only one which is concerned by this modification, please
refer to Documentation/feature-removal-schedule.txt and look for ns_cgroup.

The problem is coming from we check for clone_children and we set it
automatically and then we try to create a new cgroup. As the
ns_cgroup is present the cgroup already exists and we are not allowed
to attach our pid to a new cgroup. The next error will be when we try
to create a new container because we enabled the clone_children flag
and the ns_cgroup is present, it is not allowed by the kernel.

The patch fix this by checking the mount options.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Duplicate the lxc-debian template to use it as a fine grained
template.

Subject: Daniel Lezcano <dlezcano@fr.ibm.com>

If the ns_cgroup does not exist, we use the clone_children feature.
Everytime a cgroup is created, we set this compatibility flag and we create
the cgroup manually and add the child task to the cgroup.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

For both the ns_cgroup and the usual cgroup creation, we have to
check if a previous does not exist and remove it if it is empty.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Create a single API to create a cgroup which will switch to the old
ns_cgroup automatically.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Prepare the nscgroup to be converted to the clone_children changes.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

This field is unused.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Why not chdir into the root of container right when
the root filesystem is (bind-)mounted, and let all
mount entries to be relative to the container root?

Even more, to warn if lxc.mount[.entry] contains
absolute path for the destination directory (or a
variation of this, absolute and does not start with
container root mount point)?

This way, all mounts will look much more sane, and
it will be much easier to move/clone containers -
by changing only lxc.rootfs.

I do it this way locally since the beginning, by
chdir'ing to the proper directory (rootfs) before
running lxc-start (in a startup script), but this
is now broken in 0.7.3 which bind-mounts rootfs
somewhere in /usr/lib/lxc.

Signed-off-by: Michael Tokarev<mjt@tls.msk.ru>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Add support for `dirsync' mount option. MS_DIRSYNC is on of the
mount(2) mountflags so don't send it as extra mount option to avoid:

 	lxc-start: Invalid argument - failed to mount ...

errors.
Signed-off-by: Sergey S. Kostyliov <rathamahata@gmail.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Version 0.7.3
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>

Update the man page wrt the hook script added for the host side
network configuration.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>

Don't close the socket when we ask for a console, otherwise this will
make the console slot to be freed, so the next console will use the same
slot leading to an erratic behavior.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>

We don't want to drop the capabilities when we are root because that
leads to some problems. For exemple, sudo lxc-start -n foo -o $(tty) fails with
"permission denied".
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>

The capability header makes the inclusion of the loop header to 
fail. Moving the inclusion of loop.h before capability.h fixes the
problem.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fix some compilation warnings:
 * include caps.h in lxc_checkpoint and lxc_restart
 * check the return of the timer notification read
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Cosmetic change by reducing the function names.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Change the run_script function to use popen and to redirect
the output of the script to the log file.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Fix the coding style, 80 chars lines, etc ...
Fix indentation blocks if ... then ... else ... fi
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

This commit adds an configuration option to specify a script to be
executed after creating and configuring the network used by the
container. The following arguments are passed to the script:

	* container name
	* config section name (net)

Additional arguments depend on the config section employing a
script hook; the following are used by the network system:

	* execution context (up)
	* network type (empty/veth/macvlan/phys)

Depending on the network type, other arguments may be passed:

veth/macvlan/phys:
	* (host-sided) device name
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Update the man page regarding the image or block device
supported as a rootfs.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

This patch allows to specify an image or a block device.

The image or the block device is mounted on rootfs->mount.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

In the case we use an image for rootfs, if we need to do extra mount
from the host to the rootfs, we have to specify the place where the
image is mounted. This value is configured by the user with the
lxc.rootfs.mount otherwise defaulting to @LXCROOTFSMOUNT@. Let's 
export this variable to pkg-config, so the user can use it to build
a correct path to the rootfs.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Don't display an error when the callback returns an error different
from zero. A value greater than zero may means "stop". Let's the caller
to check the error.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The <rootfs>/var/run/utmp is located in:

/proc/<containerinit>/root/var/run/utmp, let's use it.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Let's initialize rootfs->mount to LXCROOTFSMOUNT. The value
will be overwritten by the configuration in case it is specified.

That will make the code nicer, instead of the ugly rootfs->mount checks.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The rootfs is always located in rootfs->mount, let's use it for
the tty.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The rootfs is always located in the mount point now, let's
use it.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Split the rootfs setup by mounting the rootfs to the mount
point. This mount point will be used as the facto place where
the rootfs is placed.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

The attached patch adds a variable at the top of lxc-debian to change the SUITE.
Currently tested suites are lenny, squeeze, sid.

Also, the patch uses the dhcp3-client package instead of dhcp-client which is
deprecated in lenny and removed in squeeze.

Patch initialy from Mathieu Parent.
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Correctly link to libcap to avoid underlinking and unused direct
dependency problems.
Signed-off-by: Ozan Caglayan <ozan@pardus.org.tr>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

When a container is installed with 32bits binaries while we are
running on a 64bits host, inside the container we are seen as
64bits arch. That leads to some problems for the package updates
because the scripts will download 64bits packages instead of 32bits.

This patch defines a configuration variable to set the architecture
of the container.

lxc.arch = i686 | x86 | x86_64 | amd64
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>