Re: [lxc-devel] Device Namespaces
On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote: > So the big issues for a device namespace to solve are filtering which > devices a container has access to and being able to dynamically change > which devices those are at run time (aka hotplug). As _all_ devices are hotpluggable now (look, there's no CONFIG_HOTPLUG anymore, because it was redundant), I think you need to really think this through better (pci, memory, cpus, etc.) before you do anything in the kernel. > After having thought about this for a bit I don't know if a pure > userspace solution is sufficient or actually a good idea. > > - We can manually manage a tmpfs with device nodes in userspace. > (But that is deprecated functionality in the mainstream kernel). Yes, but I'm not going to namespace devtmpfs, as that is going to be an impossible task, right? And remember, udev doesn't create device nodes anymore... > - We can manually export a subset of sysfs with bind mounts. > (But that feels hacky, and is essentially incompatible with hotplug). True. > - We can relay a call of /sbin/hotplug from outside of a container > to inside of a container based on policy. > (But no one uses /sbin/hotplug anymore). That's right, they should be listening to libudev events, so why can't your daemon shuffle them off to the proper container, all in userspace? > - There is no way to fake netlink uevents for a container to see them. > (The best we could do is replace udev everywhere with something that >listens on a unix domain socket). You shouldn't need to do this. > - It would be nice to replace the device cgroup with a comprehensive > solution that really works. (Among other things the device cgroup > does not work in terms of struct device the underlying kernel > abstraction for devices). I didn't even know there was a device cgroup. Which means that if there is one, odds are it's useless. > We must manage sysfs entries as well device nodes because: > - Seeing more than we should has the real potential to confuse > userspace, especially a userspace that replays uevents. You should never replay uevents. If you don't do that, why can't you see all of sysfs? > - Some device control must happens through writing to sysfs files and > if we don't remove all root privileges from a container only by > exporting a subset of sysfs to that container can we limit which > sysfs nodes can be written to. But you have the issue of controlling devices in a "shared" way, which isn't going to be usable for almost all devices. > The current kernel tagged sysfs entry support does not look like a good > match for the impelementing device filtering. The common case will > be allowing devices like /dev/zero, and /dev/null that live in > /sys/devices/virtual and are the devices we are most likely to care > about. Those devices need to live in multiple device namespaces so > everyone can use them. Perhaps exclusive assignment will be the more > common paradigm for device namespaces like it is for network devices in > the network namespace but from what little I can of this problem right now I > don't think so. > > I definitely think we should hold off on a kernel level implementation > until we really understand the issues and are ready to implement device > namespaces correctly. I agree, especially as I don't think this will ever work. > A userspace implementation looks like it can only do about 95% of what > is really needed, but at the same time looks like an easy way to > experiment until the problem is sufficiently well understood. 95% is probably way better than what you have today, and will fit the needs of almost everyone today, so why not do it? I'd argue that those last 5% either are custom solutions that never get merged, or candidates for true virtulization. > In summary the situation with device hoptlug and containers sucks today, > and we need to do something. Running a linux desktop in a container is > a reasonably good example use case. No it isn't. I'd argue that this is a horrible use case, one that you shouldn't do. Why not just use multi-head machines like people do who really want to do this, relying on user separation? That's a workable solution that is quite common and works very well today. > Having one standard common maintainable implementation would be very > useful and the most logical place for that would be in the kernel. > For now we should focus on simple device filtering and hotplug. Just listen for libudev stuff, don't try to filter them, or ever "replay" them, that way lies madness, and lots of nasty race conditions that is guaranteed to break things. good luck, greg k-h -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and
Re: [lxc-devel] Device Namespaces
On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman wrote: >> In summary the situation with device hoptlug and containers sucks today, >> and we need to do something. Running a linux desktop in a container is >> a reasonably good example use case. > > No it isn't. I'd argue that this is a horrible use case, one that you > shouldn't do. Why not just use multi-head machines like people do who > really want to do this, relying on user separation? That's a workable > solution that is quite common and works very well today. I suppose so, but now you take the assumption that there is no need for running multiple Linux variants on the same host (say Ubuntu and Android side by side). Is this something you would not like to see done? -- Janne -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] Device Namespaces
>From conversations at Linux Plumbers Converence it became fairly clear that one if not the roughest edge on containers today is dealing with devices. - Hotplug does not work. - There seems to be no implementation that does a much beyond creating setting up a static set of /dev entries today. - Containers do not see the appropriate uevents for their container. One of the more compelling cases I heard was of someone who was running the a Linux Desktop in container and wanted to just let that container see the devices needed for his desktop, and not everything else. Talking with the OpenVZ folks it appears that preserving device numbers across checkpoint/restart is not currently an issue. However they reuse the same loopback minor number when they can which would hide this issue. So while it is clear we don't need to worry about migrating an application that cares about major/minor numbers of filesystems right now as the set of application that are migrated increases that situation may change. As the case with the network device ifindex has shown it is possible to implement filtering now and later when there is a usecase it is possible to expand filtering to actual namespace local identifiers. Thinking about it for the case of container migration the simplest solution for the rare application that needs something more may be to figure out how to send a kernel hotplug event. Something to think about when we encounter them. So the big issues for a device namespace to solve are filtering which devices a container has access to and being able to dynamically change which devices those are at run time (aka hotplug). After having thought about this for a bit I don't know if a pure userspace solution is sufficient or actually a good idea. - We can manually manage a tmpfs with device nodes in userspace. (But that is deprecated functionality in the mainstream kernel). - We can manually export a subset of sysfs with bind mounts. (But that feels hacky, and is essentially incompatible with hotplug). - We can relay a call of /sbin/hotplug from outside of a container to inside of a container based on policy. (But no one uses /sbin/hotplug anymore). - There is no way to fake netlink uevents for a container to see them. (The best we could do is replace udev everywhere with something that listens on a unix domain socket). - It would be nice to replace the device cgroup with a comprehensive solution that really works. (Among other things the device cgroup does not work in terms of struct device the underlying kernel abstraction for devices). We must manage sysfs entries as well device nodes because: - Seeing more than we should has the real potential to confuse userspace, especially a userspace that replays uevents. - Some device control must happens through writing to sysfs files and if we don't remove all root privileges from a container only by exporting a subset of sysfs to that container can we limit which sysfs nodes can be written to. The current kernel tagged sysfs entry support does not look like a good match for the impelementing device filtering. The common case will be allowing devices like /dev/zero, and /dev/null that live in /sys/devices/virtual and are the devices we are most likely to care about. Those devices need to live in multiple device namespaces so everyone can use them. Perhaps exclusive assignment will be the more common paradigm for device namespaces like it is for network devices in the network namespace but from what little I can of this problem right now I don't think so. I definitely think we should hold off on a kernel level implementation until we really understand the issues and are ready to implement device namespaces correctly. A userspace implementation looks like it can only do about 95% of what is really needed, but at the same time looks like an easy way to experiment until the problem is sufficiently well understood. At the end of the day we need to filter the devices a set of userspace processes can use and be able to change that set of devices dynamically. All of the rest of the infrastructure for that lives in the kernel, and keeping all of the infrastructure in one place where it can be maintained together is likely to be most maintainable. It looks like the code is just complicated enough and the use cases just boring enough that spreading the code to perform container device hotplug and container device filtering between a dozen userspace tools, and a hadful of userspace device managers will not be particularly managable at the end of the day. In summary the situation with device hoptlug and containers sucks today, and we need to do something. Running a linux desktop in a container is a reasonably good example use case. Having one standard common maintainable implementation would be very useful and the most logical place for that would be in the kernel. For now we should focus on simple device filtering and hotplug. Eric --
Re: [lxc-devel] [PATCH] fix segfault on lxc-create with bad template name
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > - change get_template_path() to only return NULL or non-NULL since one of
> > the callers was doing a free(-1) which caused the segfault. Handle the
> > NULL template case in the lxcapi_create() caller.
>
> Hm, some people really do want to run lxc-create without a template
> though. I'm not terribly attached to that idea, but I don't want to
> break it if we can help it - would it solve it to just set tpath = NULL
> right after
> ERROR("bad template: %s\n", t);
> and before the goto out?
D'oh, I see now.
> > - make sure to free(tpath) in the sha1sum_file() failure case
> >
> > Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
thanks,
-serge
> > ---
> > src/lxc/lxccontainer.c | 45 -
> > 1 file changed, 20 insertions(+), 25 deletions(-)
> >
> > diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> > index f5d41b3..d3f5b0d 100644
> > --- a/src/lxc/lxccontainer.c
> > +++ b/src/lxc/lxccontainer.c
> > @@ -713,38 +713,32 @@ static struct bdev *do_bdev_create(struct
> > lxc_container *c, const char *type,
> > /*
> > * Given the '-t' template option to lxc-create, figure out what to
> > * do. If the template is a full executable path, use that. If it
> > - * is something like 'sshd', then return $templatepath/lxc-sshd. If
> > - * no template was passed in, return NULL (this is ok).
> > - * On error return (char *) -1.
> > + * is something like 'sshd', then return $templatepath/lxc-sshd.
> > + * On success return the template, on error return NULL.
> > */
> > -char *get_template_path(const char *t)
> > +static char *get_template_path(const char *t)
> > {
> > int ret, len;
> > char *tpath;
> >
> > - if (!t)
> > - return NULL;
> > -
> > if (t[0] == '/' && access(t, X_OK) == 0) {
> > tpath = strdup(t);
> > - if (!tpath)
> > - return (char *) -1;
> > return tpath;
> > }
> >
> > len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen("/lxc-") + 1;
> > tpath = malloc(len);
> > if (!tpath)
> > - return (char *) -1;
> > + return NULL;
> > ret = snprintf(tpath, len, "%s/lxc-%s", LXCTEMPLATEDIR, t);
> > if (ret < 0 || ret >= len) {
> > free(tpath);
> > - return (char *) -1;
> > + return NULL;
> > }
> > if (access(tpath, X_OK) < 0) {
> > SYSERROR("bad template: %s\n", t);
> > free(tpath);
> > - return (char *) -1;
> > + return NULL;
> > }
> >
> > return tpath;
> > @@ -917,20 +911,19 @@ bool prepend_lxc_header(char *path, const char *t,
> > char *const argv[])
> >
> > #if HAVE_LIBGNUTLS
> > tpath = get_template_path(t);
> > - if (tpath == (char *) -1) {
> > + if (!tpath) {
> > ERROR("bad template: %s\n", t);
> > goto out_free_contents;
> > }
> >
> > - if (tpath) {
> > - have_tpath = true;
> > - ret = sha1sum_file(tpath, md_value);
> > - if (ret < 0) {
> > - ERROR("Error getting sha1sum of %s", tpath);
> > - goto out_free_contents;
> > - }
> > + have_tpath = true;
> > + ret = sha1sum_file(tpath, md_value);
> > + if (ret < 0) {
> > + ERROR("Error getting sha1sum of %s", tpath);
> > free(tpath);
> > + goto out_free_contents;
> > }
> > + free(tpath);
> > #endif
> >
> > process_lock();
> > @@ -1006,16 +999,18 @@ static bool lxcapi_create(struct lxc_container *c,
> > const char *t,
> > {
> > bool bret = false;
> > pid_t pid;
> > - char *tpath;
> > + char *tpath = NULL;
> > int partial_fd;
> >
> > if (!c)
> > return false;
> >
> > - tpath = get_template_path(t);
> > - if (tpath == (char *) -1) {
> > - ERROR("bad template: %s\n", t);
> > - goto out;
> > + if (t) {
> > + tpath = get_template_path(t);
> > + if (!tpath) {
> > + ERROR("bad template: %s\n", t);
> > + goto out;
> > + }
> > }
> >
> > if (!c->save_config(c, NULL)) {
> > --
> > 1.8.1.4
> >
> >
> > --
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> > ___
> > Lxc-devel mailing list
> > Lxc-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
>
[lxc-devel] [lxc/lxc] 85db55: fix segfault on lxc-create with bad template name
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 85db5535c346fcba1ff6c30835ebd3a95214da04 https://github.com/lxc/lxc/commit/85db5535c346fcba1ff6c30835ebd3a95214da04 Author: Dwight Engen Date: 2013-09-26 (Thu, 26 Sep 2013) Changed paths: M src/lxc/lxccontainer.c Log Message: --- fix segfault on lxc-create with bad template name - change get_template_path() to only return NULL or non-NULL since one of the callers was doing a free(-1) which caused the segfault. Handle the NULL template case in the lxcapi_create() caller. - make sure to free(tpath) in the sha1sum_file() failure case Signed-off-by: Dwight Engen Acked-by: Serge E. Hallyn Signed-off-by: Serge E. Hallyn -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 566981: drop now-useless have_tpath bool
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 566981770e840b9043f57dac15958a723413e688 https://github.com/lxc/lxc/commit/566981770e840b9043f57dac15958a723413e688 Author: Serge Hallyn Date: 2013-09-26 (Thu, 26 Sep 2013) Changed paths: M src/lxc/lxccontainer.c Log Message: --- drop now-useless have_tpath bool (Which will also break failure-to-build in the !HAVE_LIBGNUTLS case) Signed-off-by: Serge Hallyn -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH v2 rebased against github master 9d0cda4f] refactor AppArmor into LSM backend, add SELinux support
On Wed, 25 Sep 2013 17:25:13 -0500 Serge Hallyn wrote: > Quoting Dwight Engen (dwight.en...@oracle.com): > > Currently, a maximum of one LSM within LXC will be initialized and > > used. If in the future stacked LSMs become a reality, we can > > support it without changing the configuration syntax and add > > support for more than a single LSM at a time to the lsm code. > > > > Generic LXC code should note that lsm_process_label_set() will take > > effect "now" for AppArmor, and upon exec() for SELinux. > > Ah, that's right, lxc-attach doesn't always exec a new task, right? > So that's where the selinux behavior may be a problem. Right, thats what I was trying to get at with the whole "different semantics" thing. Sorry I couldn't clearly explain that before. lxc-attach works fine on selinux as long as you run a program, but just doing a function will not be in the new context. I don't think there is a way to support that in selinux. > -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [minor] Changing the version naming
On Wed, 25 Sep 2013 17:57:02 -0400 Stéphane Graber wrote: > On Wed, Sep 25, 2013 at 05:48:26PM -0400, S.Çağlar Onur wrote: > > Hey, > > > > It's not that important but I just wanted to learn your thoughts > > about starting to use more predictable version names for releases. > > I was trying to do some stuff based on the LXC version that is > > installed on the system and realized that current naming is little > > different than what I was expecting. > > > > Do you think something like following (and also starting to use > > http://semver.org/ kind of naming) is acceptable? > > > > diff --git a/configure.ac b/configure.ac > > index a523583..f466a43 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -1,7 +1,7 @@ > > # -*- Autoconf -*- > > # Process this file with autoconf to produce a configure script. > > > > -AC_INIT([lxc], [1.0.0.alpha1]) > > +AC_INIT([lxc], [1.0.0-alpha1]) > > > > AC_CONFIG_SRCDIR([configure.ac]) > > AC_CONFIG_AUX_DIR([config]) > > > > Best, > > It doesn't really matter to me or to any of the Debian based distros, > but I seem to remember the version number being a problem to the RPM > based distros in the past, so I'd rather not change the format unless > we first make sure it's going to work with everyone's packaging. Yeah using the dash was a problem for RPM, see commit 0b531758. > (And if we do change format, I'd only start doing it with alpha2 to > avoid some extra confusion) > -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH v2 rebased against github master 9d0cda4f] refactor AppArmor into LSM backend, add SELinux support
Quoting Dwight Engen (dwight.en...@oracle.com): > On Wed, 25 Sep 2013 17:25:13 -0500 > Serge Hallyn wrote: > > > Quoting Dwight Engen (dwight.en...@oracle.com): > > > Currently, a maximum of one LSM within LXC will be initialized and > > > used. If in the future stacked LSMs become a reality, we can > > > support it without changing the configuration syntax and add > > > support for more than a single LSM at a time to the lsm code. > > > > > > Generic LXC code should note that lsm_process_label_set() will take > > > effect "now" for AppArmor, and upon exec() for SELinux. > > > > Ah, that's right, lxc-attach doesn't always exec a new task, right? > > So that's where the selinux behavior may be a problem. > > Right, thats what I was trying to get at with the whole "different > semantics" thing. Sorry I couldn't clearly explain that before. > lxc-attach works fine on selinux as long as you run a program, but just > doing a function will not be in the new context. I don't think there is > a way to support that in selinux. Ok, now i remember (after looking through selinux/hooks.c) - you can use /proc/pid/attr/current to effect an immediate context switch if you have the setcurrent permission to the new domain. I think the sanest thing to do would be to use the normal behavior when possible, then use setcurrent only when doing an attach of a function. -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [minor] Changing the version naming
Hi, On Thu, Sep 26, 2013 at 9:51 AM, Dwight Engen wrote: > On Wed, 25 Sep 2013 17:57:02 -0400 > Stéphane Graber wrote: > > > On Wed, Sep 25, 2013 at 05:48:26PM -0400, S.Çağlar Onur wrote: > > > Hey, > > > > > > It's not that important but I just wanted to learn your thoughts > > > about starting to use more predictable version names for releases. > > > I was trying to do some stuff based on the LXC version that is > > > installed on the system and realized that current naming is little > > > different than what I was expecting. > > > > > > Do you think something like following (and also starting to use > > > http://semver.org/ kind of naming) is acceptable? > > > > > > diff --git a/configure.ac b/configure.ac > > > index a523583..f466a43 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -1,7 +1,7 @@ > > > # -*- Autoconf -*- > > > # Process this file with autoconf to produce a configure script. > > > > > > -AC_INIT([lxc], [1.0.0.alpha1]) > > > +AC_INIT([lxc], [1.0.0-alpha1]) > > > > > > AC_CONFIG_SRCDIR([configure.ac]) > > > AC_CONFIG_AUX_DIR([config]) > > > > > > Best, > > > > It doesn't really matter to me or to any of the Debian based distros, > > but I seem to remember the version number being a problem to the RPM > > based distros in the past, so I'd rather not change the format unless > > we first make sure it's going to work with everyone's packaging. > > Yeah using the dash was a problem for RPM, see commit 0b531758. Got it. Thanks for the feedback... > > (And if we do change format, I'd only start doing it with alpha2 to > > avoid some extra confusion) > > > > Best, -- S.Çağlar Onur -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Device Namespaces
As I mentioned in another part of this thread, my use case is deploying "linux desktops" to users as containers. The goal is to have the container run unmodified distros, and to be able to run arbitrary code. A tall order to be sure, and maybe not realistic, but I'm in research so its good to think big. To that end, we would like the container to be manage as if it were a "real" system. This includes udev. I realize that udev no longer creates devices but uses devtmpfs, but the event notification needs to be seen for other parts to the system, and for the rules that udev actually does. In particular, X uses uevents to detect keyboard, mice and display connections. But when a new device is added, we need that information to go to only the appropriate container. Currently, uevents are broadcasted to all listeners in all network namespaces. I have a set of patches that restrict the initial broadcast to only the host namespace. The second part is a user space deamon that applies policy and forwards the message to the container's udev. But rather than have to run a modified udev, by allowing an interface for the host to inject a replay of the original message to the container's udev, we achieve at least part of our goal. This still leave devtmpfs, and while I do believe that there are user space solutions, I think a virtualization of that is a better approach. The policy needs to be driven by the host, but the view of the synthetic filesystem should be managed by the kernel. There are a number of other kernel filesystems that are equally problematic, sysfs, proc, debugfs, etc. Is it really proposed that all of these be handled in userspace?. We can get some safety by disallows some mounts, and using readonly, but a unified policy would be nice. My kernel patch is just to facility the communication to the container of the appropriate uevents, and the daemon uses libudev to collect, apply policy, and forward the appropriate events. And I'm working on a solution for devtmpfs ---Michael J Coss -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Device Namespaces
On Thu, Sep 26, 2013 at 11:25:56AM +0300, Janne Karhunen wrote: > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman > wrote: > > >> In summary the situation with device hoptlug and containers sucks today, > >> and we need to do something. Running a linux desktop in a container is > >> a reasonably good example use case. > > > > No it isn't. I'd argue that this is a horrible use case, one that you > > shouldn't do. Why not just use multi-head machines like people do who > > really want to do this, relying on user separation? That's a workable > > solution that is quite common and works very well today. > > I suppose so, but now you take the assumption that there is no > need for running multiple Linux variants on the same host (say > Ubuntu and Android side by side). Is this something you would > not like to see done? You can do that today without any need for device namespaces, so why is this an issue here? greg k-h -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Device Namespaces
On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote: > That being said, our wish would be to support any combination of > OS's and frankly, I'd be slightly annoyed to tell the customer that > they can't do two Androids or we magically run out of bits. If you want to support "any" combination of operating systems, then use a hypervisor, that's what they are there for :) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Device Namespaces
On Thu, Sep 26, 2013 at 4:56 PM, Greg Kroah-Hartman wrote: >> I suppose so, but now you take the assumption that there is no >> need for running multiple Linux variants on the same host (say >> Ubuntu and Android side by side). Is this something you would >> not like to see done? > > You can do that today without any need for device namespaces, so why is > this an issue here? I think you misunderstood me. I wasn't so much advocating on the device namespace part, just the issue at hand (device access filtering based on which ns happens to be 'active'). We are already trying to do this in userspace, let's see how that goes. That being said, our wish would be to support any combination of OS's and frankly, I'd be slightly annoyed to tell the customer that they can't do two Androids or we magically run out of bits. -- Janne -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys
Quoting Christian Seiler (christ...@iwakd.de):
...
> + /* Read-only bind-mounting... In older kernels, doing that
> required
> + * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
> same
> + * one. According to mount(2) manpage, MS_BIND honors MS_RDONLY
> from
> + * kernel 2.6.26 onwards. However, this apparently does not
> work on
> + * kernel 3.8.
I'm still not sure what is going on for you with this. Running with the
latest 3.11 userns-enabled kernel (at ppa:ubuntu-lxc/kernel), I can
still do
sudo mkdir /tmp/{a,b}
sudo mount -t tmpfs tmpfs /tmp/a
sudo mount --bind /tmp/a /tmp/b
sudo mount -o remount,bind,ro /tmp/b
and end up with /tmp/b roand /tmp/a rw. This works for me in 3.2, 3.8,
and userns-enabled 3.11.
> Unfortunately, on that very same kernel, doing the
> + * same trick as above doesn't seem to work either, there one
> needs
> + * to ALSO specify MS_BIND for the remount, otherwise the entire
> + * fs is remounted read-only or the mount fails because it's
> busy...
That's actually understandable - there are two things which both have
a readonly.vs.readwrite state - the vfsmount, and the superblock. If
you don't add MS_BIND, then you are requesting remount of the
superblock.
-serge
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Device Namespaces
On Thu, Sep 26, 2013 at 8:07 PM, Greg Kroah-Hartman wrote: >> That being said, our wish would be to support any combination of >> OS's and frankly, I'd be slightly annoyed to tell the customer that >> they can't do two Androids or we magically run out of bits. > > If you want to support "any" combination of operating systems, then use > a hypervisor, that's what they are there for :) Only relevant mobile OS's are of interest ;) -- Janne -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys
Hi Serge,
>> +/* Read-only bind-mounting... In older kernels, doing that
>> required
>> + * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
>> same
>> + * one. According to mount(2) manpage, MS_BIND honors MS_RDONLY
>> from
>> + * kernel 2.6.26 onwards. However, this apparently does not
>> work
>> on
>> + * kernel 3.8.
>
> I'm still not sure what is going on for you with this. Running with
> the
> latest 3.11 userns-enabled kernel (at ppa:ubuntu-lxc/kernel), I can
> still do
>
> sudo mkdir /tmp/{a,b}
> sudo mount -t tmpfs tmpfs /tmp/a
> sudo mount --bind /tmp/a /tmp/b
> sudo mount -o remount,bind,ro /tmp/b
>
> and end up with /tmp/b roand /tmp/a rw. This works for me in 3.2,
> 3.8,
> and userns-enabled 3.11.
I meant with that comment that mount --bind -o ro /tmp/a /tmp/b doesn't
work directly, at least with 3.8, but you have to do two steps. This
does not appear to be in accordance with the mount(2) manpage.
>> Unfortunately, on that very same kernel, doing the
>> + * same trick as above doesn't seem to work either, there one
>> needs
>> + * to ALSO specify MS_BIND for the remount, otherwise the entire
>> + * fs is remounted read-only or the mount fails because it's
>> busy...
>
> That's actually understandable - there are two things which both have
> a readonly.vs.readwrite state - the vfsmount, and the superblock. If
> you don't add MS_BIND, then you are requesting remount of the
> superblock.
Yes, I see what you mean, but this is definitely a change in the
behaviour of the kernel compared to previous versions. And that
also means that (see other thread) bind-mounting a rootfs onto
itself will not prevent a container from remounting the filesystem
readonly on shutdown.
Nevertheless, this should not be a problem for THIS patch, the
current version should work with any reasonable kernel you may
want to use LXC with.
-- Christian
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >>+ /* Read-only bind-mounting... In older kernels, doing that
> >>required
> >>+* to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
> >>same
> >>+* one. According to mount(2) manpage, MS_BIND honors
> >>MS_RDONLY from
> >>+* kernel 2.6.26 onwards. However, this apparently does not
> >>work on
> >>+* kernel 3.8.
> >
> >I'm still not sure what is going on for you with this. Running
> >with the
> >latest 3.11 userns-enabled kernel (at ppa:ubuntu-lxc/kernel), I can
> >still do
> >
> > sudo mkdir /tmp/{a,b}
> > sudo mount -t tmpfs tmpfs /tmp/a
> > sudo mount --bind /tmp/a /tmp/b
> > sudo mount -o remount,bind,ro /tmp/b
> >
> >and end up with /tmp/b roand /tmp/a rw. This works for me in 3.2,
> >3.8,
> >and userns-enabled 3.11.
>
> I meant with that comment that mount --bind -o ro /tmp/a /tmp/b doesn't
> work directly, at least with 3.8, but you have to do two steps. This
> does not appear to be in accordance with the mount(2) manpage.
>
> >>Unfortunately, on that very same kernel, doing the
> >>+* same trick as above doesn't seem to work either, there one
> >>needs
> >>+* to ALSO specify MS_BIND for the remount, otherwise the entire
> >>+* fs is remounted read-only or the mount fails because it's
> >>busy...
> >
> >That's actually understandable - there are two things which both have
> >a readonly.vs.readwrite state - the vfsmount, and the superblock. If
> >you don't add MS_BIND, then you are requesting remount of the
> >superblock.
>
> Yes, I see what you mean, but this is definitely a change in the
> behaviour of the kernel compared to previous versions. And that
> also means that (see other thread) bind-mounting a rootfs onto
> itself will not prevent a container from remounting the filesystem
> readonly on shutdown.
True, but (despite my having forgotten this in the earlier parts of
this thread) that *should* always have been the case. I distinctly
remember being disappointed a few years ago about it.
So yeah, we can't give up rootfs.hold :( Thanks for the reminder!
> Nevertheless, this should not be a problem for THIS patch, the
> current version should work with any reasonable kernel you may
> want to use LXC with.
Ok, thanks. I've looked over the patches and all look reasonable. I'm
going to set up two vms to really test these in (3.2 and 3.11 based) and
give them a going-over tonight or tomorrow, then intend to push them.
thanks,
-serge
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys
Hi Serge, >> Yes, I see what you mean, but this is definitely a change in the >> behaviour of the kernel compared to previous versions. And that >> also means that (see other thread) bind-mounting a rootfs onto >> itself will not prevent a container from remounting the filesystem >> readonly on shutdown. > > True, but (despite my having forgotten this in the earlier parts of > this thread) that *should* always have been the case. I distinctly > remember being disappointed a few years ago about it. No, previously, the kernel has behaved differently. As I said, on my 3.2 and 2.6.32 a mount -o remount,ro /bindmount without the bind option would only change the bind mount and not the entire filesystem. That definitely changed somewhere in between 3.2 and 3.8. -- Christian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] memory leak
Hi guys, So the line: r = lxc_grow_array((void ***)&h->all_mount_points, &h->all_mount_point_capacity, k + 1, 4); in cgroup.c shows up in valgrind as a leak. I thought the appropriate fix was: diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c index e27bc03..c5dc7e2 100644 --- a/src/lxc/cgroup.c +++ b/src/lxc/cgroup.c @@ -1563,6 +1563,7 @@ void lxc_cgroup_hierarchy_free(struct cgroup_hierarchy *h) if (!h) return; lxc_free_array((void **)h->subsystems, free); + lxc_free_array((void **)h->all_mount_points, free); free(h); } which does free the allocated memory, but then causes a segv the next time free(line) in find_hierarchy_mountpts() is called. The trap is in libc::malloc_consolidate() so I think there is heap corruption going on. Any ideas? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] memory leak
Quoting Dwight Engen (dwight.en...@oracle.com): > Hi guys, > > So the line: > > r = lxc_grow_array((void ***)&h->all_mount_points, > &h->all_mount_point_capacity, k + 1, 4); > > in cgroup.c shows up in valgrind as a leak. I thought the appropriate > fix was: > > diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c > index e27bc03..c5dc7e2 100644 > --- a/src/lxc/cgroup.c > +++ b/src/lxc/cgroup.c > @@ -1563,6 +1563,7 @@ void lxc_cgroup_hierarchy_free(struct > cgroup_hierarchy *h) if (!h) > return; > lxc_free_array((void **)h->subsystems, free); > + lxc_free_array((void **)h->all_mount_points, free); > free(h); > } > > which does free the allocated memory, but then causes a segv the next > time free(line) in find_hierarchy_mountpts() is called. The trap is in > libc::malloc_consolidate() so I think there is heap corruption going > on. Any ideas? Well the exact symptoms you describe are a bit fishy - I'd expect a double-free warning right at the line you added. I think you want to just free(h->all_mount_points). The all_mount_points[i] entries get set to 'mount_point' which are also pointed to by meta_data, and which you freed right before the loop calling lxc_cgroup_hierarchy_free(). Does just using free at this same spot fix it for you? -serge -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 1/2] lxc-info: Port to LXC API
Signed-off-by: Stéphane Graber
---
src/lxc/lxc_info.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
index e61ae63..ab3aacf 100644
--- a/src/lxc/lxc_info.c
+++ b/src/lxc/lxc_info.c
@@ -29,6 +29,7 @@
#include
#include
+#include
#include "commands.h"
#include "arguments.h"
@@ -83,43 +84,50 @@ Options :\n\
int main(int argc, char *argv[])
{
- int ret,i;
+ struct lxc_container *c;
- ret = lxc_arguments_parse(&my_args, argc, argv);
- if (ret)
- return 1;
+ int i;
+
+ if (lxc_arguments_parse(&my_args, argc, argv))
+ return -1;
if (lxc_log_init(my_args.name, my_args.log_file, my_args.log_priority,
my_args.progname, my_args.quiet, my_args.lxcpath[0]))
- return 1;
+ return -1;
+
+ c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
+ if (!c)
+ return -1;
if (!state && !pid && keys <= 0)
state = pid = true;
if (state || test_state) {
- ret = lxc_getstate(my_args.name, my_args.lxcpath[0]);
- if (ret < 0)
- return 1;
if (test_state)
- return strcmp(lxc_state2str(ret), test_state) != 0;
+ return strcmp(c->state(c), test_state) != 0;
- printf("state:%10s\n", lxc_state2str(ret));
+ printf("state:%10s\n", c->state(c));
}
if (pid) {
pid_t initpid;
- initpid = lxc_cmd_get_init_pid(my_args.name,
my_args.lxcpath[0]);
+ initpid = c->init_pid(c);
if (initpid >= 0)
printf("pid:%10d\n", initpid);
}
for(i = 0; i < keys; i++) {
- char *val;
+ int len = c->get_config_item(c, key[i], NULL, 0);
+
+ if (len >= 0) {
+ char *val = (char*) malloc(sizeof(char)*len + 1);
- val = lxc_cmd_get_config_item(my_args.name, key[i],
my_args.lxcpath[0]);
- if (val) {
- printf("%s = %s\n", key[i], val);
+ if (c->get_config_item(c, key[i], val, len + 1) != len)
{
+ fprintf(stderr, "unable to read %s from
configuration\n", key[i]);
+ } else {
+ printf("%s = %s\n", key[i], val);
+ }
free(val);
} else {
fprintf(stderr, "%s unset or invalid\n", key[i]);
--
1.8.3.2
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 2/2] lxc-info: Allow printing IP addresses
This adds a new -i flag to lxc-info to print the container's IP
addresses using get_ips().
Example:
$ lxc-info -n lxc-dev -s -p -i
state: RUNNING
pid:21331
ip: 10.0.3.165
ip: 2607:f2c0:f00f:2751:e9ca:842f:efa9:97d1
ip: 2607:f2c0:f00f:2751:216:3eff:fe3a:f1c1
Signed-off-by: Stéphane Graber
---
doc/lxc-info.sgml.in | 12
src/lxc/lxc_info.c | 24
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/doc/lxc-info.sgml.in b/doc/lxc-info.sgml.in
index c6fc624..819d5ca 100644
--- a/doc/lxc-info.sgml.in
+++ b/doc/lxc-info.sgml.in
@@ -51,6 +51,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
-c KEY
-s
-p
+ -i
-t state
@@ -114,6 +115,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301 USA
+ -i
+
+
+
+Just print the container's IP addresses.
+
+
+
+
+
+
-t
state
diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
index ab3aacf..23cf789 100644
--- a/src/lxc/lxc_info.c
+++ b/src/lxc/lxc_info.c
@@ -20,6 +20,7 @@
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+
#include
#include
#include
@@ -34,6 +35,7 @@
#include "commands.h"
#include "arguments.h"
+static bool ips;
static bool state;
static bool pid;
static char *test_state = NULL;
@@ -48,6 +50,7 @@ static int my_parser(struct lxc_arguments* args, int c, char*
arg)
key[keys] = arg;
keys++;
break;
+ case 'i': ips = true; break;
case 's': state = true; break;
case 'p': pid = true; break;
case 't': test_state = arg; break;
@@ -57,6 +60,7 @@ static int my_parser(struct lxc_arguments* args, int c, char*
arg)
static const struct option my_longopts[] = {
{"config", required_argument, 0, 'c'},
+ {"ips", no_argument, 0, 'i'},
{"state", no_argument, 0, 's'},
{"pid", no_argument, 0, 'p'},
{"state-is", required_argument, 0, 't'},
@@ -73,6 +77,7 @@ lxc-info display some information about a container with the
identifier NAME\n\
Options :\n\
-n, --name=NAME NAME for name of the container\n\
-c, --config=KEY show configuration variable KEY from running
container\n\
+ -i, --ips shows the IP addresses\n\
-p, --pid shows the process id of the init container\n\
-s, --state shows the state of the container\n\
-t, --state-is=STATE test if current state is STATE\n\
@@ -99,14 +104,14 @@ int main(int argc, char *argv[])
if (!c)
return -1;
- if (!state && !pid && keys <= 0)
- state = pid = true;
+ if (!state && !pid && !ips && keys <= 0)
+ state = pid = ips = true;
if (state || test_state) {
if (test_state)
return strcmp(c->state(c), test_state) != 0;
- printf("state:%10s\n", c->state(c));
+ printf("state: \t%s\n", c->state(c));
}
if (pid) {
@@ -114,7 +119,18 @@ int main(int argc, char *argv[])
initpid = c->init_pid(c);
if (initpid >= 0)
- printf("pid:%10d\n", initpid);
+ printf("pid: \t%d\n", initpid);
+ }
+
+ if (ips) {
+ char **addresses = c->get_ips(c, NULL, NULL, 0);
+ char *address;
+ i = 0;
+ while (addresses[i]) {
+ address = addresses[i];
+ printf("ip: \t%s\n", address);
+ i++;
+ }
}
for(i = 0; i < keys; i++) {
--
1.8.3.2
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys
Quoting Christian Seiler (christ...@iwakd.de): > No, previously, the kernel has behaved differently. As I said, > on my 3.2 and 2.6.32 a mount -o remount,ro /bindmount without > the bind option would only change the bind mount and not the > entire filesystem. My 3.2, 3.8 and 3.11 kernels all behave the same: serge@sergeh1:~$ sudo mount -t tmpfs tmpfs /mnt serge@sergeh1:~$ sudo mount --bind /mnt /mnt2 serge@sergeh1:~$ sudo mount -o remount,ro /mnt2 serge@sergeh1:~$ sudo touch /mnt/a serge@sergeh1:~$ mount | grep /mnt tmpfs on /mnt type tmpfs (rw) /mnt on /mnt2 type none (ro,bind) (I'll dig deeper later.) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] lxc-info: Port to LXC API
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> src/lxc/lxc_info.c | 38 +++---
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
> index e61ae63..ab3aacf 100644
> --- a/src/lxc/lxc_info.c
> +++ b/src/lxc/lxc_info.c
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> #include "commands.h"
> #include "arguments.h"
> @@ -83,43 +84,50 @@ Options :\n\
>
> int main(int argc, char *argv[])
> {
> - int ret,i;
> + struct lxc_container *c;
>
> - ret = lxc_arguments_parse(&my_args, argc, argv);
> - if (ret)
> - return 1;
> + int i;
> +
> + if (lxc_arguments_parse(&my_args, argc, argv))
> + return -1;
>
> if (lxc_log_init(my_args.name, my_args.log_file, my_args.log_priority,
>my_args.progname, my_args.quiet, my_args.lxcpath[0]))
> - return 1;
> + return -1;
> +
> + c = lxc_container_new(my_args.name, my_args.lxcpath[0]);
> + if (!c)
> + return -1;
>
> if (!state && !pid && keys <= 0)
> state = pid = true;
>
> if (state || test_state) {
> - ret = lxc_getstate(my_args.name, my_args.lxcpath[0]);
> - if (ret < 0)
> - return 1;
> if (test_state)
> - return strcmp(lxc_state2str(ret), test_state) != 0;
> + return strcmp(c->state(c), test_state) != 0;
>
> - printf("state:%10s\n", lxc_state2str(ret));
> + printf("state:%10s\n", c->state(c));
> }
>
> if (pid) {
> pid_t initpid;
>
> - initpid = lxc_cmd_get_init_pid(my_args.name,
> my_args.lxcpath[0]);
> + initpid = c->init_pid(c);
> if (initpid >= 0)
> printf("pid:%10d\n", initpid);
> }
>
> for(i = 0; i < keys; i++) {
> - char *val;
> + int len = c->get_config_item(c, key[i], NULL, 0);
> +
> + if (len >= 0) {
> + char *val = (char*) malloc(sizeof(char)*len + 1);
>
> - val = lxc_cmd_get_config_item(my_args.name, key[i],
> my_args.lxcpath[0]);
> - if (val) {
> - printf("%s = %s\n", key[i], val);
> + if (c->get_config_item(c, key[i], val, len + 1) != len)
> {
> + fprintf(stderr, "unable to read %s from
> configuration\n", key[i]);
> + } else {
> + printf("%s = %s\n", key[i], val);
> + }
> free(val);
> } else {
> fprintf(stderr, "%s unset or invalid\n", key[i]);
> --
> 1.8.3.2
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 2/2] lxc-info: Allow printing IP addresses
Quoting Stéphane Graber (stgra...@ubuntu.com):
> This adds a new -i flag to lxc-info to print the container's IP
> addresses using get_ips().
>
> Example:
> $ lxc-info -n lxc-dev -s -p -i
> state: RUNNING
> pid:21331
> ip: 10.0.3.165
> ip: 2607:f2c0:f00f:2751:e9ca:842f:efa9:97d1
> ip: 2607:f2c0:f00f:2751:216:3eff:fe3a:f1c1
>
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> doc/lxc-info.sgml.in | 12
> src/lxc/lxc_info.c | 24
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/doc/lxc-info.sgml.in b/doc/lxc-info.sgml.in
> index c6fc624..819d5ca 100644
> --- a/doc/lxc-info.sgml.in
> +++ b/doc/lxc-info.sgml.in
> @@ -51,6 +51,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> MA 02110-1301 USA
>-c KEY
>-s
>-p
> + -i
>-t state
>
>
> @@ -114,6 +115,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor,
> Boston, MA 02110-1301 USA
>
>
>
> + -i
> +
> +
> +
> +Just print the container's IP addresses.
> +
> +
> +
> +
> +
> +
>-t
> state
>
>
> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
> index ab3aacf..23cf789 100644
> --- a/src/lxc/lxc_info.c
> +++ b/src/lxc/lxc_info.c
> @@ -20,6 +20,7 @@
> * License along with this library; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
> +
> #include
> #include
> #include
> @@ -34,6 +35,7 @@
> #include "commands.h"
> #include "arguments.h"
>
> +static bool ips;
> static bool state;
> static bool pid;
> static char *test_state = NULL;
> @@ -48,6 +50,7 @@ static int my_parser(struct lxc_arguments* args, int c,
> char* arg)
> key[keys] = arg;
> keys++;
> break;
> + case 'i': ips = true; break;
> case 's': state = true; break;
> case 'p': pid = true; break;
> case 't': test_state = arg; break;
> @@ -57,6 +60,7 @@ static int my_parser(struct lxc_arguments* args, int c,
> char* arg)
>
> static const struct option my_longopts[] = {
> {"config", required_argument, 0, 'c'},
> + {"ips", no_argument, 0, 'i'},
> {"state", no_argument, 0, 's'},
> {"pid", no_argument, 0, 'p'},
> {"state-is", required_argument, 0, 't'},
> @@ -73,6 +77,7 @@ lxc-info display some information about a container with
> the identifier NAME\n\
> Options :\n\
>-n, --name=NAME NAME for name of the container\n\
>-c, --config=KEY show configuration variable KEY from running
> container\n\
> + -i, --ips shows the IP addresses\n\
>-p, --pid shows the process id of the init container\n\
>-s, --state shows the state of the container\n\
>-t, --state-is=STATE test if current state is STATE\n\
> @@ -99,14 +104,14 @@ int main(int argc, char *argv[])
> if (!c)
> return -1;
>
> - if (!state && !pid && keys <= 0)
> - state = pid = true;
> + if (!state && !pid && !ips && keys <= 0)
> + state = pid = ips = true;
>
> if (state || test_state) {
> if (test_state)
> return strcmp(c->state(c), test_state) != 0;
>
> - printf("state:%10s\n", c->state(c));
> + printf("state: \t%s\n", c->state(c));
> }
>
> if (pid) {
> @@ -114,7 +119,18 @@ int main(int argc, char *argv[])
>
> initpid = c->init_pid(c);
> if (initpid >= 0)
> - printf("pid:%10d\n", initpid);
> + printf("pid: \t%d\n", initpid);
> + }
> +
> + if (ips) {
> + char **addresses = c->get_ips(c, NULL, NULL, 0);
> + char *address;
> + i = 0;
> + while (addresses[i]) {
> + address = addresses[i];
> + printf("ip: \t%s\n", address);
> + i++;
> + }
> }
>
> for(i = 0; i < keys; i++) {
> --
> 1.8.3.2
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore ti
