mirror of
https://git.proxmox.com/git/mirror_lxc
synced 2025-07-27 08:12:20 +00:00
07385df53e
- If lxc_container_new() fails we check for ENOMEM and if so goto out. If
ENOMEM is not set we will simply continue. The same goes for the call to
regcomp() but instead of checking for ENOMEM we need to check for REG_ESPACE.
- Tweaking: Since lxc-ls might have to gather a lot of containers and I don't
know if compilers will always optimize this let's move *some* variable
declarations outside of the loop when it does not hinder readability
- Set ls_nesting to 0 initially. Otherwise users will always see nested
containers printed.
- ls_get() gains an argument char **lockpath which is a string pointing us to
the lock we put under /run/lxc/lock/.../... so that we can remove the lock
when we no longer need it. To avoid pointless memory allocation in each new
recursion level we share lockpath amongst all non-fork()ing recursive call to
ls_get(). As it is not guaranteed that realloc() does not do any memory
moving when newlen == len_lockpath, we give ls_get() an additional argument
size_t len_lockpath). Every time we have a non-fork()ing recursive call to
ls_get() we check if newlen > len_lockpath and only then do we
realloc(*lockpath, newlen * 2) a reasonable chunk of memory (as the path will
keep growing) and set len_lockpath = newlen * 2 to pass to the next
non-fork()ing recursive call to ls_get().
To avoid keeping a variable char *lockpath in main() which serves no purpose
whatsoever and might be abused later we use a compound literal
&(char *){NULL} which gives us an anonymous pointer which we can use for
memory allocation in ls_get() for lockpath. We can conveniently free() it in
ls_get() when the nesting level parameter lvl == 0 after exiting the loop.
The advantage is that the variable is only accessible within ls_get() and not
in main() while at the same time giving us an easy way to share lockpath
amongst all non-fork()ing recursive calls to ls_get().
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
|
||
|---|---|---|
| config | ||
| doc | ||
| hooks | ||
| src | ||
| templates | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING | ||
| COPYING | ||
| INSTALL | ||
| lxc.pc.in | ||
| lxc.spec.in | ||
| MAINTAINERS | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
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 a userspace container object which provides full resource isolation
and resource control for an application 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://linuxcontainers.org/downloads/
You can browse the up to the minute source code and change history online.
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.
Troubleshooting:
If you get an error message at the autogen.sh or configure stage, make
sure you have, autoconf, automake, pkg-config, make and gcc installed on
your machine.
The configure script will usually give you hints as to what you are missing,
looking for those in your package manager will usually give you the package
that you need to install.
Also pay a close attention to the feature summary showed at the end of
the configure run, features are automatically enabled/disabled based on
whether the needed development packages are installed on your machine.
If you want a feature but don't know what to install, force it with
--enable-<feature> and look at the error message from configure.
Getting help:
when you find you need help, you can check out one of the two
lxc mailing list archives and register if interested:
http://lists.linuxcontainers.org/listinfo/lxc-devel
http://lists.linuxcontainers.org/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