mirror of
https://git.proxmox.com/git/mirror_lxc
synced 2025-08-03 08:52:48 +00:00
13f5be6276
The previous lxcpath patches added support for a custom LXCPATH set
through a system-wide configuration file.
This was also exposed through the C api, so that a custom lxcpath could
be set at the container object instanciation time, or set at runtime.
However the command sock filename was always located under the global
lxcpath, which could be confusing, and would be a problem for users
with insufficient perms to the system-wide lxc path (i.e. if setting
lxcpath to $HOME/lxcbase). This patch changes that by passing the
lxcpath to all callers of lxc_command().
It remains to add an lxcpath command line argument to most of the
command line tools (which are not using the C api) - lxc-start,
lxc-info, lxc-stop, etc.
At this point it becomes tempting to do something like
c = lxc.Container("r1", "/var/lib/lxc")
c2 = lxc.Container("r1", "$HOME/lxcbase")
However, that's problematic - those two will use the same directory
names for cgroup directories.
What would be the best way to handle this? One way (which I kind
of like) is to give up on naming the cgroups after the container.
use mkstemp for the cgroup name, let lxc keep track of the cgroup
name based on the command socket, and make users use lxc-cgroup to get
and change settings.
Other ideas?
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
|
||
|---|---|---|
| config | ||
| doc | ||
| src | ||
| templates | ||
| .gitignore | ||
| AUTHORS | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING | ||
| COPYING | ||
| INSTALL | ||
| lxc.pc.in | ||
| lxc.spec.in | ||
| MAINTAINERS | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| RELEASE-NOTES | ||
| runapitests.sh | ||
| TODO | ||
Please see the COPYING file for details on copying and usage.
Please refer to the INSTALL file for instructions on how to build.
What is lxc:
The container technology is actively being pushed into the mainstream linux
kernel. It provides the resource management through the control groups aka
process containers and resource isolation through the namespaces.
The linux containers, lxc, aims to use these new functionalities to pro-
vide an userspace container object which provides full resource isolation
and resource control for an applications or a system.
The first objective of this project is to make the life easier for the ker-
nel developers involved in the containers project and especially to con-
tinue working on the Checkpoint/Restart new features. The lxc is small
enough to easily manage a container with simple command lines and complete
enough to be used for other purposes.
Using lxc:
Refer the lxc* man pages (generated from doc/* files)
Downloading the current source code:
Source for the latest released version can always be downloaded from
http://lxc.sourceforge.net/download/lxc
You can browse the up to the minute source code and change history online.
http://lxc.git.sourceforge.net
For an even more bleeding edge experience, you may want to look at the
staging branch where all changes aimed at the next release land before
getting pulled into the master branch.
http://github.com/lxc/lxc
For detailed build instruction refer to INSTALL and man lxc man page
but a short command line should work:
./autogen.sh && ./configure && make && sudo make install
preceded by ./autogen.sh if configure do not exist yet.
Getting help:
when you find you need help, you can check out one of the two
lxc mailing list archives and register if interested:
https://lists.sourceforge.net/lists/listinfo/lxc-devel
https://lists.sourceforge.net/lists/listinfo/lxc-users
Portability:
lxc is still in development, so the command syntax and the API can
change. The version 1.0.0 will be the frozen version.
lxc is developed and tested on Linux since kernel mainline version 2.6.27
(without network) and 2.6.29 with network isolation.
It's compiled with gcc, and should work on most architectures as long as the
required kernel features are available. This includes (but isn't limited to):
i686, x86_64, ppc, ppc64, S390, armel and armhf.
AUTHOR
Daniel Lezcano <daniel.lezcano@free.fr>
Seccomp with LXC
----------------
To restrict a container with seccomp, you must specify a profile which is
basically a whitelist of system calls it may execute. In the container
config file, add a line like
lxc.seccomp = /var/lib/lxc/q1/seccomp.full
I created a usable (but basically worthless) seccomp.full file using
cat > seccomp.full << EOF
1
whitelist
EOF
for i in `seq 0 300`; do
echo $i >> seccomp.full
done
for i in `seq 1024 1079`; do
echo $i >> seccomp.full
done
-- Serge Hallyn <serge.hallyn@ubuntu.com> Fri, 27 Jul 2012 15:47:02 +0600