mirror of
https://git.proxmox.com/git/mirror_lxc
synced 2025-08-03 21:21:39 +00:00
ab1bf971d2
On Fri, 26 Apr 2013 10:18:12 -0500 Serge Hallyn <serge.hallyn@ubuntu.com> wrote: > Quoting Dwight Engen (dwight.engen@oracle.com): > > On Fri, 26 Apr 2013 09:37:49 -0500 > > Serge Hallyn <serge.hallyn@ubuntu.com> wrote: > > > > > Quoting Dwight Engen (dwight.engen@oracle.com): > > > > Using lxc configured with --enable-configpath-log, and > > > > specifying a path to the lxc commands with -P, the log file > > > > path is generated with a basename of LOGPATH instead of the > > > > lxcpath. This means for example if you do > > > > > > > > lxc-start -P /tmp/containers -n test01 -l INFO > > > > > > > > your log file will be > > > > > > > > /var/lib/lxc/test01/test01.log > > > > > > > > I was expecting the log to be /tmp/containers/test01/test01.log. > > > > This is particularly confusing if you also have test01 on the > > > > regular lxcpath. The patch below changes the log file path to be > > > > based on lxcpath rather than LOGPATH when lxc is configured with > > > > --enable-configpath-log. > > > > > > > > I think that even in the normal non --enable-configpath-log case > > > > we should consider using lxcpath as the base and not having > > > > LOGPATH at all, as attempting to create the log files > > > > in /var/log is not going to work for regular users on their own > > > > lxcpath. If we want that, I'll update the patch to do that as > > > > well. > > > > > > > > > Perhaps we should do: > > > > > > 1. If lxcpath == default_lxc_path(), then first choice is > > > LOGPATH, second is lxcpath/container.log > > > 2. when opening, if first choice fails, use second choice > > > if there is any. > > > > > > That way 'system' containers will go to /var/log/lxc, as I think > > > they should. Custom-lxcpath containers should never go > > > to /var/log/lxc, since their names could be dups of containers in > > > default_lxc_path(). And if the system is a weird one where > > > default_lxc_path is set up so that an unprivileged user can use > > > it, then we should log into $lxcpath. > > > > That sounds good to me. So these rules would apply in both the > > regular and --enable-configpath-log cases. I updated the patch to try to open the log file according to the choices given above. Along the way I cleaned up log.c a bit, making some things static, grouping external interfaces together, etc... Hopefully that doesn't add too much noise. > > > (Note this patch will trivially conflict with my new lxc_clone.c > > > causing it to fail to build - unfortunate result of timing) > > > > Yeah unfortunately this touches every lxc_log_init() caller. I can > > work on the above logic and re-submit after your new lxc_clone > > stuff goes in. > > No no, I'll just need to remember to update mine. Don't hold up on > mine, this is just the nature of such collaboration :) > > > Did you have any thoughts on the XXX what to pass in for lxcpath in > > lxc_init? Right now it just falls back to LOGPATH. > > No - that's a weird one, since lxc_init runs in the container. If > there were only system containers I'd say always use LOGPATH. > However there are people (apparently :) who use container sharing the > host's rootfs... > > lxc-execute does know the lxcpath. Perhaps we can simply have > src/lxc/execute.c:execute_start() look at handler->conf to see if a > rootfs is set. If rootfs is NOT set, then pass lxcpath along to > lxc-init. Then lxc-init can mostly do the same as the others? (It > doesn't use src/lxc/arguments.c, so you'd have to add lxcpath to > options[] in lxc-init.c) So I did this, only to realize that lxc-init is passing "none" for the file anyway, so it currently doesn't intend to log. This makes me think that passing NULL for lxcpath is the right thing to do in this patch. If you want me to make it so lxc-init can log, I can do that but I think it should be in a different change :) -- Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> |
||
|---|---|---|
| config | ||
| doc | ||
| hooks | ||
| src | ||
| templates | ||
| .gitignore | ||
| AUTHORS | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING | ||
| COPYING | ||
| INSTALL | ||
| lxc.pc.in | ||
| lxc.spec.in | ||
| MAINTAINERS | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| 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.
Troubleshooting:
If the ./autogen.sh script shows the following message: "aclocal: not found",
you are likely missing the "automake" package. Make sure it's installed and
try again.
If the ./configure script gives you the following message:
"configure: error: Please install the libcap development files."
you are likely missing the "libcap-dev" package.
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.
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