Re: [lxc-devel] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: > On 08/21/2013 03:06 PM, Eric W. Biederman wrote: >> I suspect libvirt should simply not share /run or any other normally >> writable directory with the host. Sharing /run /var/run or even /tmp >> seems extremely dubious if you want some kind of containment, and >> without strange things spilling through. Right, /run or /var cannot be shared. It's not only about sockets, many other things will also go really wrong that way. > right now I only take note of the unix socket /run/systemd/private, > but there may have many similar unix sockets, they can exist in any > path. the strange problems will still happen. > > anyway, I will send a patch to setup a fresh tmpfs for the /run directory of > container first. This is what systemd-nspawn does for a container setup: http://cgit.freedesktop.org/systemd/systemd/tree/src/nspawn/nspawn.c#n350 Kay -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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/5] cgroup: minor bugfixes so start and attach work again
Hi Serge, > Ok, how about we make the system-cgroup-dir configurable in > /etc/lxc/lxc.conf? So if you have > > lxc.system-cgroup-dir = /machine > > then root-created containers will end up in /machine (or, if you're > already nested under /lxc/m1, then /lxc/m1/machine). If that is > unset or /, then you're placed in root cgroup. If you're not > root, then you end up under your current cgroup (assuming you > have rights to create them, which you won't for some) > > Does that seem reasonable? Yes, but maybe we could generalize it a bit more: lxc.system-cgroup-pattern = /lxc/%s -> $init_cgroup/lxc/foo lxc.system-cgroup-pattern = /machine/%s.lxc -> $init_cgroup/machine/foo.lxc lxc.system-cgroup-pattern = %s -> $current_cgroup/foo For non-root, I agree, it should be under your current cgroup. Thoughts? -- Christian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] hooks/ubuntu-cloud-prep: add hostname to meta-data
prior to my enabling of the clone hook, the setting of the hostname
was being done by writing to /etc/hostname. Instead of relying on that
we're now writing 'local-hostname' into the metadata for the instance.
cloud-init then reads this and sets the hostname properly.
The one caveat is that setting of the hostname then occurs after
the initial dhcp, so the hostname sent in the dhcp request would be
the original one.
Should this prove problematic (possibly for avahi dns) we can revert
to explicitly writing the hostname into /etc/hostname as well.
---
hooks/ubuntu-cloud-prep | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hooks/ubuntu-cloud-prep b/hooks/ubuntu-cloud-prep
index c4c3620..725c63a 100755
--- a/hooks/ubuntu-cloud-prep
+++ b/hooks/ubuntu-cloud-prep
@@ -49,8 +49,8 @@ prep() {
fi
local cur="" next=""
-local userdata="" hostid="" authkey="" locales=1 cloud=0 name=""
-local create_etc_init=0
+local userdata="" hostid="" authkey="" locales=1 cloud=0
+local create_etc_init=0 name="ubuntucloud-lxc"
while [ $# -ne 0 ]; do
cur="$1"; next="$2";
@@ -110,6 +110,9 @@ prep() {
echo "instance-id: lxc-$hostid" > "$seed_d/meta-data" ||
{ error "failed to write to $seed_d/meta-data"; return 1; }
+echo "local-hostname: $name" >> "$seed_d/meta-data" ||
+{ error "failed to write to $seed_d/meta-data"; return 1; }
+
if [ -n "$authkey" ]; then
{
echo "public-keys:" &&
--
1.8.3.2
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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] hooks/ubuntu-cloud-prep: add hostname to meta-data
Quoting Scott Moser (smo...@ubuntu.com): > prior to my enabling of the clone hook, the setting of the hostname > was being done by writing to /etc/hostname. Instead of relying on that > we're now writing 'local-hostname' into the metadata for the instance. > > cloud-init then reads this and sets the hostname properly. > > The one caveat is that setting of the hostname then occurs after > the initial dhcp, so the hostname sent in the dhcp request would be > the original one. > > Should this prove problematic (possibly for avahi dns) we can revert > to explicitly writing the hostname into /etc/hostname as well. Hi Scott, this did manage to set the container name as hostname on first boot, however apparently not in time for dhcp's send gethostname(). On first boot, the parent dnsmasq couldn't resolve the hostname, but after a reboot it could. I don't mind applying the patch as is, but is that going to be a problem for ubuntu-cloud users? -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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/5] cgroup: minor bugfixes so start and attach work again
Quoting Christian Seiler (christ...@iwakd.de): > Hi Serge, > > >Ok, how about we make the system-cgroup-dir configurable in > >/etc/lxc/lxc.conf? So if you have > > > > lxc.system-cgroup-dir = /machine > > > >then root-created containers will end up in /machine (or, if you're > >already nested under /lxc/m1, then /lxc/m1/machine). If that is > >unset or /, then you're placed in root cgroup. If you're not > >root, then you end up under your current cgroup (assuming you > >have rights to create them, which you won't for some) > > > >Does that seem reasonable? > > Yes, but maybe we could generalize it a bit more: > > lxc.system-cgroup-pattern = /lxc/%s > -> $init_cgroup/lxc/foo > lxc.system-cgroup-pattern = /machine/%s.lxc > -> $init_cgroup/machine/foo.lxc > lxc.system-cgroup-pattern = %s > -> $current_cgroup/foo > > For non-root, I agree, it should be under your current cgroup. > > Thoughts? Looks good to me, thanks -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] api: convert lxc_start
Normal lxc-start usage tends to be "lxc-start -n name [-P lxcpath]".
This causes $lxcpath/$name/config to be the configuration for the
container. However, lxc-start is more flexible than that. You can
specify a custom configuration file, in which case $lxcpath/$name/config
is not used. You can also (in addition or in place of either of these)
specify configuration entries one-by-one using "-s lxc.utsname=xxx".
To support this using the API, if we are not using
$lxcpath/$name/config then we put ourselves into a custom lxcpath
called (configurable using LXCPATH) /var/lib/lxc_anon. To stop a
container so created, then, you would use
lxc-stop -P /var/lib/lxc_anon -n name
TODO: we should walk over the list of &defines by hand and set them
using c->set_config_item. I haven't done that in this patch.
Signed-off-by: Serge Hallyn
---
src/lxc/lxc_start.c | 74 +++--
1 file changed, 43 insertions(+), 31 deletions(-)
diff --git a/src/lxc/lxc_start.c b/src/lxc/lxc_start.c
index 3a12410..125284c 100644
--- a/src/lxc/lxc_start.c
+++ b/src/lxc/lxc_start.c
@@ -43,6 +43,7 @@
#include "log.h"
#include "caps.h"
#include "lxc.h"
+#include "lxccontainer.h"
#include "conf.h"
#include "cgroup.h"
#include "utils.h"
@@ -151,6 +152,8 @@ int main(int argc, char *argv[])
'\0',
};
FILE *pid_fp = NULL;
+ struct lxc_container *c;
+ char *anonpath;
lxc_list_init(&defines);
@@ -169,13 +172,32 @@ int main(int argc, char *argv[])
my_args.progname, my_args.quiet, my_args.lxcpath[0]))
return err;
+ anonpath = alloca(strlen(LXCPATH) + 6);
+ sprintf(anonpath, "%s_anon", LXCPATH);
+ /*
+* rcfile possibilities:
+* 1. rcfile from random path specified in cli option
+* 2. rcfile not specified, use $lxcpath/$lxcname/config
+* 3. rcfile not specified and does not exist.
+*/
/* rcfile is specified in the cli option */
- if (my_args.rcfile)
+ if (my_args.rcfile) {
rcfile = (char *)my_args.rcfile;
- else {
+ c = lxc_container_new(my_args.name, anonpath);
+ if (!c) {
+ ERROR("Failed to create lxc_container");
+ return err;
+ }
+ if (!c->load_config(c, rcfile)) {
+ ERROR("Failed to load rcfile");
+ lxc_container_put(c);
+ return err;
+ }
+ } else {
int rc;
+ const char *lxcpath = my_args.lxcpath[0];
- rc = asprintf(&rcfile, "%s/%s/config", my_args.lxcpath[0],
my_args.name);
+ rc = asprintf(&rcfile, "%s/%s/config", lxcpath, my_args.name);
if (rc == -1) {
SYSERROR("failed to allocate memory");
return err;
@@ -186,25 +208,28 @@ int main(int argc, char *argv[])
if (access(rcfile, F_OK)) {
free(rcfile);
rcfile = NULL;
+ lxcpath = anonpath;
+ }
+ c = lxc_container_new(my_args.name, lxcpath);
+ if (!c) {
+ ERROR("Failed to create lxc_container");
+ return err;
}
}
- conf = lxc_conf_init();
- if (!conf) {
- ERROR("failed to initialize configuration");
- return err;
- }
-
- if (rcfile && lxc_config_read(rcfile, conf)) {
- ERROR("failed to read configuration file");
- goto out;
- }
+ /*
+* We should use set_config_item() over &defines, which would handle
+* unset c->lxc_conf for us and let us not use lxc_config_define_load()
+*/
+ if (!c->lxc_conf)
+ c->lxc_conf = lxc_conf_init();
+ conf = c->lxc_conf;
if (lxc_config_define_load(&defines, conf))
goto out;
if (!rcfile && !strcmp("/sbin/init", args[0])) {
- ERROR("no configuration file for '/sbin/init' (may crash the
host)");
+ ERROR("Executing '/sbin/init' with no configuration file may
crash the host");
goto out;
}
@@ -228,10 +253,7 @@ int main(int argc, char *argv[])
}
if (my_args.daemonize) {
- if (daemon(0, 0)) {
- SYSERROR("failed to daemonize '%s'", my_args.name);
- goto out;
- }
+ c->want_daemonize(c);
}
if (pid_fp != NULL) {
@@ -245,23 +267,13 @@ int main(int argc, char *argv[])
if (my_args.close_all_fds)
conf->close_all_fds = 1;
- err = lxc_start(my_args.name, args, conf, my_args.lxcpath[0]);
-
- /*
-* exec ourself, that requires to have all opene
Re: [lxc-devel] [PATCH] hooks/ubuntu-cloud-prep: add hostname to meta-data
On Thu, 22 Aug 2013, Serge Hallyn wrote: > Quoting Scott Moser (smo...@ubuntu.com): > > prior to my enabling of the clone hook, the setting of the hostname > > was being done by writing to /etc/hostname. Instead of relying on that > > we're now writing 'local-hostname' into the metadata for the instance. > > > > cloud-init then reads this and sets the hostname properly. > > > > The one caveat is that setting of the hostname then occurs after > > the initial dhcp, so the hostname sent in the dhcp request would be > > the original one. > > > > Should this prove problematic (possibly for avahi dns) we can revert > > to explicitly writing the hostname into /etc/hostname as well. > > Hi Scott, > > this did manage to set the container name as hostname on first boot, > however apparently not in time for dhcp's send gethostname(). On > first boot, the parent dnsmasq couldn't resolve the hostname, but > after a reboot it could. > > I don't mind applying the patch as is, but is that going to be a problem > for ubuntu-cloud users? I kind of see this as a broken design in that you're having lxc tell the instance what its hostname is, then having the instance tell dnsmasq, and relying on that for hostname resolution. A better solution would be for lxc to set dnsmasq correctly so dns resolution works independent of the instance's configuration. lxc knows the MAC address. That said, I'll re-send with setting /etc/hostname also. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] RFC: Device Namespaces
Quoting Oren Laadan (or...@cellrox.com): > Hi everyone! > > We [1] have been working on bringing lightweight virtualization to > Linux-based mobile devices like Android (or other Linux-based devices with > diverse I/O) and want to share our solution: device namespaces. > > Imagine you could run several instances of your favorite mobile OS or other > distributions in isolated containers, each under the impression of having > exclusive access to device drivers; Interact and switch between them within > a blink, no flashing, no reboot. > > Device namespaces are an extension to existing Linux kernel namespaces that > brings lightweight virtualization to Linux-based end-user devices, > primarily mobile devices. > Device namespaces introduce a private and virtual namespace for device > drivers to create the illusion for a process group that it interacts > exclusively with a set of drivers. Device namespaces also introduce the > concepts of an “active” namespace with which a user interacts, vs > “non-active” namespaces that run in the background, and the ability to > switch between them.[2] Note that unless I'm misunderstanding what you're saying here, this is also what net_ns does. A netns can exist with no processes so long as you've bound its /proc/$$/ns/net somewhere. You can then re-enter that ns using ns_attach. I haven't looked closely enough yet to see whether you should be (or are) using the same interface. > We are planning to prepare individual patches to be submitted to the Looking forward to it, and seeing you at the containers track :) > 2: https://github.com/Cellrox/devns-patches/wiki/DeviceNamespace > 3: https://github.com/Cellrox/devns-patches > 4: https://github.com/Cellrox/devns-demo (Have looked over the wiki, will look over the patches as well) -serge -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] RFC: Device Namespaces
Hi everyone! We [1] have been working on bringing lightweight virtualization to Linux-based mobile devices like Android (or other Linux-based devices with diverse I/O) and want to share our solution: device namespaces. Imagine you could run several instances of your favorite mobile OS or other distributions in isolated containers, each under the impression of having exclusive access to device drivers; Interact and switch between them within a blink, no flashing, no reboot. Device namespaces are an extension to existing Linux kernel namespaces that brings lightweight virtualization to Linux-based end-user devices, primarily mobile devices. Device namespaces introduce a private and virtual namespace for device drivers to create the illusion for a process group that it interacts exclusively with a set of drivers. Device namespaces also introduce the concepts of an “active” namespace with which a user interacts, vs “non-active” namespaces that run in the background, and the ability to switch between them.[2] We are planning to prepare individual patches to be submitted to the relevant maintainers and mailing lists. In the meantime, we already want to share a set of patches on top of the Android goldfish Kernel 3.4 as well as a user-space demo, so you can see where we are heading and get an overview of the approach and see how it works. We are aware that the patches are not ready for submission in their current state, and we'd highly appreciate any feedback or suggestions which may come to your mind once you have a look [3]. Of particular interest is to elaborate a proper userspace API with respect to existing and future use-cases. To illustrate a simple use-case we also provide a simple userspace demo for Android [4]. I will be presenting "The Case for Linux Device Namespace" [5] at LinuxCon North America 2013 [6]. We will also be attending the Containers Track [7] at LPC 2013 to present the current state of the patches and discuss the best course to proceed. We are looking forward to hear from you! Thanks, Oren. 1: http://www.cellrox.com/ 2: https://github.com/Cellrox/devns-patches/wiki/DeviceNamespace 3: https://github.com/Cellrox/devns-patches 4: https://github.com/Cellrox/devns-demo 5: http://sched.co/1asN1v7 6: http://events.linuxfoundation.org/events/linuxcon-north-america 7: http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/153 -- Oren Laadan Cellrox Ltd. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] hooks/ubuntu-cloud-prep: add hostname to meta-data
prior to my enabling of the clone hook, the setting of the hostname
was being done by writing to /etc/hostname. Instead of relying on that
we're now writing 'local-hostname' into the metadata for the instance.
cloud-init then reads this and sets the hostname properly.
We are also writing /etc/hostname with the new hostname explicitly. This is
useful/necessary because on network bringup of eth0, dhclient will submit its
hosname. The updating done by cloud-init occurs to late, and thus
the dhcp request goes out with the un-configured hostname and dns doens't
work correctly.
Signed-off-by: Scott Moser
---
hooks/ubuntu-cloud-prep | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/hooks/ubuntu-cloud-prep b/hooks/ubuntu-cloud-prep
index c4c3620..f0b30ea 100755
--- a/hooks/ubuntu-cloud-prep
+++ b/hooks/ubuntu-cloud-prep
@@ -49,8 +49,8 @@ prep() {
fi
local cur="" next=""
-local userdata="" hostid="" authkey="" locales=1 cloud=0 name=""
-local create_etc_init=0
+local userdata="" hostid="" authkey="" locales=1 cloud=0
+local create_etc_init=0 name="ubuntucloud-lxc"
while [ $# -ne 0 ]; do
cur="$1"; next="$2";
@@ -97,6 +97,10 @@ prep() {
local seed_d=""
seed_d="$root_d/var/lib/cloud/seed/nocloud-net"
+
+echo "$name" > "$root_d/etc/hostname" ||
+{ error "failed to write /etc/hostname"; return 1; }
+
if [ $cloud -eq 1 ]; then
debug 1 "--cloud provided, not modifying seed in '$seed_d'"
else
@@ -110,6 +114,9 @@ prep() {
echo "instance-id: lxc-$hostid" > "$seed_d/meta-data" ||
{ error "failed to write to $seed_d/meta-data"; return 1; }
+echo "local-hostname: $name" >> "$seed_d/meta-data" ||
+{ error "failed to write to $seed_d/meta-data"; return 1; }
+
if [ -n "$authkey" ]; then
{
echo "public-keys:" &&
--
1.8.3.2
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&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] hooks/ubuntu-cloud-prep: add hostname to meta-data
Quoting Scott Moser (smo...@ubuntu.com):
> prior to my enabling of the clone hook, the setting of the hostname
> was being done by writing to /etc/hostname. Instead of relying on that
> we're now writing 'local-hostname' into the metadata for the instance.
>
> cloud-init then reads this and sets the hostname properly.
>
> We are also writing /etc/hostname with the new hostname explicitly. This is
> useful/necessary because on network bringup of eth0, dhclient will submit its
> hosname. The updating done by cloud-init occurs to late, and thus
> the dhcp request goes out with the un-configured hostname and dns doens't
> work correctly.
>
> Signed-off-by: Scott Moser
Acked-by: Serge E. Hallyn
Thanks, Scott.
-serge
> ---
> hooks/ubuntu-cloud-prep | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/hooks/ubuntu-cloud-prep b/hooks/ubuntu-cloud-prep
> index c4c3620..f0b30ea 100755
> --- a/hooks/ubuntu-cloud-prep
> +++ b/hooks/ubuntu-cloud-prep
> @@ -49,8 +49,8 @@ prep() {
> fi
>
> local cur="" next=""
> -local userdata="" hostid="" authkey="" locales=1 cloud=0 name=""
> -local create_etc_init=0
> +local userdata="" hostid="" authkey="" locales=1 cloud=0
> +local create_etc_init=0 name="ubuntucloud-lxc"
>
> while [ $# -ne 0 ]; do
> cur="$1"; next="$2";
> @@ -97,6 +97,10 @@ prep() {
>
> local seed_d=""
> seed_d="$root_d/var/lib/cloud/seed/nocloud-net"
> +
> +echo "$name" > "$root_d/etc/hostname" ||
> +{ error "failed to write /etc/hostname"; return 1; }
> +
> if [ $cloud -eq 1 ]; then
> debug 1 "--cloud provided, not modifying seed in '$seed_d'"
> else
> @@ -110,6 +114,9 @@ prep() {
> echo "instance-id: lxc-$hostid" > "$seed_d/meta-data" ||
> { error "failed to write to $seed_d/meta-data"; return 1; }
>
> +echo "local-hostname: $name" >> "$seed_d/meta-data" ||
> +{ error "failed to write to $seed_d/meta-data"; return 1; }
> +
> if [ -n "$authkey" ]; then
> {
> echo "public-keys:" &&
> --
> 1.8.3.2
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
