From serge.hallyn at canonical.com Mon Oct 1 12:50:18 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 1 Oct 2012 07:50:18 -0500 Subject: [Lxc-users] use libvirt-bin in lxc In-Reply-To: References: Message-ID: <20121001125018.GA4470@sergelap> Quoting ??? (xuanmingyi at gmail.com): > can we use libvirt-bin in lxc??? Yes, you can. The failures you show are due to your apparmor policy not allowing mounting of cgroups in the containers. You can create a new policy for your containers allowing just the permissions you need, or (not recommended long term) simply make the containers unconfined using the line lxc.aa_profile = unconfined in the container config. -serge > the output: > > root at ubuntu:~# apt-get install libvirt-bin > Reading package lists... Done > Building dependency tree > Reading state information... Done > libvirt-bin is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > 2 not fully installed or removed. > After this operation, 0 B of additional disk space will be used. > Do you want to continue [Y/n]? y > Setting up cgroup-bin (0.37.1-1ubuntu10) ... > Loading configuration file /etc/cgconfig.conf failed > Cgroup mounting failed > start: Job failed to start > invoke-rc.d: initscript cgconfig, action "start" failed. > dpkg: error processing cgroup-bin (--configure): > subprocess installed post-installation script returned error exit status 1 > dpkg: dependency problems prevent configuration of libvirt-bin: > libvirt-bin depends on cgroup-lite | cgroup-bin; however: > Package cgroup-lite is not installed. > Package cgroup-bin is not configured yet. > dpkg: error processing libvirt-bin (--configure): > dependency problems - leaving unconfigured > No apport report written because the error message indicates its a followup > error from a previous failure. > Errors were encountered while processing: > cgroup-bin > libvirt-bin > E: Sub-process /usr/bin/dpkg returned an error code (1) > root at ubuntu:~# > > > -- > ???: http://www.xuanmingyi.com > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From flomotlik at gmail.com Mon Oct 1 22:29:34 2012 From: flomotlik at gmail.com (Florian Motlik) Date: Tue, 2 Oct 2012 00:29:34 +0200 Subject: [Lxc-users] Grub error when setting up a current ubuntu cloud-image template Message-ID: When setting up a current cloud image I ran into the following error: /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?) I tried it on our Development Server and my local system. Both lead to the same error. To recreate the issue: sudo lxc-create -n railsonfire -t ubuntu-cloud sudo lxc-start -n railsonfire log in with ubuntu/ubuntu sudo -i apt-get update apt-get upgrade Any idea how to fix this? best, Flo From serge.hallyn at canonical.com Tue Oct 2 14:51:25 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Tue, 2 Oct 2012 09:51:25 -0500 Subject: [Lxc-users] Grub error when setting up a current ubuntu cloud-image template In-Reply-To: References: Message-ID: <20121002145125.GA6281@sergelap> Quoting Florian Motlik (flomotlik at gmail.com): > When setting up a current cloud image I ran into the following error: > > /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?) > > I tried it on our Development Server and my local system. Both lead to > the same error. > > To recreate the issue: > sudo lxc-create -n railsonfire -t ubuntu-cloud > sudo lxc-start -n railsonfire > log in with ubuntu/ubuntu > sudo -i > apt-get update > apt-get upgrade > > Any idea how to fix this? Thanks, this is real - sounds like a regression in grub. I'll look into it more and open a bug in launchpad. -serge From matejnanut at gmail.com Tue Oct 2 17:25:35 2012 From: matejnanut at gmail.com (Matej Nanut) Date: Tue, 2 Oct 2012 19:25:35 +0200 Subject: [Lxc-users] After a switch to systemd, lxc-execute hides /proc from the host Message-ID: Hey everyone, I've recently switched to systemd on Arch Linux. When running lxc-execute as root, it messes up my /proc (hides it from the host, it seems) and everything else I specify as lxc.mount.entry=..., which forces me to do a reboot. I don't understand the internal workings of LXC well enough to investigate properly, but I suspect something is amiss with cgroups, as they were structured differently with initscripts (manually on /cgroups, now they're at /sys/fs/cgroup). But I'm not sure. Switching back to initscripts is a temporary solution, but I would like to know what's going on. Ubuntu has cgroups at /sys/fs/cgroup aswell, and that works, so something else must be wrong? Thanks for your attention, Matej From dank at kegel.com Thu Oct 4 00:11:23 2012 From: dank at kegel.com (Dan Kegel) Date: Wed, 3 Oct 2012 17:11:23 -0700 Subject: [Lxc-users] lxc-start-ephemeral + upstart = pain? Message-ID: Hi ho. ( I see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049908 also deals with lxc and upstart, but my use case is probably different.) I'd like to run an ephemeral container in a respawning upstart job, but I don't know how shutdown should work. Has anybody else tried this? First issue: upstart likes to use signals for this, not commands. Looking at lxc-restart and lxc-start, I noticed that lxc already does use signals for shutting down. Whew. Second issue: it's init that needs to get the signal, not lxc-start. Happily, lxc-start seems to forward signals to init. Third issue: upstart sends SIGTERM and then later SIGKILL, whereas lxc-restart sends SIGINT and then later SIGPWR. Bit of an impedence mismatch :-) Happily, Upstart lets you tell it which signal to send instead of SIGTERM, and even has kill signal INT as an example .conf line to change that to SIGINT. (I don't know if it lets you configure the later signal.) Fourth issue: which PID to kill? Upstart figures out which pid to send the kill to as follows: default: command is running in foreground, just kill it "kill fork": command forks once, watch the fork and kill the child "kill daemon": command forks twice, watch the forks and kill the grandchild My script which runs lxc-start-ephemeral, which runs lxc-start and then ssh: ???sh /home/buildbot/buildbot-git/slave/lxcslave.sh start_ephemeral_once_foreground hello --> ??bash -x /home/buildbot/buildbot-git/slave/cherrypicks/lxc-start-ephemeral --overlaydir /ephemeral-overlay --name ... -----> lxc-start ----------> init -----> ??ssh -n -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /home/buildbot/.ssh/id_rsa buildbot at 10.0.3.224 --... So perhaps if I tell upstart to watch for the second fork (with "expect daemon"), it will choose lxc-start as the process to kill. But no. It turns out that upstart counts all forks, including any commands before the final daemon is started, so you *can not* use a shell script that runs any external commands before starting the final daemon! ( See https://bugs.launchpad.net/upstart/+bug/530779/comments/10 ) Since lxc-start-ephemeral does all kinds of forks before lxc-start, there's no way upstart can find lxc-start by counting forks. Might be able to work around this by wrapping lxc-start-ephemeral in a program which forks off the script, then sits waiting for signals (SIGCHILD or SIGINT), and tell upstart to send its signals to the wrapper. Oy, gevalt! I wonder if the Python version of lxc-start-ephemeral might help here. Or is sh able to do what I need with the proper use of & and friends? From dank at kegel.com Thu Oct 4 20:46:59 2012 From: dank at kegel.com (Dan Kegel) Date: Thu, 4 Oct 2012 13:46:59 -0700 Subject: [Lxc-users] lxc-start-ephemeral + upstart = pain? In-Reply-To: References: Message-ID: I took the coward's way out, adding a pre-stop script that just runs lxc-stop. Dunno how kosher that is, but it seems to work. From serge.hallyn at canonical.com Fri Oct 5 14:21:50 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 5 Oct 2012 09:21:50 -0500 Subject: [Lxc-users] lxc-start-ephemeral + upstart = pain? In-Reply-To: References: Message-ID: <20121005142150.GA4530@sergelap> Quoting Dan Kegel (dank at kegel.com): > Hi ho. > ( I see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049908 also > deals with lxc and upstart, but my use case is probably different.) > > I'd like to run an ephemeral container in a respawning upstart job, > but I don't know how shutdown should work. > > Has anybody else tried this? > > First issue: upstart likes to use signals for this, not commands. > Looking at lxc-restart and lxc-start, I noticed that lxc already does > use signals for shutting down. Whew. > > Second issue: it's init that needs to get the signal, not lxc-start. Happily, > lxc-start seems to forward signals to init. > > Third issue: > upstart sends SIGTERM and then later SIGKILL, whereas > lxc-restart sends SIGINT and then later SIGPWR. > Bit of an impedence mismatch :-) > Happily, Upstart lets you tell it which signal to send instead of SIGTERM, > and even has > kill signal INT > as an example .conf line to change that to SIGINT. > (I don't know if it lets you configure the later signal.) > > Fourth issue: which PID to kill? > Upstart figures out which pid to send the kill to as follows: > default: command is running in foreground, just kill it > "kill fork": command forks once, watch the fork and kill the child > "kill daemon": command forks twice, watch the forks and kill the grandchild > My script which runs lxc-start-ephemeral, which runs lxc-start and then ssh: > ???sh /home/buildbot/buildbot-git/slave/lxcslave.sh > start_ephemeral_once_foreground hello > --> ??bash -x > /home/buildbot/buildbot-git/slave/cherrypicks/lxc-start-ephemeral > --overlaydir /ephemeral-overlay --name ... > -----> lxc-start > ----------> init > -----> ??ssh -n -o StrictHostKeyChecking=no -o > UserKnownHostsFile=/dev/null -i /home/buildbot/.ssh/id_rsa > buildbot at 10.0.3.224 --... > So perhaps if I tell upstart to watch for the second fork (with > "expect daemon"), > it will choose lxc-start as the process to kill. > But no. It turns out that upstart counts all forks, including any > commands before the final daemon is started, so you *can not* use a > shell script that runs any external commands before starting the final > daemon! ( See https://bugs.launchpad.net/upstart/+bug/530779/comments/10 > ) > Since lxc-start-ephemeral does all kinds of forks before lxc-start, > there's no way upstart can find lxc-start by counting forks. > > Might be able to work around this by wrapping lxc-start-ephemeral in a > program which forks off the script, then sits waiting for signals > (SIGCHILD or SIGINT), and tell upstart to send its signals to the > wrapper. > > Oy, gevalt! > > I wonder if the Python version of lxc-start-ephemeral might help here. > Or is sh able to do what I need with the proper use of & and friends? Just thinking out loud - what about creating a wrapper script which traps SIGUSR1, having it start your ephemeral container and then lxc-wait on it to be first RUNNING then STOPPED, have the upstart instance job leave command running int he foreground, have it 'kill signal SIGUSR1', and then have the script lxc-stop when it gets SIGUSR1? -serge From dank at kegel.com Fri Oct 5 16:06:08 2012 From: dank at kegel.com (Dan Kegel) Date: Fri, 5 Oct 2012 09:06:08 -0700 Subject: [Lxc-users] lxc-start-ephemeral + upstart = pain? In-Reply-To: <20121005142150.GA4530@sergelap> References: <20121005142150.GA4530@sergelap> Message-ID: On Fri, Oct 5, 2012 at 7:21 AM, Serge Hallyn wrote: >> Might be able to work around this by wrapping lxc-start-ephemeral in a >> program which forks off the script, then sits waiting for signals >> (SIGCHILD or SIGINT), and tell upstart to send its signals to the >> wrapper. >> I wonder if the Python version of lxc-start-ephemeral might help here. >> Or is sh able to do what I need with the proper use of & and friends? > > Just thinking out loud - what about creating a wrapper script which > traps SIGUSR1, having it start your ephemeral container and then lxc-wait > on it to be first RUNNING then STOPPED, have the upstart instance job > leave command running int he foreground, have it 'kill signal SIGUSR1', > and then have the script lxc-stop when it gets SIGUSR1? I think the showstopper with doing this in a shell script is that they can't quite wait for both a child process to finish and listen for signals at the same time. Unless you turn on job control, you can't trap SIGCHLD (and even then you get a trap for each process that exits). The next most universal language is Perl, but if lxc-start-ephemeral is now written in Python, the most logical thing to do is build this SIGTERM listening right into that script. But I'm ok with the coward's way out for now, letting lxc-start-ephemeral run in the foreground, and stopping it via lxc-stop in a pre-stop stanza. - Dan p.s. Here's a broken draft that can't work. #!/bin/sh # Upstart wrapper for lxc-start-ephemeral # # Upstart requires that jobs it starts listen for signals on the original # process started ( http://upstart.ubuntu.com/cookbook/#expect ). # Signals used are: # SIGTERM - orderly shutdown ( http://upstart.ubuntu.com/cookbook/#kill-signal ) # SIGKILL - if the process ignores SIGTERM too long (http://upstart.ubuntu.com/cookbook/#kill-timeout) # SIGHUP - reload configuration ( http://upstart.ubuntu.com/cookbook/#initctl-reload ) # # lxc-start-ephemeral does lots of forking, and doesn't listen for signals, hence this wrapper. do_shutdown() { # SIGTERM recieved, shut down container sudo lxc-stop -n $LXC_NAME } do_done() { # container exited, break out of main loop exit } do_start() { lxc-start-ephemeral "$@" } trap do_shutdown 15 # SIGTERM trap do_done 17 # SIGCHLD -- fails unless job control turned on! do_start & while sleep 1 do # Every time sleep returns, the shell will check for signals, # and will execute do_shutdown if SIGTERM is received. # This adds one second of latency to shutdown. # Other languages may be better at this. : done From zheng_huabin at 163.com Mon Oct 8 04:04:11 2012 From: zheng_huabin at 163.com (Binknight) Date: Mon, 8 Oct 2012 12:04:11 +0800 (CST) Subject: [Lxc-users] problem in start lxc container In-Reply-To: References: <41e9bd99.10300.139e1a0ca29.Coremail.zheng_huabin@163.com> <13257804.1043d.139e8eeadd1.Coremail.zheng_huabin@163.com> <505C685B.4020407@gmail.com> <146ba354.10e32.139e92ff418.Coremail.zheng_huabin@163.com> Message-ID: <25058c3f.e7cf.13a3e8b5cbf.Coremail.zheng_huabin@163.com> I want to setup nginx service on the container, so the container should be visible to other hosts as well as the HOST it lives. The HOST machine's ip is 10.2.132.110. so is it possible to setup an ip for container that's visible to other hosts by configuring libvirt? At 2012-09-22 05:30:27,"Fajar A. Nugraha" wrote: >On Fri, Sep 21, 2012 at 9:16 PM, Binknight wrote: >> >> many thanks, >> >> I edit the container's /etc/rc.d/rc.sysinit and add : >> route add default gw 192.168.122.1 # address of virbr0 >> echo >> /etc/resolv.conf nameserver 10.2.0.41 #name server the same as >> that in HOST's /etc/resolv.conf >> then i can ping google successfully . > >libvirt SHOULD create the bridge as well as start dnsmasq, which >functions as DHCP and dns. So if you had to do that manually you >either: >- don't use dhcp on the guest, or >- your libvirt installation is broken > >-- >Fajar -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelsonp at pressercore.com Mon Oct 8 04:59:29 2012 From: nelsonp at pressercore.com (Nelson Pascoal) Date: Mon, 8 Oct 2012 06:59:29 +0200 (SAST) Subject: [Lxc-users] shorewall restart breaks container routing In-Reply-To: <24065388.15.1349671124444.JavaMail.foomip@foomlaptop.home.net> Message-ID: <28263196.29.1349672367011.JavaMail.foomip@foomlaptop.home.net> Hi I am experimenting with Ubuntu 12.04.1 LTS, apt installed lxc 0.7.5 and shorewall 4.5.8.1 installed from packages on the shorewall site. Shorewall is installed on the container and the lxc host. The lxc container is also Ubuntu 12.04.1, installed using lxc-create. Shorewall on the container works perfectly and I have no problems there. However, as soon as I start up the Shorewall firewall on the host, routing on the containers breaks. Even stopping Shorewall and running "shorewall clean" does not restore connectivity to the containers (rebooting the host works, and I haven't configured shorewall on the host to auto start yet). I am using the two interface sample files from the Shorewall installation sources. Sample of the interfaces file: FORMAT 2 ############################################################################### #ZONE INTERFACE OPTIONS net eth0 dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 loc lxcbr0 routeback,bridge,tcpflags,nosmurfs,logmartians Sample of the policy file: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT fw net ACCEPT net all DROP info # THE FOLLOWING POLICY MUST BE LAST all all REJECT info Sample of the rules file: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT PORT(S) DEST LIMIT GROUP #SECTION ALL #SECTION ESTABLISHED #SECTION RELATED SECTION NEW # Don't allow connection pickup from the net # Invalid(DROP) net all tcp # # Accept DNS connections from the firewall to the network # DNS(ACCEPT) $FW net DNS(ACCEPT) loc $FW # # Accept SSH connections from the local network for administration # #SSH(ACCEPT) loc $FW SSH(ACCEPT) net $FW # # Allow Ping from the local network # Ping(ACCEPT) loc $FW # # Drop Ping from the "bad" net zone.. and prevent your log from being flooded.. # Ping(DROP) net $FW ACCEPT loc $FW udp 67 ACCEPT loc $FW udp 68 ACCEPT $FW loc udp 67 ACCEPT $FW loc udp 68 ACCEPT $FW loc icmp ACCEPT $FW net icmp # Regards Nelson Pascoal -------------- next part -------------- An HTML attachment was scrubbed... URL: From nelsonp at pressercore.com Mon Oct 8 06:48:46 2012 From: nelsonp at pressercore.com (Nelson Pascoal) Date: Mon, 8 Oct 2012 08:48:46 +0200 (SAST) Subject: [Lxc-users] shorewall restart breaks container routing In-Reply-To: <28263196.29.1349672367011.JavaMail.foomip@foomlaptop.home.net> Message-ID: <13880367.35.1349678923046.JavaMail.foomip@foomlaptop.home.net> Just an update on my testing so far. If I specify iptable rules directly on the host it seems to work fine. So obviously some rule that Shorewall is setting up that is blocking things. Nothing seems to show up on the logs as being blocked though. Has anyone done this kind of setup before? Help? :) ----- Original Message ----- From: "Nelson Pascoal" To: lxc-users at lists.sourceforge.net Sent: Monday, October 8, 2012 6:59:29 AM Subject: shorewall restart breaks container routing Hi I am experimenting with Ubuntu 12.04.1 LTS, apt installed lxc 0.7.5 and shorewall 4.5.8.1 installed from packages on the shorewall site. Shorewall is installed on the container and the lxc host. The lxc container is also Ubuntu 12.04.1, installed using lxc-create. Shorewall on the container works perfectly and I have no problems there. However, as soon as I start up the Shorewall firewall on the host, routing on the containers breaks. Even stopping Shorewall and running "shorewall clean" does not restore connectivity to the containers (rebooting the host works, and I haven't configured shorewall on the host to auto start yet). I am using the two interface sample files from the Shorewall installation sources. Sample of the interfaces file: FORMAT 2 ############################################################################### #ZONE INTERFACE OPTIONS net eth0 dhcp,tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 loc lxcbr0 routeback,bridge,tcpflags,nosmurfs,logmartians Sample of the policy file: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT fw net ACCEPT net all DROP info # THE FOLLOWING POLICY MUST BE LAST all all REJECT info Sample of the rules file: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH HELPER # PORT PORT(S) DEST LIMIT GROUP #SECTION ALL #SECTION ESTABLISHED #SECTION RELATED SECTION NEW # Don't allow connection pickup from the net # Invalid(DROP) net all tcp # # Accept DNS connections from the firewall to the network # DNS(ACCEPT) $FW net DNS(ACCEPT) loc $FW # # Accept SSH connections from the local network for administration # #SSH(ACCEPT) loc $FW SSH(ACCEPT) net $FW # # Allow Ping from the local network # Ping(ACCEPT) loc $FW # # Drop Ping from the "bad" net zone.. and prevent your log from being flooded.. # Ping(DROP) net $FW ACCEPT loc $FW udp 67 ACCEPT loc $FW udp 68 ACCEPT $FW loc udp 67 ACCEPT $FW loc udp 68 ACCEPT $FW loc icmp ACCEPT $FW net icmp # Regards Nelson Pascoal From framstag at rus.uni-stuttgart.de Mon Oct 8 08:00:05 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Mon, 8 Oct 2012 10:00:05 +0200 Subject: [Lxc-users] Executing a command inside a container? In-Reply-To: <20120830124825.GA8474@amd1> References: <20120830124825.GA8474@amd1> Message-ID: <20121008080005.GC18144@rus.uni-stuttgart.de> On Thu 2012-08-30 (07:48), Serge Hallyn wrote: > Quoting Dan Kegel (dank at kegel.com): > > > Man, this has got to be an FAQ. > > > > I'm merrily scripting buildbot setup inside a container, and tried to do > > sudo lxc-start -n foo sh my-existing-setup-script.sh > > The answer to this *will* be lxc-attach. We're just waiting for the > final kernel bits to filter upstream. > > So yeah ssh is probably the most robust solution for now. I do it with "lxc -x", example: root at zoo:~# lxc -x fex uname -a Linux fex.uni-stuttgart.de 2.6.38-16-server #67~lucid1-Ubuntu SMP Fri Sep 7 18:36:10 UTC 2012 x86_64 GNU/Linux root at zoo:~# lxc -h usage: lxc option options: -l list containers -L list containers with disk usage -p list all container processes usage: lxc [-v] -C container [gateway/net:interface] options: -v verbose mode -C create new container clone example: lxc -C bunny 129.69.8.254/24:br8 usage: lxc [-v] option container options: -v verbose mode -b boot container -c connect container console -e edit container configuration -x execute command in container -s shutdown container -p list container processes -l container process list tree http://fex.rus.uni-stuttgart.de/lxc.html -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: <20120830124825.GA8474 at amd1> From framstag at rus.uni-stuttgart.de Mon Oct 8 07:47:35 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Mon, 8 Oct 2012 09:47:35 +0200 Subject: [Lxc-users] Cluster filesystem? Message-ID: <20121008074735.GB18144@rus.uni-stuttgart.de> Are there recommendations on cluster filesystems? I have several hosts with fibre channel. They should use a common filesystem to have a half-automatic fail-over. -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: <20121008074735.GB18144 at rus.uni-stuttgart.de> From tompos at martos.bme.hu Mon Oct 8 08:32:34 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 08 Oct 2012 10:32:34 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <20121008074735.GB18144@rus.uni-stuttgart.de> References: <20121008074735.GB18144@rus.uni-stuttgart.de> Message-ID: <50728FA2.4010708@martos.bme.hu> On 10/08/2012 09:47 AM, Ulli Horlacher wrote: > Are there recommendations on cluster filesystems? > I have several hosts with fibre channel. They should use a common > filesystem to have a half-automatic fail-over. I think you should be able to use any of the cluster FS (eg. gluster, moosefs, GFS... etc.) However if you want "quota", maybe it's worth to consider images over the cluster fs and container's fs in the image. BTW I would rather use just pure volume's from the storage with ext4 and set MMP (multiple mount protection) on the fs. tamas From list at fajar.net Mon Oct 8 10:02:34 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Mon, 8 Oct 2012 17:02:34 +0700 Subject: [Lxc-users] problem in start lxc container In-Reply-To: <25058c3f.e7cf.13a3e8b5cbf.Coremail.zheng_huabin@163.com> References: <41e9bd99.10300.139e1a0ca29.Coremail.zheng_huabin@163.com> <13257804.1043d.139e8eeadd1.Coremail.zheng_huabin@163.com> <505C685B.4020407@gmail.com> <146ba354.10e32.139e92ff418.Coremail.zheng_huabin@163.com> <25058c3f.e7cf.13a3e8b5cbf.Coremail.zheng_huabin@163.com> Message-ID: On Mon, Oct 8, 2012 at 11:04 AM, Binknight wrote: > I want to setup nginx service on the container, so the container should be > visible to other hosts as well as the HOST it lives. The HOST machine's ip > is 10.2.132.110. > > so is it possible to setup an ip for container that's visible to other hosts > by configuring libvirt? Yes, setup a bridge on your physical interface. It will be just like any other host on your network. Note that in only works for wired interface though, not for wireless. My wiki has examples for several types of bridge for Debian/Ubuntu, but for F16 you can try Google "fedora bridge howto" -- Fajar From emamdouh at cloud9ers.com Mon Oct 8 11:34:06 2012 From: emamdouh at cloud9ers.com (Eslam Mamdouh) Date: Mon, 8 Oct 2012 11:34:06 +0000 (UTC) Subject: [Lxc-users] lxc and openvswitch References: <20120527160423.GA3970@sergelap> Message-ID: any updates regarding your try From framstag at rus.uni-stuttgart.de Mon Oct 8 15:00:34 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Mon, 8 Oct 2012 17:00:34 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <50728FA2.4010708@martos.bme.hu> References: <20121008074735.GB18144@rus.uni-stuttgart.de> <50728FA2.4010708@martos.bme.hu> Message-ID: <20121008150034.GA21380@rus.uni-stuttgart.de> On Mon 2012-10-08 (10:32), Papp Tamas wrote: > On 10/08/2012 09:47 AM, Ulli Horlacher wrote: > > > Are there recommendations on cluster filesystems? > > I have several hosts with fibre channel. They should use a common > > filesystem to have a half-automatic fail-over. > > I think you should be able to use any of the cluster FS (eg. gluster, > moosefs, GFS... etc.) "should" - I prefer recommendations ny experience :-) I have tried by myself gluster and it is HORRIBLE slow. With GFS I have heard of several fatal crashes with data corruption. > BTW I would rather use just pure volume's from the storage with ext4 and > set MMP (multiple mount protection) on the fs. What is MMP? -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: <50728FA2.4010708 at martos.bme.hu> From tompos at martos.bme.hu Mon Oct 8 15:16:01 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 08 Oct 2012 17:16:01 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <20121008150034.GA21380@rus.uni-stuttgart.de> References: <20121008074735.GB18144@rus.uni-stuttgart.de> <50728FA2.4010708@martos.bme.hu> <20121008150034.GA21380@rus.uni-stuttgart.de> Message-ID: <5072EE31.8060403@martos.bme.hu> On 10/08/2012 05:00 PM, Ulli Horlacher wrote: > "should" - I prefer recommendations ny experience :-) > > I have tried by myself gluster and it is HORRIBLE slow. > With GFS I have heard of several fatal crashes with data corruption. Also GFS locking mechanism is not the best if I know well. If you are interested, try Moosefs. I have quite good experiences with it, however not under containers. >> BTW I would rather use just pure volume's from the storage with ext4 and >> set MMP (multiple mount protection) on the fs. > What is MMP? multiple mount protection You cannot mount the partition multiple times at the same time. It's a safe protection. With this trick you can be safe and fast with all the benefits of true posix filesystems. tamas From framstag at rus.uni-stuttgart.de Mon Oct 8 15:58:40 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Mon, 8 Oct 2012 17:58:40 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <5072EE31.8060403@martos.bme.hu> References: <20121008074735.GB18144@rus.uni-stuttgart.de> <50728FA2.4010708@martos.bme.hu> <20121008150034.GA21380@rus.uni-stuttgart.de> <5072EE31.8060403@martos.bme.hu> Message-ID: <20121008155840.GB21380@rus.uni-stuttgart.de> On Mon 2012-10-08 (17:16), Papp Tamas wrote: > On 10/08/2012 05:00 PM, Ulli Horlacher wrote: > > > "should" - I prefer recommendations ny experience :-) > > > > I have tried by myself gluster and it is HORRIBLE slow. > > If you are interested, try Moosefs. I have quite good experiences with > it, however not under containers. Moosefs is FUSE based (for clients) and therefore will be very slow. I suspect NFS is faster, even on (only) GbE. > multiple mount protection > > You cannot mount the partition multiple times at the same time. It's a > safe protection. With this trick you can be safe and fast with all the > benefits of true posix filesystems. Ubuntu 12.04 does not have ext4 MMP support. Besides this, I would need n filesystems for n hosts. A failover solution would be very complex. -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: <5072EE31.8060403 at martos.bme.hu> From tompos at martos.bme.hu Mon Oct 8 17:20:19 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 08 Oct 2012 19:20:19 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <20121008155840.GB21380@rus.uni-stuttgart.de> References: <20121008074735.GB18144@rus.uni-stuttgart.de> <50728FA2.4010708@martos.bme.hu> <20121008150034.GA21380@rus.uni-stuttgart.de> <5072EE31.8060403@martos.bme.hu> <20121008155840.GB21380@rus.uni-stuttgart.de> Message-ID: <50730B53.3080008@martos.bme.hu> On 10/08/2012 05:58 PM, Ulli Horlacher wrote: > Moosefs is FUSE based (for clients) and therefore will be very slow. I > suspect NFS is faster, even on (only) GbE. Glusterfs is also fuse based. If you don't want that, try Lustre. NFS is faster, but it's not clusterfs. > Ubuntu 12.04 does not have ext4 MMP support. Besides this, I would > need n filesystems for n hosts. A failover solution would be very > complex. On my 12.04 system tune2fs(8) contains this option. tamas From le.waldman at gmail.com Mon Oct 8 19:02:16 2012 From: le.waldman at gmail.com (Leon Waldman) Date: Mon, 08 Oct 2012 16:02:16 -0300 Subject: [Lxc-users] Issues with mass-starting and bridge Message-ID: <50732338.9080704@gmail.com> Hi all, I'm having a strange issue with the bridge on my lxc host. First, some background info: I'm running lxc version 0.75 on a CentOS 6.3 install with the standard kernel (2.6.32-279.9.1.el6.i686). it's running inside a VirtualBox VM. I created 100 containers and named from 000 to 099. they are all with sequential assigned IPs and macaddresses (from 10.0.1.0/8 till 10.0.1.99/8 | 80:04:C0:AB:00:00 till 80:04:C0:AB:00:63). When starting them in "mass" with something like: for i in `range 0 99`; do echo $i; lxc-start -n $i -d; done after a random number of containers is started the br0 bridge just stops to answer for anything. It just freezes (it's easy to note because I'm connecting to the host through ssh using the same bridge). If I put a sleep 5 on the for above, things goes better, but then one or two of the containers became a "remote bridge bomb". The bridge stays working till a packet arrives to the "bomb" container, and them again the entire bridge freezes. This container bomb is also random. if I remove the problematic container iface from the bridge, it unfreezes. If I add it again and send a packet... It freezes again. If I stop the container and re-start it... all goes fine and the issue vanish. From my point of view, looks like when the virtual iface is created during the container start (if under load or with too much concurrent starts... I don't know), sometimes something goes wrong with the iface and it mess with the entire bridge if this "messy" iface is attached. Do any one have any input on this (do this happened before? Is there a limit for concurrent containers initializations? Is there a kernel setting or some config that I could do to solve it)? In order to achieve what I need in production environment, I will need to start and stop containers several times per minute. Do this sound too problematic? If you guys need any additional information, please just let me know. Thanks in advance -- *Leon Waldman* Senior Linux/UNIX SysAdmin & Consultant. Back-End & Infrastructure Architect. View Leon Waldman's profile on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: btn_profile_bluetxt_80x15.png Type: image/png Size: 382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: twitter130x22.png Type: image/png Size: 2775 bytes Desc: not available URL: From toens.bueker at lists0903.nurfuerspam.neuroserve.de Mon Oct 8 20:53:57 2012 From: toens.bueker at lists0903.nurfuerspam.neuroserve.de (Toens Bueker) Date: Mon, 8 Oct 2012 22:53:57 +0200 Subject: [Lxc-users] Cluster filesystem? In-Reply-To: <20121008155840.GB21380@rus.uni-stuttgart.de> References: <20121008074735.GB18144@rus.uni-stuttgart.de> <50728FA2.4010708@martos.bme.hu> <20121008150034.GA21380@rus.uni-stuttgart.de> <5072EE31.8060403@martos.bme.hu> <20121008155840.GB21380@rus.uni-stuttgart.de> Message-ID: <20121008205357.GA4382@neteligent.de> Ulli Horlacher wrote: > > > "should" - I prefer recommendations ny experience :-) > > > > > > I have tried by myself gluster and it is HORRIBLE slow. > > > > If you are interested, try Moosefs. I have quite good experiences with > > it, however not under containers. > > Moosefs is FUSE based (for clients) and therefore will be very slow. > I suspect NFS is faster, even on (only) GbE. > > > multiple mount protection > > > > You cannot mount the partition multiple times at the same time. It's a > > safe protection. With this trick you can be safe and fast with all the > > benefits of true posix filesystems. > > Ubuntu 12.04 does not have ext4 MMP support. > Besides this, I would need n filesystems for n hosts. A failover solution > would be very complex. Although it is only partially open source, the "parallels cloud storage" might give us a hint where to look (http://www.parallels.com/products/pcs/) As far as I understand it, it consists of basically two components: - a distributed "filesystem" (which seems to be very similar to cephfs (http://ceph.com/) or scality ring (http://www.scality.com/) with its metadata servers, chunk servers, number of replicas, etc.) - a special loopback block device: ploop (http://wiki.openvz.org/Ploop) With ploop you are able to have your container as one big "image file" on your distributed object store (which is not very good in serving small files anyway) and access the contents of your container over a different mount point at the same time. The distributed filesystem can be mounted on all servers running containers. The fileservers can be containerservers at the same time. The containers of a failed containerserver could be restarted on any other containerserver of the cluster. This is only a wild guess. Probably there is more to it - but it could be a starting point. by T?ns -- There is no safe distance. From serge.hallyn at canonical.com Mon Oct 8 22:29:00 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 8 Oct 2012 17:29:00 -0500 Subject: [Lxc-users] Issues with mass-starting and bridge In-Reply-To: <50732338.9080704@gmail.com> References: <50732338.9080704@gmail.com> Message-ID: <20121008222900.GC566@sergelap> I just created and started 99 containers on a cloud instance. Those were using the lxcbr0 bridge and using dnsmasq rather than statically assigned ips. But I had no problems. So your issue isn't with the container's veth devices themselves, though it still could be a bug in your kernel's bridging code. Is there anything in your /var/log/syslog? Try adding '-l debug -o out$i' to the batch startup script, and see in out$i exactly where the startup hangs. -serge Quoting Leon Waldman (le.waldman at gmail.com): > Hi all, > > > I'm having a strange issue with the bridge on my lxc host. > > > First, some background info: > I'm running lxc version 0.75 on a CentOS 6.3 install with the > standard kernel (2.6.32-279.9.1.el6.i686). > it's running inside a VirtualBox VM. > > I created 100 containers and named from 000 to 099. they are all > with sequential assigned IPs and macaddresses (from 10.0.1.0/8 till > 10.0.1.99/8 | 80:04:C0:AB:00:00 till 80:04:C0:AB:00:63). > > > When starting them in "mass" with something like: > for i in `range 0 99`; do echo $i; lxc-start -n $i -d; done > after a random number of containers is started the br0 bridge just > stops to answer for anything. It just freezes (it's easy to note > because I'm connecting to the host through ssh using the same > bridge). > > If I put a sleep 5 on the for above, things goes better, but then > one or two of the containers became a "remote bridge bomb". The > bridge stays working till a packet arrives to the "bomb" container, > and them again the entire bridge freezes. This container bomb is > also random. > > if I remove the problematic container iface from the bridge, it > unfreezes. If I add it again and send a packet... It freezes again. > If I stop the container and re-start it... all goes fine and the > issue vanish. > > > From my point of view, looks like when the virtual iface is created > during the container start (if under load or with too much > concurrent starts... I don't know), sometimes something goes wrong > with the iface and it mess with the entire bridge if this "messy" > iface is attached. > > > Do any one have any input on this (do this happened before? Is there > a limit for concurrent containers initializations? Is there a kernel > setting or some config that I could do to solve it)? > > > In order to achieve what I need in production environment, I will > need to start and stop containers several times per minute. Do this > sound too problematic? > > > If you guys need any additional information, please just let me know. > > > Thanks in advance > > -- > *Leon Waldman* > Senior Linux/UNIX SysAdmin & Consultant. > Back-End & Infrastructure Architect. > View Leon Waldman's profile on LinkedIn > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From zheng_huabin at 163.com Tue Oct 9 02:05:20 2012 From: zheng_huabin at 163.com (Binknight) Date: Tue, 9 Oct 2012 10:05:20 +0800 (CST) Subject: [Lxc-users] problem in start lxc container In-Reply-To: References: <41e9bd99.10300.139e1a0ca29.Coremail.zheng_huabin@163.com> <13257804.1043d.139e8eeadd1.Coremail.zheng_huabin@163.com> <505C685B.4020407@gmail.com> <146ba354.10e32.139e92ff418.Coremail.zheng_huabin@163.com> <25058c3f.e7cf.13a3e8b5cbf.Coremail.zheng_huabin@163.com> Message-ID: <5e0ad69b.2fd0.13a4344e9ab.Coremail.zheng_huabin@163.com> I setup a bridge by modify the scripts in /etc/sysconfig/network-scripts/ in my test environment?it does work but it's not a satisfied solution, since it will change much of the HOST. My system administrator may not be pleased if I change the system config of the product environment. Though changing system config is inevitable, I am looking for an approach that's easy to deploy and easy to recover. Maybe libvirt is the right way. At 2012-10-08 18:02:34,"Fajar A. Nugraha" wrote: >On Mon, Oct 8, 2012 at 11:04 AM, Binknight wrote: >> I want to setup nginx service on the container, so the container should be >> visible to other hosts as well as the HOST it lives. The HOST machine's ip >> is 10.2.132.110. >> >> so is it possible to setup an ip for container that's visible to other hosts >> by configuring libvirt? > >Yes, setup a bridge on your physical interface. It will be just like >any other host on your network. Note that in only works for wired >interface though, not for wireless. > >My wiki has examples for several types of bridge for Debian/Ubuntu, >but for F16 you can try Google "fedora bridge howto" > >-- >Fajar -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Tue Oct 9 03:07:56 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Tue, 9 Oct 2012 10:07:56 +0700 Subject: [Lxc-users] problem in start lxc container In-Reply-To: <5e0ad69b.2fd0.13a4344e9ab.Coremail.zheng_huabin@163.com> References: <41e9bd99.10300.139e1a0ca29.Coremail.zheng_huabin@163.com> <13257804.1043d.139e8eeadd1.Coremail.zheng_huabin@163.com> <505C685B.4020407@gmail.com> <146ba354.10e32.139e92ff418.Coremail.zheng_huabin@163.com> <25058c3f.e7cf.13a3e8b5cbf.Coremail.zheng_huabin@163.com> <5e0ad69b.2fd0.13a4344e9ab.Coremail.zheng_huabin@163.com> Message-ID: On Tue, Oct 9, 2012 at 9:05 AM, Binknight wrote: > I setup a bridge by modify the scripts in /etc/sysconfig/network-scripts/ in > my test environment?it does work but it's not a satisfied solution, since it > will change much of the HOST. My system administrator may not be pleased if > I change the system config of the product environment. Though changing > system config is inevitable, I am looking for an approach that's easy to > deploy and easy to recover. Maybe libvirt is the right way. It depends. Both virbr0 (libvirt) and lxcbr0 uses NAT masquarade, so by default you won't be able to access the VM from outside the host. You CAN do so though, by manually setting up a static NAT. IMHO this is too much hassle, better just use bridge. Bridge setup works fine even when you don't actually use it, so it shouldn't be a problem. As always, choose whatever solution suits you best. -- Fajar From b08248 at gmail.com Tue Oct 9 20:55:00 2012 From: b08248 at gmail.com (Stuart Yoder) Date: Tue, 9 Oct 2012 15:55:00 -0500 Subject: [Lxc-users] hwaddr and vlan networking? Message-ID: I've found that I can get vlan networking working, using the example config file _if_ I comment out/delete the hwaddr: diff --git a/doc/examples/lxc-vlan.conf.in b/doc/examples/lxc-vlan.conf.in index 4404439..231d618 100644 --- a/doc/examples/lxc-vlan.conf.in +++ b/doc/examples/lxc-vlan.conf.in @@ -4,6 +4,5 @@ lxc.network.type = vlan lxc.network.vlan.id = 1234 lxc.network.flags = up lxc.network.link = eth0 -lxc.network.hwaddr = 4a:49:43:49:79:bd lxc.network.ipv4 = 1.2.3.4/24 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596 I'm not a networking guru... anyone know why that is there in the example and whether/when it is needed? Am I masking some issue by removing it? Stuart From dank at kegel.com Thu Oct 11 17:07:45 2012 From: dank at kegel.com (Dan Kegel) Date: Thu, 11 Oct 2012 10:07:45 -0700 Subject: [Lxc-users] lxc-start leaks network interfaces? Message-ID: Has anyone else run into this? Each time I start and stop a container, it seems to leave behind another pair of instances of network-interface and network-interface-security in the output of 'initctl list'. https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 From serge.hallyn at canonical.com Thu Oct 11 19:16:56 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 11 Oct 2012 14:16:56 -0500 Subject: [Lxc-users] lxc-start leaks network interfaces? In-Reply-To: References: Message-ID: <20121011191656.GA9013@sergelap> Quoting Dan Kegel (dank at kegel.com): > Has anyone else run into this? > > Each time I start and stop a container, it seems to leave behind > another pair of instances of network-interface and network-interface-security > in the output of 'initctl list'. > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 Thanks, Dan. I've reproduced it and commented in the bug. It's not really a bug in lxc. I at least when the veth is destroyed a uevent should be sent saying net-device-removed. Still digging/thinking. -serge From dank at kegel.com Thu Oct 11 19:18:41 2012 From: dank at kegel.com (Dan Kegel) Date: Thu, 11 Oct 2012 12:18:41 -0700 Subject: [Lxc-users] lxc-start leaks network interfaces? In-Reply-To: <20121011191656.GA9013@sergelap> References: <20121011191656.GA9013@sergelap> Message-ID: On Thu, Oct 11, 2012 at 12:16 PM, Serge Hallyn wrote: > Thanks, Dan. I've reproduced it and commented in the bug. It's not > really a bug in lxc. I at least when the veth is destroyed a uevent > should be sent saying net-device-removed. Still digging/thinking. Now I know I'm an early adopter :-) From stgraber at ubuntu.com Thu Oct 11 19:27:26 2012 From: stgraber at ubuntu.com (=?ISO-8859-1?Q?St=E9phane_Graber?=) Date: Thu, 11 Oct 2012 15:27:26 -0400 Subject: [Lxc-users] lxc-start leaks network interfaces? In-Reply-To: References: <20121011191656.GA9013@sergelap> Message-ID: <50771D9E.7030404@ubuntu.com> On 10/11/2012 03:18 PM, Dan Kegel wrote: > On Thu, Oct 11, 2012 at 12:16 PM, Serge Hallyn > wrote: >> Thanks, Dan. I've reproduced it and commented in the bug. It's not >> really a bug in lxc. I at least when the veth is destroyed a uevent >> should be sent saying net-device-removed. Still digging/thinking. > > Now I know I'm an early adopter :-) Odd that I didn't notice that before, I indeed have several thousands of those on my servers ;) Anyway, it's not going to impact the performance or cause any real effect besides polluting upstart's instance list. Even though I could (with my ifupdown maintainer hack on) fix the upstart job to ignore veth, it's not really the right solution, as Serge said, I think the right way of handling that would be to get a net-device-removed even from udev when moving a veth device inside the container. -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From dank at kegel.com Thu Oct 11 21:13:01 2012 From: dank at kegel.com (Dan Kegel) Date: Thu, 11 Oct 2012 14:13:01 -0700 Subject: [Lxc-users] lxc-start-ephemeral fails unless run as root? Message-ID: Not sure what's up with this, but on my ubuntu 12.04.1 system, lxc-start-ephemeral seems to trip over its shoelaces: $ lxc-start-ephemeral -o precise5-ubu10 Setting up ephemeral container... mkdir: cannot create directory `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs': Permission denied mount: mount point /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs does not exist cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config': Permission denied cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab': Permission denied cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs.hold': Permission denied sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab: No such file or directory sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config: No such file or directory sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs/etc/hostname: No such file or directory sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs/etc/hosts: No such file or directory cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab': No such file or directory /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab.old: Permission denied mv: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config': No such file or directory /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config.old: Permission denied Starting up the container... And then it hangs. Adding a sudo to that mkdir gets rid of a couple errors, but then I still see $ lxc-start-ephemeral -o precise5-ubu10 Setting up ephemeral container... cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config': Permission denied cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab': Permission denied cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/rootfs.hold': Permission denied sed: can't read /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab: No such file or directory sed: can't read /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config: No such file or directory cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab': No such file or directory /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab.old: Permission denied mv: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config': No such file or directory /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config.old: Permission denied Starting up the container... and it still hangs. Running with bash -x shows: ... + sudo cp /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab.old + sudo tee /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab.old: Permission denied + '[' -n '' ']' + c=/var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config + sudo mv /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old + sudo tee /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config /usr/bin/lxc-start-ephemeral: line 160: /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old: Permission denied + sudo rm -f /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old + start_container ... Mysterious. Whereas just running the whole script as root works. Maybe it's time to purge all the sudo's out of it. Or maybe the great initctl explosion of '12 has messed with my machine... - Dan From serge.hallyn at canonical.com Fri Oct 12 03:13:28 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 11 Oct 2012 22:13:28 -0500 Subject: [Lxc-users] uevent when moving nic between network namespaces? Message-ID: <20121012031328.GA5472@sergelap> Hi, Dan Kegel (cc:d) found an interesting nuisance relating to upstart and network interfaces with lxc containers. In particular, when you start a container, two veths are created. A uevent for their creation is sent, and so a 'network-interface' upstart job is created for each. One of the veths is passed into the container. When the container shuts down, the veth in the init-net-ns gets a net-device-removed uevent, so the network-interface upstart job goes away. But the veth in the container doesn't cause a net-device-removed upstart uevent to be sent. So its network-interface upstart job sticks around. The details are at: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 I notice that when simply renaming a netdev (sudo ip link set veth1 name veth2) then udevadm monitor shows: KERNEL[17945.234850] move /devices/virtual/net/veth2 (net) UDEV [17945.235758] move /devices/virtual/net/veth2 (net) but when I do 'sudo ip link set veth2 netns 27689' then 'udevadm monitor' shows nothing. When I do sudo ip link set veth1 netns 32296 (in process 32296) sudo ip link set veth1 name veth2 then, again udevadm monitor shows nothing. So the question is, should the kernel be sending uevents for net-device-removed and then net-device-added when a nic is moved between network namespaces? Or should lxc just fake that? -serge From johannes_graumann at web.de Fri Oct 12 10:31:51 2012 From: johannes_graumann at web.de (Johannes Graumann) Date: Fri, 12 Oct 2012 13:31:51 +0300 Subject: [Lxc-users] lxc-container as a tool to learn selinux? Message-ID: Hello, Is it possible to run selinux in a lxc container on a non-selinux host? I am considering starting to learl selinux and this would make things easy? Any pointers to howtos? Thanks for any insight. Sincerely, Joh From serge.hallyn at canonical.com Fri Oct 12 13:34:54 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 08:34:54 -0500 Subject: [Lxc-users] lxc-container as a tool to learn selinux? In-Reply-To: References: Message-ID: <20121012133454.GA4901@sergelap> Quoting Johannes Graumann (johannes_graumann at web.de): > Hello, > > Is it possible to run selinux in a lxc container on a non-selinux host? I am > considering starting to learl selinux and this would make things easy? Any > pointers to howtos? No. But you could run an selinux-enabled (and enforcing) host with a completely unconfined system, and have just the container start an enforcing policy. That could be fun and educational. How to go about it would depend on the distro, version and configuration of the host. > Thanks for any insight. > > Sincerely, Joh > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From frank at frankscholten.nl Fri Oct 12 16:57:57 2012 From: frank at frankscholten.nl (Frank Scholten) Date: Fri, 12 Oct 2012 18:57:57 +0200 Subject: [Lxc-users] lxc-setcap 'Failed to set capabilities on file /usr/local/libexec/lxc-init' Message-ID: Hi all, I want to run non-root LXCs and I read I have to run sudo lxc-setcap first. I am running Ubuntu 12.04 btw. So I cloned the git repo, ran ./configure, make, make install but when I run lxc-setcap I get: root at franktop:/usr/local/libexec# lxc-setcap Failed to set capabilities on file `/usr/local/libexec/lxc-init' (No such file or directory) Turns out lxc-init exists under /usr/local/libexec/lxc/lxc-init Is this an error in the Makefile? Cheers, Frank From serge.hallyn at canonical.com Fri Oct 12 17:40:59 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 12:40:59 -0500 Subject: [Lxc-users] lxc-setcap 'Failed to set capabilities on file /usr/local/libexec/lxc-init' In-Reply-To: References: Message-ID: <20121012174059.GA30919@sergelap> Quoting Frank Scholten (frank at frankscholten.nl): > Hi all, > > I want to run non-root LXCs and I read I have to run sudo lxc-setcap > first. I am running Ubuntu 12.04 btw. > > So I cloned the git repo, ran ./configure, make, make install but when > I run lxc-setcap I get: > > root at franktop:/usr/local/libexec# lxc-setcap > Failed to set capabilities on file `/usr/local/libexec/lxc-init' (No > such file or directory) > > Turns out lxc-init exists under /usr/local/libexec/lxc/lxc-init > > Is this an error in the Makefile? Yeah, bc lxc-init has moved, but supporting lxc-setcap is not interesting right now. It doesn't really work anyway (there are scripts involved, which you cannot attach capabilities to). I realize waiting is no fun, but we're getting really close to being able to start up containers unp-privileged through user namespaces. -serge From serge.hallyn at canonical.com Fri Oct 12 19:18:28 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 14:18:28 -0500 Subject: [Lxc-users] uevent when moving nic between network namespaces? In-Reply-To: <871uh4pdzd.fsf@xmission.com> References: <20121012031328.GA5472@sergelap> <871uh4pdzd.fsf@xmission.com> Message-ID: <20121012191828.GA12200@sergelap> Quoting Eric W. Biederman (ebiederm at xmission.com): > Serge Hallyn writes: > > > Hi, > > > > Dan Kegel (cc:d) found an interesting nuisance relating to upstart > > and network interfaces with lxc containers. In particular, when you > > start a container, two veths are created. A uevent for their creation > > is sent, and so a 'network-interface' upstart job is created for each. > > One of the veths is passed into the container. When the container > > shuts down, the veth in the init-net-ns gets a net-device-removed > > uevent, so the network-interface upstart job goes away. But the veth > > in the container doesn't cause a net-device-removed upstart uevent > > to be sent. So its network-interface upstart job sticks around. > > > > The details are at: > > > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 > > > > I notice that when simply renaming a netdev (sudo ip link set veth1 name > > veth2) then udevadm monitor shows: > > > > KERNEL[17945.234850] move /devices/virtual/net/veth2 (net) > > UDEV [17945.235758] move /devices/virtual/net/veth2 (net) > > > > but when I do 'sudo ip link set veth2 netns 27689' then 'udevadm > > monitor' shows nothing. > > > > When I do > > > > sudo ip link set veth1 netns 32296 > > (in process 32296) sudo ip link set veth1 name veth2 > > > > then, again udevadm monitor shows nothing. > > > > So the question is, should the kernel be sending uevents for > > net-device-removed and then net-device-added when a nic is moved > > between network namespaces? Or should lxc just fake that? > > To the best of my memory I wired up those events, and they should be > delivered. Now they uevents will only be delivered in the relevant > network namespace. > > Hmm. But the relevant code in the kernel is device_rename, and it > happens after we switch the network namespace on the device. > > Which probably means that in practice only the new network namespace is > seeing uevents. > > Grr. Ah, indeed. A few more experiments show that: 1. 'sudo ip link add type veth' on the host ends up with some kernel messages, namely KERNEL[389.393581] add /devices/virtual/net/veth1/queues/rx-0 (queues) KERNEL[389.394953] add /devices/virtual/net/veth1/queues/tx-0 (queues) sent to all namespaces - though the UDEV [389.405255] add /devices/virtual/net/veth1 (net) only gets sent to the initial namespace. 2. Then when I 'sudo ip link set veth1 netns ', I get KERNEL[405.041296] move /devices/virtual/net/veth2 (net) only in the container's namespace - exactly as you said above should happen. Eric, are you working on a patch for this? Should we just explicitly add a remove uevent before doing the transition, or is it more complicated than that? thanks, -serge From serge.hallyn at canonical.com Fri Oct 12 19:28:58 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 14:28:58 -0500 Subject: [Lxc-users] lxc-start-ephemeral fails unless run as root? In-Reply-To: References: Message-ID: <20121012192858.GA14928@sergelap> Try in quantal. I think Stephane got it all fixed back up there. Looking at the diff, pulling the lxc-start-ephemeral out of the quantal package and using it in precise might work just fine. Quoting Dan Kegel (dank at kegel.com): > Not sure what's up with this, but on my ubuntu 12.04.1 system, > lxc-start-ephemeral seems to trip over its shoelaces: > $ lxc-start-ephemeral -o precise5-ubu10 > Setting up ephemeral container... > mkdir: cannot create directory > `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs': Permission denied > mount: mount point /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs > does not exist > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config': > Permission denied > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab': > Permission denied > cp: cannot stat > `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs.hold': Permission > denied > sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab: No > such file or directory > sed: can't read /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config: No > such file or directory > sed: can't read > /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs/etc/hostname: No such > file or directory > sed: can't read > /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/rootfs/etc/hosts: No such > file or directory > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab': No > such file or directory > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/fstab.old: Permission denied > mv: cannot stat `/var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config': No > such file or directory > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-ZXnntF1/config.old: Permission denied > Starting up the container... > > And then it hangs. > > Adding a sudo to that mkdir gets rid of a couple errors, but then I still see > > > $ lxc-start-ephemeral -o precise5-ubu10 > Setting up ephemeral container... > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config': > Permission denied > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab': > Permission denied > cp: cannot stat > `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/rootfs.hold': Permission > denied > sed: can't read /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab: No > such file or directory > sed: can't read /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config: No > such file or directory > cp: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab': No > such file or directory > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/fstab.old: Permission denied > mv: cannot stat `/var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config': No > such file or directory > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-G5kNWUW/config.old: Permission denied > Starting up the container... > > and it still hangs. > > Running with bash -x shows: > ... > + sudo cp /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab > /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab.old > + sudo tee /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/fstab.old: Permission denied > + '[' -n '' ']' > + c=/var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config > + sudo mv /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config > /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old > + sudo tee /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config > /usr/bin/lxc-start-ephemeral: line 160: > /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old: Permission denied > + sudo rm -f /var/lib/lxc/precise5-ubu10-temp-UZ8wtxV/config.old > + start_container > ... > > Mysterious. Whereas just running the whole script as root works. > > Maybe it's time to purge all the sudo's out of it. > > Or maybe the great initctl explosion of '12 has messed with my machine... > - Dan > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From serge.hallyn at canonical.com Fri Oct 12 21:56:50 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 16:56:50 -0500 Subject: [Lxc-users] uevent when moving nic between network namespaces? In-Reply-To: <87sj9jmqew.fsf@xmission.com> References: <20121012031328.GA5472@sergelap> <871uh4pdzd.fsf@xmission.com> <20121012191828.GA12200@sergelap> <87sj9jmqew.fsf@xmission.com> Message-ID: <20121012215650.GA22665@sergelap> Quoting Eric W. Biederman (ebiederm at xmission.com): > I am not currently working on a patch for this, but I will be happy to > review one. At a quick glance it looks like this could just be as > simple as calling kobject_uevent at the proper time, but testing and > reading through the relevant code paths is probably a good idea as there > always seems to be gotchas in that code. > > Eric This (the simple fix) works for me, actually. I do notice the ifdef shouldn't be needed, all the better. >From b436802aa8ae80f699b3d7bcf584d3e86af7355a Mon Sep 17 00:00:00 2001 From: Serge Hallyn Date: Fri, 12 Oct 2012 21:42:05 +0100 Subject: [PATCH 1/1] dev_change_net_namespace: send a KOBJ_REMOVED to original netns Signed-off-by: Serge Hallyn --- net/core/dev.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/core/dev.c b/net/core/dev.c index e2215ee..8062a5a 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6172,6 +6172,10 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char dev_uc_flush(dev); dev_mc_flush(dev); + /* Send a netdev-removed uevent to the old namespace */ +#ifdef CONFIG_HOTPLUG + kobject_uevent(&dev->dev.kobj, KOBJ_REMOVE); +#endif /* Actually switch the network namespace */ dev_net_set(dev, net); -- 1.7.9.5 From serge.hallyn at canonical.com Fri Oct 12 22:17:11 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 12 Oct 2012 17:17:11 -0500 Subject: [Lxc-users] uevent when moving nic between network namespaces? In-Reply-To: <87bog7mjhm.fsf@xmission.com> References: <20121012031328.GA5472@sergelap> <871uh4pdzd.fsf@xmission.com> <20121012191828.GA12200@sergelap> <87sj9jmqew.fsf@xmission.com> <20121012215650.GA22665@sergelap> <87bog7mjhm.fsf@xmission.com> Message-ID: <20121012221711.GA23227@sergelap> Quoting Eric W. Biederman (ebiederm at xmission.com): > Serge Hallyn writes: > > > Quoting Eric W. Biederman (ebiederm at xmission.com): > >> I am not currently working on a patch for this, but I will be happy to > >> review one. At a quick glance it looks like this could just be as > >> simple as calling kobject_uevent at the proper time, but testing and > >> reading through the relevant code paths is probably a good idea as there > >> always seems to be gotchas in that code. > >> > >> Eric > > > > This (the simple fix) works for me, actually. > > > > I do notice the ifdef shouldn't be needed, all the better. > > Should we have a KOBJ_ADD in the new network namespace or is the > KOBJ_MOVE sufficient? I was wondering about that... the KOBJ_ADD is technically not sufficient imo, since a MOVE (for a device which udev/upstart has never seen before) doesn't necessarily mean "configure this." So when I pass one end of a veth into a running ubuntu container, there is no network-interface or network-interface-security upstart job for it, whereas if I do a ip link add type veth inside the container, those do get the jobs. Now, ISTM passing an endpoing into a container is mainly done at startup, and upstart will end up configuring it anyway. Nothing is really breaking in any of the container usages I've seen because of this. But it would definately be cleaner to pass a KOBJ_ADD before the KOBJ_MOVE. Otherwise, udev has to guess what the MOVE meant. If there's no objection, I'll add that (and test it) and send to netdev on monday. -serge From johannes_graumann at web.de Sat Oct 13 04:13:36 2012 From: johannes_graumann at web.de (Johannes Graumann) Date: Sat, 13 Oct 2012 07:13:36 +0300 Subject: [Lxc-users] lxc-container as a tool to learn selinux? References: <20121012133454.GA4901@sergelap> Message-ID: Serge Hallyn wrote: > Quoting Johannes Graumann > (johannes_graumann at web.de): >> Hello, >> >> Is it possible to run selinux in a lxc container on a non-selinux host? I >> am considering starting to learl selinux and this would make things easy? >> Any pointers to howtos? > > No. But you could run an selinux-enabled (and enforcing) host with a > completely unconfined system, and have just the container start an > enforcing > policy. That could be fun and educational. > > How to go about it would depend on the distro, version and configuration > of the host. Thank you for your input - I will be looking into that possibility. Sincerely, Joh From serge.hallyn at canonical.com Sat Oct 13 05:17:22 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sat, 13 Oct 2012 00:17:22 -0500 Subject: [Lxc-users] uevent when moving nic between network namespaces? In-Reply-To: <87626fmihz.fsf@xmission.com> References: <20121012031328.GA5472@sergelap> <871uh4pdzd.fsf@xmission.com> <20121012191828.GA12200@sergelap> <87sj9jmqew.fsf@xmission.com> <20121012215650.GA22665@sergelap> <87bog7mjhm.fsf@xmission.com> <20121012221711.GA23227@sergelap> <87626fmihz.fsf@xmission.com> Message-ID: <20121013051722.GA13589@sergelap> Quoting Eric W. Biederman (ebiederm at xmission.com): > Serge Hallyn writes: > > > Quoting Eric W. Biederman (ebiederm at xmission.com): > >> Serge Hallyn writes: > >> > >> > Quoting Eric W. Biederman (ebiederm at xmission.com): > >> >> I am not currently working on a patch for this, but I will be happy to > >> >> review one. At a quick glance it looks like this could just be as > >> >> simple as calling kobject_uevent at the proper time, but testing and > >> >> reading through the relevant code paths is probably a good idea as there > >> >> always seems to be gotchas in that code. > >> >> > >> >> Eric > >> > > >> > This (the simple fix) works for me, actually. > >> > > >> > I do notice the ifdef shouldn't be needed, all the better. > >> > >> Should we have a KOBJ_ADD in the new network namespace or is the > >> KOBJ_MOVE sufficient? > > > > I was wondering about that... the KOBJ_ADD is technically not sufficient > > imo, since a MOVE (for a device which udev/upstart has never seen before) > > doesn't necessarily mean "configure this." So when I pass one end of a > > veth into a running ubuntu container, there is no network-interface or > > network-interface-security upstart job for it, whereas if I do a > > ip link add type veth inside the container, those do get the jobs. > > > > Now, ISTM passing an endpoing into a container is mainly done at > > startup, and upstart will end up configuring it anyway. Nothing is > > really breaking in any of the container usages I've seen because of this. > > But it would definately be cleaner to pass a KOBJ_ADD before the KOBJ_MOVE. > > Otherwise, udev has to guess what the MOVE meant. > > > > If there's no objection, I'll add that (and test it) and send to netdev > > on monday. > > Sounds good. Right now I have the suspicion we might want our own > variant on sysfs_move that sends these instead of the move... > > But let's confirm things work better with add/remove before we go crazy > on the best way to generate maintainable code. Yup all still looks good with the following trivial patch. And now when I pass a netdev into a running container, it gets a network-interface upstart job just as it does on a real host. And no network-interface jobs stick around after the container shuts down, meaning this solves the kernel part of bug 1065589 (https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589). (Pre-existing nics don't get a network-interface job - the fact that lxc first passes in the netdevs and then execs init therefore still causes some asymmetry wrt a real host, where netdevs always come up after init starts. AFAIK we don't care, but St?phane might know of a reason why we do - in either case it's not the kernel's problem) >From 01dc08273fa63a50f6dbb7377397ec52a7a337f8 Mon Sep 17 00:00:00 2001 From: Serge Hallyn Date: Fri, 12 Oct 2012 21:42:05 +0100 Subject: [PATCH 1/1] dev_change_net_namespace: send a KOBJ_REMOVED to original netns v2: also send KOBJ_ADD to new netns. There will then be a _MOVE event from the device_rename() call, but that should be innocuous. Signed-off-by: Serge Hallyn --- net/core/dev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/core/dev.c b/net/core/dev.c index e2215ee..2c43aaf 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6172,6 +6172,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char dev_uc_flush(dev); dev_mc_flush(dev); + /* Send a netdev-removed uevent to the old namespace */ + kobject_uevent(&dev->dev.kobj, KOBJ_REMOVE); + /* Actually switch the network namespace */ dev_net_set(dev, net); @@ -6183,6 +6186,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char dev->iflink = dev->ifindex; } + /* Send a netdev-add uevent to the new namespace */ + kobject_uevent(&dev->dev.kobj, KOBJ_ADD); + /* Fixup kobjects */ err = device_rename(&dev->dev, dev->name); WARN_ON(err); -- 1.7.10.4 From xuanmingyi at gmail.com Mon Oct 15 02:19:37 2012 From: xuanmingyi at gmail.com (=?GB2312?B?0PvD+tLV?=) Date: Mon, 15 Oct 2012 10:19:37 +0800 Subject: [Lxc-users] use lxc in python,manage lxc Message-ID: can we use lxc with python2 I find a lxc binding for python3 http://www.stgraber.org/2012/09/28/introducing-the-python-lxc-api/ But I used python2. And Do we have a software which can manage lxc-containers such as create,destroy,start,modify containers.But not command with shell . Thanks. -- ???: http://www.xuanmingyi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stgraber at ubuntu.com Mon Oct 15 07:50:15 2012 From: stgraber at ubuntu.com (=?UTF-8?B?U3TDqXBoYW5lIEdyYWJlcg==?=) Date: Mon, 15 Oct 2012 09:50:15 +0200 Subject: [Lxc-users] use lxc in python,manage lxc In-Reply-To: References: Message-ID: <507BC037.9020908@ubuntu.com> On 10/15/2012 04:19 AM, ??? wrote: > can we use lxc with python2 > I find a lxc binding for python3 > > http://www.stgraber.org/2012/09/28/introducing-the-python-lxc-api/ > > But I used python2. > > And Do we have a software which can manage lxc-containers such as > create,destroy,start,modify containers.But not command with shell . > Thanks. The bindings are for python3 only and I don't intend to support python2 as it'd mean twice the amount of implementation time and testing + a nightmare for unicode handling. python3 has now been around for a long time and should be the preferred python version for any new development. There are a few scripts already using python3-lxc to manage containers, Jonathan Carter has one on his github: https://github.com/highvoltage/llxc > -- > ???: http://www.xuanmingyi.com -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From tompos at martos.bme.hu Mon Oct 15 08:23:40 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 15 Oct 2012 10:23:40 +0200 Subject: [Lxc-users] use lxc in python,manage lxc In-Reply-To: <507BC037.9020908@ubuntu.com> References: <507BC037.9020908@ubuntu.com> Message-ID: <507BC80C.8030906@martos.bme.hu> On 10/15/2012 09:50 AM, St?phane Graber wrote: > There are a few scripts already using python3-lxc to manage containers, > Jonathan Carter has one on his github: > https://github.com/highvoltage/llxc Is there an uptodate LXC ppa available? Maybe Serge, do you plan to update your backport PPA int he future? Thank you, tamas From xuanmingyi at gmail.com Mon Oct 15 09:03:46 2012 From: xuanmingyi at gmail.com (=?GB2312?B?0PvD+tLV?=) Date: Mon, 15 Oct 2012 17:03:46 +0800 Subject: [Lxc-users] use lxc in python,manage lxc In-Reply-To: <507BC037.9020908@ubuntu.com> References: <507BC037.9020908@ubuntu.com> Message-ID: 2012/10/15 St?phane Graber > On 10/15/2012 04:19 AM, ??? wrote: > > can we use lxc with python2 > > I find a lxc binding for python3 > > > > http://www.stgraber.org/2012/09/28/introducing-the-python-lxc-api/ > > > > But I used python2. > > > > And Do we have a software which can manage lxc-containers such as > > create,destroy,start,modify containers.But not command with shell . > > Thanks. > > The bindings are for python3 only and I don't intend to support python2 > as it'd mean twice the amount of implementation time and testing + a > nightmare for unicode handling. > > python3 has now been around for a long time and should be the preferred > python version for any new development. > > > There are a few scripts already using python3-lxc to manage containers, > Jonathan Carter has one on his github: > https://github.com/highvoltage/llxc > > > -- > > ???: http://www.xuanmingyi.com > > > -- > St?phane Graber > Ubuntu developer > http://www.ubuntu.com > > Thank you for your lib and your advice about python3. I'm so sad that you won't support python2 :( Now I will use python2 and python3 in different projects at the same time ! OMG -- ???: http://www.xuanmingyi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stgraber at ubuntu.com Mon Oct 15 10:04:24 2012 From: stgraber at ubuntu.com (=?ISO-8859-1?Q?St=E9phane_Graber?=) Date: Mon, 15 Oct 2012 12:04:24 +0200 Subject: [Lxc-users] use lxc in python,manage lxc In-Reply-To: <507BC80C.8030906@martos.bme.hu> References: <507BC037.9020908@ubuntu.com> <507BC80C.8030906@martos.bme.hu> Message-ID: <507BDFA8.2020400@ubuntu.com> On 10/15/2012 10:23 AM, Papp Tamas wrote: > On 10/15/2012 09:50 AM, St?phane Graber wrote: >> There are a few scripts already using python3-lxc to manage containers, >> Jonathan Carter has one on his github: >> https://github.com/highvoltage/llxc > > Is there an uptodate LXC ppa available? > Maybe Serge, do you plan to update your backport PPA int he future? > > Thank you, > tamas I try to keep ppa:~stgraber/experimental up to date with backports from Ubuntu 12.10, though ideally those should go to the official precise-backports pocket. On top of that, we have daily builds for Ubuntu 12.04 and 12.10 in ppa:~ubuntu-lxc/daily. Note that those aren't guaranteed to always work as they come straight from the staging git tree and don't have any distro patch applied to them. -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From frank at frankscholten.nl Mon Oct 15 16:04:13 2012 From: frank at frankscholten.nl (Frank Scholten) Date: Mon, 15 Oct 2012 18:04:13 +0200 Subject: [Lxc-users] lxc-setcap 'Failed to set capabilities on file /usr/local/libexec/lxc-init' In-Reply-To: <20121012174059.GA30919@sergelap> References: <20121012174059.GA30919@sergelap> Message-ID: On Fri, Oct 12, 2012 at 7:40 PM, Serge Hallyn wrote: > Quoting Frank Scholten (frank at frankscholten.nl): >> Hi all, >> >> I want to run non-root LXCs and I read I have to run sudo lxc-setcap >> first. I am running Ubuntu 12.04 btw. >> >> So I cloned the git repo, ran ./configure, make, make install but when >> I run lxc-setcap I get: >> >> root at franktop:/usr/local/libexec# lxc-setcap >> Failed to set capabilities on file `/usr/local/libexec/lxc-init' (No >> such file or directory) >> >> Turns out lxc-init exists under /usr/local/libexec/lxc/lxc-init >> >> Is this an error in the Makefile? > > Yeah, bc lxc-init has moved, but supporting lxc-setcap is not interesting > right now. It doesn't really work anyway (there are scripts involved, > which you cannot attach capabilities to). Ok, I wasn't aware of that. Curious to know more about this. Which docs / man pages can I read about this subject? I realize waiting is no fun, but > we're getting really close to being able to start up containers unp-privileged > through user namespaces. > > -serge > Looking foward to it! Cheers, Frank From frank at frankscholten.nl Mon Oct 15 16:10:45 2012 From: frank at frankscholten.nl (Frank Scholten) Date: Mon, 15 Oct 2012 18:10:45 +0200 Subject: [Lxc-users] [lxc-attach error] Failed to open /proc/4468/ns/pid. Failed to enter namespace Message-ID: Hi all, I am trying to run commands inside the container. Running lxc 0.7.5.1, commit 60a742e0afd from sourceforge. I created and started an Ubuntu container and when I run $ sudo lxc-attach -e -n test whoami I get 'Failed to open /proc/4468/ns/pid. Failed to enter namespace' Any idea what could be wrong? Cheers, Frank From serge.hallyn at canonical.com Mon Oct 15 16:25:07 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 15 Oct 2012 11:25:07 -0500 Subject: [Lxc-users] [lxc-attach error] Failed to open /proc/4468/ns/pid. Failed to enter namespace In-Reply-To: References: Message-ID: <20121015162507.GA25776@sergelap> Quoting Frank Scholten (frank at frankscholten.nl): > Hi all, > > I am trying to run commands inside the container. > > Running lxc 0.7.5.1, commit 60a742e0afd from sourceforge. > > I created and started an Ubuntu container and when I run > > $ sudo lxc-attach -e -n test whoami > > I get > > 'Failed to open /proc/4468/ns/pid. Failed to enter namespace' > > Any idea what could be wrong? Your kernel does not support setns for pid. /proc/$$/ns/pid does not exist. -serge From serge.hallyn at canonical.com Mon Oct 15 17:47:26 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 15 Oct 2012 12:47:26 -0500 Subject: [Lxc-users] [PATCH 1/1] dev_change_net_namespace: send a KOBJ_REMOVED/KOBJ_ADD Message-ID: <20121015174726.GA15435@sergelap> When a new nic is created in namespace ns1, the kernel sends a KOBJ_ADD uevent to ns1. When the nic is moved to ns2, we only send a KOBJ_MOVE to ns2, and nothing to ns1. This patch changes that behavior so that when moving a nic from ns1 to ns2, we send a KOBJ_REMOVED to ns1 and KOBJ_ADD to ns2. (The KOBJ_MOVE is still sent to ns2). The effects of this can be seen when starting and stopping containers in an upstart based host. Lxc will create a pair of veth nics, the kernel sends KOBJ_ADD, and upstart starts network-instance jobs for each. When one nic is moved to the container, because no KOBJ_REMOVED event is received, the network-instance job for that veth never goes away. This was reported at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 With this patch the networ-instance jobs properly go away. The other oddness solved here is that if a nic is passed into a running upstart-based container, without this patch no network-instance job is started in the container. But when the container creates a new nic itself (ip link add new type veth) then network-interface jobs are created. With this patch, behavior comes in line with a regular host. v2: also send KOBJ_ADD to new netns. There will then be a _MOVE event from the device_rename() call, but that should be innocuous. Signed-off-by: Serge Hallyn Acked-by: "Eric W. Biederman" --- net/core/dev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/core/dev.c b/net/core/dev.c index e2215ee..2c43aaf 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6172,6 +6172,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char dev_uc_flush(dev); dev_mc_flush(dev); + /* Send a netdev-removed uevent to the old namespace */ + kobject_uevent(&dev->dev.kobj, KOBJ_REMOVE); + /* Actually switch the network namespace */ dev_net_set(dev, net); @@ -6183,6 +6186,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char dev->iflink = dev->ifindex; } + /* Send a netdev-add uevent to the new namespace */ + kobject_uevent(&dev->dev.kobj, KOBJ_ADD); + /* Fixup kobjects */ err = device_rename(&dev->dev, dev->name); WARN_ON(err); -- 1.7.9.5 From daniel.lezcano at free.fr Mon Oct 15 20:14:17 2012 From: daniel.lezcano at free.fr (Daniel Lezcano) Date: Mon, 15 Oct 2012 22:14:17 +0200 Subject: [Lxc-users] [PATCH 1/1] dev_change_net_namespace: send a KOBJ_REMOVED/KOBJ_ADD In-Reply-To: <20121015174726.GA15435@sergelap> References: <20121015174726.GA15435@sergelap> Message-ID: <507C6E99.7090906@free.fr> On 10/15/2012 07:47 PM, Serge Hallyn wrote: > When a new nic is created in namespace ns1, the kernel sends a KOBJ_ADD uevent > to ns1. When the nic is moved to ns2, we only send a KOBJ_MOVE to ns2, and > nothing to ns1. > > This patch changes that behavior so that when moving a nic from ns1 to ns2, we > send a KOBJ_REMOVED to ns1 and KOBJ_ADD to ns2. (The KOBJ_MOVE is still > sent to ns2). > > The effects of this can be seen when starting and stopping containers in > an upstart based host. Lxc will create a pair of veth nics, the kernel > sends KOBJ_ADD, and upstart starts network-instance jobs for each. When > one nic is moved to the container, because no KOBJ_REMOVED event is > received, the network-instance job for that veth never goes away. This > was reported at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1065589 > With this patch the networ-instance jobs properly go away. > > The other oddness solved here is that if a nic is passed into a running > upstart-based container, without this patch no network-instance job is > started in the container. But when the container creates a new nic > itself (ip link add new type veth) then network-interface jobs are > created. With this patch, behavior comes in line with a regular host. > > v2: also send KOBJ_ADD to new netns. There will then be a > _MOVE event from the device_rename() call, but that should > be innocuous. > > Signed-off-by: Serge Hallyn > Acked-by: "Eric W. Biederman" Acked-by: Daniel Lezcano > --- > net/core/dev.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/net/core/dev.c b/net/core/dev.c > index e2215ee..2c43aaf 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -6172,6 +6172,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char > dev_uc_flush(dev); > dev_mc_flush(dev); > > + /* Send a netdev-removed uevent to the old namespace */ > + kobject_uevent(&dev->dev.kobj, KOBJ_REMOVE); > + > /* Actually switch the network namespace */ > dev_net_set(dev, net); > > @@ -6183,6 +6186,9 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char > dev->iflink = dev->ifindex; > } > > + /* Send a netdev-add uevent to the new namespace */ > + kobject_uevent(&dev->dev.kobj, KOBJ_ADD); > + > /* Fixup kobjects */ > err = device_rename(&dev->dev, dev->name); > WARN_ON(err); From tompos at martos.bme.hu Tue Oct 16 08:07:24 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Tue, 16 Oct 2012 10:07:24 +0200 Subject: [Lxc-users] task counter cgroup Message-ID: <507D15BC.6050807@martos.bme.hu> hi All, Is there any news about this in the mainline kernel? I didn't see it in the kernel changelog. Thank you, tamas From serge.hallyn at canonical.com Tue Oct 16 13:04:21 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Tue, 16 Oct 2012 08:04:21 -0500 Subject: [Lxc-users] Changes for lxc-debian template (based on lxc-ubuntu) In-Reply-To: <3086713.Se4gNuEGMp@thinkpad-x61-tablet> References: <3086713.Se4gNuEGMp@thinkpad-x61-tablet> Message-ID: <20121016130421.GB5721@sergelap> Quoting Axel Sch?ner (axel.schoener at fh-kl.de): > Hi @all, > > to install older debian versions as linux-container, i've modified the lxc- > debian template based on the lxc-ubuntu template. > > The template is attached to this email. > > It would be nice, if someone can replace the old one with something like this. > > Thanks Axel Please send a patch, not a new template, and a more detailed changelog, so we can better review. thanks, -serge From swairshah at gmail.com Tue Oct 16 13:28:19 2012 From: swairshah at gmail.com (swair shah) Date: Tue, 16 Oct 2012 18:58:19 +0530 Subject: [Lxc-users] errors with the example conf lxc-macvlan Message-ID: I'm trying to use lxc in arch linux. lxc version is 0.8. Running lxc-execute with the conf file lxc-macvlan.conf is not working. whereas if I exclude the network part from the conf, e.g using lxc-no-netns.conf is working fine. Errors are as follows, #lxc-create -n test -f /usr/share/doc/lxc/examples/lxc-macvlan.conf 'test' created #lxc-execute -n test /bin/bash lxc-execute: failed to setup_ipv6_addr ifindex 91 : Permission denied lxc-execute: failed to setup ipv6 addresses for 'eth0' lxc-execute: failed to setup netdev lxc-execute: failed to setup the network for 'test' lxc-execute: failed to setup the container lxc-execute: invalid sequence number 1. expected 2 lxc-execute: failed to spawn 'test' When i do lxc-checkconfig, everything is enabled EXCEPT, User namespace: missing. what could be the issue? cheers, swair -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at frankscholten.nl Tue Oct 16 15:18:10 2012 From: frank at frankscholten.nl (Frank Scholten) Date: Tue, 16 Oct 2012 17:18:10 +0200 Subject: [Lxc-users] [lxc-attach error] Failed to open /proc/4468/ns/pid. Failed to enter namespace In-Reply-To: <20121015162507.GA25776@sergelap> References: <20121015162507.GA25776@sergelap> Message-ID: frank at franktop:~$ uname -a Linux franktop 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux I thought setns was added in 3.0? I also have the setns man page. How do I enable it? Do I have to compile a new kernel? Cheers, Frank On Mon, Oct 15, 2012 at 6:25 PM, Serge Hallyn wrote: > Quoting Frank Scholten (frank at frankscholten.nl): >> Hi all, >> >> I am trying to run commands inside the container. >> >> Running lxc 0.7.5.1, commit 60a742e0afd from sourceforge. >> >> I created and started an Ubuntu container and when I run >> >> $ sudo lxc-attach -e -n test whoami >> >> I get >> >> 'Failed to open /proc/4468/ns/pid. Failed to enter namespace' >> >> Any idea what could be wrong? > > Your kernel does not support setns for pid. /proc/$$/ns/pid > does not exist. > > -serge > From le.waldman at gmail.com Tue Oct 16 15:30:44 2012 From: le.waldman at gmail.com (Leon Waldman) Date: Tue, 16 Oct 2012 12:30:44 -0300 Subject: [Lxc-users] Issues with mass-starting and bridge In-Reply-To: <50732338.9080704@gmail.com> References: <50732338.9080704@gmail.com> Message-ID: <507D7DA4.7040709@gmail.com> Hi, Just to send a feedback... Looks like the problems were related to the virtualbox network layer. I did the same setup on a Xen VM and till now, everything went fine (except for the fact that the VMs are rebooting after 20 minutes, but I think this is duo to low setting on the gc_thresh1 (it's on 128) and I'm starting to troubleshoot it now! :P). Any way, thank very much for the insights! :) On 10/08/2012 04:02 PM, Leon Waldman wrote: > Hi all, > > > I'm having a strange issue with the bridge on my lxc host. > > > First, some background info: > I'm running lxc version 0.75 on a CentOS 6.3 install with the standard > kernel (2.6.32-279.9.1.el6.i686). > it's running inside a VirtualBox VM. > > I created 100 containers and named from 000 to 099. they are all with > sequential assigned IPs and macaddresses (from 10.0.1.0/8 till > 10.0.1.99/8 | 80:04:C0:AB:00:00 till 80:04:C0:AB:00:63). > > > When starting them in "mass" with something like: > for i in `range 0 99`; do echo $i; lxc-start -n $i -d; done > after a random number of containers is started the br0 bridge just > stops to answer for anything. It just freezes (it's easy to note > because I'm connecting to the host through ssh using the same bridge). > > If I put a sleep 5 on the for above, things goes better, but then one > or two of the containers became a "remote bridge bomb". The bridge > stays working till a packet arrives to the "bomb" container, and them > again the entire bridge freezes. This container bomb is also random. > > if I remove the problematic container iface from the bridge, it > unfreezes. If I add it again and send a packet... It freezes again. If > I stop the container and re-start it... all goes fine and the issue > vanish. > > > From my point of view, looks like when the virtual iface is created > during the container start (if under load or with too much concurrent > starts... I don't know), sometimes something goes wrong with the iface > and it mess with the entire bridge if this "messy" iface is attached. > > > Do any one have any input on this (do this happened before? Is there a > limit for concurrent containers initializations? Is there a kernel > setting or some config that I could do to solve it)? > > > In order to achieve what I need in production environment, I will need > to start and stop containers several times per minute. Do this sound > too problematic? > > > If you guys need any additional information, please just let me know. > > > Thanks in advance > > -- > *Leon Waldman* > Senior Linux/UNIX SysAdmin & Consultant. > Back-End & Infrastructure Architect. > View Leon Waldman's profile on LinkedIn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2775 bytes Desc: not available URL: From serge.hallyn at canonical.com Tue Oct 16 15:48:32 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Tue, 16 Oct 2012 10:48:32 -0500 Subject: [Lxc-users] [lxc-attach error] Failed to open /proc/4468/ns/pid. Failed to enter namespace In-Reply-To: References: <20121015162507.GA25776@sergelap> Message-ID: <20121016154832.GA12793@sergelap> Quoting Frank Scholten (frank at frankscholten.nl): > frank at franktop:~$ uname -a > Linux franktop 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC > 2012 x86_64 x86_64 x86_64 GNU/Linux > > I thought setns was added in 3.0? Not for pid ns. do 'ls /proc/self/ns' to see the list of namespaces to which you can setns. > I also have the setns man page. How > do I enable it? Do I have to compile a new kernel? > > Cheers, > > Frank > > On Mon, Oct 15, 2012 at 6:25 PM, Serge Hallyn > wrote: > > Quoting Frank Scholten (frank at frankscholten.nl): > >> Hi all, > >> > >> I am trying to run commands inside the container. > >> > >> Running lxc 0.7.5.1, commit 60a742e0afd from sourceforge. > >> > >> I created and started an Ubuntu container and when I run > >> > >> $ sudo lxc-attach -e -n test whoami > >> > >> I get > >> > >> 'Failed to open /proc/4468/ns/pid. Failed to enter namespace' > >> > >> Any idea what could be wrong? > > > > Your kernel does not support setns for pid. /proc/$$/ns/pid > > does not exist. > > > > -serge > > From xuanmingyi at gmail.com Wed Oct 17 01:39:45 2012 From: xuanmingyi at gmail.com (=?GB2312?B?0PvD+tLV?=) Date: Wed, 17 Oct 2012 09:39:45 +0800 Subject: [Lxc-users] can we run a kvm vm in lxc? Message-ID: Dear all: Can we run a kvm vm in lxc? Should we modify some thing to make sure the vm work? Thanks -- ???: http://www.xuanmingyi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.hallyn at canonical.com Wed Oct 17 13:27:11 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Wed, 17 Oct 2012 08:27:11 -0500 Subject: [Lxc-users] can we run a kvm vm in lxc? In-Reply-To: References: Message-ID: <20121017132711.GA4935@sergelap> Quoting ??? (xuanmingyi at gmail.com): > Dear all: > Can we run a kvm vm in lxc? Yes. > Should we modify some thing to make sure the vm work? Depends on what you're starting with. You mainly just need to make sure the container can access /dev/kvm. From xuanmingyi at gmail.com Thu Oct 18 03:04:43 2012 From: xuanmingyi at gmail.com (=?GB2312?B?0PvD+tLV?=) Date: Thu, 18 Oct 2012 11:04:43 +0800 Subject: [Lxc-users] python3-lxc "lxc_container: bad template: ubuntu" Message-ID: Dear all: I use python3-lxc but report this error lxc_container: bad template: ubuntu how to build the ubuntu template? Thanks -- ???: http://www.xuanmingyi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.ballantyne at haulashore.com Fri Oct 19 01:42:46 2012 From: gary.ballantyne at haulashore.com (Gary Ballantyne) Date: Fri, 19 Oct 2012 14:42:46 +1300 Subject: [Lxc-users] apparmor and nfs Message-ID: <5080B016.8050200@haulashore.com> Hi I use "lxc.aa_profile = unconfined" to get the NFS client to work in a container (precise host and container). Is that the best approach? Thanks Gary From lxc at jelmail.com Fri Oct 19 13:29:55 2012 From: lxc at jelmail.com (John) Date: Fri, 19 Oct 2012 14:29:55 +0100 Subject: [Lxc-users] systemd inside LXC Message-ID: <508155D3.4000504@jelmail.com> Hello, I'm in the middle of a migration from init to systemd. I've completed the transition of my host environment and my 6 existing containers continue to work as expected (they all use sysvinit internally). I've started work on a systemd container and am getting some odd effects. First off, if I use systemd-nspawn to start the container, it starts fine. I can log in and halt it and all goes as expected. If, however I use lxc-start, it clobbers my desktop, which is running in another container. So I have 2 problems: (a) the container does not boot and (b) it manages to effect changes in another container. I've been searching the 'net for most of this morning looking for information on using systemd inside a container. I'm using Arch Linux (3.6.2-1-ARCH) with LXC 0.8.0-rc2. Arch now uses systemd by default. To try to test this, I created a basic container and this exhibits the same problems: $ mkarchroot test base Starting with systemd-nspawn works fine: $ systemd-nspawn -D test/ /sbin/init Starting with LXC does not: $ lxc-create -n test -f test.conf $ lxc-start -n test The file test.conf contains these two lines: lxc.utsname = test2 lxc.rootfs = /srv/lxc/test When I start the container in LXC, all that happens is that my X session dies (this is running in another container). The X session re-starts but the keyboard does not work. I have to connect using another machine to kill the test container and re-start my desktop container. I can't see anything starting inside the test container. I'd be grateful for any help and/or pointers in the right direction so I can complete this transition to systemd. Many thanks, John From serge.hallyn at canonical.com Fri Oct 19 15:51:01 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 19 Oct 2012 10:51:01 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <508155D3.4000504@jelmail.com> References: <508155D3.4000504@jelmail.com> Message-ID: <20121019155101.GA10078@sergelap> Quoting John (lxc at jelmail.com): > Hello, I'm in the middle of a migration from init to systemd. I've > completed the transition of my host environment and my 6 existing > containers continue to work as expected (they all use sysvinit > internally). I've started work on a systemd container and am getting > some odd effects. > > First off, if I use systemd-nspawn to start the container, it starts > fine. I can log in and halt it and all goes as expected. If, however I > use lxc-start, it clobbers my desktop, which is running in another > container. > > So I have 2 problems: (a) the container does not boot and (b) it manages > to effect changes in another container. > > I've been searching the 'net for most of this morning looking for > information on using systemd inside a container. > > I'm using Arch Linux (3.6.2-1-ARCH) with LXC 0.8.0-rc2. Arch now uses > systemd by default. > > To try to test this, I created a basic container and this exhibits the > same problems: > > $ mkarchroot test base > > Starting with systemd-nspawn works fine: > $ systemd-nspawn -D test/ /sbin/init > > Starting with LXC does not: > $ lxc-create -n test -f test.conf > $ lxc-start -n test > > The file test.conf contains these two lines: > > lxc.utsname = test2 > lxc.rootfs = /srv/lxc/test Add: lxc.network.type = empty If you don't have any lxc.network.type sections, then the container shares network with the host, and so the container talks to the host's systemd. (same with upstart) > When I start the container in LXC, all that happens is that my X session > dies (this is running in another container). The X session re-starts but > the keyboard does not work. I have to connect using another machine to > kill the test container and re-start my desktop container. I can't see > anything starting inside the test container. > > I'd be grateful for any help and/or pointers in the right direction so I > can complete this transition to systemd. > > Many thanks, > John > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From serge.hallyn at canonical.com Sat Oct 20 00:21:00 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 19 Oct 2012 19:21:00 -0500 Subject: [Lxc-users] apparmor and nfs In-Reply-To: <5080B016.8050200@haulashore.com> References: <5080B016.8050200@haulashore.com> Message-ID: <20121020002100.GA29941@sergelap> Quoting Gary Ballantyne (gary.ballantyne at haulashore.com): > Hi > > I use "lxc.aa_profile = unconfined" to get the NFS client to work in a > container (precise host and container). > > Is that the best approach? If disabling apparmor works, then a custom profile should also work, and would be your best bet. I haven't tried it, but would suggest starting a container with apparmor enabled, and looking through /var/log/auth.log or /var/log/syslog for the specific apparmor denial message. How are you using nfs exactly? Is the lxc.rootfs in the config file set to a subdir on nfs? Or does the container itself try to mount nfs? Can you show the relevant config files? -serge From ken at ipl31.net Sat Oct 20 01:29:02 2012 From: ken at ipl31.net (Ken Caruso) Date: Fri, 19 Oct 2012 18:29:02 -0700 Subject: [Lxc-users] Lingering LXC veth interfaces Message-ID: Hello, I am using system LXCs on Ubuntu 11.10 (switching to 12.04 soon). I am managing the LXCs with some home grown scripts(not via libvirtd). If I lxc-stop a container sometimes the veth interfaces created on the host do not go away immediately, I believe it is the same thing described in this thread: http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg00165.html Is there an easy way to clean these sockets up manually to force the deletion of the veth devices? Does libvirt clean these when LXCs are destroyed or does behave the same way? Thanks -Ken From dank at kegel.com Sat Oct 20 04:16:51 2012 From: dank at kegel.com (Dan Kegel) Date: Fri, 19 Oct 2012 21:16:51 -0700 Subject: [Lxc-users] Lingering LXC veth interfaces In-Reply-To: References: Message-ID: On Fri, Oct 19, 2012 at 6:29 PM, Ken Caruso wrote: > I am using system LXCs on Ubuntu 11.10 (switching to 12.04 soon). I am > managing the LXCs with some home grown scripts(not via libvirtd). > > If I lxc-stop a container sometimes the veth interfaces created on the > host do not go away immediately, I believe it is the same thing > described in this thread: > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg00165.html > > Is there an easy way to clean these sockets up manually to force the > deletion of the veth devices? Might that be https://bugs.launchpad.net/bugs/1065589 ? - Dan From ken at ipl31.net Sat Oct 20 04:37:53 2012 From: ken at ipl31.net (Ken Caruso) Date: Fri, 19 Oct 2012 21:37:53 -0700 Subject: [Lxc-users] Lingering LXC veth interfaces In-Reply-To: References: Message-ID: On 10/19/12, Dan Kegel wrote: > On Fri, Oct 19, 2012 at 6:29 PM, Ken Caruso wrote: >> I am using system LXCs on Ubuntu 11.10 (switching to 12.04 soon). I am >> managing the LXCs with some home grown scripts(not via libvirtd). >> >> If I lxc-stop a container sometimes the veth interfaces created on the >> host do not go away immediately, I believe it is the same thing >> described in this thread: >> >> http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg00165.html >> >> Is there an easy way to clean these sockets up manually to force the >> deletion of the veth devices? > > Might that be https://bugs.launchpad.net/bugs/1065589 ? > - Dan I don't think it is. The reason is that the lingering interface goes away after a few minutes or less. I read the bug report and corresponding list thread and gathered that in that situation the interface would not go away unless it was manually removed or the host was rebooted. -Ken From carlopmart at gmail.com Sat Oct 20 13:12:24 2012 From: carlopmart at gmail.com (C. L. Martinez) Date: Sat, 20 Oct 2012 13:12:24 +0000 Subject: [Lxc-users] Template for Oracle Linux 6.3 Message-ID: Hi all, Somebody knows where can I found an Oracle Linux 6.3 template to use with a OL6.3 host using UEK2 kernel?? Or can I re-use OL5 template?? Thanks. From list at fajar.net Sat Oct 20 16:26:38 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sat, 20 Oct 2012 23:26:38 +0700 Subject: [Lxc-users] Template for Oracle Linux 6.3 In-Reply-To: References: Message-ID: On Sat, Oct 20, 2012 at 8:12 PM, C. L. Martinez wrote: > Hi all, > > Somebody knows where can I found an Oracle Linux 6.3 template to use > with a OL6.3 host using UEK2 kernel?? Short answer: No > Or can I re-use OL5 template?? ... and No. Long answer: See this thread: http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03936.html You SHOULD be able to customize my centos template for OL (untested). Start with the line that says "[base]", and change it to OL's public yum repository. PS: (1) it doesn't matter (in lxc template context) whether you use RH's kernel or UEK2. The container doesn't really need a kernel package installed (and in most cases, it doesn't care which kernel is installed, cause it's only used to resolve dependency). What matters is what kernel you use on the host. (2) UEK2 is pretty old (3.0+?). If your focus is lxc, you might have better luck using kernel-ml (http://elrepo.org/tiki/kernel-ml) -- Fajar From ken at ipl31.net Sat Oct 20 17:21:43 2012 From: ken at ipl31.net (Ken Caruso) Date: Sat, 20 Oct 2012 10:21:43 -0700 Subject: [Lxc-users] Lingering LXC veth interfaces In-Reply-To: References: Message-ID: On 10/19/12, Ken Caruso wrote: > Hello, > > I am using system LXCs on Ubuntu 11.10 (switching to 12.04 soon). I am > managing the LXCs with some home grown scripts(not via libvirtd). > > If I lxc-stop a container sometimes the veth interfaces created on the > host do not go away immediately, I believe it is the same thing > described in this thread: > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg00165.html > > Is there an easy way to clean these sockets up manually to force the > deletion of the veth devices? FWIW, I discovered that "ip link delete $veth_int" seems to fix remove the lingering interface regardless of open sockets that were associated with the now stopped LXC. -Ken From mhw at WittsEnd.com Sat Oct 20 23:41:59 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 20 Oct 2012 19:41:59 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121019155101.GA10078@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> Message-ID: <1350776519.30263.36.camel@canyon.wittsend.com> Serge, I'm going to top post here simply because this is going to go off in a different direction and bringing in an old thread but it is related... Back on February 14 you responded to a message about Fedora 16 in a container, which is something I've been trying to do and I had run into that posters problems. You responded with this: Subject: Re: [Lxc-users] fedora 16 under lxc On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote: > Quoting Ramez Hanna (rhanna at informatiq.org): > > now all my efforts have not succeedd to get getty on tty1 to start > > unmasking udev did something different > > it created all the /dev devices > > and made getty start but it started on the hosts's tty not on the container's > > could someone shed some light here? > > Blind guess: > > lxc-start creates some ptys and bind mounts them onto the guest's > /dev/{console,tty{1,2,3,4}}. It sounds like fedora's init is mounting > over the /dev set up by lxc causing a new /dev/tty to be created as > chardev 4:{1-4}. Devices namespaces would help this. We're hoping to > discuss design for those at next UDS, but those will come after user > namespaces. In the mean time, you'll need to make sure that the guest > does not mount over /dev, and does not remount /dev/pts. > > -serge That got me thinking and started into looking deeper into systemd, which Fedora 16 and above uses and why it may be related here. I've made Fedora 16 work in the past by installing upstart and disabling systemd but that really becomes impractical in Fedora 17 because they're including so few of the compatibility scripts. Yes, you are right, the Fedora's init (systemd) is mounting something on /dev like this: devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=1784160k,nr_inodes=446040,mode=755) This is very bad for the reasons you pointed out in Feb. Looking at the source code for systemd, this is hard coded into the binary and is not configurable. systemd-37/src/mount-setup.c: -- /* The first three entries we might need before SELinux is up. The * other ones we can delay until SELinux is loaded. */ #define N_EARLY_MOUNT 3 static const MountPoint mount_table[] = { { "proc", "/proc", "proc", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, { "sysfs", "/sys", "sysfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, { "devtmpfs", "/dev", "devtmpfs", "mode=755", MS_NOSUID, true }, { "tmpfs", "/dev/shm", "tmpfs", "mode=1777", MS_NOSUID|MS_NODEV, true }, { "devpts", "/dev/pts", "devpts", "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false }, { "tmpfs", "/run", "tmpfs", "mode=755", MS_NOSUID|MS_NODEV, true }, { "tmpfs", "/sys/fs/cgroup", "tmpfs", "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, { "cgroup", "/sys/fs/cgroup/systemd", "cgroup", "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, }; -- Short of building a custom systemd, I don't know how to fix that problem and I suspect this OP is going to run into this same thing (container taking over host's console) and might explain some of what he's seeing. Several of these look like they could cause problems (like /dev/pts in there). I've really reached an impasse at getting systemd (at least Fedora 16 and 17) to work in a container without screwing up the host. Prohibiting mounts entirely in the container might work but I suspect (having read some systemd error messages) systemd is going to have some serious heartburn there. Thoughts? Regards, Mike On Fri, 2012-10-19 at 10:51 -0500, Serge Hallyn wrote: > Quoting John (lxc at jelmail.com): > > Hello, I'm in the middle of a migration from init to systemd. I've > > completed the transition of my host environment and my 6 existing > > containers continue to work as expected (they all use sysvinit > > internally). I've started work on a systemd container and am getting > > some odd effects. > > > > First off, if I use systemd-nspawn to start the container, it starts > > fine. I can log in and halt it and all goes as expected. If, however I > > use lxc-start, it clobbers my desktop, which is running in another > > container. > > > > So I have 2 problems: (a) the container does not boot and (b) it manages > > to effect changes in another container. > > > > I've been searching the 'net for most of this morning looking for > > information on using systemd inside a container. > > > > I'm using Arch Linux (3.6.2-1-ARCH) with LXC 0.8.0-rc2. Arch now uses > > systemd by default. > > > > To try to test this, I created a basic container and this exhibits the > > same problems: > > > > $ mkarchroot test base > > > > Starting with systemd-nspawn works fine: > > $ systemd-nspawn -D test/ /sbin/init > > > > Starting with LXC does not: > > $ lxc-create -n test -f test.conf > > $ lxc-start -n test > > > > The file test.conf contains these two lines: > > > > lxc.utsname = test2 > > lxc.rootfs = /srv/lxc/test > > Add: > > lxc.network.type = empty > > If you don't have any lxc.network.type sections, then the container > shares network with the host, and so the container talks to the host's > systemd. (same with upstart) > > > When I start the container in LXC, all that happens is that my X session > > dies (this is running in another container). The X session re-starts but > > the keyboard does not work. I have to connect using another machine to > > kill the test container and re-start my desktop container. I can't see > > anything starting inside the test container. > > > > I'd be grateful for any help and/or pointers in the right direction so I > > can complete this transition to systemd. > > > > Many thanks, > > John > > > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > > Lxc-users mailing list > > Lxc-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-users > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From carlopmart at gmail.com Sun Oct 21 08:42:51 2012 From: carlopmart at gmail.com (C. L. Martinez) Date: Sun, 21 Oct 2012 08:42:51 +0000 Subject: [Lxc-users] Problems starting OL6.3 lxc container Message-ID: Hi all, I have setup my first OL6 container but it doesn't starts. When I launch lxc-start command, nothing appears: [root at ol6host templates]# lxc-start -n ol6vmserver -o /tmp/ol.log --logpriority=DEBUG My config is: # Container configuration for Oracle Linux 6 lxc.arch = x86_64 lxc.utsname = ol6vmserver #lxc.devttydir = lxc lxc.console = /vmdata/ol6vmserver/dev/console lxc.tty = 4 lxc.pts = 1024 lxc.rootfs = /vmdata/ol6vmserver lxc.mount = /vmdata/lxc-config/ol6vmserver.fstab lxc.network.type = veth lxc.network.flags = up lxc.network.link = prodif lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.hwaddr = 00:50:56:21:2a:d2 lxc.network.ipv4 = 172.25.50.7/27 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 1:7 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 254:0 rwm Trying to access using lxc-console: [root at ol6host dev]# lxc-console -n ol6vmserver Type to exit the console And in log file, I don't see nothing strange: lxc-start 1350808610.402 DEBUG lxc_conf - allocated pty '/dev/pts/4' (4/5) lxc-start 1350808610.403 DEBUG lxc_conf - allocated pty '/dev/pts/5' (6/7) lxc-start 1350808610.403 DEBUG lxc_conf - allocated pty '/dev/pts/6' (8/9) lxc-start 1350808610.403 DEBUG lxc_conf - allocated pty '/dev/pts/7' (10/11) lxc-start 1350808610.403 INFO lxc_conf - tty's configured lxc-start 1350808610.403 DEBUG lxc_console - using '/vmdata/ol6vmserver/dev/console' as console lxc-start 1350808610.403 DEBUG lxc_start - sigchild handler set lxc-start 1350808610.403 INFO lxc_start - 'ol6vmserver' is initialized lxc-start 1350808610.408 DEBUG lxc_conf - instanciated veth 'vethMePv5x/veth2e4SEr', index is '26' lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/' (rootfs) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/proc' (proc) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/sys' (sysfs) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/dev' (devtmpfs) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/dev/pts' (devpts) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/dev/shm' (tmpfs) lxc-start 1350808610.412 DEBUG lxc_cgroup - checking '/' (btrfs) lxc-start 1350808610.413 DEBUG lxc_cgroup - checking '/proc/bus/usb' (usbfs) lxc-start 1350808610.413 DEBUG lxc_cgroup - checking '/boot' (ext4) lxc-start 1350808610.413 DEBUG lxc_cgroup - checking '/proc/sys/fs/binfmt_misc' (binfmt_misc) lxc-start 1350808610.413 DEBUG lxc_cgroup - checking '/cgroup/cpuset' (cgroup) lxc-start 1350808610.413 INFO lxc_cgroup - found cgroup mounted at '/cgroup/cpuset' lxc-start 1350808610.413 DEBUG lxc_cgroup - cgroup /cgroup/cpuset has flags 0x2 lxc-start 1350808610.419 INFO lxc_cgroup - created cgroup '/cgroup/cpuset/ol6vmserver' lxc-start 1350808610.419 DEBUG lxc_cgroup - checking '/cgroup/cpu' (cgroup) lxc-start 1350808610.419 INFO lxc_cgroup - found cgroup mounted at '/cgroup/cpu' lxc-start 1350808610.419 DEBUG lxc_cgroup - cgroup /cgroup/cpu has flags 0x2 lxc-start 1350808610.423 INFO lxc_cgroup - created cgroup '/cgroup/cpu/ol6vmserver' lxc-start 1350808610.423 DEBUG lxc_cgroup - checking '/cgroup/cpuacct' (cgroup) lxc-start 1350808610.423 INFO lxc_cgroup - found cgroup mounted at '/cgroup/cpuacct' lxc-start 1350808610.423 DEBUG lxc_cgroup - cgroup /cgroup/cpuacct has flags 0x2 lxc-start 1350808610.426 INFO lxc_cgroup - created cgroup '/cgroup/cpuacct/ol6vmserver' lxc-start 1350808610.427 DEBUG lxc_cgroup - checking '/cgroup/memory' (cgroup) lxc-start 1350808610.427 INFO lxc_cgroup - found cgroup mounted at '/cgroup/memory' lxc-start 1350808610.427 DEBUG lxc_cgroup - cgroup /cgroup/memory has flags 0x2 lxc-start 1350808610.432 INFO lxc_cgroup - created cgroup '/cgroup/memory/ol6vmserver' lxc-start 1350808610.432 DEBUG lxc_cgroup - checking '/cgroup/devices' (cgroup) lxc-start 1350808610.432 INFO lxc_cgroup - found cgroup mounted at '/cgroup/devices' lxc-start 1350808610.432 DEBUG lxc_cgroup - cgroup /cgroup/devices has flags 0x2 lxc-start 1350808610.436 INFO lxc_cgroup - created cgroup '/cgroup/devices/ol6vmserver' lxc-start 1350808610.436 DEBUG lxc_cgroup - checking '/cgroup/freezer' (cgroup) lxc-start 1350808610.436 INFO lxc_cgroup - found cgroup mounted at '/cgroup/freezer' lxc-start 1350808610.436 DEBUG lxc_cgroup - cgroup /cgroup/freezer has flags 0x2 lxc-start 1350808610.440 INFO lxc_cgroup - created cgroup '/cgroup/freezer/ol6vmserver' lxc-start 1350808610.440 DEBUG lxc_cgroup - checking '/cgroup/net_cls' (cgroup) lxc-start 1350808610.440 INFO lxc_cgroup - found cgroup mounted at '/cgroup/net_cls' lxc-start 1350808610.440 DEBUG lxc_cgroup - cgroup /cgroup/net_cls has flags 0x2 lxc-start 1350808610.443 INFO lxc_cgroup - created cgroup '/cgroup/net_cls/ol6vmserver' lxc-start 1350808610.444 DEBUG lxc_cgroup - checking '/cgroup/blkio' (cgroup) lxc-start 1350808610.444 INFO lxc_cgroup - found cgroup mounted at '/cgroup/blkio' lxc-start 1350808610.444 DEBUG lxc_cgroup - cgroup /cgroup/blkio has flags 0x2 lxc-start 1350808610.449 INFO lxc_cgroup - created cgroup '/cgroup/blkio/ol6vmserver' lxc-start 1350808610.450 DEBUG lxc_conf - move 'eth0' to '3323' lxc-start 1350808610.450 INFO lxc_conf - 'ol6vmserver' hostname has been setup lxc-start 1350808610.454 DEBUG lxc_conf - mac address '00:50:56:21:2a:d2' on 'eth0' has been setup lxc-start 1350808610.459 DEBUG lxc_conf - 'eth0' has been setup lxc-start 1350808610.459 INFO lxc_conf - network has been setup lxc-start 1350808610.459 DEBUG lxc_conf - mounted '/vmdata/ol6vmserver' on '/usr/lib64/lxc/rootfs' lxc-start 1350808610.459 DEBUG lxc_conf - mounted 'devpts' on '/usr/lib64/lxc/rootfs/dev/pts', type 'devpts' lxc-start 1350808610.459 DEBUG lxc_conf - mounted 'sysfs' on '/usr/lib64/lxc/rootfs/sys', type 'sysfs' lxc-start 1350808610.460 DEBUG lxc_conf - mounted 'proc' on '/usr/lib64/lxc/rootfs/proc', type 'proc' lxc-start 1350808610.460 INFO lxc_conf - mount points have been setup lxc-start 1350808610.460 INFO lxc_conf - mount points have been setup lxc-start 1350808610.460 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.460 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.460 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.deny lxc-start 1350808610.460 DEBUG lxc_conf - cgroup 'devices.deny' set to 'a' lxc-start 1350808610.460 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.461 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.461 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 1:3 rwm' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.461 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.461 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 1:5 rwm' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.461 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.461 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 1:7 rwm' lxc-start 1350808610.461 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.464 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.464 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.464 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 5:0 rwm' lxc-start 1350808610.464 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.464 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.464 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.464 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 1:8 rwm' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.465 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.465 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 1:9 rwm' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.465 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.465 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 136:* rwm' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.465 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.465 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 5:2 rwm' lxc-start 1350808610.465 DEBUG lxc_cgroup - lxc_cgroup_path_get: called for subsys devices name ol6vmserver lxc-start 1350808610.466 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup/devices' lxc-start 1350808610.466 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/devices/ol6vmserver for subsystem devices.allow lxc-start 1350808610.466 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 254:0 rwm' lxc-start 1350808610.466 INFO lxc_conf - cgroup has been setup lxc-start 1350808610.466 WARN lxc_conf - rootfs specified but no console found at '/usr/lib64/lxc/rootfs/dev/console' lxc-start 1350808610.466 INFO lxc_conf - 4 tty(s) has been setup lxc-start 1350808610.466 DEBUG lxc_conf - mountpoint for old rootfs is '/usr/lib64/lxc/rootfs/mnt' lxc-start 1350808610.466 DEBUG lxc_conf - pivot_root syscall to '/usr/lib64/lxc/rootfs' successful lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/dev/pts' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/dev/shm' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/proc/bus/usb' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/proc/sys/fs/binfmt_misc' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/sys' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/boot' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/cpuset' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/cpu' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/cpuacct' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/memory' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/devices' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/freezer' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/net_cls' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/cgroup/blkio' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/dev' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt/proc' lxc-start 1350808610.467 DEBUG lxc_conf - umounted '/mnt' lxc-start 1350808610.468 INFO lxc_conf - set personality to '0x0' lxc-start 1350808610.468 DEBUG lxc_conf - capabilities has been setup lxc-start 1350808610.468 NOTICE lxc_conf - 'ol6vmserver' is setup. lxc-start 1350808610.468 NOTICE lxc_start - exec'ing '/sbin/init' lxc-start 1350808610.468 NOTICE lxc_start - '/sbin/init' started with pid '3323' lxc-start 1350808610.468 DEBUG lxc_utmp - Added '/proc/3323/root/var/run' to inotifywatch lxc-start 1350808677.016 DEBUG lxc_commands - peer has disconnected Somebody knows where can it be the problem?? Thanks. From list at fajar.net Sun Oct 21 08:46:44 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 21 Oct 2012 15:46:44 +0700 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 3:42 PM, C. L. Martinez wrote: > Hi all, > > I have setup my first OL6 container but it doesn't starts. How? > lxc-start 1350808610.466 WARN lxc_conf - rootfs specified > but no console found at '/usr/lib64/lxc/rootfs/dev/console' Does /usr/lib64/lxc/rootfs/dev/console exists? I highly suggest you try my centos template first. It definitely creates that file. If it works for you, modify it for OL. > Somebody knows where can it be the problem?? Bad container setup? Missing necessary files? -- Fajar From list at fajar.net Sun Oct 21 08:51:30 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 21 Oct 2012 15:51:30 +0700 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 3:46 PM, Fajar A. Nugraha wrote: >> lxc-start 1350808610.466 WARN lxc_conf - rootfs specified >> but no console found at '/usr/lib64/lxc/rootfs/dev/console' > > Does /usr/lib64/lxc/rootfs/dev/console exists? Sorry. It should be "does /dev/console exists under your container rootfs?" Also, you might not need this line: lxc.console = /vmdata/ol6vmserver/dev/console In fact, I'd say remove it, and see if it solves your problem. -- Fajar From carlopmart at gmail.com Sun Oct 21 09:14:16 2012 From: carlopmart at gmail.com (C. L. Martinez) Date: Sun, 21 Oct 2012 09:14:16 +0000 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 8:51 AM, Fajar A. Nugraha wrote: > On Sun, Oct 21, 2012 at 3:46 PM, Fajar A. Nugraha wrote: >>> lxc-start 1350808610.466 WARN lxc_conf - rootfs specified >>> but no console found at '/usr/lib64/lxc/rootfs/dev/console' >> >> Does /usr/lib64/lxc/rootfs/dev/console exists? > > Sorry. It should be "does /dev/console exists under your container rootfs?" > > Also, you might not need this line: > lxc.console = /vmdata/ol6vmserver/dev/console > > In fact, I'd say remove it, and see if it solves your problem. > > -- No, problem continues ... I have used this template to create my lxc container: https://github.com/lxc/lxc/blob/staging/templates/lxc-oracle.in From list at fajar.net Sun Oct 21 09:20:25 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 21 Oct 2012 16:20:25 +0700 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 4:14 PM, C. L. Martinez wrote: > On Sun, Oct 21, 2012 at 8:51 AM, Fajar A. Nugraha wrote: >> On Sun, Oct 21, 2012 at 3:46 PM, Fajar A. Nugraha wrote: >>>> lxc-start 1350808610.466 WARN lxc_conf - rootfs specified >>>> but no console found at '/usr/lib64/lxc/rootfs/dev/console' >>> >>> Does /usr/lib64/lxc/rootfs/dev/console exists? >> >> Sorry. It should be "does /dev/console exists under your container rootfs?" >> >> Also, you might not need this line: >> lxc.console = /vmdata/ol6vmserver/dev/console >> >> In fact, I'd say remove it, and see if it solves your problem. >> >> -- > > No, problem continues ... I have used this template to create my lxc container: In that I says use the unmodified config file first. For example, it says "lxc.devttydir = lxc" (which you commented out). If you HAVE used the default config file created by the template, but it still doesn't work, you should probably contact the template creator directly (it's on top of the template file) and ask them how to use the template. -- Fajar From carlopmart at gmail.com Sun Oct 21 09:23:25 2012 From: carlopmart at gmail.com (C. L. Martinez) Date: Sun, 21 Oct 2012 09:23:25 +0000 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 9:20 AM, Fajar A. Nugraha wrote: >>> -- >> >> No, problem continues ... I have used this template to create my lxc container: > > In that I says use the unmodified config file first. For example, it > says "lxc.devttydir = lxc" (which you commented out). > > If you HAVE used the default config file created by the template, but > it still doesn't work, you should probably contact the template > creator directly (it's on top of the template file) and ask them how > to use the template. > > -- > Fajar Yes, I have commented out because when I launch lxc-start, returns me this error: lxc-start 1350810587.498 ERROR lxc_confile - unknow key lxc.devttydir lxc-start 1350810587.498 ERROR lxc_start_ui - failed to read configuration file Thanks. From list at fajar.net Sun Oct 21 09:27:01 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 21 Oct 2012 16:27:01 +0700 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 4:23 PM, C. L. Martinez wrote: > On Sun, Oct 21, 2012 at 9:20 AM, Fajar A. Nugraha wrote: >>>> -- >>> >>> No, problem continues ... I have used this template to create my lxc container: >> >> In that I says use the unmodified config file first. For example, it >> says "lxc.devttydir = lxc" (which you commented out). >> >> If you HAVE used the default config file created by the template, but >> it still doesn't work, you should probably contact the template >> creator directly (it's on top of the template file) and ask them how >> to use the template. >> >> -- >> Fajar > > Yes, I have commented out because when I launch lxc-start, returns me > this error: > > lxc-start 1350810587.498 ERROR lxc_confile - unknow key lxc.devttydir > lxc-start 1350810587.498 ERROR lxc_start_ui - failed to read > configuration file Looks like an old version problem. Did you know that the staging git repo on github is newer than released lxc version? I wouldn't be surprised if you need to recompile lxc -- using sources from that repo --- to get the template to work. Personally I just use Ubuntu as the host :) It already supports devttydir configuration item. -- Fajar From carlopmart at gmail.com Sun Oct 21 09:41:19 2012 From: carlopmart at gmail.com (C. L. Martinez) Date: Sun, 21 Oct 2012 09:41:19 +0000 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 9:27 AM, Fajar A. Nugraha wrote: > On Sun, Oct 21, 2012 at 4:23 PM, C. L. Martinez wrote: >> On Sun, Oct 21, 2012 at 9:20 AM, Fajar A. Nugraha wrote: >>>>> -- >>>> >>>> No, problem continues ... I have used this template to create my lxc container: >>> >>> In that I says use the unmodified config file first. For example, it >>> says "lxc.devttydir = lxc" (which you commented out). >>> >>> If you HAVE used the default config file created by the template, but >>> it still doesn't work, you should probably contact the template >>> creator directly (it's on top of the template file) and ask them how >>> to use the template. >>> >>> -- Thanks Fajar, I will try to use centos6 instead of OL6 ... Are these your instructions?? http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum http://wiki.1tux.org/wiki/Lxc/Installation/Guest/Centos/6 From list at fajar.net Sun Oct 21 10:17:35 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 21 Oct 2012 17:17:35 +0700 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 4:41 PM, C. L. Martinez wrote: >>>> If you HAVE used the default config file created by the template, but >>>> it still doesn't work, you should probably contact the template >>>> creator directly (it's on top of the template file) and ask them how >>>> to use the template. >>>> >>>> -- > > Thanks Fajar, I will try to use centos6 instead of OL6 ... Are these > your instructions?? > > http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum > http://wiki.1tux.org/wiki/Lxc/Installation/Guest/Centos/6 Yes, those are the manual way of creating them. You can also try the centos template from the link I sent earlier, rename it as lxc-centos, chmod 755, and put it on your templates directory (usually /usr/lib/lxc/templates). Tested on Ubuntu host, should work for other hosts as well. -- Fajar From frank at frankscholten.nl Sun Oct 21 15:17:15 2012 From: frank at frankscholten.nl (Frank Scholten) Date: Sun, 21 Oct 2012 17:17:15 +0200 Subject: [Lxc-users] [lxc-attach error] Failed to open /proc/4468/ns/pid. Failed to enter namespace In-Reply-To: <20121016154832.GA12793@sergelap> References: <20121015162507.GA25776@sergelap> <20121016154832.GA12793@sergelap> Message-ID: Laptop (Linux 3.2.0-25-generic x86_64) $ ls /proc/self/ns ipc net uts Desktop (Linux 3.5.0-17-generic x86_64) $ ls /proc/self/ns ipc net uts Do you have links to the kernel sources + patches that I need in for lxc-attach to work? Also, where is the official lxc repo located? Github, sourceforge? Cheers, Frank On Tue, Oct 16, 2012 at 5:48 PM, Serge Hallyn wrote: > Quoting Frank Scholten (frank at frankscholten.nl): >> frank at franktop:~$ uname -a >> Linux franktop 3.2.0-25-generic #40-Ubuntu SMP Wed May 23 20:30:51 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux >> >> I thought setns was added in 3.0? > > Not for pid ns. do 'ls /proc/self/ns' to see the list of namespaces to > which you can setns. > >> I also have the setns man page. How >> do I enable it? Do I have to compile a new kernel? >> >> Cheers, >> >> Frank >> >> On Mon, Oct 15, 2012 at 6:25 PM, Serge Hallyn >> wrote: >> > Quoting Frank Scholten (frank at frankscholten.nl): >> >> Hi all, >> >> >> >> I am trying to run commands inside the container. >> >> >> >> Running lxc 0.7.5.1, commit 60a742e0afd from sourceforge. >> >> >> >> I created and started an Ubuntu container and when I run >> >> >> >> $ sudo lxc-attach -e -n test whoami >> >> >> >> I get >> >> >> >> 'Failed to open /proc/4468/ns/pid. Failed to enter namespace' >> >> >> >> Any idea what could be wrong? >> > >> > Your kernel does not support setns for pid. /proc/$$/ns/pid >> > does not exist. >> > >> > -serge >> > > From lxc at jelmail.com Sun Oct 21 18:56:43 2012 From: lxc at jelmail.com (John) Date: Sun, 21 Oct 2012 19:56:43 +0100 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121019155101.GA10078@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> Message-ID: <5084456B.1020300@jelmail.com> On 19/10/12 16:51, Serge Hallyn wrote: > > Add: > > lxc.network.type = empty > > If you don't have any lxc.network.type sections, then the container > shares network with the host, and so the container talks to the host's > systemd. (same with upstart) > > Thanks for the reply, I will try that tomorrow. I am sorry I wasn't around to check for replies before now. One question though... I actually want a separate network in the container (hence using veth) so it has its own address distinct from the host. Are you saying that I can't do this any more? I've also read the later replies and they seem to be saying that this simply does not work (systemd inside a container). Given its proliferation into other distros (I'm on Arch and that's the reason I am looking at this now), where does systemd come in the priorities of LXC? I really hope we can get this working, as LXC has so far worked very well for me. Thanks, John From serge.hallyn at canonical.com Sun Oct 21 19:49:54 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sun, 21 Oct 2012 14:49:54 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350776519.30263.36.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> Message-ID: <20121021194954.GA5168@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > Serge, > > I'm going to top post here simply because this is going to go off in a > different direction and bringing in an old thread but it is related... > > Back on February 14 you responded to a message about Fedora 16 in a > container, which is something I've been trying to do and I had run into > that posters problems. You responded with this: > > Subject: Re: [Lxc-users] fedora 16 under lxc > > On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote: > > Quoting Ramez Hanna (rhanna at informatiq.org): > > > > now all my efforts have not succeedd to get getty on tty1 to start > > > unmasking udev did something different > > > it created all the /dev devices > > > and made getty start but it started on the hosts's tty not on the container's > > > could someone shed some light here? > > > > Blind guess: > > > > lxc-start creates some ptys and bind mounts them onto the guest's > > /dev/{console,tty{1,2,3,4}}. It sounds like fedora's init is mounting > > over the /dev set up by lxc causing a new /dev/tty to be created as > > chardev 4:{1-4}. Devices namespaces would help this. We're hoping to > > discuss design for those at next UDS, but those will come after user > > namespaces. In the mean time, you'll need to make sure that the guest > > does not mount over /dev, and does not remount /dev/pts. > > > > -serge > > That got me thinking and started into looking deeper into systemd, which > Fedora 16 and above uses and why it may be related here. I've made > Fedora 16 work in the past by installing upstart and disabling systemd > but that really becomes impractical in Fedora 17 because they're > including so few of the compatibility scripts. Yes, you are right, the > Fedora's init (systemd) is mounting something on /dev like this: > > devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=1784160k,nr_inodes=446040,mode=755) > > This is very bad for the reasons you pointed out in Feb. Looking at the > source code for systemd, this is hard coded into the binary and is not > configurable. > > systemd-37/src/mount-setup.c: > -- > /* The first three entries we might need before SELinux is up. The > * other ones we can delay until SELinux is loaded. */ > #define N_EARLY_MOUNT 3 > > static const MountPoint mount_table[] = { > { "proc", "/proc", "proc", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, > { "sysfs", "/sys", "sysfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, > { "devtmpfs", "/dev", "devtmpfs", "mode=755", MS_NOSUID, true }, > { "tmpfs", "/dev/shm", "tmpfs", "mode=1777", MS_NOSUID|MS_NODEV, true }, > { "devpts", "/dev/pts", "devpts", "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false }, > { "tmpfs", "/run", "tmpfs", "mode=755", MS_NOSUID|MS_NODEV, true }, > { "tmpfs", "/sys/fs/cgroup", "tmpfs", "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, > { "cgroup", "/sys/fs/cgroup/systemd", "cgroup", "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, > }; > -- > > Short of building a custom systemd, I don't know how to fix that problem > and I suspect this OP is going to run into this same thing (container > taking over host's console) and might explain some of what he's seeing. > Several of these look like they could cause problems (like /dev/pts in > there). I've really reached an impasse at getting systemd (at least > Fedora 16 and 17) to work in a container without screwing up the host. > Prohibiting mounts entirely in the container might work but I suspect > (having read some systemd error messages) systemd is going to have some > serious heartburn there. > > Thoughts? IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the container should work, i.e. systemd was not going to fail as a result. -serge From serge.hallyn at canonical.com Sun Oct 21 20:00:10 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sun, 21 Oct 2012 15:00:10 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <5084456B.1020300@jelmail.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <5084456B.1020300@jelmail.com> Message-ID: <20121021200010.GA5380@sergelap> Quoting John (lxc at jelmail.com): > On 19/10/12 16:51, Serge Hallyn wrote: > > > > Add: > > > > lxc.network.type = empty > > > > If you don't have any lxc.network.type sections, then the container > > shares network with the host, and so the container talks to the host's > > systemd. (same with upstart) > > > > > Thanks for the reply, I will try that tomorrow. I am sorry I wasn't > around to check for replies before now. One question though... I > actually want a separate network in the container (hence using veth) so > it has its own address distinct from the host. Are you saying that I > can't do this any more? Not at all. But if you're saying you have a 'lxc.network.type = veth' in your container config, then what I said doesn't apply anyway. It sounds like the remount of /dev which Micheal mentioned is in fact your real problem! > I've also read the later replies and they seem to be saying that this > simply does not work (systemd inside a container). Given its > proliferation into other distros (I'm on Arch and that's the reason I am > looking at this now), where does systemd come in the priorities of LXC? Where does LXC come in the priorities of systemd? :) (my point being that it might be far easier to patch systemd to make the filesystems to mount configurable, versus implementing a devices namespace in the kernel so that lxc can work around it) But, lxc is open source, as is the kernel (and systemd) - when you send patches, your priorities influence its priorities. > I really hope we can get this working, as LXC has so far worked very > well for me. -serge From mhw at WittsEnd.com Sun Oct 21 21:25:05 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 21 Oct 2012 17:25:05 -0400 Subject: [Lxc-users] Unable to run systemd in an LXC / cgroup container. Message-ID: <1350854705.5036.77.camel@canyon.wittsend.com> Hello, This is being directed to the systemd-devel community but I'm cc'ing the lxc-users community and the Fedora community on this for their input as well. I know it's not always good to cross post between multiple lists but this is of interest to all three communities who may have valuable input. I'm new to this particular list, just having joined after tracking a problem down to some systemd internals... Several people over the last year or two on the lxc-users list have been discussions trying to run certain distros (notably Fedora 16 and above, recent Arch Linux and possibly others) in LXC containers, virualizing entire servers this way. This is very similar to Virtuoso / OpenVZ only it's using the native Linux cgroups for the containers (primary reason I dumped OpenVZ was to avoid their custom patched kernels). These recent distros have switched to systemd for the main init process and this has proven to be disastrous for those of us using LXC and trying to install or update our containers. To put it bluntly, it doesn't work and causes all sorts of problems on the host. To summarize the problem... The LXC startup binary sets up various things for /dev and /dev/pts for the container to run properly and this works perfectly fine for SystemV start-up scripts and/or Upstart. Unfortunately, systemd has mounts of devtmpfs on /dev and devpts on /dev/pts which then break things horribly. This is because the kernel currently lacks namespaces for devices and won't for some time to come (in design). When devtmpfs gets mounted over top of /dev in the container, it then hijacks the hosts console tty and several other devices which had been set up through bind mounts by LXC and should have been LEFT ALONE. Yes! I recognize that this problem with devtmpfs and lack of namespaces is a potential security problem anyways that could (and does) cause serious container-to-host problems. We're just not going to get that fixed right away in the linux cgroups and namespaces. How do we work around this problem in systemd where it has hard coded mounts in the binary that we can't override or configure? Or is it there and I'm just missing it trying to examine the sources? That's how I found where the problem lay. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sun Oct 21 21:27:50 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 21 Oct 2012 17:27:50 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121021194954.GA5168@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> Message-ID: <1350854870.5036.80.camel@canyon.wittsend.com> On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > Serge, > > > > I'm going to top post here simply because this is going to go off in a > > different direction and bringing in an old thread but it is related... > > > > Back on February 14 you responded to a message about Fedora 16 in a > > container, which is something I've been trying to do and I had run into > > that posters problems. You responded with this: > > > > Subject: Re: [Lxc-users] fedora 16 under lxc > > > > On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote: > > > Quoting Ramez Hanna (rhanna at informatiq.org): > > > > > > now all my efforts have not succeedd to get getty on tty1 to start > > > > unmasking udev did something different > > > > it created all the /dev devices > > > > and made getty start but it started on the hosts's tty not on the container's > > > > could someone shed some light here? > > > > > > Blind guess: > > > > > > lxc-start creates some ptys and bind mounts them onto the guest's > > > /dev/{console,tty{1,2,3,4}}. It sounds like fedora's init is mounting > > > over the /dev set up by lxc causing a new /dev/tty to be created as > > > chardev 4:{1-4}. Devices namespaces would help this. We're hoping to > > > discuss design for those at next UDS, but those will come after user > > > namespaces. In the mean time, you'll need to make sure that the guest > > > does not mount over /dev, and does not remount /dev/pts. > > > > > > -serge > > > > That got me thinking and started into looking deeper into systemd, which > > Fedora 16 and above uses and why it may be related here. I've made > > Fedora 16 work in the past by installing upstart and disabling systemd > > but that really becomes impractical in Fedora 17 because they're > > including so few of the compatibility scripts. Yes, you are right, the > > Fedora's init (systemd) is mounting something on /dev like this: > > > > devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=1784160k,nr_inodes=446040,mode=755) > > > > This is very bad for the reasons you pointed out in Feb. Looking at the > > source code for systemd, this is hard coded into the binary and is not > > configurable. > > > > systemd-37/src/mount-setup.c: > > -- > > /* The first three entries we might need before SELinux is up. The > > * other ones we can delay until SELinux is loaded. */ > > #define N_EARLY_MOUNT 3 > > > > static const MountPoint mount_table[] = { > > { "proc", "/proc", "proc", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, > > { "sysfs", "/sys", "sysfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, > > { "devtmpfs", "/dev", "devtmpfs", "mode=755", MS_NOSUID, true }, > > { "tmpfs", "/dev/shm", "tmpfs", "mode=1777", MS_NOSUID|MS_NODEV, true }, > > { "devpts", "/dev/pts", "devpts", "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false }, > > { "tmpfs", "/run", "tmpfs", "mode=755", MS_NOSUID|MS_NODEV, true }, > > { "tmpfs", "/sys/fs/cgroup", "tmpfs", "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, > > { "cgroup", "/sys/fs/cgroup/systemd", "cgroup", "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, > > }; > > -- > > > > Short of building a custom systemd, I don't know how to fix that problem > > and I suspect this OP is going to run into this same thing (container > > taking over host's console) and might explain some of what he's seeing. > > Several of these look like they could cause problems (like /dev/pts in > > there). I've really reached an impasse at getting systemd (at least > > Fedora 16 and 17) to work in a container without screwing up the host. > > Prohibiting mounts entirely in the container might work but I suspect > > (having read some systemd error messages) systemd is going to have some > > serious heartburn there. > > > > Thoughts? > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > container should work, i.e. systemd was not going to fail as a result. I'm not sure how that would work or if that would work in the case where you didn't have selinux in the host kernel or you were crossing apparmor in the container and selinux in the host or vice-versa. In any case, I'm hitting the systemd-devel list looking to raise their awareness of the problem and including this list and the fedora list. If someone wants to mention it on the Arch Linux list, please do, I don't participate over there. > -serge Thanks Regards, Mike > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 02:06:53 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 21 Oct 2012 22:06:53 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: References: <1350854705.5036.77.camel@canyon.wittsend.com> Message-ID: <1350871613.5036.83.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 02:53 +0200, Kay Sievers wrote: > On Sun, Oct 21, 2012 at 11:25 PM, Michael H. Warfield wrote: > > This is being directed to the systemd-devel community but I'm cc'ing the > > lxc-users community and the Fedora community on this for their input as > > well. I know it's not always good to cross post between multiple lists > > but this is of interest to all three communities who may have valuable > > input. > > > > I'm new to this particular list, just having joined after tracking a > > problem down to some systemd internals... > > > > Several people over the last year or two on the lxc-users list have been > > discussions trying to run certain distros (notably Fedora 16 and above, > > recent Arch Linux and possibly others) in LXC containers, virualizing > > entire servers this way. This is very similar to Virtuoso / OpenVZ only > > it's using the native Linux cgroups for the containers (primary reason I > > dumped OpenVZ was to avoid their custom patched kernels). These recent > > distros have switched to systemd for the main init process and this has > > proven to be disastrous for those of us using LXC and trying to install > > or update our containers. > > > > To put it bluntly, it doesn't work and causes all sorts of problems on > > the host. > > > > To summarize the problem... The LXC startup binary sets up various > > things for /dev and /dev/pts for the container to run properly and this > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > on /dev/pts which then break things horribly. This is because the > > kernel currently lacks namespaces for devices and won't for some time to > > come (in design). When devtmpfs gets mounted over top of /dev in the > > container, it then hijacks the hosts console tty and several other > > devices which had been set up through bind mounts by LXC and should have > > been LEFT ALONE. > > > > Yes! I recognize that this problem with devtmpfs and lack of namespaces > > is a potential security problem anyways that could (and does) cause > > serious container-to-host problems. We're just not going to get that > > fixed right away in the linux cgroups and namespaces. > > > > How do we work around this problem in systemd where it has hard coded > > mounts in the binary that we can't override or configure? Or is it > > there and I'm just missing it trying to examine the sources? That's how > > I found where the problem lay. > As a first step, this probably explains most of it: > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface A very long ways, yeah. That looks like it could be just what we've been looking for. Just gotta figure out how to set that environment variable but that's up to a couple of others to comment on in the lxc-users list. Then we'll see where we go from there. Many thanks! > Kay Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 02:21:01 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 21 Oct 2012 22:21:01 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121021194954.GA5168@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> Message-ID: <1350872461.5036.88.camel@canyon.wittsend.com> On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > Serge, > > ... > > Short of building a custom systemd, I don't know how to fix that problem > > and I suspect this OP is going to run into this same thing (container > > taking over host's console) and might explain some of what he's seeing. > > Several of these look like they could cause problems (like /dev/pts in > > there). I've really reached an impasse at getting systemd (at least > > Fedora 16 and 17) to work in a container without screwing up the host. > > Prohibiting mounts entirely in the container might work but I suspect > > (having read some systemd error messages) systemd is going to have some > > serious heartburn there. > > > > Thoughts? > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > container should work, i.e. systemd was not going to fail as a result. Hopefully, you've seen the message from Kay Sievers cc'ed to this list from my post to the systemd-devel list. Looks like they have a mechanism in place to do this... http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface First step appears to be to set a container=LXC (or some other short string) before invoking init in the container. Is there a mechanism to do this? Might look over the rest of their recommendation and see if there's anything else we need to do. Looks like there might be some additional mounts (some read-only) in there that need to be handled in lxc-start as well. > -serge > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 03:29:46 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 21 Oct 2012 23:29:46 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350872461.5036.88.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> Message-ID: <1350876586.5036.92.camel@canyon.wittsend.com> Serge, On Sun, 2012-10-21 at 22:21 -0400, Michael H. Warfield wrote: > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > Serge, > > > > > ... > > > > Short of building a custom systemd, I don't know how to fix that problem > > > and I suspect this OP is going to run into this same thing (container > > > taking over host's console) and might explain some of what he's seeing. > > > Several of these look like they could cause problems (like /dev/pts in > > > there). I've really reached an impasse at getting systemd (at least > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > Prohibiting mounts entirely in the container might work but I suspect > > > (having read some systemd error messages) systemd is going to have some > > > serious heartburn there. > > > > > > Thoughts? > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > container should work, i.e. systemd was not going to fail as a result. > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > from my post to the systemd-devel list. Looks like they have a > mechanism in place to do this... > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > First step appears to be to set a container=LXC (or some other short > string) before invoking init in the container. Is there a mechanism to > do this? > Might look over the rest of their recommendation and see if there's > anything else we need to do. Looks like there might be some additional > mounts (some read-only) in there that need to be handled in lxc-start as > well. Tried simply exporting the container=LXC variable, the HOSTNAME and a couple of others in there. Confirmed in upstart mode that the variables did propagate but in systemd mode it just hung with 0 processes and left an unremovable "busy" cgroup directory when I tried to "lxc-stop" it. BUT... Something obviously behaved differently. It didn't try to grab the console and commit other heinous on the system like it did before with systemd. Maybe need to look closer at those mount requirements. > > -serge > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > > Lxc-users mailing list > > Lxc-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-users > > Regards, > Mike > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ Lxc-users mailing list Lxc-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From zheng_huabin at 163.com Mon Oct 22 08:04:16 2012 From: zheng_huabin at 163.com (Binknight) Date: Mon, 22 Oct 2012 16:04:16 +0800 (CST) Subject: [Lxc-users] limit network bandwidth with tc Message-ID: <46011e5e.14c88.13a87803132.Coremail.zheng_huabin@163.com> It seems that there are two way to limit the network usage of containers. One is with net_cls and the other one is net_prio?The first one can be used with "tc" to limit bandwidth while the second one manipulate the priority of package sent from container. I've tried net_cls with tc by set # net classid 1:10 lxc.cgroup.net_cls.classid = 0x10010 in lxc config file and run tc.sh to setup tc queue discipline # cat tc.sh tc qdisc add dev virbr0 root handle 1: htb tc class add dev virbr0 parent 1: classid 1:10 htb rate 1kbit ceil 2kbit Note: The container use virbr0 created by libvirt as net interface, iptable is configured to make it possible to access server running inside the container from outside. But in my test, network is not limited at all. What's wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxc at jelmail.com Mon Oct 22 08:06:41 2012 From: lxc at jelmail.com (John) Date: Mon, 22 Oct 2012 09:06:41 +0100 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1350871613.5036.83.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <1350871613.5036.83.camel@canyon.wittsend.com> Message-ID: <5084FE91.4070105@jelmail.com> On 22/10/12 03:06, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 02:53 +0200, Kay Sievers wrote: >> On Sun, Oct 21, 2012 at 11:25 PM, Michael H. Warfield wrote: >>> This is being directed to the systemd-devel community but I'm cc'ing the >>> lxc-users community and the Fedora community on this for their input as >>> well. I know it's not always good to cross post between multiple lists >>> but this is of interest to all three communities who may have valuable >>> input. >>> >>> I'm new to this particular list, just having joined after tracking a >>> problem down to some systemd internals... >>> >>> Several people over the last year or two on the lxc-users list have been >>> discussions trying to run certain distros (notably Fedora 16 and above, >>> recent Arch Linux and possibly others) in LXC containers, virualizing >>> entire servers this way. This is very similar to Virtuoso / OpenVZ only >>> it's using the native Linux cgroups for the containers (primary reason I >>> dumped OpenVZ was to avoid their custom patched kernels). These recent >>> distros have switched to systemd for the main init process and this has >>> proven to be disastrous for those of us using LXC and trying to install >>> or update our containers. >>> >>> To put it bluntly, it doesn't work and causes all sorts of problems on >>> the host. >>> >>> To summarize the problem... The LXC startup binary sets up various >>> things for /dev and /dev/pts for the container to run properly and this >>> works perfectly fine for SystemV start-up scripts and/or Upstart. >>> Unfortunately, systemd has mounts of devtmpfs on /dev and devpts >>> on /dev/pts which then break things horribly. This is because the >>> kernel currently lacks namespaces for devices and won't for some time to >>> come (in design). When devtmpfs gets mounted over top of /dev in the >>> container, it then hijacks the hosts console tty and several other >>> devices which had been set up through bind mounts by LXC and should have >>> been LEFT ALONE. >>> >>> Yes! I recognize that this problem with devtmpfs and lack of namespaces >>> is a potential security problem anyways that could (and does) cause >>> serious container-to-host problems. We're just not going to get that >>> fixed right away in the linux cgroups and namespaces. >>> >>> How do we work around this problem in systemd where it has hard coded >>> mounts in the binary that we can't override or configure? Or is it >>> there and I'm just missing it trying to examine the sources? That's how >>> I found where the problem lay. >> As a first step, this probably explains most of it: >> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > A very long ways, yeah. That looks like it could be just what we've > been looking for. Just gotta figure out how to set that environment > variable but that's up to a couple of others to comment on in the > lxc-users list. Then we'll see where we go from there. > > Many thanks! > >> Kay > Regards, > Mike > I've just performed a very quick check on my Arch Linux system here. on host (running systemd): # cat /proc/1/environ TERM=linuxRD_TIMESTAMP= In a container (running sysvinit): # cat /proc/1/environ STY=623.systemd-lithiumTERM=screenTERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\ :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\ :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\ :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\ :li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\ :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\ :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\ :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\ :ti=\E[?1049h:te=\E[?1049l:k0=\E[10~:k1=\EOP:k2=\EOQ:\ :k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\ :k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\ :kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\ :kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:WINDOW=0SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binLANG=en_GB.UTF-8container=lxc So it looks like that "container" environment variable is already set on PID1 Regards, John From swairshah at gmail.com Mon Oct 22 10:11:49 2012 From: swairshah at gmail.com (swair shah) Date: Mon, 22 Oct 2012 15:41:49 +0530 Subject: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address ) Message-ID: I have a container running centos 6, on a host system also running centos 6. I have allocated a different subnet for containers and I'm able to ping the container. Now when I try to ssh into the container from another console, it prompts me for password. This is the log on the host system. Oct 22 14:00:25 localhost sshd[264]: Accepted password for root from 192.168.0.2 port 38355 ssh2 Oct 22 14:00:25 localhost sshd[264]: pam_unix(sshd:session): session opened for user root by (uid=0) Oct 22 14:00:25 localhost sshd[266]: error: ioctl(TIOCSCTTY): Operation not permitted Oct 22 14:00:25 localhost sshd[266]: error: open /dev/tty failed - could not set controlling tty: No such device or address I should also mention that my host machine is a remote one and I have ssh'd into that. Do I need to make any specific changes to the tty conf in the container? How do I go about debugging this issue? thanks, swair -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Mon Oct 22 10:19:42 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Mon, 22 Oct 2012 17:19:42 +0700 Subject: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address ) In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 5:11 PM, swair shah wrote: > I have a container running centos 6, on a host system also running centos 6. > I have allocated a different subnet for containers and I'm able to ping the > container. > > Now when I try to ssh into the container from another console, it prompts me > for password. This is the log on the host system. > > Oct 22 14:00:25 localhost sshd[264]: Accepted password for root from > 192.168.0.2 port 38355 ssh2 > Oct 22 14:00:25 localhost sshd[264]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Oct 22 14:00:25 localhost sshd[266]: error: ioctl(TIOCSCTTY): Operation not > permitted > Oct 22 14:00:25 localhost sshd[266]: error: open /dev/tty failed - could not > set controlling tty: No such device or address That's odd. My centos container has no /dev/tty and it works just fine. My host has one though. > > I should also mention that my host machine is a remote one and I have ssh'd > into that. It shouldn't matter. > > Do I need to make any specific changes to the tty conf in the container? Do you have /dev/pts directory inside the container? What files are in there? Do you have /dev/tty inside the host? -- Fajar From swairshah at gmail.com Mon Oct 22 10:26:55 2012 From: swairshah at gmail.com (swair shah) Date: Mon, 22 Oct 2012 15:56:55 +0530 Subject: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address ) In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 3:49 PM, Fajar A. Nugraha wrote: > On Mon, Oct 22, 2012 at 5:11 PM, swair shah wrote: > > I have a container running centos 6, on a host system also running > centos 6. > > I have allocated a different subnet for containers and I'm able to ping > the > > container. > > > > Now when I try to ssh into the container from another console, it > prompts me > > for password. This is the log on the host system. > > > > Oct 22 14:00:25 localhost sshd[264]: Accepted password for root from > > 192.168.0.2 port 38355 ssh2 > > Oct 22 14:00:25 localhost sshd[264]: pam_unix(sshd:session): session > opened > > for user root by (uid=0) > > Oct 22 14:00:25 localhost sshd[266]: error: ioctl(TIOCSCTTY): Operation > not > > permitted > > Oct 22 14:00:25 localhost sshd[266]: error: open /dev/tty failed - could > not > > set controlling tty: No such device or address > > That's odd. My centos container has no /dev/tty and it works just > fine. My host has one though. > > > > > I should also mention that my host machine is a remote one and I have > ssh'd > > into that. > > It shouldn't matter. > > > > Do I need to make any specific changes to the tty conf in the container? > > Do you have /dev/pts directory inside the container? What files are in > there? > /dev/pts has crw--w---- 1 root tty 136, 0 Oct 22 15:54 0 crw--w---- 1 swair tty 136, 7 Oct 22 15:52 7 c--------- 1 root root 5, 2 Oct 22 15:25 ptmx > Do you have /dev/tty inside the host? > Host has /dev/tty. swair. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swairshah at gmail.com Mon Oct 22 10:34:09 2012 From: swairshah at gmail.com (swair shah) Date: Mon, 22 Oct 2012 16:04:09 +0530 Subject: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address ) In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 3:56 PM, swair shah wrote: > > > On Mon, Oct 22, 2012 at 3:49 PM, Fajar A. Nugraha wrote: > >> On Mon, Oct 22, 2012 at 5:11 PM, swair shah wrote: >> > I have a container running centos 6, on a host system also running >> centos 6. >> > I have allocated a different subnet for containers and I'm able to ping >> the >> > container. >> > >> > Now when I try to ssh into the container from another console, it >> prompts me >> > for password. This is the log on the host system. >> > >> > Oct 22 14:00:25 localhost sshd[264]: Accepted password for root from >> > 192.168.0.2 port 38355 ssh2 >> > Oct 22 14:00:25 localhost sshd[264]: pam_unix(sshd:session): session >> opened >> > for user root by (uid=0) >> > Oct 22 14:00:25 localhost sshd[266]: error: ioctl(TIOCSCTTY): Operation >> not >> > permitted >> > Oct 22 14:00:25 localhost sshd[266]: error: open /dev/tty failed - >> could not >> > set controlling tty: No such device or address >> >> That's odd. My centos container has no /dev/tty and it works just >> fine. My host has one though. >> >> > >> > I should also mention that my host machine is a remote one and I have >> ssh'd >> > into that. >> >> It shouldn't matter. > > >> > >> > Do I need to make any specific changes to the tty conf in the container? >> >> Do you have /dev/pts directory inside the container? What files are in >> there? >> > > /dev/pts has > > crw--w---- 1 root tty 136, 0 Oct 22 15:54 0 > crw--w---- 1 swair tty 136, 7 Oct 22 15:52 7 > c--------- 1 root root 5, 2 Oct 22 15:25 ptmx > > >> Do you have /dev/tty inside the host? >> > > Host has /dev/tty. > > > swair. > Oh sorry. /dev/pts contains these crw--w---- 1 500 tty 136, 0 Oct 22 14:30 0 crw--w---- 1 500 tty 136, 1 Oct 22 14:32 1 crw--w---- 1 root tty 136, 10 Oct 22 14:32 10 crw--w---- 1 root tty 136, 11 Oct 22 14:32 11 crw-rw-rw- 1 root tty 136, 12 Oct 22 14:32 12 crw--w---- 1 root tty 136, 2 Oct 22 14:30 2 crw--w---- 1 root tty 136, 3 Oct 22 14:30 3 crw--w---- 1 root tty 136, 4 Oct 22 14:30 4 crw--w---- 1 root tty 136, 5 Oct 22 14:30 5 crw--w---- 1 root tty 136, 6 Oct 22 14:33 6 crw--w---- 1 500 tty 136, 7 Oct 22 14:31 7 crw--w---- 1 root tty 136, 8 Oct 22 14:32 8 crw--w---- 1 root tty 136, 9 Oct 22 14:32 9 c--------- 1 root root 5, 2 Oct 22 14:29 ptmx swair -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Mon Oct 22 10:36:37 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Mon, 22 Oct 2012 17:36:37 +0700 Subject: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address ) In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 5:26 PM, swair shah wrote: >> > Do I need to make any specific changes to the tty conf in the container? >> >> Do you have /dev/pts directory inside the container? What files are in >> there? > > > /dev/pts has > > crw--w---- 1 root tty 136, 0 Oct 22 15:54 0 > crw--w---- 1 swair tty 136, 7 Oct 22 15:52 7 > c--------- 1 root root 5, 2 Oct 22 15:25 ptmx > >> >> Do you have /dev/tty inside the host? > > > Host has /dev/tty. > Try http://osdir.com/ml/lxc-chroot-linux-containers/2012-03/msg00050.html -- Fajar From swairshah at gmail.com Mon Oct 22 12:39:29 2012 From: swairshah at gmail.com (swair shah) Date: Mon, 22 Oct 2012 18:09:29 +0530 Subject: [Lxc-users] Using lxc on production Message-ID: I've been trying out lxc for a week now, and it seems there are a lot of issues if the host system is centos and things work fine while using ubuntu as the host. any way, right now I don't think lxc seems to be fit to run on production boxes. I was wondering if anyone is using lxc on production. and if you don't mind disclosing, for what purpose do you use it on production? cheers, swair -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Mon Oct 22 12:51:20 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 22 Oct 2012 14:51:20 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: <50854148.2000202@martos.bme.hu> On 10/22/2012 02:39 PM, swair shah wrote: > I've been trying out lxc for a week now, and it seems there are a lot > of issues if the host system is centos and things work fine while > using ubuntu as the host. any way, right now I don't think lxc seems > to be fit to run on production boxes. > > I was wondering if anyone is using lxc on production. and if you don't > mind disclosing, for what purpose do you use it on production? We use it typically as web- and mail szervers, samba..etc. It works fine in most cases. tamas From stgraber at ubuntu.com Mon Oct 22 12:53:49 2012 From: stgraber at ubuntu.com (=?ISO-8859-1?Q?St=E9phane_Graber?=) Date: Mon, 22 Oct 2012 14:53:49 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: <508541DD.10607@ubuntu.com> On 10/22/2012 02:39 PM, swair shah wrote: > I've been trying out lxc for a week now, and it seems there are a lot of > issues if the host system is centos and things work fine while using > ubuntu as the host. any way, right now I don't think lxc seems to be fit > to run on production boxes. > > I was wondering if anyone is using lxc on production. and if you don't > mind disclosing, for what purpose do you use it on production? > > cheers, > swair I use LXC in production for all my server services (web hosting, dns servers, internal dhcp, directory services, ...) and for the Edubuntu WebLive VDI service (hundred of desktop installations running under LXC). All in all, that's somewhere around 300-400 containers I'm managing in production, without any problem so far. This is all running on Ubuntu 12.04 LTS with apparmor on both host and containers. Using apparmor fixes all the security concerns that have been highlighted so far with containers and Ubuntu ships the latest upstream LXC and has a container-aware userspace that doesn't require any kind of hack to work in containers. You mention you're using Centos, I'd suggest that's really your problem as nobody is working on LXC on Centos so the distribution probably wasn't made container aware, we don't actually have a maintained template for it and it's likely that some other bits of LXC plain don't work because nobody tested it on centos. We recently got some contributions for LXC support on Oracle Linux which as far as I know is pretty close to RHEL6/CentOS, so maybe that work will lead to a better experience on CentOS, but that may take some time. -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From dwight.engen at oracle.com Mon Oct 22 12:33:27 2012 From: dwight.engen at oracle.com (Dwight Engen) Date: Mon, 22 Oct 2012 08:33:27 -0400 Subject: [Lxc-users] Problems starting OL6.3 lxc container In-Reply-To: References: Message-ID: <20121022083327.6e8b089e@delphi.home> On Sun, 21 Oct 2012 16:27:01 +0700 "Fajar A. Nugraha" wrote: > On Sun, Oct 21, 2012 at 4:23 PM, C. L. Martinez > wrote: > > On Sun, Oct 21, 2012 at 9:20 AM, Fajar A. Nugraha > > wrote: > >>>> -- > >>> > >>> No, problem continues ... I have used this template to create my > >>> lxc container: > >> > >> In that I says use the unmodified config file first. For example, > >> it says "lxc.devttydir = lxc" (which you commented out). > >> > >> If you HAVE used the default config file created by the template, > >> but it still doesn't work, you should probably contact the template > >> creator directly (it's on top of the template file) and ask them > >> how to use the template. > >> > >> -- > >> Fajar > > > > Yes, I have commented out because when I launch lxc-start, returns > > me this error: > > > > lxc-start 1350810587.498 ERROR lxc_confile - unknow key > > lxc.devttydir lxc-start 1350810587.498 ERROR lxc_start_ui - > > failed to read configuration file > > Looks like an old version problem. Did you know that the staging git > repo on github is newer than released lxc version? I wouldn't be > surprised if you need to recompile lxc -- using sources from that repo > --- to get the template to work. Exactly. You are trying to use the template from git staging lxc which supports devttydir with older lxc-0.7.5 from OL6.3. If you want to use the oracle template, I would also recommend just building from the staging git repo: (git clone git://github.com/lxc/lxc; ./autogen; ./configure; make rpm). From mhw at WittsEnd.com Mon Oct 22 13:04:34 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 09:04:34 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <5084FE91.4070105@jelmail.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <1350871613.5036.83.camel@canyon.wittsend.com> <5084FE91.4070105@jelmail.com> Message-ID: <1350911074.5036.102.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 09:06 +0100, John wrote: > On 22/10/12 03:06, Michael H. Warfield wrote: > > On Mon, 2012-10-22 at 02:53 +0200, Kay Sievers wrote: > >> On Sun, Oct 21, 2012 at 11:25 PM, Michael H. Warfield wrote: > >>> This is being directed to the systemd-devel community but I'm cc'ing the > >>> lxc-users community and the Fedora community on this for their input as > >>> well. I know it's not always good to cross post between multiple lists > >>> but this is of interest to all three communities who may have valuable > >>> input. > >>> > >>> I'm new to this particular list, just having joined after tracking a > >>> problem down to some systemd internals... > >>> > >>> Several people over the last year or two on the lxc-users list have been > >>> discussions trying to run certain distros (notably Fedora 16 and above, > >>> recent Arch Linux and possibly others) in LXC containers, virualizing > >>> entire servers this way. This is very similar to Virtuoso / OpenVZ only > >>> it's using the native Linux cgroups for the containers (primary reason I > >>> dumped OpenVZ was to avoid their custom patched kernels). These recent > >>> distros have switched to systemd for the main init process and this has > >>> proven to be disastrous for those of us using LXC and trying to install > >>> or update our containers. > >>> > >>> To put it bluntly, it doesn't work and causes all sorts of problems on > >>> the host. > >>> > >>> To summarize the problem... The LXC startup binary sets up various > >>> things for /dev and /dev/pts for the container to run properly and this > >>> works perfectly fine for SystemV start-up scripts and/or Upstart. > >>> Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > >>> on /dev/pts which then break things horribly. This is because the > >>> kernel currently lacks namespaces for devices and won't for some time to > >>> come (in design). When devtmpfs gets mounted over top of /dev in the > >>> container, it then hijacks the hosts console tty and several other > >>> devices which had been set up through bind mounts by LXC and should have > >>> been LEFT ALONE. > >>> > >>> Yes! I recognize that this problem with devtmpfs and lack of namespaces > >>> is a potential security problem anyways that could (and does) cause > >>> serious container-to-host problems. We're just not going to get that > >>> fixed right away in the linux cgroups and namespaces. > >>> > >>> How do we work around this problem in systemd where it has hard coded > >>> mounts in the binary that we can't override or configure? Or is it > >>> there and I'm just missing it trying to examine the sources? That's how > >>> I found where the problem lay. > >> As a first step, this probably explains most of it: > >> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > A very long ways, yeah. That looks like it could be just what we've > > been looking for. Just gotta figure out how to set that environment > > variable but that's up to a couple of others to comment on in the > > lxc-users list. Then we'll see where we go from there. > > > > Many thanks! > > > >> Kay > > Regards, > > Mike > > > > I've just performed a very quick check on my Arch Linux system here. > > on host (running systemd): > # cat /proc/1/environ > TERM=linuxRD_TIMESTAMP= > > In a container (running sysvinit): > # cat /proc/1/environ > STY=623.systemd-lithiumTERM=screenTERMCAP=SC|screen|VT 100/ANSI X3.64 > virtual terminal:\ > :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\ > :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\ > :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\ > :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\ > :li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\ > :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\ > :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\ > :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\ > :ti=\E[?1049h:te=\E[?1049l:k0=\E[10~:k1=\EOP:k2=\EOQ:\ > :k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\ > :k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\ > :kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\ > :kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:WINDOW=0SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binLANG=en_GB.UTF-8container=lxc > So it looks like that "container" environment variable is already set on > PID1 Yeah, I saw that myself last night. Testing that out and it's still not working here (although it doesn't seem to be grabbing the host console now) if I use systemd but upstart fires right up and I see that container variable set. Looked like a number of mounts listed on that wiki page. Maybe something is missing. Right now it's just hanging trying to start the container and, when I subsequently try to shut the container down it results in a hung resource and it can't delete the cgroups directory because it's busy. Only thing I did was change the link to /sbin/init from upstart to systemd and it's now dead and I'll have to reboot the host to free the resource. :-P > Regards, > John Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Mon Oct 22 13:09:49 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 22 Oct 2012 08:09:49 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350872461.5036.88.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> Message-ID: <20121022130949.GA5466@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > Serge, > > > > > ... > > > > Short of building a custom systemd, I don't know how to fix that problem > > > and I suspect this OP is going to run into this same thing (container > > > taking over host's console) and might explain some of what he's seeing. > > > Several of these look like they could cause problems (like /dev/pts in > > > there). I've really reached an impasse at getting systemd (at least > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > Prohibiting mounts entirely in the container might work but I suspect > > > (having read some systemd error messages) systemd is going to have some > > > serious heartburn there. > > > > > > Thoughts? > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > container should work, i.e. systemd was not going to fail as a result. > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > from my post to the systemd-devel list. Looks like they have a > mechanism in place to do this... > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface Saw the email, haven't yet read the page, thanks. > First step appears to be to set a container=LXC (or some other short > string) before invoking init in the container. Is there a mechanism to > do this? We've been setting 'container=lxc' since before system existed :) It's hardcoded in lxc_start.c using putenv.c. I don't think we want to make it runtime configurable, but a build-time (configure) flag would be fine. > Might look over the rest of their recommendation and see if there's > anything else we need to do. Looks like there might be some additional > mounts (some read-only) in there that need to be handled in lxc-start as > well. Thanks, Michael! -serge From mhw at WittsEnd.com Mon Oct 22 13:18:33 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 09:18:33 -0400 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: <1350911913.5036.113.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 18:09 +0530, swair shah wrote: > I've been trying out lxc for a week now, and it seems there are a lot of > issues if the host system is centos and things work fine while using ubuntu > as the host. any way, right now I don't think lxc seems to be fit to run on > production boxes. > I was wondering if anyone is using lxc on production. and if you don't mind > disclosing, for what purpose do you use it on production? I'm using it on Fedora hosts just fine and I've got some deployed on CentOS as well with no problem. Before anyone says anything about Fedora - the reason is that I can generally yum upgrade from one release to the next but going through the upgrade from RHEL/CentOS from say 4 to 5 to 6 is a painful experience. I totally abandoned Ubuntu when they went to Unity and the changes they made make it almost impossible to setup freenx servers on those machines. Seems the packages are their but certain dependencies can not be resolved and reports I've read indicated, even AFTER you manually recompile some audio libraries and crap that Ubuntu dropped the ball on, it still is unreliable as all get out. I rely too much on NX for remote desktops with 5 remote locations even when I'm home (and six when I'm on the road). I can't have that. I gave up after a couple of days of trying and ripped Ubuntu off all my systems and replaced it with Fedora. To each his own... I have one host (Fedora 15) which has approximately 3 dozen VM's running on it doing a variety of things like web, mail, mailing lists, databases, remote desktops, DNS (authoritative and caching), Nagios etc, etc. My biggest headache is when a buddy of mine runs one of his database intensive scripts it runs the load average of the host up to over 10 for a couple of minutes but I'll beat on him later. I'd love to hear what issues you had on CentOS. Obviously, if you are running LXC, it must have been CentOS 6. What rev level and kernel? > cheers, > swair Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From michael.bonfils at pace.com Mon Oct 22 13:54:43 2012 From: michael.bonfils at pace.com (Michael Bonfils) Date: Mon, 22 Oct 2012 15:54:43 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: <50855023.7000905@pace.com> Hi, At work, I use LXC to build our software with fixed environment : we have checked it with ten builds at once. Debian Squeeze is used as container and host. Regards, Michael On 10/22/2012 02:39 PM, swair shah wrote: > I've been trying out lxc for a week now, and it seems there are a lot > of issues if the host system is centos and things work fine while > using ubuntu as the host. any way, right now I don't think lxc seems > to be fit to run on production boxes. > > I was wondering if anyone is using lxc on production. and if you don't > mind disclosing, for what purpose do you use it on production? > > cheers, > swair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.hallyn at canonical.com Mon Oct 22 14:12:16 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 22 Oct 2012 09:12:16 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022130949.GA5466@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> Message-ID: <20121022141216.GA6916@sergelap> Quoting Serge Hallyn (serge.hallyn at canonical.com): > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > Serge, > > > > > > > > ... > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > and I suspect this OP is going to run into this same thing (container > > > > taking over host's console) and might explain some of what he's seeing. > > > > Several of these look like they could cause problems (like /dev/pts in > > > > there). I've really reached an impasse at getting systemd (at least > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > (having read some systemd error messages) systemd is going to have some > > > > serious heartburn there. > > > > > > > > Thoughts? > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > container should work, i.e. systemd was not going to fail as a result. > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > from my post to the systemd-devel list. Looks like they have a > > mechanism in place to do this... > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > Saw the email, haven't yet read the page, thanks. So based on that page, what we do (set 'container=lxc') should already be sufficient. -serge From mhw at WittsEnd.com Mon Oct 22 14:37:46 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 10:37:46 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022141216.GA6916@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> Message-ID: <1350916666.5036.119.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > Serge, > > > > > > > > > > > ... > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > and I suspect this OP is going to run into this same thing (container > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > (having read some systemd error messages) systemd is going to have some > > > > > serious heartburn there. > > > > > > > > > > Thoughts? > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > from my post to the systemd-devel list. Looks like they have a > > > mechanism in place to do this... > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > Saw the email, haven't yet read the page, thanks. > So based on that page, what we do (set 'container=lxc') should already be > sufficient. For that step yes. I'm hearing that they also need tmpfs mounted on /dev, for some reason, and then bind mounting appropriate ttys and creating devices. It's mentioned on that page and mentioned in another reply. I'm going down the list of mounts that are detailed out now. Several of those steps (UUID and HOSTNAME) seem optional. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From swairshah at gmail.com Mon Oct 22 14:52:27 2012 From: swairshah at gmail.com (swair shah) Date: Mon, 22 Oct 2012 20:22:27 +0530 Subject: [Lxc-users] Using lxc on production In-Reply-To: <1350911913.5036.113.camel@canyon.wittsend.com> References: <1350911913.5036.113.camel@canyon.wittsend.com> Message-ID: On Mon, Oct 22, 2012 at 6:48 PM, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 18:09 +0530, swair shah wrote: > > I've been trying out lxc for a week now, and it seems there are a lot of > > issues if the host system is centos and things work fine while using > ubuntu > > as the host. any way, right now I don't think lxc seems to be fit to run > on > > production boxes. > > > I was wondering if anyone is using lxc on production. and if you don't > mind > > disclosing, for what purpose do you use it on production? > > I'm using it on Fedora hosts just fine and I've got some deployed on > CentOS as well with no problem. Before anyone says anything about > Fedora - the reason is that I can generally yum upgrade from one release > to the next but going through the upgrade from RHEL/CentOS from say 4 to > 5 to 6 is a painful experience. > > I totally abandoned Ubuntu when they went to Unity and the changes they > made make it almost impossible to setup freenx servers on those > machines. Seems the packages are their but certain dependencies can not > be resolved and reports I've read indicated, even AFTER you manually > recompile some audio libraries and crap that Ubuntu dropped the ball on, > it still is unreliable as all get out. I rely too much on NX for remote > desktops with 5 remote locations even when I'm home (and six when I'm on > the road). I can't have that. I gave up after a couple of days of > trying and ripped Ubuntu off all my systems and replaced it with Fedora. > To each his own... > > I have one host (Fedora 15) which has approximately 3 dozen VM's running > on it doing a variety of things like web, mail, mailing lists, > databases, remote desktops, DNS (authoritative and caching), Nagios etc, > etc. My biggest headache is when a buddy of mine runs one of his > database intensive scripts it runs the load average of the host up to > over 10 for a couple of minutes but I'll beat on him later. > > I'd love to hear what issues you had on CentOS. Obviously, if you are > running LXC, it must have been CentOS 6. What rev level and kernel? > > I'm using lxc version 0.7.5 and kernel version 2.6.32. This is the script I'm using. The recent issue is that once I start a container, and try to do an ssh from outside it doesn't show anything on the terminal. Though a ps aux says that a pts/1 has been allocated to an ssh login. It used to fail before and would give an error saying error: ioctl(TIOCSCTTY): Operation not permitted error: open /dev/tty failed - could not set controlling tty: No such device Which seems to be fixed by removing the mount of devpts from fstab and/or doing #mount -o remount,rw /dev/pts One more problem is that I have to reboot the host everytime after I shutdown any container to make everything work like before. After the remount of /dev/pts that seems to have been fixed. But the ssh thing is still a big issue. I'm thinking something is wrong with the mount of /dev. Can you share your script? or conf file? thanks! swair > > cheers, > > swair > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | > http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of > all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drescherjm at gmail.com Mon Oct 22 14:59:56 2012 From: drescherjm at gmail.com (John Drescher) Date: Mon, 22 Oct 2012 10:59:56 -0400 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: > I was wondering if anyone is using lxc on production. and if you don't mind > disclosing, for what purpose do you use it on production? At work I have used lxc for production servers for 2 to 3 years. I believe I have a dozen or so production lxc guests running on 64 bit gentoo linux. At the moment most are using a 3.4 or 3.5 kernel however I believe I used 2.6.35 kernels when I started converting from OpenVZ to lxc. John From kojiel at gmail.com Mon Oct 22 19:07:33 2012 From: kojiel at gmail.com (Koji Takiguchi) Date: Tue, 23 Oct 2012 04:07:33 +0900 Subject: [Lxc-users] error message with dual bridge setting Message-ID: Hello, I'm trying dual bridge network setting(br0 and br1) for route redundancy(like 192.168.100.1/24 and 192.168.200.1/24). Host and Guest OS is CentOS6.3(2.6.32-279.11.1.el6) and Host is running on VMware Player. Lxc version is 0.8.0-rc2. Container is running successfully and some checking is seeing ok(ssh remote login, isolated devpts, etc). But I get two error messages. 1.When reboot/shutdown in container, I get following log in Host's /var/log/messages. ------------------------------------------------------------------ Oct 23 01:09:26 localhost kernel: br0: port 2(vethD7p1uW) entering disabled state Oct 23 01:09:26 localhost kernel: br0: port 2(vethD7p1uW) entering disabled state Oct 23 01:09:26 localhost kernel: ------------[ cut here ]------------ Oct 23 01:09:26 localhost kernel: WARNING: at kernel/sysctl.c:2372 unregister_sysctl_table+0xb1/0x120() (Not tainted) Oct 23 01:09:26 localhost kernel: Hardware name: VMware Virtual Platform Oct 23 01:09:26 localhost kernel: Modules linked in: veth bridge stp llc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ppdev parport_pc parport snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000 vmware_balloon i2c_piix4 i2c_core sg shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom mptspi mptscsih mptbase scsi_transport_spi pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Oct 23 01:09:26 localhost kernel: Pid: 10, comm: netns Not tainted 2.6.32-279.11.1.el6.x86_64 #1 Oct 23 01:09:26 localhost kernel: Call Trace: Oct 23 01:09:26 localhost kernel: [] ? warn_slowpath_common+0x87/0xc0 Oct 23 01:09:26 localhost kernel: [] ? warn_slowpath_null+0x1a/0x20 Oct 23 01:09:26 localhost kernel: [] ? unregister_sysctl_table+0xb1/0x120 Oct 23 01:09:26 localhost kernel: [] ? __ipv6_dev_mc_dec+0xcb/0x120 [ipv6] Oct 23 01:09:26 localhost kernel: [] ? neigh_sysctl_unregister+0x27/0x50 Oct 23 01:09:26 localhost kernel: [] ? addrconf_ifdown+0x29a/0x3d0 [ipv6] Oct 23 01:09:26 localhost kernel: [] ? addrconf_notify+0xdd/0x970 [ipv6] Oct 23 01:09:26 localhost kernel: [] ? call_rcu_sched+0x15/0x20 Oct 23 01:09:26 localhost kernel: [] ? call_rcu+0xe/0x10 Oct 23 01:09:26 localhost kernel: [] ? notifier_call_chain+0x55/0x80 Oct 23 01:09:26 localhost kernel: [] ? raw_notifier_call_chain+0x16/0x20 Oct 23 01:09:26 localhost kernel: [] ? call_netdevice_notifiers+0x1b/0x20 Oct 23 01:09:26 localhost kernel: [] ? rollback_registered+0x77/0x130 Oct 23 01:09:26 localhost kernel: [] ? unregister_netdevice+0x22/0x70 Oct 23 01:09:26 localhost kernel: [] ? veth_dellink+0x1a/0x30 [veth] Oct 23 01:09:26 localhost kernel: [] ? default_device_exit+0x9a/0x100 Oct 23 01:09:26 localhost kernel: [] ? cleanup_net+0x0/0xa0 Oct 23 01:09:26 localhost kernel: [] ? cleanup_net+0x6e/0xa0 Oct 23 01:09:26 localhost kernel: [] ? worker_thread+0x170/0x2a0 Oct 23 01:09:26 localhost kernel: [] ? autoremove_wake_function+0x0/0x40 Oct 23 01:09:26 localhost kernel: [] ? worker_thread+0x0/0x2a0 Oct 23 01:09:26 localhost kernel: [] ? kthread+0x96/0xa0 Oct 23 01:09:26 localhost kernel: [] ? child_rip+0xa/0x20 Oct 23 01:09:26 localhost kernel: [] ? kthread+0x0/0xa0 Oct 23 01:09:26 localhost kernel: [] ? child_rip+0x0/0x20 Oct 23 01:09:26 localhost kernel: ---[ end trace a3e2fc9bc2611149 ]--- Oct 23 01:09:26 localhost kernel: br1: port 2(vethFUgOpJ) entering disabled state Oct 23 01:09:26 localhost kernel: br1: port 2(vethFUgOpJ) entering disabled state ------------------------------------------------------------------ This log appear only dual bridge and reboot/shutdown in container. I've try one bridge setting, not appear this message. I've try to change container's ipv6 setting(to disable by /etc/sysctl.conf), not appear too. (ipv6 setting refference: http://lifeofageekadmin.com/disable-ipv6-on-centos-6/) And I've try to stop container with lxc-stop, not appear. 2.When running lxc-start with -o test.log option, I get following WARN message in test.log ------------------------------------------------------------------ lxc-start 1350923335.375 DEBUG lxc_cgroup - using cgroup mounted at '/cgroup' lxc-start 1350923335.375 DEBUG lxc_cgroup - lxc_cgroup_path_get: returning /cgroup/lxc63_01 for subsystem devices.allow lxc-start 1350923335.375 DEBUG lxc_conf - cgroup 'devices.allow' set to 'c 254:0 rwm' lxc-start 1350923335.375 INFO lxc_conf - cgroup has been setup lxc-start 1350923335.375 INFO lxc_conf - console has been setup lxc-start 1350923335.379 INFO lxc_conf - 4 tty(s) has been setup lxc-start 1350923335.382 DEBUG lxc_conf - mountpoint for old rootfs is '/usr/local/lib/lxc/rootfs/mnt' lxc-start 1350923335.382 DEBUG lxc_conf - pivot_root syscall to '/usr/local/lib/lxc/rootfs' successful lxc-start 1350923335.382 DEBUG lxc_conf - umounted '/mnt/dev/pts' lxc-start 1350923335.382 DEBUG lxc_conf - umounted '/mnt/dev/shm' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/proc/bus/usb' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/proc/sys/fs/binfmt_misc' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/sys' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/boot' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/cgroup' lxc-start 1350923335.383 DEBUG lxc_conf - umounted '/mnt/proc' lxc-start 1350923335.383 INFO lxc_conf - lazy unmount of '/mnt' >> lxc-start 1350923335.383 WARN lxc_conf - failed to unmount '/mnt/dev' lxc-start 1350923335.383 DEBUG lxc_conf - capabilities has been setup lxc-start 1350923335.384 NOTICE lxc_conf - 'lxc63_01' is setup. lxc-start 1350923335.384 NOTICE lxc_start - exec'ing '/sbin/init' lxc-start 1350923335.384 NOTICE lxc_start - '/sbin/init' started with pid '3349' lxc-start 1350923335.384 DEBUG lxc_utmp - Added '/proc/3349/root/var/run' to inotifywatch lxc-start 1350923335.609 DEBUG lxc_utmp - got inotify event 256 for utmp lxc-start 1350923335.635 DEBUG lxc_utmp - got inotify event 2 for utmp lxc-start 1350923335.635 DEBUG lxc_utmp - got inotify event 2 for utmp lxc-start 1350923335.635 DEBUG lxc_utmp - utmp handler - run level is ^@/3 ------------------------------------------------------------------ Probably, this WARN is not for dual bridge setting... So I search google and checking lxc source code, but I couldn't judge that two message is critical or not critical. Anyone can help? At last, I describe about how to create my environment. My script is in github.(lxc-centos template). (https://github.com/koji--/lxc-centos) I take command for creating container, like this. ---------------------------------------------------------------------------- [root at localhost ~]# lxc-centos --name=lxc63_01 --utsname= lxc63_01.example.com --path=/home/lxc --first-ipv4=192.168.1.129/24--second-ipv4= 192.168.2.129/24 --arch=x86_64 --arch-base=x86_64 ---------------------------------------------------------------------------- And running container like this. ---------------------------------------------------------------------------- [root at localhost ~]# lxc-start -n lxc63_01 -f /home/lxc/lxc63_01/config -o test.log -l DEBUG ---------------------------------------------------------------------------- Host's /etc/fstab is like this. ------------------------------------------------------------------------------------------ [root at localhost ~]# cat /etc/fstab | grep 'devpts\|cgroup' devpts /dev/pts devpts gid=5,mode=620,newinstance,ptmxmode=0666 0 0 none /cgroup cgroup defaults 0 0 ------------------------------------------------------------------------------------------ Sorry for such a long text... Thanks. Koji Takiguchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ope-linux at gmx.de Mon Oct 22 19:05:22 2012 From: ope-linux at gmx.de (olx69) Date: Mon, 22 Oct 2012 21:05:22 +0200 Subject: [Lxc-users] centos6 container and root login Message-ID: <508598F2.9050808@gmx.de> Hello, basically I did follow http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum Additionally I added echo "pts/0" >> /etc/securetty to the lxc container to allow root login, but it doesn't allow me this. Any hints for this? The goal is to run postgresql 9.x, bacula 5.x and others inside the lxc env. Thanks, Olaf From tompos at martos.bme.hu Mon Oct 22 19:25:27 2012 From: tompos at martos.bme.hu (Papp Tamas) Date: Mon, 22 Oct 2012 21:25:27 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <508598F2.9050808@gmx.de> References: <508598F2.9050808@gmx.de> Message-ID: <50859DA7.5060607@martos.bme.hu> On 10/22/2012 09:05 PM, olx69 wrote: > Hello, > > basically I did follow > http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum > > Additionally I added > > echo "pts/0" >> /etc/securetty > > to the lxc container to allow root login, but it doesn't allow me this. > Any hints for this? The goal is to run postgresql 9.x, bacula 5.x and You didn't paste error messages. > others inside the lxc env. FYI I could not run psql inside container successfully, only with a very basic postgresql.conf. It was all about shared memory handling. See the list archives for the details. If I remember well, other people did not encounter the issue. tamas From ope-linux at gmx.de Mon Oct 22 19:19:36 2012 From: ope-linux at gmx.de (olx69) Date: Mon, 22 Oct 2012 21:19:36 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <508598F2.9050808@gmx.de> References: <508598F2.9050808@gmx.de> Message-ID: <50859C48.6060206@gmx.de> > Hello, > > basically I did follow > http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum > > Additionally I added > > echo "pts/0" >> /etc/securetty > > to the lxc container to allow root login, but it doesn't allow me this. > Any hints for this? The goal is to run postgresql 9.x, bacula 5.x and > others inside the lxc env. > to be more precise, I've got after root/passwd phrase the option: Would you like to enter a security context? [N] and then no login is possible. I've started the lxc with virsh -c lxc:/// start lxcvm virsh -c lxc:/// console lxcvm From mhw at wittsend.com Mon Oct 22 20:05:20 2012 From: mhw at wittsend.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 16:05:20 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022141216.GA6916@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> Message-ID: <1350936320.1481.19.camel@canyon.wittsend.com> Serge, On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > Serge, > > > > > > > > > > > ... > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > and I suspect this OP is going to run into this same thing (container > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > (having read some systemd error messages) systemd is going to have some > > > > > serious heartburn there. > > > > > > > > > > Thoughts? > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > from my post to the systemd-devel list. Looks like they have a > > > mechanism in place to do this... > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > Saw the email, haven't yet read the page, thanks. > So based on that page, what we do (set 'container=lxc') should already be > sufficient. Thanks to the dude asking a libvirt-lxc question on the list, I was let to a page that let to a page that led to some discussion you were having back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] f16 update"... http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html This would look to be the kludge to make a workaround for this problem, I'm just not sure how to make it happen. Given you already found the answer that the device for /dev has to be different than the device for the parent, what should we do. I tried this in the config... lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 Maybe I got that entry wrong but it didn't do anything (and would have resulted in other failures later as I found out). A similar mount entry for a shared filesystem worked just fine. Trying an empty /dev fails because it's missing EVERYTHING so starting out with a tmpfs without populating it is not the answer either. The correct answer would be to mount a tmpfs file system and then populate it before firing up systemd in the container. I don't see how to do that. A bind mount isn't going to work either, for the reasons you stated in that thread, it ends up on the same device. Having another mount on another real device would be a workaround but a really bad kludge that would complicate things immensely. > -serge -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Mon Oct 22 20:14:52 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 22 Oct 2012 15:14:52 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350936320.1481.19.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> Message-ID: <20121022201452.GA13908@sergelap> Quoting Michael H. Warfield (mhw at wittsend.com): > Serge, > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > Serge, > > > > > > > > > > > > > > ... > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > > and I suspect this OP is going to run into this same thing (container > > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > > (having read some systemd error messages) systemd is going to have some > > > > > > serious heartburn there. > > > > > > > > > > > > Thoughts? > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > from my post to the systemd-devel list. Looks like they have a > > > > mechanism in place to do this... > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > Saw the email, haven't yet read the page, thanks. > > > So based on that page, what we do (set 'container=lxc') should already be > > sufficient. > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > to a page that let to a page that led to some discussion you were having > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > f16 update"... > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html thanks, I knew we'd been over some of this, but couldn't find my logs of it. > This would look to be the kludge to make a workaround for this problem, > I'm just not sure how to make it happen. Given you already found the > answer that the device for /dev has to be different than the device for > the parent, what should we do. > > I tried this in the config... > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 How about just a devtmpfs? We actually now do this by default (as of very recently) in ubuntu by adding devtmpfs dev devtmpfs defaults 0 0 to /var/lib/lxc/$container/fstab Or, are you on an older kernel which doesn't have devtmpfs? > Maybe I got that entry wrong but it didn't do anything (and would have > resulted in other failures later as I found out). A similar mount entry > for a shared filesystem worked just fine. > > Trying an empty /dev fails because it's missing EVERYTHING so starting > out with a tmpfs without populating it is not the answer either. > > The correct answer would be to mount a tmpfs file system and then > populate it before firing up systemd in the container. I don't see how > to do that. A bind mount isn't going to work either, for the reasons > you stated in that thread, it ends up on the same device. Having > another mount on another real device would be a workaround but a really > bad kludge that would complicate things immensely. > > > -serge > > > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! From list at fajar.net Mon Oct 22 20:15:06 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Tue, 23 Oct 2012 03:15:06 +0700 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <50859C48.6060206@gmx.de> References: <508598F2.9050808@gmx.de> <50859C48.6060206@gmx.de> Message-ID: On Tue, Oct 23, 2012 at 2:19 AM, olx69 wrote: >> Hello, >> >> basically I did follow >> http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum >> >> Additionally I added >> >> echo "pts/0" >> /etc/securetty >> >> to the lxc container to allow root login, You shouldn't need that. >> but it doesn't allow me this. >> Any hints for this? The goal is to run postgresql 9.x, bacula 5.x and >> others inside the lxc env. >> As papp mentioned, you'd probably have problems there (at least if the host is ubuntu) since postgres use shared memory and apparmor doesn't allow setting it. > to be more precise, I've got after root/passwd phrase the option: > > Would you like to enter a security context? [N] Looks like selinux problem? Can you try disabling selinux in the host (and possibly in the guest as well) with "setenforce 0". -- Fajar From dwight.engen at oracle.com Mon Oct 22 20:37:38 2012 From: dwight.engen at oracle.com (Dwight Engen) Date: Mon, 22 Oct 2012 16:37:38 -0400 Subject: [Lxc-users] centos6 container and root login In-Reply-To: References: <508598F2.9050808@gmx.de> <50859C48.6060206@gmx.de> Message-ID: <20121022163738.3ae492f7@delphi.home> On Tue, 23 Oct 2012 03:15:06 +0700 "Fajar A. Nugraha" wrote: [...] > > to be more precise, I've got after root/passwd phrase the option: > > > > Would you like to enter a security context? [N] > > Looks like selinux problem? Can you try disabling selinux in the host > (and possibly in the guest as well) with "setenforce 0". FWIW in my experience doing setenforce 0 in the host isn't enough for the guest to think selinux is disabled since libselinux::is_selinux_enabled() in the guest will check /proc/filesystems and see selinuxfs, thus reporting that it is on. (ie. check the output of sestatus in the guest). I had to disable it and reboot to make the guest think it is not enabled. From mhw at WittsEnd.com Mon Oct 22 20:48:45 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 16:48:45 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022201452.GA13908@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> Message-ID: <1350938925.1481.39.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at wittsend.com): > > Serge, > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > Serge, > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > > > and I suspect this OP is going to run into this same thing (container > > > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > > > (having read some systemd error messages) systemd is going to have some > > > > > > > serious heartburn there. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > > from my post to the systemd-devel list. Looks like they have a > > > > > mechanism in place to do this... > > > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > > > Saw the email, haven't yet read the page, thanks. > > > > > So based on that page, what we do (set 'container=lxc') should already be > > > sufficient. > > > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > > to a page that let to a page that led to some discussion you were having > > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > > f16 update"... > > > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html > > thanks, I knew we'd been over some of this, but couldn't find my logs of > it. > > > This would look to be the kludge to make a workaround for this problem, > > I'm just not sure how to make it happen. Given you already found the > > answer that the device for /dev has to be different than the device for > > the parent, what should we do. > > > > I tried this in the config... > > > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 > How about just a devtmpfs? We actually now do this by default (as of very > recently) in ubuntu by adding > devtmpfs dev devtmpfs defaults 0 0 NO! That's the problem! That leads to the container connecting to the hosts console and other devices and committing random acts of terrorism. That's exactly the case we are trying to avoid and which is causing the problems to begin with. That's what systemd is doing if it doesn't find /dev mounted to begin with. > to /var/lib/lxc/$container/fstab > Or, are you on an older kernel which doesn't have devtmpfs? > > Maybe I got that entry wrong but it didn't do anything (and would have > > resulted in other failures later as I found out). A similar mount entry > > for a shared filesystem worked just fine. > > > > Trying an empty /dev fails because it's missing EVERYTHING so starting > > out with a tmpfs without populating it is not the answer either. > > > > The correct answer would be to mount a tmpfs file system and then > > populate it before firing up systemd in the container. I don't see how > > to do that. A bind mount isn't going to work either, for the reasons > > you stated in that thread, it ends up on the same device. Having > > another mount on another real device would be a workaround but a really > > bad kludge that would complicate things immensely. > > > > > -serge > > > > > > -- > > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 20:59:22 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 16:59:22 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121022205019.GA24239@tango.0pointer.de> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> Message-ID: <1350939562.1481.43.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: > On Mon, 22.10.12 11:48, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > To summarize the problem... The LXC startup binary sets up various > > > > things for /dev and /dev/pts for the container to run properly and this > > > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > > > on /dev/pts which then break things horribly. This is because the > > > > kernel currently lacks namespaces for devices and won't for some time to > > > > come (in design). When devtmpfs gets mounted over top of /dev in the > > > > container, it then hijacks the hosts console tty and several other > > > > devices which had been set up through bind mounts by LXC and should have > > > > been LEFT ALONE. > > > > > Please initialize a minimal tmpfs on /dev. systemd will then work fine. > > > > My containers have a reasonable /dev that work with Upstart just fine > > but they are not on tmpfs. Is mounting tmpfs on /dev and recreating > > that minimal /dev required? > Well, it can be any kind of mount really. Just needs to be a mount. And > the idea is to use tmpfs for this. > What /dev are you currently using? It's probably not a good idea to > reuse the hosts' /dev, since it contains so many device nodes that > should not be accessible/visible to the container. Got it. And that explains the problems we're seeing but also what I'm seeing in some libvirt-lxc related pages, which is a separate and distinct project in spite of the similarities in the name... http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes Unfortunately, in our case, merely getting a mount in there is a complication in that it also has to be populated but, at least, we understand the problem set now. > > > systemd will make use of pre-existing mounts if they exist, and only > > > mount something new if they don't exist. > > > > So you're saying that, if we have something mounted on /dev, that's what > > prevents systemd from mounting devtmpfs on /dev? > Yes. > > But, I have systemd running on my host system (F17) and containers with > > sysvinit or upstart inits are all starting just fine. That sounds like > > it should impact all containers as pivot_root() is issued before systemd > > in the container is started. Or am I missing something here? That > > sounds like a problem for Serge and others to investigate further. I'll > > see about trying that workaround though. > The "shared" issue is F18, and it's about running LXC on a systemd > system, not about running systemd inside of LXC. Whew! I'll deal with F18 when I need to deal with F18. That explains why my F17 hosts are running and gives Serge and others a chance to address this, forewarned. Thanks for that info. > Lennart > -- > Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Mon Oct 22 21:21:50 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 22 Oct 2012 16:21:50 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350938925.1481.39.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> Message-ID: <20121022212150.GA29740@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at wittsend.com): > > > Serge, > > > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > > > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > > Serge, > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > > > > and I suspect this OP is going to run into this same thing (container > > > > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > > > > (having read some systemd error messages) systemd is going to have some > > > > > > > > serious heartburn there. > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > > > from my post to the systemd-devel list. Looks like they have a > > > > > > mechanism in place to do this... > > > > > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > > > > > Saw the email, haven't yet read the page, thanks. > > > > > > > So based on that page, what we do (set 'container=lxc') should already be > > > > sufficient. > > > > > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > > > to a page that let to a page that led to some discussion you were having > > > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > > > f16 update"... > > > > > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html > > > > thanks, I knew we'd been over some of this, but couldn't find my logs of > > it. > > > > > This would look to be the kludge to make a workaround for this problem, > > > I'm just not sure how to make it happen. Given you already found the > > > answer that the device for /dev has to be different than the device for > > > the parent, what should we do. > > > > > > I tried this in the config... > > > > > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 > > > How about just a devtmpfs? We actually now do this by default (as of very > > recently) in ubuntu by adding > > > devtmpfs dev devtmpfs defaults 0 0 > > NO! That's the problem! That leads to the container connecting to the > hosts console and other devices and committing random acts of terrorism. No, it shouldn't, because lxc sets up the console after doing the mounts. -serge From mhw at WittsEnd.com Mon Oct 22 21:36:59 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 17:36:59 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022212150.GA29740@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> Message-ID: <1350941819.1481.49.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (mhw at wittsend.com): > > > > Serge, > > > > > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > > > > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > > > Serge, > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > > > > > and I suspect this OP is going to run into this same thing (container > > > > > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > > > > > (having read some systemd error messages) systemd is going to have some > > > > > > > > > serious heartburn there. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > > > > from my post to the systemd-devel list. Looks like they have a > > > > > > > mechanism in place to do this... > > > > > > > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > > > > > > > Saw the email, haven't yet read the page, thanks. > > > > > > > > > So based on that page, what we do (set 'container=lxc') should already be > > > > > sufficient. > > > > > > > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > > > > to a page that let to a page that led to some discussion you were having > > > > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > > > > f16 update"... > > > > > > > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html > > > > > > thanks, I knew we'd been over some of this, but couldn't find my logs of > > > it. > > > > > > > This would look to be the kludge to make a workaround for this problem, > > > > I'm just not sure how to make it happen. Given you already found the > > > > answer that the device for /dev has to be different than the device for > > > > the parent, what should we do. > > > > > > > > I tried this in the config... > > > > > > > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 > > > > > How about just a devtmpfs? We actually now do this by default (as of very > > > recently) in ubuntu by adding > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > NO! That's the problem! That leads to the container connecting to the > > hosts console and other devices and committing random acts of terrorism. > No, it shouldn't, because lxc sets up the console after doing the mounts. Maybe it shouldn't but that appears to be what is happening and even you remarked that maybe the problem was something doing a remount of /dev after entering the container... I see your point though. If you did that mount after LXC set up the console, then systemd wouldn't set it up and would drop into its more restricted mode. That MIGHT help but you still have the entire dev space of the host exposed to the guest which is what you were talking about before wrt namespaces on devices. It might help. Would it be the answer? Given that we've restricted access to those nodes in the config, maybe yes. I'm just not so sure. Will give it a shot though. Strange, though, my earlier effort at tmpfs on dev had no effect. Will give it a shot. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Mon Oct 22 21:58:13 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 22 Oct 2012 16:58:13 -0500 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350941819.1481.49.camel@canyon.wittsend.com> References: <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> <1350941819.1481.49.camel@canyon.wittsend.com> Message-ID: <20121022215813.GA1116@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > > Quoting Michael H. Warfield (mhw at wittsend.com): > > > > > Serge, > > > > > > > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > > > > > Quoting Serge Hallyn (serge.hallyn at canonical.com): > > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > > > > Serge, > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem > > > > > > > > > > and I suspect this OP is going to run into this same thing (container > > > > > > > > > > taking over host's console) and might explain some of what he's seeing. > > > > > > > > > > Several of these look like they could cause problems (like /dev/pts in > > > > > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host. > > > > > > > > > > Prohibiting mounts entirely in the container might work but I suspect > > > > > > > > > > (having read some systemd error messages) systemd is going to have some > > > > > > > > > > serious heartburn there. > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > > > > > from my post to the systemd-devel list. Looks like they have a > > > > > > > > mechanism in place to do this... > > > > > > > > > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > > > > > > > > > Saw the email, haven't yet read the page, thanks. > > > > > > > > > > > So based on that page, what we do (set 'container=lxc') should already be > > > > > > sufficient. > > > > > > > > > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > > > > > to a page that let to a page that led to some discussion you were having > > > > > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > > > > > f16 update"... > > > > > > > > > > http://www.mail-archive.com/lxc-users at lists.sourceforge.net/msg03263.html > > > > > > > > thanks, I knew we'd been over some of this, but couldn't find my logs of > > > > it. > > > > > > > > > This would look to be the kludge to make a workaround for this problem, > > > > > I'm just not sure how to make it happen. Given you already found the > > > > > answer that the device for /dev has to be different than the device for > > > > > the parent, what should we do. > > > > > > > > > > I tried this in the config... > > > > > > > > > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 > > > > > > > How about just a devtmpfs? We actually now do this by default (as of very > > > > recently) in ubuntu by adding > > > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > > > NO! That's the problem! That leads to the container connecting to the > > > hosts console and other devices and committing random acts of terrorism. > > > No, it shouldn't, because lxc sets up the console after doing the mounts. > > Maybe it shouldn't but that appears to be what is happening and even you > remarked that maybe the problem was something doing a remount of /dev > after entering the container... > > I see your point though. If you did that mount after LXC set up the > console, then systemd wouldn't set it up and would drop into its more > restricted mode. That MIGHT help but you still have the entire dev > space of the host exposed to the guest which is what you were talking > about before wrt namespaces on devices. It might help. Would it be the > answer? Given that we've restricted access to those nodes in the > config, maybe yes. I'm just not so sure. Will give it a shot though. > > Strange, though, my earlier effort at tmpfs on dev had no effect. Will > give it a shot. Thanks again for looking into this - I know just how frustrating it can be! :) -serge From mhw at WittsEnd.com Mon Oct 22 22:05:13 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 18:05:13 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <20121022212150.GA29740@sergelap> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> Message-ID: <1350943513.1481.58.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > How about just a devtmpfs? We actually now do this by default (as of very > > > recently) in ubuntu by adding > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > NO! That's the problem! That leads to the container connecting to the > > hosts console and other devices and committing random acts of terrorism. > No, it shouldn't, because lxc sets up the console after doing the mounts. Damn, dude! That worked! That kludge rang da bell. Of course, I also discovered the boneheaded typo I had in attempting the tmpfs mount in the process. :-P I now have a container running systemd up and running with Fedora 17 in it. I'm not sure I'm totally happy with it. Because of doing the devtmpfs thing, the guest can immediately see things like removable drives coming and going and might, presumably, be able to mount them. Not thrilled with that from a security standpoint. Would also mean the guests could access things like my permanent forensic CDs that are in the CD drives. I guess that can be restricted in the config but still makes me a bit uncomfortable that the guest has complete visibility into the hosts dev system. Another gotcha, albeit a much more minor one... When systemd drops into this mode, you no longer have vty consoles available so lxc-console won't work. That's actually on their page. I remember seeing this: -- If systemd detects it is run in a container it will spawn a single shell on /dev/console, and not care about VTs or multiple gettys on VTs -- Suboptimal but a small price to pay I suppose. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 22:08:52 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 18:08:52 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350943513.1481.58.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> <1350943513.1481.58.camel@canyon.wittsend.com> Message-ID: <1350943732.1481.60.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > > > > > How about just a devtmpfs? We actually now do this by default (as of very > > > > recently) in ubuntu by adding > > > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > > > NO! That's the problem! That leads to the container connecting to the > > > hosts console and other devices and committing random acts of terrorism. > > > No, it shouldn't, because lxc sets up the console after doing the mounts. > Damn, dude! That worked! That kludge rang da bell. Of course, I also > discovered the boneheaded typo I had in attempting the tmpfs mount in > the process. :-P I now have a container running systemd up and running > with Fedora 17 in it. Forgot to include the entry I added to the config file to make it all workie... lxc.mount.entry=devtmpfs /srv/lxc/rootfs/dev devtmpfs defaults 0 0 That /srv/lxc/rootfs is my common bind mount for all my containers. > I'm not sure I'm totally happy with it. > Because of doing the devtmpfs thing, the guest can immediately see > things like removable drives coming and going and might, presumably, be > able to mount them. Not thrilled with that from a security standpoint. > Would also mean the guests could access things like my permanent > forensic CDs that are in the CD drives. I guess that can be restricted > in the config but still makes me a bit uncomfortable that the guest has > complete visibility into the hosts dev system. > > Another gotcha, albeit a much more minor one... When systemd drops into > this mode, you no longer have vty consoles available so lxc-console > won't work. That's actually on their page. > > I remember seeing this: > > -- > If systemd detects it is run in a container it will spawn a single shell > on /dev/console, and not care about VTs or multiple gettys on VTs > -- > > Suboptimal but a small price to pay I suppose. > > > -serge > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From framstag at rus.uni-stuttgart.de Mon Oct 22 22:26:43 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Tue, 23 Oct 2012 00:26:43 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: References: Message-ID: <20121022222643.GA26094@rus.uni-stuttgart.de> On Mon 2012-10-22 (18:09), swair shah wrote: > I was wondering if anyone is using lxc on production. and if you don't mind > disclosing, for what purpose do you use it on production? fex.rus.uni-stuttgart.de is a LXC container and runs smooth for nearly 2 years. It gives more than 300 MB/s for HTTP file transfers See http://fex.rus.uni-stuttgart.de/ for details -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: From framstag at rus.uni-stuttgart.de Mon Oct 22 22:29:29 2012 From: framstag at rus.uni-stuttgart.de (Ulli Horlacher) Date: Tue, 23 Oct 2012 00:29:29 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: <508541DD.10607@ubuntu.com> References: <508541DD.10607@ubuntu.com> Message-ID: <20121022222929.GB26094@rus.uni-stuttgart.de> On Mon 2012-10-22 (14:53), St?phane Graber wrote: > All in all, that's somewhere around 300-400 containers I'm managing How do you handle a host (hardware) failure? -- Ullrich Horlacher Informationssysteme und Serverbetrieb Rechenzentrum IZUS/TIK E-Mail: horlacher at rus.uni-stuttgart.de Universitaet Stuttgart Tel: ++49-711-68565868 Allmandring 30a Fax: ++49-711-682357 70550 Stuttgart (Germany) WWW: http://www.rus.uni-stuttgart.de/ REF: <508541DD.10607 at ubuntu.com> From mhw at WittsEnd.com Mon Oct 22 22:37:04 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 18:37:04 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350943513.1481.58.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> <1350943513.1481.58.camel@canyon.wittsend.com> Message-ID: <1350945424.1481.64.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > > > > > How about just a devtmpfs? We actually now do this by default (as of very > > > > recently) in ubuntu by adding > > > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > > > NO! That's the problem! That leads to the container connecting to the > > > hosts console and other devices and committing random acts of terrorism. > > No, it shouldn't, because lxc sets up the console after doing the mounts. > Damn, dude! That worked! That kludge rang da bell. Of course, I also > discovered the boneheaded typo I had in attempting the tmpfs mount in > the process. :-P I now have a container running systemd up and running > with Fedora 17 in it. > I'm not sure I'm totally happy with it. > Because of doing the devtmpfs thing, the guest can immediately see > things like removable drives coming and going and might, presumably, be > able to mount them. Not thrilled with that from a security standpoint. > Would also mean the guests could access things like my permanent > forensic CDs that are in the CD drives. I guess that can be restricted > in the config but still makes me a bit uncomfortable that the guest has > complete visibility into the hosts dev system. Another downside. Container does not shut down cleanly... init 0 inside the container... In lxc-start - Unmounting file systems. Could not remount as read-only /: Device or resource busy Not all file systems unmounted, 1 left. Detaching loop devices. Could not delete loopback /dev/loop7: Operation not permitted Could not delete loopback /dev/loop6: Operation not permitted Could not delete loopback /dev/loop5: Operation not permitted Could not delete loopback /dev/loop4: Operation not permitted Could not delete loopback /dev/loop3: Operation not permitted Could not delete loopback /dev/loop2: Operation not permitted Could not delete loopback /dev/loop1: Operation not permitted Could not delete loopback /dev/loop0: Operation not permitted Not all loop devices detached, 8 left. Cannot finalize remaining file systems and devices, giving up. Exiting container. lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/Alcove' Not good. The tasks file is empty but... Can't get rid of it. "Operation not permitted". Sigh... Getting closer though. Much closer. > Another gotcha, albeit a much more minor one... When systemd drops into > this mode, you no longer have vty consoles available so lxc-console > won't work. That's actually on their page. > I remember seeing this: > > -- > If systemd detects it is run in a container it will spawn a single shell > on /dev/console, and not care about VTs or multiple gettys on VTs > -- > > Suboptimal but a small price to pay I suppose. > > > -serge > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Mon Oct 22 22:55:45 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Mon, 22 Oct 2012 18:55:45 -0400 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350945424.1481.64.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> <1350943513.1481.58.camel@canyon.wittsend.com> <1350945424.1481.64.camel@canyon.wittsend.com> Message-ID: <1350946545.1481.67.camel@canyon.wittsend.com> On Mon, 2012-10-22 at 18:37 -0400, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote: > > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > > > > > > > > > How about just a devtmpfs? We actually now do this by default (as of very > > > > > recently) in ubuntu by adding > > > > > > > > > devtmpfs dev devtmpfs defaults 0 0 > > > > > > > > NO! That's the problem! That leads to the container connecting to the > > > > hosts console and other devices and committing random acts of terrorism. > > > > No, it shouldn't, because lxc sets up the console after doing the mounts. > > > Damn, dude! That worked! That kludge rang da bell. Of course, I also > > discovered the boneheaded typo I had in attempting the tmpfs mount in > > the process. :-P I now have a container running systemd up and running > > with Fedora 17 in it. > > > I'm not sure I'm totally happy with it. > > > Because of doing the devtmpfs thing, the guest can immediately see > > things like removable drives coming and going and might, presumably, be > > able to mount them. Not thrilled with that from a security standpoint. > > Would also mean the guests could access things like my permanent > > forensic CDs that are in the CD drives. I guess that can be restricted > > in the config but still makes me a bit uncomfortable that the guest has > > complete visibility into the hosts dev system. > Another downside. Container does not shut down cleanly... And another... Container seems to hang if lxc-start is run in disconnected mode (lxc-start -d -o {log}). Starts up fine with a console that's connected to pty's but not to a log it seems... > init 0 inside the container... > > In lxc-start - > > Unmounting file systems. > Could not remount as read-only /: Device or resource busy > Not all file systems unmounted, 1 left. > Detaching loop devices. > Could not delete loopback /dev/loop7: Operation not permitted > Could not delete loopback /dev/loop6: Operation not permitted > Could not delete loopback /dev/loop5: Operation not permitted > Could not delete loopback /dev/loop4: Operation not permitted > Could not delete loopback /dev/loop3: Operation not permitted > Could not delete loopback /dev/loop2: Operation not permitted > Could not delete loopback /dev/loop1: Operation not permitted > Could not delete loopback /dev/loop0: Operation not permitted > Not all loop devices detached, 8 left. > Cannot finalize remaining file systems and devices, giving up. > Exiting container. > lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/Alcove' > > Not good. The tasks file is empty but... Can't get rid of it. > "Operation not permitted". > > Sigh... > > Getting closer though. Much closer. > > > Another gotcha, albeit a much more minor one... When systemd drops into > > this mode, you no longer have vty consoles available so lxc-console > > won't work. That's actually on their page. > > > I remember seeing this: > > > > -- > > If systemd detects it is run in a container it will spawn a single shell > > on /dev/console, and not care about VTs or multiple gettys on VTs > > -- > > > > Suboptimal but a small price to pay I suppose. > > > > > -serge > > > > Regards, > > Mike > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From ope-linux at gmx.de Tue Oct 23 05:52:28 2012 From: ope-linux at gmx.de (olx69) Date: Tue, 23 Oct 2012 07:52:28 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: References: <508598F2.9050808@gmx.de> <50859C48.6060206@gmx.de> Message-ID: <5086309C.9010100@gmx.de> >>> basically I did follow >>> http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum >>> >>> Additionally I added >>> >>> echo "pts/0" >> /etc/securetty >>> >>> to the lxc container to allow root login, > > You shouldn't need that. So I will remove it. >>> but it doesn't allow me this. >>> Any hints for this? The goal is to run postgresql 9.x, bacula 5.x and >>> others inside the lxc env. >>> > > As papp mentioned, you'd probably have problems there (at least if the > host is ubuntu) since postgres use shared memory and apparmor doesn't > allow setting it. this is really sad, therefore I've to use a dedicated kvm instance which is another story ... >> to be more precise, I've got after root/passwd phrase the option: >> >> Would you like to enter a security context? [N] > > Looks like selinux problem? Can you try disabling selinux in the host > (and possibly in the guest as well) with "setenforce 0". > I''ve seen this in some web articles but it doesn't help. Anway, I check it again. Thanks, Olaf From list at fajar.net Tue Oct 23 06:51:40 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Tue, 23 Oct 2012 13:51:40 +0700 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <5086309C.9010100@gmx.de> References: <508598F2.9050808@gmx.de> <50859C48.6060206@gmx.de> <5086309C.9010100@gmx.de> Message-ID: On Tue, Oct 23, 2012 at 12:52 PM, olx69 wrote: >> As papp mentioned, you'd probably have problems there (at least if the >> host is ubuntu) since postgres use shared memory and apparmor doesn't >> allow setting it. > > this is really sad, therefore I've to use a dedicated kvm instance which > is another story ... Not HAVE to. The thing is lxc is still somewhat insecure. To counteract that, apparmor on ubuntu limits some things you can't do inside a container, so you can't increase SHM limit. For now, anyway. A workaround is to just disable apparmor for the container, but that might lead to other problems (e.g. container doing "bad things" to the host). Postgres should work then (I tested with Oracle DB, which also requires SHM settings to be increased). ... then again if you use centos host, it might not matter anyway, since AFAIK it doesn't implement the restriction to containers (i.e. all containers are inherently insecure). >> Looks like selinux problem? Can you try disabling selinux in the host >> (and possibly in the guest as well) with "setenforce 0". >> > > I''ve seen this in some web articles but it doesn't help. Anway, I check > it again. See last email from Dwight. -- Fajar From stgraber at ubuntu.com Tue Oct 23 15:20:01 2012 From: stgraber at ubuntu.com (=?ISO-8859-1?Q?St=E9phane_Graber?=) Date: Tue, 23 Oct 2012 17:20:01 +0200 Subject: [Lxc-users] Using lxc on production In-Reply-To: <20121022222929.GB26094@rus.uni-stuttgart.de> References: <508541DD.10607@ubuntu.com> <20121022222929.GB26094@rus.uni-stuttgart.de> Message-ID: <5086B5A1.5080607@ubuntu.com> On 10/23/2012 12:29 AM, Ulli Horlacher wrote: > On Mon 2012-10-22 (14:53), St?phane Graber wrote: > >> All in all, that's somewhere around 300-400 containers I'm managing > > How do you handle a host (hardware) failure? Everything that runs in the container is in a configuration management system, so any container can be redeployed from scratch in just a couple of minutes without needing the actual rootfs. On top of that, all the containers are backed up centrally using data deduplication, so if I really need it, I can extract a .tar.gz of the rootfs of any container in minutes and then just dump that on another machine. Though technically all the critical services are already redundant, so in case of a host failure, all I'd see is an increase of load on the other servers while I fix the host and get the rest back online. -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From stgraber at ubuntu.com Tue Oct 23 15:22:54 2012 From: stgraber at ubuntu.com (=?ISO-8859-1?Q?St=E9phane_Graber?=) Date: Tue, 23 Oct 2012 17:22:54 +0200 Subject: [Lxc-users] systemd inside LXC In-Reply-To: <1350943513.1481.58.camel@canyon.wittsend.com> References: <508155D3.4000504@jelmail.com> <20121019155101.GA10078@sergelap> <1350776519.30263.36.camel@canyon.wittsend.com> <20121021194954.GA5168@sergelap> <1350872461.5036.88.camel@canyon.wittsend.com> <20121022130949.GA5466@sergelap> <20121022141216.GA6916@sergelap> <1350936320.1481.19.camel@canyon.wittsend.com> <20121022201452.GA13908@sergelap> <1350938925.1481.39.camel@canyon.wittsend.com> <20121022212150.GA29740@sergelap> <1350943513.1481.58.camel@canyon.wittsend.com> Message-ID: <5086B64E.5070709@ubuntu.com> On 10/23/2012 12:05 AM, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: >> Quoting Michael H. Warfield (mhw at WittsEnd.com): >>> On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: > > > >>>> How about just a devtmpfs? We actually now do this by default (as of very >>>> recently) in ubuntu by adding >>> >>>> devtmpfs dev devtmpfs defaults 0 0 >>> >>> NO! That's the problem! That leads to the container connecting to the >>> hosts console and other devices and committing random acts of terrorism. > >> No, it shouldn't, because lxc sets up the console after doing the mounts. > > Damn, dude! That worked! That kludge rang da bell. Of course, I also > discovered the boneheaded typo I had in attempting the tmpfs mount in > the process. :-P I now have a container running systemd up and running > with Fedora 17 in it. > > I'm not sure I'm totally happy with it. > > Because of doing the devtmpfs thing, the guest can immediately see > things like removable drives coming and going and might, presumably, be > able to mount them. Not thrilled with that from a security standpoint. > Would also mean the guests could access things like my permanent > forensic CDs that are in the CD drives. I guess that can be restricted > in the config but still makes me a bit uncomfortable that the guest has > complete visibility into the hosts dev system. That's actually similar to what Ubuntu has had for the past few releases as we're running udevd in the container. Basically all the block devices of the host and any hotplugged device will appear in /dev but our default configuration is to only allow "mknod"ing them, not read or write to them. So the end result is basically the same as if they weren't there to start with, except that for those that are actually allowed, they then behave like they'd on the host by showing up when added and disappearing when removed without any manual interaction. It's not ideal, but it's safe. For the ideal implementation, we'll need to wait for the device namespace. > Another gotcha, albeit a much more minor one... When systemd drops into > this mode, you no longer have vty consoles available so lxc-console > won't work. That's actually on their page. > > I remember seeing this: > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- St?phane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From ope-linux at gmx.de Tue Oct 23 18:03:33 2012 From: ope-linux at gmx.de (olx69) Date: Tue, 23 Oct 2012 20:03:33 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <508598F2.9050808@gmx.de> References: <508598F2.9050808@gmx.de> Message-ID: <5086DBF5.1040309@gmx.de> >> > to be more precise, I've got after root/passwd phrase the option: >> > >> > Would you like to enter a security context? [N] >> >> Looks like selinux problem? Can you try disabling selinux in the host >> (and possibly in the guest as well) with "setenforce 0". > >FWIW in my experience doing setenforce 0 in the host isn't enough for >the guest to think selinux is disabled since >libselinux::is_selinux_enabled() in the guest will >check /proc/filesystems and see selinuxfs, thus reporting that it is >on. (ie. check the output of sestatus in the guest). I had to disable >it and reboot to make the guest think it is not enabled. How to disable it in that manner? In the container I did install policycoreutils (as shown at http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum I have only centos-release and the essential packages) and have # echo 0 >selinux/enforce # cat etc/selinux/config SELINUX=disabled in the the lxc container I can do now [root at pgsql ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: disabled Policy version: 24 Policy from config file: targeted which disables selinux obviously. BTW, for root login all what I did was to disable all pam_selinux.so pam_loginuid.so lines in /etc/pam.d/login ! From ope-linux at gmx.de Tue Oct 23 18:10:07 2012 From: ope-linux at gmx.de (olx69) Date: Tue, 23 Oct 2012 20:10:07 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <5086DBF5.1040309@gmx.de> References: <508598F2.9050808@gmx.de> <5086DBF5.1040309@gmx.de> Message-ID: <5086DD7F.6040309@gmx.de> > in the the lxc container I can do now > > [root at pgsql ~]# sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: disabled > Policy version: 24 > Policy from config file: targeted > > which disables selinux obviously. ... *not* Interesting, in the container: [root at pgsql ~]# setenforce 0 setenforce: setenforce() failed ??? not possible??? From ope-linux at gmx.de Tue Oct 23 18:17:15 2012 From: ope-linux at gmx.de (olx69) Date: Tue, 23 Oct 2012 20:17:15 +0200 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <5086DD7F.6040309@gmx.de> References: <508598F2.9050808@gmx.de> <5086DBF5.1040309@gmx.de> <5086DD7F.6040309@gmx.de> Message-ID: <5086DF2B.9090501@gmx.de> Am 23.10.2012 20:10, schrieb olx69: >> in the the lxc container I can do now >> >> [root at pgsql ~]# sestatus >> SELinux status: enabled >> SELinuxfs mount: /selinux >> Current mode: enforcing >> Mode from config file: disabled >> Policy version: 24 >> Policy from config file: targeted >> >> which disables selinux obviously. > ... *not* > > Interesting, in the container: > > [root at pgsql ~]# setenforce 0 > setenforce: setenforce() failed > > ??? not possible??? Even after more thinking about - do you mean disable SELinux on host? This would make sense for me, since the host kernel has SELinux - using the same kernel in a disabled container would disable it on host self also, probably not intentionally - isn't it? From dwight.engen at oracle.com Tue Oct 23 19:53:05 2012 From: dwight.engen at oracle.com (Dwight Engen) Date: Tue, 23 Oct 2012 15:53:05 -0400 Subject: [Lxc-users] centos6 container and root login In-Reply-To: <5086DBF5.1040309@gmx.de> References: <508598F2.9050808@gmx.de> <5086DBF5.1040309@gmx.de> Message-ID: <20121023155305.4abb4a75@delphi.home> On Tue, 23 Oct 2012 20:03:33 +0200 olx69 wrote: > >> > to be more precise, I've got after root/passwd phrase the > >> > option: > >> > > >> > Would you like to enter a security context? [N] > >> > >> Looks like selinux problem? Can you try disabling selinux in the > >> host (and possibly in the guest as well) with "setenforce 0". > > > >FWIW in my experience doing setenforce 0 in the host isn't enough > >for the guest to think selinux is disabled since > >libselinux::is_selinux_enabled() in the guest will > >check /proc/filesystems and see selinuxfs, thus reporting that it is > >on. (ie. check the output of sestatus in the guest). I had to > >disable it and reboot to make the guest think it is not enabled. > > How to disable it in that manner? > > In the container I did install policycoreutils (as shown at > http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum > I have only centos-release and the essential packages) and have > > # echo 0 >selinux/enforce > # cat etc/selinux/config > SELINUX=disabled > > in the the lxc container I can do now > > [root at pgsql ~]# sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: disabled > Policy version: 24 > Policy from config file: targeted > > which disables selinux obviously. Not actually disabled yet, for example try changing roots password in the container and you will not be able to. Doing the change to the hosts /etc/selinux/config you showed and rebooting the host should disable it, not just set it to permissive. As long as sestatus shows like above (the SELinux status is enabled), programs in the guest still think its enabled regardless of what the config file says because they call the libselinux::is_selinux_enabled() function I mentioned above which checks to see if selinuxfs is in /proc/filesystems. > BTW, for root login all what I did was to disable all > pam_selinux.so pam_loginuid.so lines in /etc/pam.d/login ! Yes, you may also have to add lxc/tty1 or pts/0 (for libvirt) to $container/etc/securetty depending on how you have your ptys mapped. From zheng_huabin at 163.com Wed Oct 24 05:58:32 2012 From: zheng_huabin at 163.com (Binknight) Date: Wed, 24 Oct 2012 13:58:32 +0800 (CST) Subject: [Lxc-users] Using lxc on production In-Reply-To: <5086B5A1.5080607@ubuntu.com> References: <508541DD.10607@ubuntu.com> <20121022222929.GB26094@rus.uni-stuttgart.de> <5086B5A1.5080607@ubuntu.com> Message-ID: <51405682.13885.13a9159ce46.Coremail.zheng_huabin@163.com> I am trying to use lxc in product environment? but i can not limit the guest's network bandwidth. I followed the list instructions, but it does take effect. How do you limit the guest's network bandwidth? # tc qdisc add dev virbr0 root handle 10: htb # tc filter add dev virbr0 parent 10: protocol ip prio 10 handle 1: cgroup # tc class add dev virbr0 parent 10: classid 10:1 htb rate 24Mbit # echo 0x100001 > /cgroup/c/net_cls.classid ? 2012-10-24 00:38:47?"St?phane Graber" ??? >On 10/23/2012 12:29 AM, Ulli Horlacher wrote: >> On Mon 2012-10-22 (14:53), St?phane Graber wrote: >> >>> All in all, that's somewhere around 300-400 containers I'm managing >> >> How do you handle a host (hardware) failure? > >Everything that runs in the container is in a configuration management >system, so any container can be redeployed from scratch in just a couple >of minutes without needing the actual rootfs. > >On top of that, all the containers are backed up centrally using data >deduplication, so if I really need it, I can extract a .tar.gz of the >rootfs of any container in minutes and then just dump that on another >machine. > >Though technically all the critical services are already redundant, so >in case of a host failure, all I'd see is an increase of load on the >other servers while I fix the host and get the rest back online. > >-- >St?phane Graber >Ubuntu developer >http://www.ubuntu.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuanmingyi at gmail.com Thu Oct 25 09:11:13 2012 From: xuanmingyi at gmail.com (=?GB2312?B?0PvD+tLV?=) Date: Thu, 25 Oct 2012 17:11:13 +0800 Subject: [Lxc-users] how to limit disk space in lxc Message-ID: Dear all: The problem is that,how can we limit the disk space in lxc.Now I use the default config. And the container can access all space in host.can we use lvm or other tools to limit it? And how :) Thanks ?? -- ???: http://www.xuanmingyi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Thu Oct 25 09:19:47 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Thu, 25 Oct 2012 16:19:47 +0700 Subject: [Lxc-users] how to limit disk space in lxc In-Reply-To: References: Message-ID: On Thu, Oct 25, 2012 at 4:11 PM, ??? wrote: > Dear all: > The problem is that,how can we limit the disk space in lxc.Now I use the > default config. > And the container can access all space in host.can we use lvm or other tools > to limit it? > And how :) simplest solution: place the container rootfs in an LV. You need to create and format the LV and move the rootfs MANUALLY after the container is created though, as AFAIK no template has the ability to "create a rootfs in an LV of this size". -- Fajar From serge.hallyn at canonical.com Thu Oct 25 14:07:42 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 25 Oct 2012 09:07:42 -0500 Subject: [Lxc-users] how to limit disk space in lxc In-Reply-To: References: Message-ID: <20121025140742.GA11596@sergelap> Quoting Fajar A. Nugraha (list at fajar.net): > On Thu, Oct 25, 2012 at 4:11 PM, ??? wrote: > > Dear all: > > The problem is that,how can we limit the disk space in lxc.Now I use the > > default config. > > And the container can access all space in host.can we use lvm or other tools > > to limit it? > > And how :) > > simplest solution: place the container rootfs in an LV. > > You need to create and format the LV and move the rootfs MANUALLY > after the container is created though, as AFAIK no template has the > ability to "create a rootfs in an LV of this size". -B option to lxc-create specifies the backing store type. sudo lxc-create -t ubuntu -B lvm -n u1 will default to 500M rootfs with ext4, or sudo lxc-create -t ubuntu -B lvm -n u1 --fssize 2G --fstype xfs -serge From list at fajar.net Thu Oct 25 14:42:02 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Thu, 25 Oct 2012 21:42:02 +0700 Subject: [Lxc-users] how to limit disk space in lxc In-Reply-To: <20121025140742.GA11596@sergelap> References: <20121025140742.GA11596@sergelap> Message-ID: On Thu, Oct 25, 2012 at 9:07 PM, Serge Hallyn wrote: > Quoting Fajar A. Nugraha (list at fajar.net): >> On Thu, Oct 25, 2012 at 4:11 PM, ??? wrote: >> > Dear all: >> > The problem is that,how can we limit the disk space in lxc.Now I use the >> > default config. >> > And the container can access all space in host.can we use lvm or other tools >> > to limit it? >> > And how :) >> >> simplest solution: place the container rootfs in an LV. >> >> You need to create and format the LV and move the rootfs MANUALLY >> after the container is created though, as AFAIK no template has the >> ability to "create a rootfs in an LV of this size". > > -B option to lxc-create specifies the backing store type. > > sudo lxc-create -t ubuntu -B lvm -n u1 > > will default to 500M rootfs with ext4, or > > sudo lxc-create -t ubuntu -B lvm -n u1 --fssize 2G --fstype xfs > Ah, thanks for pointing that out. I was (mistakenly) looking at the template (/usr/share/lxc/templates/lxc-ubuntu --help), while in fact the option belongs to lxc-create. -- Fajar From mhw at WittsEnd.com Thu Oct 25 15:59:10 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 11:59:10 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1350939562.1481.43.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> Message-ID: <1351180750.5181.42.camel@canyon.wittsend.com> Sorry for taking a few days to get back on this. I was delivering a guest lecture up at Fordham University last Tuesday so I was out of pocket a couple of days or I would have responded sooner... On Mon, 2012-10-22 at 16:59 -0400, Michael H. Warfield wrote: > On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: > > On Mon, 22.10.12 11:48, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > > To summarize the problem... The LXC startup binary sets up various > > > > > things for /dev and /dev/pts for the container to run properly and this > > > > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > > > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > > > > on /dev/pts which then break things horribly. This is because the > > > > > kernel currently lacks namespaces for devices and won't for some time to > > > > > come (in design). When devtmpfs gets mounted over top of /dev in the > > > > > container, it then hijacks the hosts console tty and several other > > > > > devices which had been set up through bind mounts by LXC and should have > > > > > been LEFT ALONE. > > > > > > > Please initialize a minimal tmpfs on /dev. systemd will then work fine. > > > > > > My containers have a reasonable /dev that work with Upstart just fine > > > but they are not on tmpfs. Is mounting tmpfs on /dev and recreating > > > that minimal /dev required? > > Well, it can be any kind of mount really. Just needs to be a mount. And > > the idea is to use tmpfs for this. > > What /dev are you currently using? It's probably not a good idea to > > reuse the hosts' /dev, since it contains so many device nodes that > > should not be accessible/visible to the container. > Got it. And that explains the problems we're seeing but also what I'm > seeing in some libvirt-lxc related pages, which is a separate and > distinct project in spite of the similarities in the name... > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > Unfortunately, in our case, merely getting a mount in there is a > complication in that it also has to be populated but, at least, we > understand the problem set now. Ok... Serge and I were corresponding on the lxc-users list and he had a suggestion that worked but I consider to be a bit of a sub-optimal workaround. Ironically, it was to mount devtmpfs on /dev. We don't (currently) have a method to auto-populate a tmpfs mount with the needed devices and this provided it. It does have a problem that makes me uncomfortable in that the container now has visibility into the hosts /dev system. I'm a security expert and I'm not comfortable with that "solution" even with the controls we have. We can control access but still, not happy with that. I now have a container that starts with systemd running more or less properly. We do have some problems with the convention that has been set up, however. When running in this mode, you run on the console and you don't spawn getty's on the tty's. There seems to be a problem with this. In this mode, if I manually start the container in a terminal window, that eventually results in a login prompt there. Under sysvinit and upstart I don't get that and can detach. If I run lxc-console (which attaches to one of the vtys) it gives me nothing. Under sysvinit and upstart I get vty login prompts because they have started getty on those vtys. This is important in case network access has not started for one reason or another and the container was started detached in the background. If I start lxc-start in detached mode (-d -o {logfile}) lxc-start redirects the system console to the log file and goes daemon. In this case, the systemd container hangs and never starts. I SUSPECT the hang condition is something to do with systemd trying to start and interactive console on /dev/console, which sysvinit and upstart do not do. Maybe we have to do something different with the redirects in this case, but it's not working consistent with the other packages. We should also start appropriate gettys on those vtys if they are configured. Maybe start the getty's if the tty? exists up to a configured limit (and don't restart if they immediately fail) and obviously don't start them if they don't. It then gives up control over that process. Also don't start a login on /dev/console if you DO start a getty? That would make your behavior congruent with that of the other two systems. I've got some more problems relating to shutting down containers, some of which may be related to mounting tmpfs on /run to which /var/run is symlinked to. We're doing halt / restart detection by monitoring utmp in that directory but it looks like utmp isn't even in that directory anymore and mounting tmpfs on it was always problematical. We may have to have a more generic method to detect when a container has shut down or is restarting in that case. I'm also finding we end up with dangling resources where we can't remove to cgroup directories after a halt and that creates a serious problem I have to investigate further. Not sure if it's a host problem running on F17 or it something to do with running systemd in a container but I can not shut down this particular container and subsequently restart it without restarting the entire host. Not good is an understatement. Regards, Mike > > > > systemd will make use of pre-existing mounts if they exist, and only > > > > mount something new if they don't exist. > > > > > > So you're saying that, if we have something mounted on /dev, that's what > > > prevents systemd from mounting devtmpfs on /dev? > > > Yes. > > > > But, I have systemd running on my host system (F17) and containers with > > > sysvinit or upstart inits are all starting just fine. That sounds like > > > it should impact all containers as pivot_root() is issued before systemd > > > in the container is started. Or am I missing something here? That > > > sounds like a problem for Serge and others to investigate further. I'll > > > see about trying that workaround though. > > > The "shared" issue is F18, and it's about running LXC on a systemd > > system, not about running systemd inside of LXC. > > Whew! I'll deal with F18 when I need to deal with F18. That explains > why my F17 hosts are running and gives Serge and others a chance to > address this, forewarned. Thanks for that info. > > > Lennart > > > -- > > Lennart Poettering - Red Hat, Inc. > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Thu Oct 25 16:19:54 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 25 Oct 2012 11:19:54 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351180750.5181.42.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> Message-ID: <20121025161954.GA31702@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > Sorry for taking a few days to get back on this. I was delivering a > guest lecture up at Fordham University last Tuesday so I was out of > pocket a couple of days or I would have responded sooner... > > On Mon, 2012-10-22 at 16:59 -0400, Michael H. Warfield wrote: > > On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: > > > On Mon, 22.10.12 11:48, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > > > > To summarize the problem... The LXC startup binary sets up various > > > > > > things for /dev and /dev/pts for the container to run properly and this > > > > > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > > > > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > > > > > on /dev/pts which then break things horribly. This is because the > > > > > > kernel currently lacks namespaces for devices and won't for some time to > > > > > > come (in design). When devtmpfs gets mounted over top of /dev in the > > > > > > container, it then hijacks the hosts console tty and several other > > > > > > devices which had been set up through bind mounts by LXC and should have > > > > > > been LEFT ALONE. > > > > > > > > > Please initialize a minimal tmpfs on /dev. systemd will then work fine. > > > > > > > > My containers have a reasonable /dev that work with Upstart just fine > > > > but they are not on tmpfs. Is mounting tmpfs on /dev and recreating > > > > that minimal /dev required? > > > > Well, it can be any kind of mount really. Just needs to be a mount. And > > > the idea is to use tmpfs for this. > > > > What /dev are you currently using? It's probably not a good idea to > > > reuse the hosts' /dev, since it contains so many device nodes that > > > should not be accessible/visible to the container. > > > Got it. And that explains the problems we're seeing but also what I'm > > seeing in some libvirt-lxc related pages, which is a separate and > > distinct project in spite of the similarities in the name... > > > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > > > Unfortunately, in our case, merely getting a mount in there is a > > complication in that it also has to be populated but, at least, we > > understand the problem set now. > > Ok... Serge and I were corresponding on the lxc-users list and he had a > suggestion that worked but I consider to be a bit of a sub-optimal > workaround. Ironically, it was to mount devtmpfs on /dev. We don't Oh, sorry - I take back that suggestion :) Note that we have mount hooks, so templates could install a mount hook to mount a tmpfs onto /dev and populate it. Or, if everyone is going to need it, we could just add a 'lxc.populatedevs = 1' option which does that without needing a hook. devtmpfs should not be used in containers :) -serge From mhw at WittsEnd.com Thu Oct 25 16:39:12 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 12:39:12 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025161954.GA31702@sergelap> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> Message-ID: <1351183152.5181.46.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > Sorry for taking a few days to get back on this. I was delivering a > > guest lecture up at Fordham University last Tuesday so I was out of > > pocket a couple of days or I would have responded sooner... > > > > On Mon, 2012-10-22 at 16:59 -0400, Michael H. Warfield wrote: > > > On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: > > > > On Mon, 22.10.12 11:48, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > > > > > > To summarize the problem... The LXC startup binary sets up various > > > > > > > things for /dev and /dev/pts for the container to run properly and this > > > > > > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > > > > > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > > > > > > on /dev/pts which then break things horribly. This is because the > > > > > > > kernel currently lacks namespaces for devices and won't for some time to > > > > > > > come (in design). When devtmpfs gets mounted over top of /dev in the > > > > > > > container, it then hijacks the hosts console tty and several other > > > > > > > devices which had been set up through bind mounts by LXC and should have > > > > > > > been LEFT ALONE. > > > > > > > > > > > Please initialize a minimal tmpfs on /dev. systemd will then work fine. > > > > > > > > > > My containers have a reasonable /dev that work with Upstart just fine > > > > > but they are not on tmpfs. Is mounting tmpfs on /dev and recreating > > > > > that minimal /dev required? > > > > > > Well, it can be any kind of mount really. Just needs to be a mount. And > > > > the idea is to use tmpfs for this. > > > > > > What /dev are you currently using? It's probably not a good idea to > > > > reuse the hosts' /dev, since it contains so many device nodes that > > > > should not be accessible/visible to the container. > > > > > Got it. And that explains the problems we're seeing but also what I'm > > > seeing in some libvirt-lxc related pages, which is a separate and > > > distinct project in spite of the similarities in the name... > > > > > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > > > > > Unfortunately, in our case, merely getting a mount in there is a > > > complication in that it also has to be populated but, at least, we > > > understand the problem set now. > > > > Ok... Serge and I were corresponding on the lxc-users list and he had a > > suggestion that worked but I consider to be a bit of a sub-optimal > > workaround. Ironically, it was to mount devtmpfs on /dev. We don't > Oh, sorry - I take back that suggestion :) Well, it worked (sort of) and reinforced what the problem was and where the solution lay so there's no need to be sorry for it. We learned and we know why it's not the right solution. This is good. We made a lot of progress on this just in the last week. This is very good. > Note that we have mount hooks, so templates could install a mount hook to > mount a tmpfs onto /dev and populate it. Ah, now that is interesting. I haven't looked at that before. I need to explore that further. > Or, if everyone is going to need it, we could just add a 'lxc.populatedevs = 1' > option which does that without needing a hook. Eventually, with Fedora (and later RHEL / CentOS / SL), Arch Linux, and others going to systemd, I think this is going to be needed sooner than later. > devtmpfs should not be used in containers :) Concur! > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Thu Oct 25 17:23:32 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 13:23:32 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025161954.GA31702@sergelap> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> Message-ID: <1351185812.5181.49.camel@canyon.wittsend.com> Hey Serge, On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > Sorry for taking a few days to get back on this. I was delivering a > > guest lecture up at Fordham University last Tuesday so I was out of > > pocket a couple of days or I would have responded sooner... > > > > On Mon, 2012-10-22 at 16:59 -0400, Michael H. Warfield wrote: > > > On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: > > > > On Mon, 22.10.12 11:48, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > > > > > > To summarize the problem... The LXC startup binary sets up various > > > > > > > things for /dev and /dev/pts for the container to run properly and this > > > > > > > works perfectly fine for SystemV start-up scripts and/or Upstart. > > > > > > > Unfortunately, systemd has mounts of devtmpfs on /dev and devpts > > > > > > > on /dev/pts which then break things horribly. This is because the > > > > > > > kernel currently lacks namespaces for devices and won't for some time to > > > > > > > come (in design). When devtmpfs gets mounted over top of /dev in the > > > > > > > container, it then hijacks the hosts console tty and several other > > > > > > > devices which had been set up through bind mounts by LXC and should have > > > > > > > been LEFT ALONE. > > > > > > > > > > > Please initialize a minimal tmpfs on /dev. systemd will then work fine. > > > > > > > > > > My containers have a reasonable /dev that work with Upstart just fine > > > > > but they are not on tmpfs. Is mounting tmpfs on /dev and recreating > > > > > that minimal /dev required? > > > > > > Well, it can be any kind of mount really. Just needs to be a mount. And > > > > the idea is to use tmpfs for this. > > > > > > What /dev are you currently using? It's probably not a good idea to > > > > reuse the hosts' /dev, since it contains so many device nodes that > > > > should not be accessible/visible to the container. > > > > > Got it. And that explains the problems we're seeing but also what I'm > > > seeing in some libvirt-lxc related pages, which is a separate and > > > distinct project in spite of the similarities in the name... > > > > > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > > > > > Unfortunately, in our case, merely getting a mount in there is a > > > complication in that it also has to be populated but, at least, we > > > understand the problem set now. > > > > Ok... Serge and I were corresponding on the lxc-users list and he had a > > suggestion that worked but I consider to be a bit of a sub-optimal > > workaround. Ironically, it was to mount devtmpfs on /dev. We don't > Oh, sorry - I take back that suggestion :) > Note that we have mount hooks, so templates could install a mount hook to > mount a tmpfs onto /dev and populate it. Ok... I've done some cursory search and turned up nothing but some comments about "pre mount hooks". Where is the documentation about this feature and how I might use / implement it? Some examples would probably suffice. Is there a require release version of lxc-utils? > Or, if everyone is going to need it, we could just add a 'lxc.populatedevs = 1' > option which does that without needing a hook. > devtmpfs should not be used in containers :) > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Thu Oct 25 17:35:11 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 13:35:11 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351185812.5181.49.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> Message-ID: <1351186511.5181.51.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > Hey Serge, > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: ... > > Oh, sorry - I take back that suggestion :) > > > Note that we have mount hooks, so templates could install a mount hook to > > mount a tmpfs onto /dev and populate it. > > Ok... I've done some cursory search and turned up nothing but some > comments about "pre mount hooks". Where is the documentation about this > feature and how I might use / implement it? Some examples would > probably suffice. Is there a require release version of lxc-utils? I think I found what I needed in the changelog here: http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html I'll play with it and report back. > > Or, if everyone is going to need it, we could just add a 'lxc.populatedevs = 1' > > option which does that without needing a hook. > > > devtmpfs should not be used in containers :) > > > -serge > > Regards, > Mike > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ Lxc-users mailing list Lxc-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Thu Oct 25 19:02:21 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 25 Oct 2012 14:02:21 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351186511.5181.51.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> Message-ID: <20121025190221.GA11683@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > Hey Serge, > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > ... > > > > Oh, sorry - I take back that suggestion :) > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > mount a tmpfs onto /dev and populate it. > > > > Ok... I've done some cursory search and turned up nothing but some > > comments about "pre mount hooks". Where is the documentation about this > > feature and how I might use / implement it? Some examples would > > probably suffice. Is there a require release version of lxc-utils? > > I think I found what I needed in the changelog here: > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > I'll play with it and report back. Also the "Lifecycle management hooks" section in https://help.ubuntu.com/12.10/serverguide/lxc.html Note that I'm thinking that having lxc-start guess how to fill in /dev is wrong, because different distros and even different releases of the same distros have different expectations. For instance ubuntu lucid wants /dev/shm to be a directory, while precise+ wants a symlink. So somehow the template should get involved, be it by adding a hook, or simply specifying a configuration file which lxc uses internally to decide how to create /dev. Personally I'd prefer if /dev were always populated by the templates, and containers (i.e. userspace) didn't mount a fresh tmpfs for /dev. But that does complicate userspace, and we've seen it in debian/ubuntu as well (i.e. at certain package upgrades which rely on /dev being cleared after a reboot). -serge From mhw at WittsEnd.com Thu Oct 25 19:42:54 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 15:42:54 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025190221.GA11683@sergelap> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> Message-ID: <1351194174.5181.55.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > Hey Serge, > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > ... > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > mount a tmpfs onto /dev and populate it. > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > comments about "pre mount hooks". Where is the documentation about this > > > feature and how I might use / implement it? Some examples would > > > probably suffice. Is there a require release version of lxc-utils? > > > > I think I found what I needed in the changelog here: > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > I'll play with it and report back. > Also the "Lifecycle management hooks" section in > https://help.ubuntu.com/12.10/serverguide/lxc.html This isn't working... Based on what was in both of those articles, I added this entry to another container (Plover) to test... lxc.hook.mount = /var/lib/lxc/Plover/mount When I run "lxc-start -n Plover", I see this: [root at forest ~]# lxc-start -n Plover lxc-start: unknow key lxc.hook.mount lxc-start: failed to read configuration file I'm running the latest rc... [root at forest ~]# rpm -qa | grep lxc lxc-0.8.0.rc2-1.fc16.x86_64 lxc-libs-0.8.0.rc2-1.fc16.x86_64 lxc-doc-0.8.0.rc2-1.fc16.x86_64 Is it something in git that hasn't made it to a release yet? > Note that I'm thinking that having lxc-start guess how to fill in /dev > is wrong, because different distros and even different releases of the > same distros have different expectations. For instance ubuntu lucid > wants /dev/shm to be a directory, while precise+ wants a symlink. So > somehow the template should get involved, be it by adding a hook, or > simply specifying a configuration file which lxc uses internally to > decide how to create /dev. I agree this needs to be by some sort of convention or template that we can adjust. > Personally I'd prefer if /dev were always populated by the templates, > and containers (i.e. userspace) didn't mount a fresh tmpfs for /dev. > But that does complicate userspace, and we've seen it in debian/ubuntu > as well (i.e. at certain package upgrades which rely on /dev being > cleared after a reboot). > > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 00:03:46 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 20:03:46 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025213806.GA25835@tango.0pointer.de> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> Message-ID: <1351209826.5181.59.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > I've got some more problems relating to shutting down containers, some > > of which may be related to mounting tmpfs on /run to which /var/run is > > symlinked to. We're doing halt / restart detection by monitoring utmp > > in that directory but it looks like utmp isn't even in that directory > > anymore and mounting tmpfs on it was always problematical. We may have > > to have a more generic method to detect when a container has shut down > > or is restarting in that case. > I can't parse this. The system call reboot() is virtualized for > containers just fine and the container managaer (i.e. LXC) can check for > that easily. The problem we have had was with differentiating between reboot and halt to either shut the container down cold or restarted it. You say "easily" and yet we never came up with an "easy" solution and monitored utmp instead for the next runlevel change. What is your "easy" solution for that problem? > Lennart > -- > Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Fri Oct 26 01:30:48 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Thu, 25 Oct 2012 20:30:48 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351209826.5181.59.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351209826.5181.59.camel@canyon.wittsend.com> Message-ID: <20121026013048.GA5056@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > I've got some more problems relating to shutting down containers, some > > > of which may be related to mounting tmpfs on /run to which /var/run is > > > symlinked to. We're doing halt / restart detection by monitoring utmp > > > in that directory but it looks like utmp isn't even in that directory > > > anymore and mounting tmpfs on it was always problematical. We may have > > > to have a more generic method to detect when a container has shut down > > > or is restarting in that case. > > > I can't parse this. The system call reboot() is virtualized for > > containers just fine and the container managaer (i.e. LXC) can check for > > that easily. > > The problem we have had was with differentiating between reboot and halt > to either shut the container down cold or restarted it. You say > "easily" and yet we never came up with an "easy" solution and monitored > utmp instead for the next runlevel change. What is your "easy" solution > for that problem? I think you're on older kernels, where we had to resort to that. Pretty recently Daniel Lezcano's patch was finally accepted upstream, which lets a container call reboot() and lets the parent of init tell whether it called reboot or shutdown by looking at wTERMSIG(status). -serge From mhw at WittsEnd.com Fri Oct 26 02:07:37 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 22:07:37 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121026013048.GA5056@sergelap> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351209826.5181.59.camel@canyon.wittsend.com> <20121026013048.GA5056@sergelap> Message-ID: <1351217257.5181.60.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 20:30 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > > > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > I've got some more problems relating to shutting down containers, some > > > > of which may be related to mounting tmpfs on /run to which /var/run is > > > > symlinked to. We're doing halt / restart detection by monitoring utmp > > > > in that directory but it looks like utmp isn't even in that directory > > > > anymore and mounting tmpfs on it was always problematical. We may have > > > > to have a more generic method to detect when a container has shut down > > > > or is restarting in that case. > > > > > I can't parse this. The system call reboot() is virtualized for > > > containers just fine and the container managaer (i.e. LXC) can check for > > > that easily. > > > > The problem we have had was with differentiating between reboot and halt > > to either shut the container down cold or restarted it. You say > > "easily" and yet we never came up with an "easy" solution and monitored > > utmp instead for the next runlevel change. What is your "easy" solution > > for that problem? > I think you're on older kernels, where we had to resort to that. Pretty > recently Daniel Lezcano's patch was finally accepted upstream, which lets > a container call reboot() and lets the parent of init tell whether it > called reboot or shutdown by looking at wTERMSIG(status). Now THAT is wonderful news! I hadn't realized that had been accepted. So we no longer need to rely on the old utmp kludge? > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 02:59:26 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Thu, 25 Oct 2012 22:59:26 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351194174.5181.55.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> Message-ID: <1351220366.5181.63.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: > On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > > Hey Serge, > > > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > > > ... > > > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > > mount a tmpfs onto /dev and populate it. > > > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > comments about "pre mount hooks". Where is the documentation about this > > > > feature and how I might use / implement it? Some examples would > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > I think I found what I needed in the changelog here: > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > I'll play with it and report back. > > > Also the "Lifecycle management hooks" section in > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > This isn't working... > > Based on what was in both of those articles, I added this entry to > another container (Plover) to test... > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > When I run "lxc-start -n Plover", I see this: > > [root at forest ~]# lxc-start -n Plover > lxc-start: unknow key lxc.hook.mount > lxc-start: failed to read configuration file > > I'm running the latest rc... > > [root at forest ~]# rpm -qa | grep lxc > lxc-0.8.0.rc2-1.fc16.x86_64 > lxc-libs-0.8.0.rc2-1.fc16.x86_64 > lxc-doc-0.8.0.rc2-1.fc16.x86_64 > > Is it something in git that hasn't made it to a release yet? nm... I see it. It's in git and hasn't made it to a release. I'm working on a git build to test now. If this is something that solves some of this, we need to move things along here and get these things moved out. According to git, 0.8.0rc2 was 7 months ago? What's the show stoppers here? > > Note that I'm thinking that having lxc-start guess how to fill in /dev > > is wrong, because different distros and even different releases of the > > same distros have different expectations. For instance ubuntu lucid > > wants /dev/shm to be a directory, while precise+ wants a symlink. So > > somehow the template should get involved, be it by adding a hook, or > > simply specifying a configuration file which lxc uses internally to > > decide how to create /dev. > I agree this needs to be by some sort of convention or template that we > can adjust. > > > Personally I'd prefer if /dev were always populated by the templates, > > and containers (i.e. userspace) didn't mount a fresh tmpfs for /dev. > > But that does complicate userspace, and we've seen it in debian/ubuntu > > as well (i.e. at certain package upgrades which rely on /dev being > > cleared after a reboot). > > > > -serge > > Regards, > Mike Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Fri Oct 26 13:12:35 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 26 Oct 2012 08:12:35 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351217257.5181.60.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351209826.5181.59.camel@canyon.wittsend.com> <20121026013048.GA5056@sergelap> <1351217257.5181.60.camel@canyon.wittsend.com> Message-ID: <20121026131235.GA6047@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Thu, 2012-10-25 at 20:30 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > > > > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > > > > I've got some more problems relating to shutting down containers, some > > > > > of which may be related to mounting tmpfs on /run to which /var/run is > > > > > symlinked to. We're doing halt / restart detection by monitoring utmp > > > > > in that directory but it looks like utmp isn't even in that directory > > > > > anymore and mounting tmpfs on it was always problematical. We may have > > > > > to have a more generic method to detect when a container has shut down > > > > > or is restarting in that case. > > > > > > > I can't parse this. The system call reboot() is virtualized for > > > > containers just fine and the container managaer (i.e. LXC) can check for > > > > that easily. > > > > > > The problem we have had was with differentiating between reboot and halt > > > to either shut the container down cold or restarted it. You say > > > "easily" and yet we never came up with an "easy" solution and monitored > > > utmp instead for the next runlevel change. What is your "easy" solution > > > for that problem? > > > I think you're on older kernels, where we had to resort to that. Pretty > > recently Daniel Lezcano's patch was finally accepted upstream, which lets > > a container call reboot() and lets the parent of init tell whether it > > called reboot or shutdown by looking at wTERMSIG(status). > > Now THAT is wonderful news! I hadn't realized that had been accepted. > So we no longer need to rely on the old utmp kludge? Yup :) It was very liberating, in terms of what containers can do with mounting. From mhw at WittsEnd.com Fri Oct 26 13:32:17 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 09:32:17 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351220366.5181.63.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> Message-ID: <1351258337.5181.68.camel@canyon.wittsend.com> Adding in the lxc-devel list. On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: > On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: > > On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > > > Hey Serge, > > > > > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > > > > > ... > > > > > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > > > mount a tmpfs onto /dev and populate it. > > > > > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > > comments about "pre mount hooks". Where is the documentation about this > > > > > feature and how I might use / implement it? Some examples would > > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > > > I think I found what I needed in the changelog here: > > > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > > > I'll play with it and report back. > > > > > Also the "Lifecycle management hooks" section in > > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > > > This isn't working... > > > > Based on what was in both of those articles, I added this entry to > > another container (Plover) to test... > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > When I run "lxc-start -n Plover", I see this: > > > > [root at forest ~]# lxc-start -n Plover > > lxc-start: unknow key lxc.hook.mount > > lxc-start: failed to read configuration file > > > > I'm running the latest rc... > > > > [root at forest ~]# rpm -qa | grep lxc > > lxc-0.8.0.rc2-1.fc16.x86_64 > > lxc-libs-0.8.0.rc2-1.fc16.x86_64 > > lxc-doc-0.8.0.rc2-1.fc16.x86_64 > > > > Is it something in git that hasn't made it to a release yet? > nm... I see it. It's in git and hasn't made it to a release. I'm > working on a git build to test now. If this is something that solves > some of this, we need to move things along here and get these things > moved out. According to git, 0.8.0rc2 was 7 months ago? What's the > show stoppers here? While the git repo says 7 months ago, the date stamp on the lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. Sounds like we've accumulated some features (like the hooks) we are going to need like months ago to deal with this systemd debacle. How close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just waiting on some more features? > > > Note that I'm thinking that having lxc-start guess how to fill in /dev > > > is wrong, because different distros and even different releases of the > > > same distros have different expectations. For instance ubuntu lucid > > > wants /dev/shm to be a directory, while precise+ wants a symlink. So > > > somehow the template should get involved, be it by adding a hook, or > > > simply specifying a configuration file which lxc uses internally to > > > decide how to create /dev. > > > I agree this needs to be by some sort of convention or template that we > > can adjust. > > > > > Personally I'd prefer if /dev were always populated by the templates, > > > and containers (i.e. userspace) didn't mount a fresh tmpfs for /dev. > > > But that does complicate userspace, and we've seen it in debian/ubuntu > > > as well (i.e. at certain package upgrades which rely on /dev being > > > cleared after a reboot). > > > > > > -serge > > > > Regards, > > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Fri Oct 26 13:38:22 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 26 Oct 2012 08:38:22 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025214528.GB25835@tango.0pointer.de> References: <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <20121025214528.GB25835@tango.0pointer.de> Message-ID: <20121026133822.GA16957@sergelap> Quoting Lennart Poettering (lennart at poettering.net): > On Thu, 25.10.12 14:02, Serge Hallyn (serge.hallyn at canonical.com) wrote: > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > comments about "pre mount hooks". Where is the documentation about this > > > > feature and how I might use / implement it? Some examples would > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > I think I found what I needed in the changelog here: > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > I'll play with it and report back. > > > > Also the "Lifecycle management hooks" section in > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > > > Note that I'm thinking that having lxc-start guess how to fill in /dev > > is wrong, because different distros and even different releases of the > > same distros have different expectations. For instance ubuntu lucid > > wants /dev/shm to be a directory, while precise+ wants a symlink. So > > somehow the template should get involved, be it by adding a hook, or > > simply specifying a configuration file which lxc uses internally to > > decide how to create /dev. > > /dev/shm can be created/mounted/symlinked by the OS in the > container. This is nothing LXC should care about. > > My recommendation for LXC would be to unconditionally pre-mount /dev as > tmpfs, and add exactly the device nodes /dev/null, /dev/zero, /dev/full, > /dev/urandom, /dev/random, /dev/tty, /dev/ptmx to it. That is the > minimal set you need to boot a machine. All further > submounts/symlinks/dirs can be created by the OS boot logic in the > container. I'm thinking we'll do that, optionally. Templates (including fedora and ubuntu) can simply always set the option to mount and fill /dev. Others (like busybox and mini-sshd) won't. > That's what libvirt-lxc and nspawn do, and is what we defined in: > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > It would be good if LXC would do the same in order to minimize the > manual user configuration necessary. > > Lennart Agreed it simplifies things for full system containers with modern distros. thanks, -serge From serge.hallyn at canonical.com Fri Oct 26 14:07:28 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Fri, 26 Oct 2012 09:07:28 -0500 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351258337.5181.68.camel@canyon.wittsend.com> References: <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> Message-ID: <20121026140728.GA23975@sergelap> Quoting Michael H. Warfield (mhw at WittsEnd.com): > Adding in the lxc-devel list. > > On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: > > On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: > > > On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > > > > Hey Serge, > > > > > > > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > > > > > > > ... > > > > > > > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > > > > mount a tmpfs onto /dev and populate it. > > > > > > > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > > > comments about "pre mount hooks". Where is the documentation about this > > > > > > feature and how I might use / implement it? Some examples would > > > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > > > > > I think I found what I needed in the changelog here: > > > > > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > > > > > I'll play with it and report back. > > > > > > > Also the "Lifecycle management hooks" section in > > > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > > > > > This isn't working... > > > > > > Based on what was in both of those articles, I added this entry to > > > another container (Plover) to test... > > > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > When I run "lxc-start -n Plover", I see this: > > > > > > [root at forest ~]# lxc-start -n Plover > > > lxc-start: unknow key lxc.hook.mount > > > lxc-start: failed to read configuration file > > > > > > I'm running the latest rc... > > > > > > [root at forest ~]# rpm -qa | grep lxc > > > lxc-0.8.0.rc2-1.fc16.x86_64 > > > lxc-libs-0.8.0.rc2-1.fc16.x86_64 > > > lxc-doc-0.8.0.rc2-1.fc16.x86_64 > > > > > > Is it something in git that hasn't made it to a release yet? > > > nm... I see it. It's in git and hasn't made it to a release. I'm > > working on a git build to test now. If this is something that solves > > some of this, we need to move things along here and get these things > > moved out. According to git, 0.8.0rc2 was 7 months ago? What's the > > show stoppers here? > > While the git repo says 7 months ago, the date stamp on the > lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. > Sounds like we've accumulated some features (like the hooks) we are > going to need like months ago to deal with this systemd debacle. How > close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just > waiting on some more features? Daniel has simply been too busy. St?phane has made a new branch which cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) From mhw at WittsEnd.com Fri Oct 26 14:58:25 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 10:58:25 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121026140728.GA23975@sergelap> References: <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <20121026140728.GA23975@sergelap> Message-ID: <1351263505.5181.101.camel@canyon.wittsend.com> On Fri, 2012-10-26 at 09:07 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > nm... I see it. It's in git and hasn't made it to a release. I'm > > > working on a git build to test now. If this is something that solves > > > some of this, we need to move things along here and get these things > > > moved out. According to git, 0.8.0rc2 was 7 months ago? What's the > > > show stoppers here? > > > > While the git repo says 7 months ago, the date stamp on the > > lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. > > Sounds like we've accumulated some features (like the hooks) we are > > going to need like months ago to deal with this systemd debacle. How > > close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just > > waiting on some more features? > Daniel has simply been too busy. Don't I know THAT feeling all too well. Over on the Samba Team (where I'm the chief security consultant on the team) we're all too busy with juggling our domain and our web cert. On top of that, I've got my day job (of course). On top of that, I've got about six other OpenSource projects I'm juggling (including this one). On top of that, I've got a consulting customer that's going through fits. And the beat goes on. I'll test out things as fast as I can. I need this. This suddenly got very interesting as soon as we had a thread to pick at on the systemd ball of yarn. > St?phane has made a new branch which > cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about > twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) I'm hoping the hook patches are in that cherry picked basket. We really need them if that's what it takes to make this work. Looking forward to it. :-)=) I'm going to look further into this whole redirect /dev/console to a log hang thing. That's not good and may need to be resolved soon as well. I can live with losing the vty's although I disagree with St?phan's arguments. They (systemd) are behaving significantly different from sysvinit and upstart and they claim they want to be transparent? Not. No matter. We need to make that work properly as well, agree with them or disagree with them. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 15:58:33 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 11:58:33 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025213806.GA25835@tango.0pointer.de> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> Message-ID: <1351267113.5181.105.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > > > > > Unfortunately, in our case, merely getting a mount in there is a > > > complication in that it also has to be populated but, at least, we > > > understand the problem set now. > > > > Ok... Serge and I were corresponding on the lxc-users list and he had a > > suggestion that worked but I consider to be a bit of a sub-optimal > > workaround. Ironically, it was to mount devtmpfs on /dev. We don't > > (currently) have a method to auto-populate a tmpfs mount with the needed > > devices and this provided it. It does have a problem that makes me > > uncomfortable in that the container now has visibility into the > > hosts /dev system. I'm a security expert and I'm not comfortable with > > that "solution" even with the controls we have. We can control access > > but still, not happy with that. > That's a pretty bad idea, access control to the device nodes in devtmpfs > is controlled by the host's udev instance. That means if your group/user > lists in the container and the host differ you already lost. Also access > control in udev is dynamic, due to stuff like uaccess and similar. You > really don't want to to have that into the container, i.e. where device > change ownership all the time with UIDs/GIDs that make no sense at all > in the container. Concur. > In general I think it's a good idea not to expose any "real" devices to > the container, but only the "virtual" ones that are programming > APIs. That means: no /dev/sda, or /dev/ttyS0, but /dev/null, /dev/zero, > /dev/random, /dev/urandom. And creating the latter in a tmpfs is quite > simple. > > If I run lxc-console (which attaches to one of the vtys) it gives me > > nothing. Under sysvinit and upstart I get vty login prompts because > > they have started getty on those vtys. This is important in case > > network access has not started for one reason or another and the > > container was started detached in the background. > The getty behaviour of systemd in containers is documented here: > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface Sorry. This is unacceptable. We need some way that these will be active and you will be consistent with other containers. > If LXC mounts ptys on top of the VT devices that's a really bad idea > too, since /dev/tty1 and friends expose a number of APIs beyond the mere > tty device that you cannot emulate with that. It includes files in /sys, > as well as /dev/vcs and /dev/vcsa, various ioctls, and so on. Heck, even > the most superficial of things, the $TERM variable will be > incorrect. LXC shouldn't do that. REGARDLESS. I'm in this situation now testing what I thought was a hang condition (which is proving to be something else). I started a container detached redirecting the console to a file (a parameter I was missing) and the log to another file (which I had been doing). But, for some reason, sshd is not starting up. I have no way to attach to the bloody console of the container and I have no getty's on a vty I can attach to using lxc-console and I can't remote access a container which, for all other intents and purposes, appears to be running fine. Parameterize this bloody thing so we can have control over it. > LXC really shouldn't pretent a pty was a VT tty, it's not. From the > libvirt guys it has been proposed that we introduce a new env var to > pass to PID 1 of the container, that simply lists ptys to start gettys > on. That way we don't pretend anything about ttys that the ttys can't > hold and have a clean setup. > > > I SUSPECT the hang condition is something to do with systemd trying to > > start and interactive console on /dev/console, which sysvinit and > > upstart do not do. > > Yes, this is documented, please see the link I already posted, and which > I linked above a second time. > > > I've got some more problems relating to shutting down containers, some > > of which may be related to mounting tmpfs on /run to which /var/run is > > symlinked to. We're doing halt / restart detection by monitoring utmp > > in that directory but it looks like utmp isn't even in that directory > > anymore and mounting tmpfs on it was always problematical. We may have > > to have a more generic method to detect when a container has shut down > > or is restarting in that case. > > I can't parse this. The system call reboot() is virtualized for > containers just fine and the container managaer (i.e. LXC) can check for > that easily. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 16:11:42 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 12:11:42 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025213806.GA25835@tango.0pointer.de> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> Message-ID: <1351267902.5181.109.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > I SUSPECT the hang condition is something to do with systemd trying to > > start and interactive console on /dev/console, which sysvinit and > > upstart do not do. > Yes, this is documented, please see the link I already posted, and which > I linked above a second time. This may have been my fault. I was using the -o option to lxc-start (output logfile) and failed to specify the -c (console output redirect) option. It seems to fire up nicely (albeit with other problems) with that additional option. Continuing my research. > > I've got some more problems relating to shutting down containers, some > > of which may be related to mounting tmpfs on /run to which /var/run is > > symlinked to. We're doing halt / restart detection by monitoring utmp > > in that directory but it looks like utmp isn't even in that directory > > anymore and mounting tmpfs on it was always problematical. We may have > > to have a more generic method to detect when a container has shut down > > or is restarting in that case. > I can't parse this. The system call reboot() is virtualized for > containers just fine and the container managaer (i.e. LXC) can check for > that easily. Apparently, in recent kernels, we can. Unfortunately, I'm still finding that I can not restart a container I have previously halted. I have no problem with sysvinit and upstart systems on this host, so it is a container problem peculiar to systemd containers. Continuing to research that problem. > Lennart > -- > Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 16:36:48 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 12:36:48 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121025213806.GA25835@tango.0pointer.de> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> Message-ID: <1351269408.5181.112.camel@canyon.wittsend.com> On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > I've got some more problems relating to shutting down containers, some > > of which may be related to mounting tmpfs on /run to which /var/run is > > symlinked to. We're doing halt / restart detection by monitoring utmp > > in that directory but it looks like utmp isn't even in that directory > > anymore and mounting tmpfs on it was always problematical. We may have > > to have a more generic method to detect when a container has shut down > > or is restarting in that case. > I can't parse this. The system call reboot() is virtualized for > containers just fine and the container managaer (i.e. LXC) can check for > that easily. I strongly suspect that the condition I'm dealing with (not being able to restart the container) is an artifact of the devtmpfs kludge. I'm seeing some errors relating to /dev/loop* busy that seems to be related to the hung resources resulting in the inability to remove the zombie container. Disregard until I can get further information following a switch to a template based setup. > Lennart Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 17:18:05 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 13:18:05 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351267113.5181.105.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351267113.5181.105.camel@canyon.wittsend.com> Message-ID: <1351271885.5181.118.camel@canyon.wittsend.com> On Fri, 2012-10-26 at 11:58 -0400, Michael H. Warfield wrote: > On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > > http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes > > > > > > > Unfortunately, in our case, merely getting a mount in there is a > > > > complication in that it also has to be populated but, at least, we > > > > understand the problem set now. > > > > > > Ok... Serge and I were corresponding on the lxc-users list and he had a > > > suggestion that worked but I consider to be a bit of a sub-optimal > > > workaround. Ironically, it was to mount devtmpfs on /dev. We don't > > > (currently) have a method to auto-populate a tmpfs mount with the needed > > > devices and this provided it. It does have a problem that makes me > > > uncomfortable in that the container now has visibility into the > > > hosts /dev system. I'm a security expert and I'm not comfortable with > > > that "solution" even with the controls we have. We can control access > > > but still, not happy with that. > > > That's a pretty bad idea, access control to the device nodes in devtmpfs > > is controlled by the host's udev instance. That means if your group/user > > lists in the container and the host differ you already lost. Also access > > control in udev is dynamic, due to stuff like uaccess and similar. You > > really don't want to to have that into the container, i.e. where device > > change ownership all the time with UIDs/GIDs that make no sense at all > > in the container. > > Concur. > > > In general I think it's a good idea not to expose any "real" devices to > > the container, but only the "virtual" ones that are programming > > APIs. That means: no /dev/sda, or /dev/ttyS0, but /dev/null, /dev/zero, > > /dev/random, /dev/urandom. And creating the latter in a tmpfs is quite > > simple. > > > > If I run lxc-console (which attaches to one of the vtys) it gives me > > > nothing. Under sysvinit and upstart I get vty login prompts because > > > they have started getty on those vtys. This is important in case > > > network access has not started for one reason or another and the > > > container was started detached in the background. > > > The getty behaviour of systemd in containers is documented here: > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > Sorry. This is unacceptable. We need some way that these will be > active and you will be consistent with other containers. > > > If LXC mounts ptys on top of the VT devices that's a really bad idea > > too, since /dev/tty1 and friends expose a number of APIs beyond the mere > > tty device that you cannot emulate with that. It includes files in /sys, > > as well as /dev/vcs and /dev/vcsa, various ioctls, and so on. Heck, even > > the most superficial of things, the $TERM variable will be > > incorrect. LXC shouldn't do that. > REGARDLESS. I'm in this situation now testing what I thought was a hang > condition (which is proving to be something else). I started a > container detached redirecting the console to a file (a parameter I was > missing) and the log to another file (which I had been doing). But, for > some reason, sshd is not starting up. I have no way to attach to the > bloody console of the container and I have no getty's on a vty I can > attach to using lxc-console and I can't remote access a container which, > for all other intents and purposes, appears to be running fine. > Parameterize this bloody thing so we can have control over it. Here's another weirdism that's in your camp... The reason that sshd did not start was because the network did not start (IPv6 was up but IPv4 was not and the startup of several services failed as a consequence). Trying to restart the network manually resulted in this: [root at alcove mhw]# ifdown eth0 ./network-functions: line 237: cd: /var/run/netreport: No such file or directory [root at alcove mhw]# ifup eth0 ./network-functions: line 237: cd: /var/run/netreport: No such file or directory [root at alcove mhw]# ls /var/run/ dbus messagebus.pid rpcbind.sock systemd user log mount syslogd.pid udev What the hell is this? /var/run is symlinked to /run and is mounted with a tmpfs. So I created that directory and could ifup the the network and start sshd. So I did a little check on the run levels... Hmmm... F17 container (Alcove) in an F17 host (Forest). WHAT is going ON here? Is this why the network didn't start? [root at forest mhw]# runlevel N 5 [root at alcove mhw]# runlevel unknown [root at alcove mhw]# chkconfig Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. modules_dep 0:off 1:off 2:on 3:on 4:on 5:on 6:off netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:off 3:on 4:off 5:off 6:off Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Fri Oct 26 21:02:00 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Fri, 26 Oct 2012 17:02:00 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351267902.5181.109.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351267902.5181.109.camel@canyon.wittsend.com> Message-ID: <1351285320.5181.126.camel@canyon.wittsend.com> On Fri, 2012-10-26 at 12:11 -0400, Michael H. Warfield wrote: > On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: > > On Thu, 25.10.12 11:59, Michael H. Warfield (mhw at WittsEnd.com) wrote: > > > > I SUSPECT the hang condition is something to do with systemd trying to > > > start and interactive console on /dev/console, which sysvinit and > > > upstart do not do. > > > Yes, this is documented, please see the link I already posted, and which > > I linked above a second time. > This may have been my fault. I was using the -o option to lxc-start > (output logfile) and failed to specify the -c (console output redirect) > option. It seems to fire up nicely (albeit with other problems) with > that additional option. Continuing my research. Confirming. Using the -c option for the console file works. Unfortunately, thanks to no getty's on the ttys so lxc-console does not work and no way to connect to that console redirect and the failure of the network to start, I'm still trying to figure out just what is face planting in a container I can not access. :-/=/ Punch out the punch list one PUNCH at at time here. > > > I've got some more problems relating to shutting down containers, some > > > of which may be related to mounting tmpfs on /run to which /var/run is > > > symlinked to. We're doing halt / restart detection by monitoring utmp > > > in that directory but it looks like utmp isn't even in that directory > > > anymore and mounting tmpfs on it was always problematical. We may have > > > to have a more generic method to detect when a container has shut down > > > or is restarting in that case. > > > I can't parse this. The system call reboot() is virtualized for > > containers just fine and the container managaer (i.e. LXC) can check for > > that easily. > > Apparently, in recent kernels, we can. Unfortunately, I'm still finding > that I can not restart a container I have previously halted. I have no > problem with sysvinit and upstart systems on this host, so it is a > container problem peculiar to systemd containers. Continuing to > research that problem. > > > Lennart > > > -- > > Lennart Poettering - Red Hat, Inc. > > Regards, > Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From gt0057 at gmail.com Fri Oct 26 23:37:27 2012 From: gt0057 at gmail.com (Giuseppe Tofoni) Date: Sat, 27 Oct 2012 01:37:27 +0200 Subject: [Lxc-users] Lxc with Slackware 14 64bit will not start. Message-ID: Hello, First thanks for your great work. I am a happy user of LXC with Slackware 13.37 and lxc-0.7.4.2, but with slack64 14.0 and lxc-0.8.0-rc2 I get the following errors: lxc-start: No such file or directory - failed to exec /sbin/init lxc-start: invalid sequence number 1. expected 2 lxc-start: failed to spawn 'lxc_999' lxc-start: No such file or directory - failed to remove cgroup '/cgroup//lxc/lxc_999' My setup is: cd lxc-0.8.0-rc2 ./configure --prefix=/usr/local --with-config-path=/etc/lxc --with-rootfs-path=/vz/lxc make && make install cd /etc/lxc/lxc_999 vi config # lxc.utsname =lxc_999 # lxc.mount=/etc/lxc/lxc_999/fstab lxc.console=/var/log/lxc/console_999 lxc.rootfs=/vz/lxc/lxc_999 # lxc.pts = 1024 # lxc.network.type =veth lxc.network.flags =up lxc.network.link =br1 lxc.network.name = eth1 lxc.network.hwaddr =02:00:ac:10:1:9 lxc.network.ipv4 =172.16.1.9/19 lxc.network.mtu =1500 lxc.network.veth.pair = veth999.1 # # #lxc.cgroup.memory.limit_in_bytes = 512M lxc.cgroup.memory.limit_in_bytes = 1G #lxc.cgroup.memory.memsw.limit_in_bytes = 2G //This option is no present in Slackware 64bit kernel 3.2.29 # lxc.cgroup.cpuset.cpus =0,1 # # % to CPU 512 =40% 1024 =50% 1524 =60% 2048 =67% # lxc.cgroup.cpu.shares = 1024 lxc.cgroup.devices.deny = a # # /dev/null and zero lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm # # consoles lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm # # /dev/{,u}random lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm # # /dev/pts/* - pts namespaces are "coming soon" # lxc.cgroup.devices.allow = c 136:* rwm # # rtc lxc.cgroup.devices.allow = c 254:0 rwm # # capabilities # # lxc.cap.drop = sys_module mac_override vi fstab # /sbin /vz/lxc/lxc_999/sbin none ro,bind 0 0 /bin /vz/lxc/lxc_999/bin none ro,bind 0 0 /lib /vz/lxc/lxc_999/lib none ro,bind 0 0 /vz/usrLxc /vz/lxc/lxc_999/usr none ro,bind 0 0 # none /vz/lxc/lxc_999/dev/pts devpts defaults 0 0 none /vz/lxc/lxc_999/proc proc defaults 0 0 none /vz/lxc/lxc_999/sys sysfs defaults 0 0 none /vz/lxc/lxc_999/dev/shm tmpfs defaults 0 0 Thanks in advance for your help. Giuseppe Tofoni From gt0057 at gmail.com Fri Oct 26 23:49:40 2012 From: gt0057 at gmail.com (Giuseppe Tofoni) Date: Sat, 27 Oct 2012 01:49:40 +0200 Subject: [Lxc-users] Lxc with Slackware 14 64bit will not start. Message-ID: Hello, First thanks for your great work. I am a happy user of LXC with Slackware 13.37 and lxc-0.7.4.2, but with slack64 14.0 and lxc-0.8.0-rc2 I get the following errors: lxc-start: No such file or directory - failed to exec /sbin/init lxc-start: invalid sequence number 1. expected 2 lxc-start: failed to spawn 'lxc_999' lxc-start: No such file or directory - failed to remove cgroup '/cgroup//lxc/lxc_999' My setup is: cd lxc-0.8.0-rc2 ./configure --prefix=/usr/local --with-config-path=/etc/lxc --with-rootfs-path=/vz/lxc make && make install cd /etc/lxc/lxc_999 vi config # lxc.utsname =lxc_999 lxc.mount=/etc/lxc/lxc_999/fstab lxc.console=/var/log/lxc/console_999 lxc.rootfs=/vz/lxc/lxc_999 # lxc.pts = 1024 lxc.network.type =veth lxc.network.flags =up lxc.network.link =br1 lxc.network.name = eth1 lxc.network.hwaddr =02:00:ac:10:1:9 lxc.network.ipv4 =172.16.1.9/19 lxc.network.mtu =1500 lxc.network.veth.pair = veth999.1 # lxc.cgroup.memory.limit_in_bytes = 1G #lxc.cgroup.memory.memsw.limit_in_bytes = 2G //This option is no present in Slackware 64bit kernel 3.2.29 # lxc.cgroup.cpuset.cpus =0,1 lxc.cgroup.cpu.shares = 1024 # lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:2 rwm lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 254:0 rwm lxc.cap.drop = sys_module mac_override vi fstab /sbin /vz/lxc/lxc_999/sbin none ro,bind 0 0 /bin /vz/lxc/lxc_999/bin none ro,bind 0 0 /lib /vz/lxc/lxc_999/lib none ro,bind 0 0 /vz/usrLxc /vz/lxc/lxc_999/usr none ro,bind 0 0 none /vz/lxc/lxc_999/dev/pts devpts defaults 0 0 none /vz/lxc/lxc_999/proc proc defaults 0 0 none /vz/lxc/lxc_999/sys sysfs defaults 0 0 none /vz/lxc/lxc_999/dev/shm tmpfs defaults 0 0 Thanks in advance for your help. Giuseppe From mhw at WittsEnd.com Sat Oct 27 16:45:24 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 12:45:24 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121026140728.GA23975@sergelap> References: <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <20121026140728.GA23975@sergelap> Message-ID: <1351356324.5001.8.camel@canyon.wittsend.com> On Fri, 2012-10-26 at 09:07 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > Adding in the lxc-devel list. > > > > On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: > > > On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: > > > > On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > > > > > Hey Serge, > > > > > > > > > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > > > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > > > > > mount a tmpfs onto /dev and populate it. > > > > > > > > > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > > > > comments about "pre mount hooks". Where is the documentation about this > > > > > > > feature and how I might use / implement it? Some examples would > > > > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > > > > > > > I think I found what I needed in the changelog here: > > > > > > > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > > > > > > > I'll play with it and report back. > > > > > > > > > Also the "Lifecycle management hooks" section in > > > > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > > > > > > > This isn't working... > > > > > > > > Based on what was in both of those articles, I added this entry to > > > > another container (Plover) to test... > > > > > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > > > When I run "lxc-start -n Plover", I see this: > > > > > > > > [root at forest ~]# lxc-start -n Plover > > > > lxc-start: unknow key lxc.hook.mount > > > > lxc-start: failed to read configuration file > > > > > > > > I'm running the latest rc... > > > > > > > > [root at forest ~]# rpm -qa | grep lxc > > > > lxc-0.8.0.rc2-1.fc16.x86_64 > > > > lxc-libs-0.8.0.rc2-1.fc16.x86_64 > > > > lxc-doc-0.8.0.rc2-1.fc16.x86_64 > > > > > > > > Is it something in git that hasn't made it to a release yet? > > > > > nm... I see it. It's in git and hasn't made it to a release. I'm > > > working on a git build to test now. If this is something that solves > > > some of this, we need to move things along here and get these things > > > moved out. According to git, 0.8.0rc2 was 7 months ago? What's the > > > show stoppers here? > > > > While the git repo says 7 months ago, the date stamp on the > > lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. > > Sounds like we've accumulated some features (like the hooks) we are > > going to need like months ago to deal with this systemd debacle. How > > close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just > > waiting on some more features? > Daniel has simply been too busy. St?phane has made a new branch which > cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about > twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) Trying to build latest from git. This is not good... checking sys/apparmor.h usability... no checking sys/apparmor.h presence... no checking for sys/apparmor.h... no configure: error: You must install the AppArmor development package in order to compile lxc What am I suppose to do on Fedora where we don't have that package? Is it available in another repo somewhere? I'm looking and not finding. Regards, Mike > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sat Oct 27 16:53:22 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 12:53:22 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351356324.5001.8.camel@canyon.wittsend.com> References: <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <20121026140728.GA23975@sergelap> <1351356324.5001.8.camel@canyon.wittsend.com> Message-ID: <1351356802.5001.9.camel@canyon.wittsend.com> On Sat, 2012-10-27 at 12:45 -0400, Michael H. Warfield wrote: > On Fri, 2012-10-26 at 09:07 -0500, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > Adding in the lxc-devel list. > > > > > > On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: > > > > On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: > > > > > On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: > > > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > > > > On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: > > > > > > > > Hey Serge, > > > > > > > > > > > > > > > > On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > Oh, sorry - I take back that suggestion :) > > > > > > > > > > > > > > > > > Note that we have mount hooks, so templates could install a mount hook to > > > > > > > > > mount a tmpfs onto /dev and populate it. > > > > > > > > > > > > > > > > Ok... I've done some cursory search and turned up nothing but some > > > > > > > > comments about "pre mount hooks". Where is the documentation about this > > > > > > > > feature and how I might use / implement it? Some examples would > > > > > > > > probably suffice. Is there a require release version of lxc-utils? > > > > > > > > > > > > > > I think I found what I needed in the changelog here: > > > > > > > > > > > > > > http://www.mail-archive.com/lxc-devel at lists.sourceforge.net/msg01490.html > > > > > > > > > > > > > > I'll play with it and report back. > > > > > > > > > > > Also the "Lifecycle management hooks" section in > > > > > > https://help.ubuntu.com/12.10/serverguide/lxc.html > > > > > > > > > > This isn't working... > > > > > > > > > > Based on what was in both of those articles, I added this entry to > > > > > another container (Plover) to test... > > > > > > > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > > > > > When I run "lxc-start -n Plover", I see this: > > > > > > > > > > [root at forest ~]# lxc-start -n Plover > > > > > lxc-start: unknow key lxc.hook.mount > > > > > lxc-start: failed to read configuration file > > > > > > > > > > I'm running the latest rc... > > > > > > > > > > [root at forest ~]# rpm -qa | grep lxc > > > > > lxc-0.8.0.rc2-1.fc16.x86_64 > > > > > lxc-libs-0.8.0.rc2-1.fc16.x86_64 > > > > > lxc-doc-0.8.0.rc2-1.fc16.x86_64 > > > > > > > > > > Is it something in git that hasn't made it to a release yet? > > > > > > > nm... I see it. It's in git and hasn't made it to a release. I'm > > > > working on a git build to test now. If this is something that solves > > > > some of this, we need to move things along here and get these things > > > > moved out. According to git, 0.8.0rc2 was 7 months ago? What's the > > > > show stoppers here? > > > > > > While the git repo says 7 months ago, the date stamp on the > > > lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. > > > Sounds like we've accumulated some features (like the hooks) we are > > > going to need like months ago to deal with this systemd debacle. How > > > close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just > > > waiting on some more features? > > > Daniel has simply been too busy. St?phane has made a new branch which > > cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about > > twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) > > Trying to build latest from git. This is not good... > > checking sys/apparmor.h usability... no > checking sys/apparmor.h presence... no > checking for sys/apparmor.h... no > configure: error: You must install the AppArmor development package in > order to compile lxc > What am I suppose to do on Fedora where we don't have that package? Is > it available in another repo somewhere? I'm looking and not finding. nm... I see that --enable-apparmor is defaulted to on. I just had to add an option to --disable-apparmor. Sorry for the noise. > Regards, > Mike Mike > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > > Lxc-users mailing list > > Lxc-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-users > > > > ------------------------------------------------------------------------------ > WINDOWS 8 is here. > Millions of people. Your app in 30 days. > Visit The Windows 8 Center at Sourceforge for all your go to resources. > http://windows8center.sourceforge.net/ > join-generation-app-and-make-money-coding-fast/ > _______________________________________________ Lxc-users mailing list Lxc-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sat Oct 27 17:40:55 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 13:40:55 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351258337.5181.68.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> Message-ID: <1351359655.5001.16.camel@canyon.wittsend.com> /me erasing everything at this point and taking off the systemd crew, since this will have no relevance to them... Testing the hook feature out using git rev (finally got it built)... I added this line to my config... lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 lxc.hook.mount = /var/lib/lxc/Plover/mount In /var/lib/lxc/Plover/mount I have this: -- rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ -- (This is just testing out the concepts. If I understand this correctly, lxc.hook.pre-mount runs BEFORE the mounting takes place and lxc.hook.mount takes place after the mount. Problem is, the result of that rsync is not showing up in the mounted tmpfs file system but is showing up in the underlying parent file system as if it were run pre-mount. Something not right here... Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sat Oct 27 17:51:48 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 13:51:48 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351359655.5001.16.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> Message-ID: <1351360308.5001.20.camel@canyon.wittsend.com> On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > /me erasing everything at this point and taking off the systemd crew, > since this will have no relevance to them... > > Testing the hook feature out using git rev (finally got it built)... > > I added this line to my config... > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > lxc.hook.mount = /var/lib/lxc/Plover/mount > > In /var/lib/lxc/Plover/mount I have this: > > -- > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > -- > (This is just testing out the concepts. > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > mounting takes place and lxc.hook.mount takes place after the mount. > Problem is, the result of that rsync is not showing up in the mounted > tmpfs file system but is showing up in the underlying parent file system > as if it were run pre-mount. Something not right here... I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the script in the container) which then works but that then requires the template and the command to be in the container. Suboptimal to say the least. But it gives me a way to test this tmpfs thing out. I also noticed that the .start hook runs, it appears, after caps are dropped and I see a lot of bitching about mknod on certain devices. I had to thrown an exit 0 into that script so it would continue in spite of the errors but, now, I can refine my template based on what it could create. > Regards, > Mike Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sat Oct 27 18:09:53 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 14:09:53 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351360308.5001.20.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> Message-ID: <1351361393.5001.30.camel@canyon.wittsend.com> On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: > On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > > /me erasing everything at this point and taking off the systemd crew, > > since this will have no relevance to them... > > > > Testing the hook feature out using git rev (finally got it built)... > > > > I added this line to my config... > > > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > In /var/lib/lxc/Plover/mount I have this: > > > > -- > > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > > -- > > > (This is just testing out the concepts. > > > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > > mounting takes place and lxc.hook.mount takes place after the mount. > > > Problem is, the result of that rsync is not showing up in the mounted > > tmpfs file system but is showing up in the underlying parent file system > > as if it were run pre-mount. Something not right here... > I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the > script in the container) which then works but that then requires the > template and the command to be in the container. Suboptimal to say the > least. But it gives me a way to test this tmpfs thing out. > I also noticed that the .start hook runs, it appears, after caps are > dropped and I see a lot of bitching about mknod on certain devices. I > had to thrown an exit 0 into that script so it would continue in spite > of the errors but, now, I can refine my template based on what it could > create. Crap. I've got a catch-22 here... This is going to take some work. Yes, we can create the /dev directory with tmpfs from a template. Problem is that /dev/pts does not exist at the time we need to mount the devpts on /dev/pts for the pty's so that hurls chunks and dies. We can't create the /dev/ directory contents prior to mounting in the pre-mount hook because we won't have tmpfs in place at the time. We have to get tmpfs mounted on /dev and then create /dev/pts and then mount the ptys in there. There has to be a mkdir in between those two mount actions. Simplest solution would seem to be to add some logic to the mount logic that says "test if directory exists and, if not, create it." I'm not sure of the consequences of that, though. I don't see a way to make this happen with hooks. It's almost like we need and on-mount per mount hook. > > Regards, > > Mike > > Regards, > Mike Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From whit at transpect.com Sat Oct 27 18:36:23 2012 From: whit at transpect.com (Whit Blauvelt) Date: Sat, 27 Oct 2012 14:36:23 -0400 Subject: [Lxc-users] Converting existing CentOS 6.x to container within Ubuntu 12.04 - can that be simple? Message-ID: <20121027183623.GA28679@black.transpect.com> Hi, I'd welcome advice on whether there's a sane, relatively simple way to take a backup copy of a CentOS 6 system, which happens to be sitting on a partition on a Ubuntu 12.04 VMware VM, and set it up to run in a container there. It's been a year since I've done anything with LXC. I see that it's been nicely streamlined in Ubuntu 12.04. Googling for pointers to answer my current question, I'm mostly seeing older discussion of older Ubuntu and CentOS versions, which I expect partially doesn't apply now. I have this notion that it might be simple indeed to set this up. But that notion is admittedly foggy. If it is simple, is there a guide to this sort of thing somewhere? I see a template for a fresh CentOS 6 guest here on the list I could try, but if there's a way to more directly just use the already configured backup rather than build a fresh instance that would be even better. Thanks, Whit From gmane at colin.guthr.ie Sat Oct 27 18:44:37 2012 From: gmane at colin.guthr.ie (Colin Guthrie) Date: Sat, 27 Oct 2012 19:44:37 +0100 Subject: [Lxc-users] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351271885.5181.118.camel@canyon.wittsend.com> References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351267113.5181.105.camel@canyon.wittsend.com> <1351271885.5181.118.camel@canyon.wittsend.com> Message-ID: 'Twas brillig, and Michael H. Warfield at 26/10/12 18:18 did gyre and gimble: > What the hell is this? /var/run is symlinked to /run and is mounted > with a tmpfs. Yup, that's how /var/run and /run is being handled these days. It provides a consistent space to pass info from the initrd over to the main system and has various other uses also. If you want to ensure files are created in this folder, just drop a config file in to /usr/lib/tmpfiles.d/ in the package in question. See man systemd-tmpfiles for more info. Could be some packages are not fully upgraded to this concept in F17. As a non-fedora user, I can't really comment on that specifically. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ From mhw at WittsEnd.com Sat Oct 27 19:37:54 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sat, 27 Oct 2012 15:37:54 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: References: <1350854705.5036.77.camel@canyon.wittsend.com> <20121022141159.GA5234@tango.0pointer.de> <1350920921.5036.128.camel@canyon.wittsend.com> <20121022205019.GA24239@tango.0pointer.de> <1350939562.1481.43.camel@canyon.wittsend.com> <1351180750.5181.42.camel@canyon.wittsend.com> <20121025213806.GA25835@tango.0pointer.de> <1351267113.5181.105.camel@canyon.wittsend.com> <1351271885.5181.118.camel@canyon.wittsend.com> Message-ID: <1351366674.5001.37.camel@canyon.wittsend.com> On Sat, 2012-10-27 at 19:44 +0100, Colin Guthrie wrote: > 'Twas brillig, and Michael H. Warfield at 26/10/12 18:18 did gyre and > gimble: > > What the hell is this? /var/run is symlinked to /run and is mounted > > with a tmpfs. > Yup, that's how /var/run and /run is being handled these days. > It provides a consistent space to pass info from the initrd over to the > main system and has various other uses also. Interesting. I hadn't considered that aspect of it before. Very interesting. > If you want to ensure files are created in this folder, just drop a > config file in to /usr/lib/tmpfiles.d/ in the package in question. See > man systemd-tmpfiles for more info. NOW THAT is something else I needed to know about! Thank you very very much! Learned something new. This whole thing has been a massive learning experience getting this container kick started. > Could be some packages are not fully upgraded to this concept in F17. As > a non-fedora user, I can't really comment on that specifically. As it turns out, the kernel has had some of our patches applied that I wasn't aware of vis-a-vis reboot/halt and this should no longer be an issue. I'm still struggling with the tmpfs on /dev thing and have run into a catch-22 with regards to that. I can mount tmpfs on /dev just fine and can populate it just fine in a post mount hook but, then, we're trying to mount a devpts file system on /dev/pts before we've had a chance to populate it and it's then crashing on the mount. Sigh... I think that's going to now have to wait for Serge or Daniel to comment on. > Col > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From list at fajar.net Sun Oct 28 09:50:07 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Sun, 28 Oct 2012 16:50:07 +0700 Subject: [Lxc-users] Converting existing CentOS 6.x to container within Ubuntu 12.04 - can that be simple? In-Reply-To: <20121027183623.GA28679@black.transpect.com> References: <20121027183623.GA28679@black.transpect.com> Message-ID: On Sun, Oct 28, 2012 at 1:36 AM, Whit Blauvelt wrote: > I have this notion that it might be simple indeed to set this up. Sure it is. Well, kindof :) > But that > notion is admittedly foggy. If it is simple, is there a guide to this sort > of thing somewhere? I see a template for a fresh CentOS 6 guest here on the > list I could try, but if there's a way to more directly just use the already > configured backup rather than build a fresh instance that would be even > better. Did your search brought you to http://wiki.1tux.org/wiki/Lxc/Installation/Guest/Centos/6 ? :D If yes, that guide assumes you have a "working" centos 6 setup already, in the form of one created using "yum install --installroot". You could change that to "a filesystem-level backup of a working centos installation", and pretty much do the same modifications. In particular, lxc-sysinit.conf and fstab. There might be other modifcations required (I forgot which ones, try looking at http://wiki.1tux.org/wiki/Centos6/Installation/Minimal_installation_using_yum#Post-install_configuration and see which ones is relevant), just try it and see how it goes. As usual, create backups before you modify anything. Just in case. -- Fajar From serge.hallyn at canonical.com Sun Oct 28 17:52:57 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sun, 28 Oct 2012 18:52:57 +0100 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351361393.5001.30.camel@canyon.wittsend.com> References: <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> Message-ID: <20121028175257.GA3007@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: > > On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > > > /me erasing everything at this point and taking off the systemd crew, > > > since this will have no relevance to them... > > > > > > Testing the hook feature out using git rev (finally got it built)... > > > > > > I added this line to my config... > > > > > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > In /var/lib/lxc/Plover/mount I have this: > > > > > > -- > > > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > > > -- > > > > > (This is just testing out the concepts. > > > > > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > > > mounting takes place and lxc.hook.mount takes place after the mount. > > > > > Problem is, the result of that rsync is not showing up in the mounted > > > tmpfs file system but is showing up in the underlying parent file system > > > as if it were run pre-mount. Something not right here... > > > I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the > > script in the container) which then works but that then requires the > > template and the command to be in the container. Suboptimal to say the > > least. But it gives me a way to test this tmpfs thing out. > > > I also noticed that the .start hook runs, it appears, after caps are > > dropped and I see a lot of bitching about mknod on certain devices. I > > had to thrown an exit 0 into that script so it would continue in spite > > of the errors but, now, I can refine my template based on what it could > > create. > > Crap. I've got a catch-22 here... This is going to take some work. Hey, I've got a rather minimal patch (appended below) to add the support for mounting and populating a minimal /dev working. (A few hours were wasted due to my not knowing that upstart was going to issue mounted-dev even though /dev was mounted before upstart started - and the mounted-dev hook deletes and recreates all consoles. GAH) > Yes, we can create the /dev directory with tmpfs from a template. > Problem is that /dev/pts does not exist at the time we need to mount the > devpts on /dev/pts for the pty's so that hurls chunks and dies. We > can't create the /dev/ directory contents prior to mounting in the > pre-mount hook because we won't have tmpfs in place at the time. We > have to get tmpfs mounted on /dev and then create /dev/pts and then > mount the ptys in there. There has to be a mkdir in between those two > mount actions. Simplest solution would seem to be to add some logic to > the mount logic that says "test if directory exists and, if not, create > it." I'm not sure of the consequences of that, though. > > I don't see a way to make this happen with hooks. It's almost like we > need and on-mount per mount hook. Should be moot given my patch, which I intend to push this week, but why couldn't a lxc.hook.mount do the whole thing, mount /dev and and populate it? I wasn't thinking a lxc.hook.start, for the reasons you encountered, but I assume you tried lxc.hook.mount and it failed? Patch below: Index: lxc-qp/src/lxc/conf.c =================================================================== --- lxc-qp.orig/src/lxc/conf.c 2012-10-27 17:24:50.768383000 -0500 +++ lxc-qp/src/lxc/conf.c 2012-10-28 05:44:07.871228322 -0500 @@ -619,7 +619,7 @@ } if (mount(pty_info->name, lxcpath, "none", MS_BIND, 0)) { - WARN("failed to mount '%s'->'%s'", + SYSERROR("failed to mount '%s'->'%s'", pty_info->name, path); continue; } @@ -636,7 +636,7 @@ } } else { if (mount(pty_info->name, path, "none", MS_BIND, 0)) { - WARN("failed to mount '%s'->'%s'", + SYSERROR("failed to mount '%s'->'%s'", pty_info->name, path); continue; } @@ -842,6 +842,67 @@ return 0; } +struct lxc_devs { + char *name; + mode_t mode; + int maj; + int min; +}; + +struct lxc_devs lxc_devs[] = { + { "null", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 }, + { "zero", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 }, + { "full", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 7 }, + { "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 }, + { "random", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 8 }, + { "tty", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 5, 0 }, + { "console", S_IFCHR | S_IRUSR | S_IWUSR, 5, 1 }, +}; + +/* + * Do we want to add options for max size of /dev and a file to + * specify which devices to create? + */ +static int setup_autodev(char *root) +{ + int ret; + struct lxc_devs *d; + char path[MAXPATHLEN]; + int i; + + INFO("Creating and populating /dev under %s\n", root); + ret = snprintf(path, MAXPATHLEN, "%s/dev", root); + if (ret < 0 || ret > MAXPATHLEN) + return -1; + ret = mount("none", path, "tmpfs", 0, "size=100000"); + if (ret) { + SYSERROR("Failed to mount /dev at %s\n", root); + return -1; + } + for (i = 0; i < sizeof(lxc_devs) / sizeof(lxc_devs[0]); i++) { + d = &lxc_devs[i]; + ret = snprintf(path, MAXPATHLEN, "%s/dev/%s", root, d->name); + if (ret < 0 || ret >= MAXPATHLEN) + return -1; + ret = mknod(path, d->mode, makedev(d->maj, d->min)); + if (ret) { + SYSERROR("Error creating %s\n", d->name); + return -1; + } + } + ret = snprintf(path, MAXPATHLEN, "%s/dev/pts", root); + if (ret < 0 || ret >= MAXPATHLEN) + return -1; + ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH); + if (ret) { + SYSERROR("Failed to create /dev/pts in container"); + return -1; + } + + INFO("Populated /dev under %s\n", root); + return 0; +} + static int setup_rootfs(const struct lxc_rootfs *rootfs) { if (!rootfs->path) @@ -2208,6 +2269,13 @@ return -1; } + if (lxc_conf->autodev) { + if (setup_autodev(lxc_conf->rootfs.mount)) { + ERROR("failed to set up /dev in the container"); + return -1; + } + } + if (setup_mount(&lxc_conf->rootfs, lxc_conf->fstab, name)) { ERROR("failed to setup the mounts for '%s'", name); return -1; Index: lxc-qp/src/lxc/conf.h =================================================================== --- lxc-qp.orig/src/lxc/conf.h 2012-10-27 17:24:50.768383000 -0500 +++ lxc-qp/src/lxc/conf.h 2012-10-27 17:24:50.768383000 -0500 @@ -227,6 +227,7 @@ struct lxc_list hooks[NUM_LXC_HOOKS]; char *seccomp; // filename with the seccomp rules int maincmd_fd; + int autodev; // if 1, mount and fill a /dev at start }; int run_lxc_hooks(const char *name, char *hook, struct lxc_conf *conf); Index: lxc-qp/src/lxc/confile.c =================================================================== --- lxc-qp.orig/src/lxc/confile.c 2012-10-27 17:24:50.768383000 -0500 +++ lxc-qp/src/lxc/confile.c 2012-10-27 17:24:50.768383000 -0500 @@ -77,6 +77,7 @@ static int config_seccomp(const char *, char *, struct lxc_conf *); static int config_includefile(const char *, char *, struct lxc_conf *); static int config_network_nic(const char *, char *, struct lxc_conf *); +static int config_autodev(const char *, char *, struct lxc_conf *); typedef int (*config_cb)(const char *, char *, struct lxc_conf *); @@ -118,6 +119,7 @@ { "lxc.console", config_console }, { "lxc.seccomp", config_seccomp }, { "lxc.include", config_includefile }, + { "lxc.autodev", config_autodev }, }; static const size_t config_size = sizeof(config)/sizeof(struct lxc_config_t); @@ -853,6 +855,16 @@ return 0; } + +static int config_autodev(const char *key, char *value, + struct lxc_conf *lxc_conf) +{ + int v = atoi(value); + + lxc_conf->autodev = v; + + return 0; +} static int config_aa_profile(const char *key, char *value, struct lxc_conf *lxc_conf) From serge.hallyn at canonical.com Sun Oct 28 17:53:06 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sun, 28 Oct 2012 18:53:06 +0100 Subject: [Lxc-users] Lxc with Slackware 14 64bit will not start. In-Reply-To: References: Message-ID: <20121028175306.GB3007@serge-ThinkPad-X130e> Quoting Giuseppe Tofoni (gt0057 at gmail.com): > Hello, > > First thanks for your great work. > > I am a happy user of LXC with Slackware 13.37 and lxc-0.7.4.2, but > with slack64 14.0 and lxc-0.8.0-rc2 I get the following errors: > > lxc-start: No such file or directory - failed to exec /sbin/init > lxc-start: invalid sequence number 1. expected 2 > lxc-start: failed to spawn 'lxc_999' > lxc-start: No such file or directory - failed to remove cgroup > '/cgroup//lxc/lxc_999' Hi, can you tell us your cgroup setup in detail, and do lxc-start -n lxc_999 -l debug -o outout and then send us outout? thanks, -serge From mhw at WittsEnd.com Sun Oct 28 18:06:52 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 28 Oct 2012 14:06:52 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121028175257.GA3007@serge-ThinkPad-X130e> References: <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> Message-ID: <1351447612.5001.43.camel@canyon.wittsend.com> On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: > > > On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > > > > /me erasing everything at this point and taking off the systemd crew, > > > > since this will have no relevance to them... > > > > > > > > Testing the hook feature out using git rev (finally got it built)... > > > > > > > > I added this line to my config... > > > > > > > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > > > In /var/lib/lxc/Plover/mount I have this: > > > > > > > > -- > > > > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > > > > -- > > > > > > > (This is just testing out the concepts. > > > > > > > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > > > > mounting takes place and lxc.hook.mount takes place after the mount. > > > > > > > Problem is, the result of that rsync is not showing up in the mounted > > > > tmpfs file system but is showing up in the underlying parent file system > > > > as if it were run pre-mount. Something not right here... > > > > > I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the > > > script in the container) which then works but that then requires the > > > template and the command to be in the container. Suboptimal to say the > > > least. But it gives me a way to test this tmpfs thing out. > > > > > I also noticed that the .start hook runs, it appears, after caps are > > > dropped and I see a lot of bitching about mknod on certain devices. I > > > had to thrown an exit 0 into that script so it would continue in spite > > > of the errors but, now, I can refine my template based on what it could > > > create. > > > > Crap. I've got a catch-22 here... This is going to take some work. > Hey, > I've got a rather minimal patch (appended below) to add the support for > mounting and populating a minimal /dev working. (A few hours were wasted > due to my not knowing that upstart was going to issue mounted-dev even though > /dev was mounted before upstart started - and the mounted-dev hook deletes > and recreates all consoles. GAH) > > Yes, we can create the /dev directory with tmpfs from a template. > > Problem is that /dev/pts does not exist at the time we need to mount the > > devpts on /dev/pts for the pty's so that hurls chunks and dies. We > > can't create the /dev/ directory contents prior to mounting in the > > pre-mount hook because we won't have tmpfs in place at the time. We > > have to get tmpfs mounted on /dev and then create /dev/pts and then > > mount the ptys in there. There has to be a mkdir in between those two > > mount actions. Simplest solution would seem to be to add some logic to > > the mount logic that says "test if directory exists and, if not, create > > it." I'm not sure of the consequences of that, though. > > > > I don't see a way to make this happen with hooks. It's almost like we > > need and on-mount per mount hook. > Should be moot given my patch, which I intend to push this week, but why > couldn't a lxc.hook.mount do the whole thing, mount /dev and and populate > it? I wasn't thinking a lxc.hook.start, for the reasons you encountered, > but I assume you tried lxc.hook.mount and it failed? See my other comment about lxc.hook.mount. I tried using it to populate /dev but it showed up in the parent of the mount undeneath the tmpfs mount. It was like it ran pre-mount. I tried it for several different combinations and couldn't get it to go. Would still have the problem with mounting /dev/pts which would take place before the mount hook at run to mount the file system and populate it. That actually MIGHT work (gotta think on this now) if I used lxc.hook.pre-mount and mounted tmpfs over /dev, and populated it but then I run into a problem where I was using a bind-mount for the rootfs. Might still work. I'll test your patch out first though. > Patch below: Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sun Oct 28 20:40:25 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 28 Oct 2012 16:40:25 -0400 Subject: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121028175257.GA3007@serge-ThinkPad-X130e> References: <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> Message-ID: <1351456825.5001.46.camel@canyon.wittsend.com> On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: > Should be moot given my patch, which I intend to push this week, but > why > couldn't a lxc.hook.mount do the whole thing, mount /dev and and > populate > it? I wasn't thinking a lxc.hook.start, for the reasons you > encountered, > but I assume you tried lxc.hook.mount and it failed? > Patch below: Patch failed against 0.8.0rc2 and git root. Even with loose patching for whitespace, had failures... This was against git: [mhw at forest lxc]$ patch -p1 -l < ../lxc-autodev.patch patching file src/lxc/conf.c Hunk #1 succeeded at 616 (offset -3 lines). Hunk #2 succeeded at 633 (offset -3 lines). Hunk #3 succeeded at 839 (offset -3 lines). Hunk #4 succeeded at 2203 (offset -66 lines). patching file src/lxc/conf.h Hunk #1 FAILED at 227. 1 out of 1 hunk FAILED -- saving rejects to file src/lxc/conf.h.rej patching file src/lxc/confile.c Hunk #1 FAILED at 77. Hunk #2 FAILED at 118. Hunk #3 succeeded at 854 with fuzz 2 (offset 1 line). 2 out of 3 hunks FAILED -- saving rejects to file src/lxc/confile Version to patch to? I'm trying to manually integrate those failed hunks now. Shouldn't be too difficult for only three. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Sun Oct 28 21:33:55 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 28 Oct 2012 17:33:55 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121028175257.GA3007@serge-ThinkPad-X130e> References: <20121025161954.GA31702@sergelap> <1351185812.5181.49.camel@canyon.wittsend.com> <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> Message-ID: <1351460035.5001.57.camel@canyon.wittsend.com> On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: > > > On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > > > > /me erasing everything at this point and taking off the systemd crew, > > > > since this will have no relevance to them... > > > > > > > > Testing the hook feature out using git rev (finally got it built)... > > > > > > > > I added this line to my config... > > > > > > > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > > > In /var/lib/lxc/Plover/mount I have this: > > > > > > > > -- > > > > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > > > > -- > > > > > > > (This is just testing out the concepts. > > > > > > > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > > > > mounting takes place and lxc.hook.mount takes place after the mount. > > > > > > > Problem is, the result of that rsync is not showing up in the mounted > > > > tmpfs file system but is showing up in the underlying parent file system > > > > as if it were run pre-mount. Something not right here... > > > > > I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the > > > script in the container) which then works but that then requires the > > > template and the command to be in the container. Suboptimal to say the > > > least. But it gives me a way to test this tmpfs thing out. > > > > > I also noticed that the .start hook runs, it appears, after caps are > > > dropped and I see a lot of bitching about mknod on certain devices. I > > > had to thrown an exit 0 into that script so it would continue in spite > > > of the errors but, now, I can refine my template based on what it could > > > create. > > > > Crap. I've got a catch-22 here... This is going to take some work. > Hey, > I've got a rather minimal patch (appended below) to add the support for > mounting and populating a minimal /dev working. (A few hours were wasted > due to my not knowing that upstart was going to issue mounted-dev even though > /dev was mounted before upstart started - and the mounted-dev hook deletes > and recreates all consoles. GAH) I am happy to report that, after manually editing my git head branch to patch in the failed hunks, I was able to build it and test it and my Fedora 17 systemd based container fired right up after adding the lxc.autodev = 1 parameter to the config file. Yeah!!!! I did run into one gotcha, but one I can live with. I had been bind mounting the private root file system to another directory and then using that as the rootfs like this: -- lxc.rootfs = /srv/lxc/rootfs lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- This did not work and I got the startup error that it can not mount to /dev because it doesn't exist. I believe I can see why... You're doing the autodev populate prior to any of the mounts being performed, so that "private" root file system is not bound to the directory at that time. Drop that bind mount for the rootfs and this then worked like a charm: -- lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 -- I think that rootfs directory bind was an effort to more fully match the OpenVZ behavior but also trying to deal with some of the read-only problems were where having in the past with shutdowns. If it won't work, it won't work and I won't miss it. I did see some errors setting up that dev... -- [root at forest mhw]# lxc-start -n Alcove lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) Welcome to Fedora 17 (Beefy Miracle)! -- Not sure what that's all about but, since systemd isn't going to start getty's on the tty? interfaces anyways, it probably doesn't make much difference. Regards, Mike > > Yes, we can create the /dev directory with tmpfs from a template. > > Problem is that /dev/pts does not exist at the time we need to mount the > > devpts on /dev/pts for the pty's so that hurls chunks and dies. We > > can't create the /dev/ directory contents prior to mounting in the > > pre-mount hook because we won't have tmpfs in place at the time. We > > have to get tmpfs mounted on /dev and then create /dev/pts and then > > mount the ptys in there. There has to be a mkdir in between those two > > mount actions. Simplest solution would seem to be to add some logic to > > the mount logic that says "test if directory exists and, if not, create > > it." I'm not sure of the consequences of that, though. > > > > I don't see a way to make this happen with hooks. It's almost like we > > need and on-mount per mount hook. > > Should be moot given my patch, which I intend to push this week, but why > couldn't a lxc.hook.mount do the whole thing, mount /dev and and populate > it? I wasn't thinking a lxc.hook.start, for the reasons you encountered, > but I assume you tried lxc.hook.mount and it failed? > > Patch below: > > Index: lxc-qp/src/lxc/conf.c > =================================================================== > --- lxc-qp.orig/src/lxc/conf.c 2012-10-27 17:24:50.768383000 -0500 > +++ lxc-qp/src/lxc/conf.c 2012-10-28 05:44:07.871228322 -0500 > @@ -619,7 +619,7 @@ > } > > if (mount(pty_info->name, lxcpath, "none", MS_BIND, 0)) { > - WARN("failed to mount '%s'->'%s'", > + SYSERROR("failed to mount '%s'->'%s'", > pty_info->name, path); > continue; > } > @@ -636,7 +636,7 @@ > } > } else { > if (mount(pty_info->name, path, "none", MS_BIND, 0)) { > - WARN("failed to mount '%s'->'%s'", > + SYSERROR("failed to mount '%s'->'%s'", > pty_info->name, path); > continue; > } > @@ -842,6 +842,67 @@ > return 0; > } > > +struct lxc_devs { > + char *name; > + mode_t mode; > + int maj; > + int min; > +}; > + > +struct lxc_devs lxc_devs[] = { > + { "null", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 }, > + { "zero", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 }, > + { "full", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 7 }, > + { "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 }, > + { "random", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 8 }, > + { "tty", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 5, 0 }, > + { "console", S_IFCHR | S_IRUSR | S_IWUSR, 5, 1 }, > +}; > + > +/* > + * Do we want to add options for max size of /dev and a file to > + * specify which devices to create? > + */ > +static int setup_autodev(char *root) > +{ > + int ret; > + struct lxc_devs *d; > + char path[MAXPATHLEN]; > + int i; > + > + INFO("Creating and populating /dev under %s\n", root); > + ret = snprintf(path, MAXPATHLEN, "%s/dev", root); > + if (ret < 0 || ret > MAXPATHLEN) > + return -1; > + ret = mount("none", path, "tmpfs", 0, "size=100000"); > + if (ret) { > + SYSERROR("Failed to mount /dev at %s\n", root); > + return -1; > + } > + for (i = 0; i < sizeof(lxc_devs) / sizeof(lxc_devs[0]); i++) { > + d = &lxc_devs[i]; > + ret = snprintf(path, MAXPATHLEN, "%s/dev/%s", root, d->name); > + if (ret < 0 || ret >= MAXPATHLEN) > + return -1; > + ret = mknod(path, d->mode, makedev(d->maj, d->min)); > + if (ret) { > + SYSERROR("Error creating %s\n", d->name); > + return -1; > + } > + } > + ret = snprintf(path, MAXPATHLEN, "%s/dev/pts", root); > + if (ret < 0 || ret >= MAXPATHLEN) > + return -1; > + ret = mkdir(path, S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH); > + if (ret) { > + SYSERROR("Failed to create /dev/pts in container"); > + return -1; > + } > + > + INFO("Populated /dev under %s\n", root); > + return 0; > +} > + > static int setup_rootfs(const struct lxc_rootfs *rootfs) > { > if (!rootfs->path) > @@ -2208,6 +2269,13 @@ > return -1; > } > > + if (lxc_conf->autodev) { > + if (setup_autodev(lxc_conf->rootfs.mount)) { > + ERROR("failed to set up /dev in the container"); > + return -1; > + } > + } > + > if (setup_mount(&lxc_conf->rootfs, lxc_conf->fstab, name)) { > ERROR("failed to setup the mounts for '%s'", name); > return -1; > Index: lxc-qp/src/lxc/conf.h > =================================================================== > --- lxc-qp.orig/src/lxc/conf.h 2012-10-27 17:24:50.768383000 -0500 > +++ lxc-qp/src/lxc/conf.h 2012-10-27 17:24:50.768383000 -0500 > @@ -227,6 +227,7 @@ > struct lxc_list hooks[NUM_LXC_HOOKS]; > char *seccomp; // filename with the seccomp rules > int maincmd_fd; > + int autodev; // if 1, mount and fill a /dev at start > }; > > int run_lxc_hooks(const char *name, char *hook, struct lxc_conf *conf); > Index: lxc-qp/src/lxc/confile.c > =================================================================== > --- lxc-qp.orig/src/lxc/confile.c 2012-10-27 17:24:50.768383000 -0500 > +++ lxc-qp/src/lxc/confile.c 2012-10-27 17:24:50.768383000 -0500 > @@ -77,6 +77,7 @@ > static int config_seccomp(const char *, char *, struct lxc_conf *); > static int config_includefile(const char *, char *, struct lxc_conf *); > static int config_network_nic(const char *, char *, struct lxc_conf *); > +static int config_autodev(const char *, char *, struct lxc_conf *); > > typedef int (*config_cb)(const char *, char *, struct lxc_conf *); > > @@ -118,6 +119,7 @@ > { "lxc.console", config_console }, > { "lxc.seccomp", config_seccomp }, > { "lxc.include", config_includefile }, > + { "lxc.autodev", config_autodev }, > }; > > static const size_t config_size = sizeof(config)/sizeof(struct lxc_config_t); > @@ -853,6 +855,16 @@ > > return 0; > } > + > +static int config_autodev(const char *key, char *value, > + struct lxc_conf *lxc_conf) > +{ > + int v = atoi(value); > + > + lxc_conf->autodev = v; > + > + return 0; > +} > > static int config_aa_profile(const char *key, char *value, > struct lxc_conf *lxc_conf) > > ------------------------------------------------------------------------------ > WINDOWS 8 is here. > Millions of people. Your app in 30 days. > Visit The Windows 8 Center at Sourceforge for all your go to resources. > http://windows8center.sourceforge.net/ > join-generation-app-and-make-money-coding-fast/ > _______________________________________________ > Lxc-devel mailing list > Lxc-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Sun Oct 28 22:02:32 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Sun, 28 Oct 2012 23:02:32 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351460035.5001.57.camel@canyon.wittsend.com> References: <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> Message-ID: <20121028220232.GA4638@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > On Sat, 2012-10-27 at 13:51 -0400, Michael H. Warfield wrote: > > > > On Sat, 2012-10-27 at 13:40 -0400, Michael H. Warfield wrote: > > > > > /me erasing everything at this point and taking off the systemd crew, > > > > > since this will have no relevance to them... > > > > > > > > > > Testing the hook feature out using git rev (finally got it built)... > > > > > > > > > > I added this line to my config... > > > > > > > > > > lxc.mount.entry=tmpfs /srv/lxc/private/Plover/dev.tmp tmpfs defaults 0 0 > > > > > lxc.hook.mount = /var/lib/lxc/Plover/mount > > > > > > > > > > In /var/lib/lxc/Plover/mount I have this: > > > > > > > > > > -- > > > > > rsync -avAH /srv/lxc/private/Plover/dev.template/. /srv/lxc/private/Plover/dev.tmp/ > > > > > -- > > > > > > > > > (This is just testing out the concepts. > > > > > > > > > If I understand this correctly, lxc.hook.pre-mount runs BEFORE the > > > > > mounting takes place and lxc.hook.mount takes place after the mount. > > > > > > > > > Problem is, the result of that rsync is not showing up in the mounted > > > > > tmpfs file system but is showing up in the underlying parent file system > > > > > as if it were run pre-mount. Something not right here... > > > > > > > I changed it to "lxc.hook.start = /srv/lxc/mount" (where I put the > > > > script in the container) which then works but that then requires the > > > > template and the command to be in the container. Suboptimal to say the > > > > least. But it gives me a way to test this tmpfs thing out. > > > > > > > I also noticed that the .start hook runs, it appears, after caps are > > > > dropped and I see a lot of bitching about mknod on certain devices. I > > > > had to thrown an exit 0 into that script so it would continue in spite > > > > of the errors but, now, I can refine my template based on what it could > > > > create. > > > > > > Crap. I've got a catch-22 here... This is going to take some work. > > > Hey, > > > I've got a rather minimal patch (appended below) to add the support for > > mounting and populating a minimal /dev working. (A few hours were wasted > > due to my not knowing that upstart was going to issue mounted-dev even though > > /dev was mounted before upstart started - and the mounted-dev hook deletes > > and recreates all consoles. GAH) > > I am happy to report that, after manually editing my git head branch to Sorry, it was against the ubuntu quantal package. I've been in the air without onboard wifi, so working with what i had at hand. > patch in the failed hunks, I was able to build it and test it and my > Fedora 17 systemd based container fired right up after adding the > lxc.autodev = 1 parameter to the config file. Yeah!!!! > > I did run into one gotcha, but one I can live with. I had been bind > mounting the private root file system to another directory and then > using that as the rootfs like this: > > -- > lxc.rootfs = /srv/lxc/rootfs > lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > lxc.autodev = 1 > -- > > This did not work and I got the startup error that it can not mount > to /dev because it doesn't exist. Hm, yeah. If you do need to play a game like this, you might be best off using a pre-mount hook for that. > I believe I can see why... You're doing the autodev populate prior to > any of the mounts being performed, so that "private" root file system is > not bound to the directory at that time. > > Drop that bind mount for the rootfs and this then worked like a charm: > > -- > lxc.rootfs = /srv/lxc/private/Alcove > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > lxc.autodev = 1 > -- > > I think that rootfs directory bind was an effort to more fully match the > OpenVZ behavior but also trying to deal with some of the read-only > problems were where having in the past with shutdowns. If it won't > work, it won't work and I won't miss it. > > I did see some errors setting up that dev... > > -- > [root at forest mhw]# lxc-start -n Alcove > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > Welcome to Fedora 17 (Beefy Miracle)! > > -- > > Not sure what that's all about but, since systemd isn't going to start > getty's on the tty? interfaces anyways, it probably doesn't make much > difference. Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev we should create the tty files. I need to fix that. Of course in your case since systemd isn't going to start getty's on them, you should not have the lxc.tty = 6 in your container config, which it looks like you still do? From mhw at WittsEnd.com Mon Oct 29 01:35:50 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Sun, 28 Oct 2012 21:35:50 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121028220232.GA4638@serge-ThinkPad-X130e> References: <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> Message-ID: <1351474550.5001.73.camel@canyon.wittsend.com> On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote: : > > > I've got a rather minimal patch (appended below) to add the support for > > > mounting and populating a minimal /dev working. (A few hours were wasted > > > due to my not knowing that upstart was going to issue mounted-dev even though > > > /dev was mounted before upstart started - and the mounted-dev hook deletes > > > and recreates all consoles. GAH) > > > > I am happy to report that, after manually editing my git head branch to > Sorry, it was against the ubuntu quantal package. I've been in the air > without onboard wifi, so working with what i had at hand. Oh, I figured it was a package mismatch. Wasn't too terribly difficult to patch those hunks in and kick out a diff against git. > > patch in the failed hunks, I was able to build it and test it and my > > Fedora 17 systemd based container fired right up after adding the > > lxc.autodev = 1 parameter to the config file. Yeah!!!! > > > > I did run into one gotcha, but one I can live with. I had been bind > > mounting the private root file system to another directory and then > > using that as the rootfs like this: > > > > -- > > lxc.rootfs = /srv/lxc/rootfs > > lxc.mount.entry=/srv/lxc/private/Alcove /srv/lxc/rootfs none bind.shared 0 0 > > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > > > lxc.autodev = 1 > > -- > > > > This did not work and I got the startup error that it can not mount > > to /dev because it doesn't exist. > Hm, yeah. If you do need to play a game like this, you might be best > off using a pre-mount hook for that. Yeah, I don't think I "need to play a game like this" anymore. I'd have to go back through some old old E-Mails to see why I did that before. I seem to recall we were playing with all sorts of bind mount options for some PRIVATE thing or another. It may not be necessary at all any longer. IAC, it's minor to switch it back. I seem to recall switching back and forth using bind mounts several times back when that got done that way. I may play with the pre-mount hook just for giggles and see how that might work as well. Any idea why I was experiencing the problem with the mount hook when trying to populate /dev? I know it wouldn't have worked because of the /dev/pts mount but I have more heartburn in that it looks like it ran too early and the mount on /dev had not even taken place at that time. > > I believe I can see why... You're doing the autodev populate prior to > > any of the mounts being performed, so that "private" root file system is > > not bound to the directory at that time. > > > > Drop that bind mount for the rootfs and this then worked like a charm: > > > > -- > > lxc.rootfs = /srv/lxc/private/Alcove > > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > > > lxc.autodev = 1 > > -- > > > > I think that rootfs directory bind was an effort to more fully match the > > OpenVZ behavior but also trying to deal with some of the read-only > > problems were where having in the past with shutdowns. If it won't > > work, it won't work and I won't miss it. > > > > I did see some errors setting up that dev... > > > > -- > > [root at forest mhw]# lxc-start -n Alcove > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > -- > > > > Not sure what that's all about but, since systemd isn't going to start > > getty's on the tty? interfaces anyways, it probably doesn't make much > > difference. > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > we should create the tty files. I need to fix that. Cool. Once again... Looks like we got some real progress here with this one. I've still got more testing to do, undoing some of my changes in the container itself and making sure it all still works. Also looks like I can stop and restart one of these containers now without the hung cgroup directory. I suspected it was some stray devices behind that. This is good. > Of course in your case since systemd isn't going to start getty's on > them, you should not have the lxc.tty = 6 in your container config, > which it looks like you still do? Yeah. I was taking it one step at a time. I wish they WOULD fire up some getty's on those tty's since that basically makes lxc-console kinda useless and the one on /dev/console is kinda useless in disconnected mode with the console redirected to a file. Maybe we need some what for lxc-console to be able to grab that? I'll have to look deeper at systemd and figure out if it can be parameterized or conditionalized in some way. ITMT, I probably will just turn them off. Many thanks! Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Mon Oct 29 09:18:45 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Mon, 29 Oct 2012 10:18:45 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351474550.5001.73.camel@canyon.wittsend.com> References: <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> Message-ID: <20121029091845.GA7338@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at WittsEnd.com): ... > Yeah, I don't think I "need to play a game like this" anymore. I'd have > to go back through some old old E-Mails to see why I did that before. I > seem to recall we were playing with all sorts of bind mount options for > some PRIVATE thing or another. It may not be necessary at all any > longer. IAC, it's minor to switch it back. I seem to recall switching > back and forth using bind mounts several times back when that got done > that way. > > I may play with the pre-mount hook just for giggles and see how that > might work as well. Any idea why I was experiencing the problem with > the mount hook when trying to populate /dev? I know it wouldn't have The only idea I have is that perhaps your root is MS_SHARED by default? Can you post the script you were using and the container config? > worked because of the /dev/pts mount but I have more heartburn in that > it looks like it ran too early and the mount on /dev had not even taken > place at that time. > > > > I believe I can see why... You're doing the autodev populate prior to > > > any of the mounts being performed, so that "private" root file system is > > > not bound to the directory at that time. > > > > > > Drop that bind mount for the rootfs and this then worked like a charm: > > > > > > -- > > > lxc.rootfs = /srv/lxc/private/Alcove > > > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > > > > > lxc.autodev = 1 > > > -- > > > > > > I think that rootfs directory bind was an effort to more fully match the > > > OpenVZ behavior but also trying to deal with some of the read-only > > > problems were where having in the past with shutdowns. If it won't > > > work, it won't work and I won't miss it. > > > > > > I did see some errors setting up that dev... > > > > > > -- > > > [root at forest mhw]# lxc-start -n Alcove > > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > > > -- > > > > > > Not sure what that's all about but, since systemd isn't going to start > > > getty's on the tty? interfaces anyways, it probably doesn't make much > > > difference. > > > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > > we should create the tty files. I need to fix that. > > Cool. Once again... Looks like we got some real progress here with > this one. I've still got more testing to do, undoing some of my changes > in the container itself and making sure it all still works. > > Also looks like I can stop and restart one of these containers now > without the hung cgroup directory. I suspected it was some stray > devices behind that. This is good. > > > Of course in your case since systemd isn't going to start getty's on > > them, you should not have the lxc.tty = 6 in your container config, > > which it looks like you still do? > > Yeah. I was taking it one step at a time. I wish they WOULD fire up > some getty's on those tty's since that basically makes lxc-console kinda As I recall, you can specify gettys to start on any tty by creating a magical symlink, something like $ETC/getty.target.wants/getty\@tty{1,2,3,4,5,6}.service > useless and the one on /dev/console is kinda useless in disconnected > mode with the console redirected to a file. Maybe we need some what for > lxc-console to be able to grab that? I'll have to look deeper at > systemd and figure out if it can be parameterized or conditionalized in > some way. ITMT, I probably will just turn them off. > > Many thanks! > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! From j.schauer at email.de Mon Oct 29 09:36:07 2012 From: j.schauer at email.de (Johannes Schauer) Date: Mon, 29 Oct 2012 10:36:07 +0100 Subject: [Lxc-users] creating debian container on debian sid Message-ID: <20121029093607.GA12924@hoothoot> Hi, I'm using LXC 0.8.0~rc1-13 on Debian Sid but after running: sudo lxc-create -n myfirstcontainer -t debian -- --preseed-file /usr/share/doc/lxc/examples/lxc-debian.cfg and then: sudo lxc-start -n myfirstcontainer But the login prompt never appears. Is this a problem in the preseed file? Or a problem with the configuration script? Find all the output after this mail. Is above command supposed to work? If not, why and how to change it? I found some similar problems in the debian bugtracker but they are either closed as being fixed or only apply to the LXC version in debian wheezy. cheers, josch josch at hoothoot> sudo lxc-create -n myfirstcontainer -t debian -- --preseed-file /usr/share/doc/lxc/examples/lxc-debian.cfg Note: Usually the template option is called with a configuration file option too, mostly to configure the network. For more information look at lxc.conf (5) Downloading minimal system... P: Retrieving InRelease W: Couldn't download InRelease! P: Retrieving Release P: Retrieving Release.gpg P: Validating Release I: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) " I: Good signature from "Squeeze Stable Release Key " P: Parsing Release P: Retrieving Packages.gz P: Validating Packages.gz P: Parsing Packages P: Retrieving libc-bin P: Validating libc-bin P: Retrieving gcc-4.4-base P: Validating gcc-4.4-base P: Retrieving libgcc1 P: Validating libgcc1 P: Retrieving libc6 P: Validating libc6 P: Retrieving libstdc++6 P: Validating libstdc++6 P: Retrieving zlib1g P: Validating zlib1g P: Retrieving libbz2-1.0 P: Validating libbz2-1.0 P: Retrieving libselinux1 P: Validating libselinux1 P: Retrieving libattr1 P: Validating libattr1 P: Retrieving libacl1 P: Validating libacl1 P: Retrieving coreutils P: Validating coreutils P: Retrieving liblzma2 P: Validating liblzma2 P: Retrieving xz-utils P: Validating xz-utils P: Retrieving dpkg P: Validating dpkg P: Retrieving readline-common P: Validating readline-common P: Retrieving libncurses5 P: Validating libncurses5 P: Retrieving libreadline6 P: Validating libreadline6 P: Retrieving libusb-0.1-4 P: Validating libusb-0.1-4 P: Retrieving gpgv P: Validating gpgv P: Retrieving gnupg P: Validating gnupg P: Retrieving debian-archive-keyring P: Validating debian-archive-keyring P: Retrieving apt P: Validating apt P: Retrieving mawk P: Validating mawk P: Retrieving base-files P: Validating base-files P: Retrieving base-passwd P: Validating base-passwd P: Retrieving sensible-utils P: Validating sensible-utils P: Retrieving debianutils P: Validating debianutils P: Retrieving dash P: Validating dash P: Retrieving bash P: Validating bash P: Retrieving bsdutils P: Validating bsdutils P: Retrieving bzip2 P: Validating bzip2 P: Retrieving libncursesw5 P: Validating libncursesw5 P: Retrieving dialog P: Validating dialog P: Retrieving diffutils P: Validating diffutils P: Retrieving e2fslibs P: Validating e2fslibs P: Retrieving perl-base P: Validating perl-base P: Retrieving liblocale-gettext-perl P: Validating liblocale-gettext-perl P: Retrieving libtext-iconv-perl P: Validating libtext-iconv-perl P: Retrieving libtext-charwidth-perl P: Validating libtext-charwidth-perl P: Retrieving libtext-wrapi18n-perl P: Validating libtext-wrapi18n-perl P: Retrieving debconf-i18n P: Validating debconf-i18n P: Retrieving debconf P: Validating debconf P: Retrieving libpam0g P: Validating libpam0g P: Retrieving libdb4.8 P: Validating libdb4.8 P: Retrieving libpam-modules P: Validating libpam-modules P: Retrieving passwd P: Validating passwd P: Retrieving libuuid1 P: Validating libuuid1 P: Retrieving libblkid1 P: Validating libblkid1 P: Retrieving libcomerr2 P: Validating libcomerr2 P: Retrieving libss2 P: Validating libss2 P: Retrieving sed P: Validating sed P: Retrieving ncurses-bin P: Validating ncurses-bin P: Retrieving lsb-base P: Validating lsb-base P: Retrieving tzdata P: Validating tzdata P: Retrieving libsepol1 P: Validating libsepol1 P: Retrieving mount P: Validating mount P: Retrieving sysvinit-utils P: Validating sysvinit-utils P: Retrieving insserv P: Validating insserv P: Retrieving sysv-rc P: Validating sysv-rc P: Retrieving initscripts P: Validating initscripts P: Retrieving libslang2 P: Validating libslang2 P: Retrieving util-linux P: Validating util-linux P: Retrieving e2fsprogs P: Validating e2fsprogs P: Retrieving findutils P: Validating findutils P: Retrieving grep P: Validating grep P: Retrieving gzip P: Validating gzip P: Retrieving hostname P: Validating hostname P: Retrieving net-tools P: Validating net-tools P: Retrieving ifupdown P: Validating ifupdown P: Retrieving iproute P: Validating iproute P: Retrieving isc-dhcp-common P: Validating isc-dhcp-common P: Retrieving isc-dhcp-client P: Validating isc-dhcp-client P: Retrieving perl-modules P: Validating perl-modules P: Retrieving libdb4.7 P: Validating libdb4.7 P: Retrieving libgdbm3 P: Validating libgdbm3 P: Retrieving perl P: Validating perl P: Retrieving libui-dialog-perl P: Validating libui-dialog-perl P: Retrieving locales P: Validating locales P: Retrieving libpam-runtime P: Validating libpam-runtime P: Retrieving login P: Validating login P: Retrieving ncurses-base P: Validating ncurses-base P: Retrieving netbase P: Validating netbase P: Retrieving libkeyutils1 P: Validating libkeyutils1 P: Retrieving libkrb5support0 P: Validating libkrb5support0 P: Retrieving libk5crypto3 P: Validating libk5crypto3 P: Retrieving libkrb5-3 P: Validating libkrb5-3 P: Retrieving libgssapi-krb5-2 P: Validating libgssapi-krb5-2 P: Retrieving libssl0.9.8 P: Validating libssl0.9.8 P: Retrieving libwrap0 P: Validating libwrap0 P: Retrieving libbsd0 P: Validating libbsd0 P: Retrieving libedit2 P: Validating libedit2 P: Retrieving adduser P: Validating adduser P: Retrieving openssh-client P: Validating openssh-client P: Retrieving openssh-blacklist P: Validating openssh-blacklist P: Retrieving procps P: Validating procps P: Retrieving openssh-server P: Validating openssh-server P: Retrieving sysvinit P: Validating sysvinit P: Retrieving tar P: Validating tar P: Retrieving user-setup P: Validating user-setup P: Extracting libc-bin P: Extracting gcc-4.4-base P: Extracting libc6 P: Extracting libgcc1 P: Extracting libstdc++6 P: Extracting zlib1g P: Extracting libselinux1 P: Extracting libattr1 P: Extracting libacl1 P: Extracting coreutils P: Extracting liblzma2 P: Extracting xz-utils P: Extracting libbz2-1.0 P: Extracting dpkg P: Extracting libncurses5 P: Extracting mawk P: Extracting base-files P: Extracting base-passwd P: Extracting sensible-utils P: Extracting debianutils P: Extracting dash P: Extracting bash P: Extracting bsdutils P: Extracting diffutils P: Extracting e2fslibs P: Extracting perl-base P: Extracting liblocale-gettext-perl P: Extracting libtext-iconv-perl P: Extracting libtext-charwidth-perl P: Extracting libtext-wrapi18n-perl P: Extracting debconf P: Extracting debconf-i18n P: Extracting libpam0g P: Extracting libdb4.8 P: Extracting libpam-modules P: Extracting passwd P: Extracting libuuid1 P: Extracting libblkid1 P: Extracting libcomerr2 P: Extracting libss2 P: Extracting sed P: Extracting ncurses-bin P: Extracting lsb-base P: Extracting tzdata P: Extracting libsepol1 P: Extracting mount P: Extracting sysvinit-utils P: Extracting insserv P: Extracting sysv-rc P: Extracting initscripts P: Extracting libslang2 P: Extracting util-linux P: Extracting e2fsprogs P: Extracting findutils P: Extracting grep P: Extracting gzip P: Extracting hostname P: Extracting libpam-runtime P: Extracting login P: Extracting ncurses-base P: Extracting sysvinit P: Extracting tar P: Unpacking package dpkg P: Configuring package dpkg P: Configuring helper cdebootstrap-helper-rc.d P: Configuring helper cdebootstrap-helper-makedev P: Unpacking package libc-bin P: Unpacking package gcc-4.4-base P: Unpacking package libc6 P: Unpacking package libgcc1 P: Unpacking package libstdc++6 P: Unpacking package zlib1g P: Unpacking package libselinux1 P: Unpacking package libattr1 P: Unpacking package libacl1 P: Unpacking package coreutils P: Unpacking package liblzma2 P: Unpacking package xz-utils P: Unpacking package libncurses5 P: Unpacking package mawk P: Unpacking package base-files P: Unpacking package base-passwd P: Unpacking package sensible-utils P: Unpacking package debianutils P: Unpacking package libbz2-1.0 P: Unpacking package dash P: Unpacking package bash P: Unpacking package bsdutils P: Unpacking package diffutils P: Unpacking package e2fslibs P: Unpacking package perl-base P: Unpacking package liblocale-gettext-perl P: Unpacking package libtext-iconv-perl P: Unpacking package libtext-charwidth-perl P: Unpacking package libtext-wrapi18n-perl P: Unpacking package debconf P: Unpacking package debconf-i18n P: Unpacking package libpam0g P: Unpacking package libdb4.8 P: Unpacking package libpam-modules P: Unpacking package passwd P: Unpacking package libuuid1 P: Unpacking package libblkid1 P: Unpacking package libcomerr2 P: Unpacking package libss2 P: Unpacking package sed P: Unpacking package ncurses-bin P: Unpacking package lsb-base P: Unpacking package tzdata P: Unpacking package libsepol1 P: Unpacking package mount P: Unpacking package sysvinit-utils P: Unpacking package insserv P: Unpacking package sysv-rc P: Unpacking package initscripts P: Unpacking package libslang2 P: Unpacking package util-linux P: Unpacking package e2fsprogs P: Unpacking package findutils P: Unpacking package grep P: Unpacking package gzip P: Unpacking package hostname P: Unpacking package libpam-runtime P: Unpacking package login P: Unpacking package ncurses-base P: Unpacking package sysvinit P: Unpacking package tar P: Configuring package ncurses-base P: Configuring package sensible-utils P: Configuring package libc-bin P: Configuring package gcc-4.4-base P: Configuring package libc6 P: Configuring package debianutils P: Configuring package bsdutils P: Configuring package perl-base P: Configuring package libsepol1 P: Configuring package diffutils P: Configuring package tar P: Configuring package zlib1g P: Configuring package libgcc1 P: Configuring package libtext-iconv-perl P: Configuring package libncurses5 P: Configuring package libattr1 P: Configuring package e2fslibs P: Configuring package base-passwd P: Configuring package libcomerr2 P: Configuring package mawk P: Configuring package libdb4.8 P: Configuring package grep P: Configuring package hostname P: Configuring package libacl1 P: Configuring package libslang2 P: Configuring package libss2 P: Configuring package findutils P: Configuring package liblzma2 P: Configuring package insserv P: Configuring package gzip P: Configuring package liblocale-gettext-perl P: Configuring package libbz2-1.0 P: Configuring package libselinux1 P: Configuring package libstdc++6 P: Configuring package libtext-charwidth-perl P: Configuring package libtext-wrapi18n-perl P: Configuring package dash P: Configuring package coreutils P: Configuring package ncurses-bin P: Configuring package base-files P: Configuring package sed P: Configuring package debconf-i18n P: Configuring package xz-utils P: Configuring package sysvinit-utils P: Configuring package bash P: Configuring package debconf P: Configuring package lsb-base P: Configuring package libpam0g P: Configuring package sysv-rc P: Configuring package libpam-modules P: Configuring package tzdata P: Configuring package passwd P: Configuring package libpam-runtime P: Configuring package login P: Configuring package libuuid1 P: Configuring package libblkid1 P: Configuring package mount P: Configuring package initscripts P: Configuring package util-linux P: Configuring package sysvinit P: Configuring package e2fsprogs P: Unpacking package readline-common P: Unpacking package libreadline6 P: Unpacking package libusb-0.1-4 P: Unpacking package gpgv P: Unpacking package gnupg P: Unpacking package debian-archive-keyring P: Unpacking package apt P: Configuring package readline-common P: Configuring package libreadline6 P: Configuring package libusb-0.1-4 P: Configuring package gpgv P: Configuring package gnupg P: Configuring package debian-archive-keyring P: Configuring package apt P: Configuring helper cdebootstrap-helper-apt P: Unpacking package openssh-blacklist P: Unpacking package adduser P: Unpacking package net-tools P: Unpacking package ifupdown P: Unpacking package iproute P: Unpacking package isc-dhcp-common P: Unpacking package isc-dhcp-client P: Unpacking package libgdbm3 P: Unpacking package libncursesw5 P: Unpacking package libssl0.9.8 P: Unpacking package netbase P: Unpacking package procps P: Unpacking package libdb4.7 P: Unpacking package libbsd0 P: Unpacking package libedit2 P: Unpacking package libkeyutils1 P: Unpacking package libkrb5support0 P: Unpacking package libk5crypto3 P: Unpacking package libkrb5-3 P: Unpacking package libgssapi-krb5-2 P: Unpacking package locales P: Unpacking package openssh-client P: Unpacking package perl-modules P: Unpacking package perl P: Unpacking package bzip2 P: Unpacking package dialog P: Unpacking package libwrap0 P: Unpacking package openssh-server P: Unpacking package libui-dialog-perl P: Unpacking package user-setup P: Configuring package openssh-blacklist P: Configuring package adduser P: Configuring package net-tools P: Configuring package ifupdown P: Configuring package iproute P: Configuring package isc-dhcp-common P: Configuring package isc-dhcp-client P: Configuring package libgdbm3 P: Configuring package libncursesw5 P: Configuring package libssl0.9.8 P: Configuring package netbase P: Configuring package procps P: Configuring package libdb4.7 P: Configuring package libbsd0 P: Configuring package libedit2 P: Configuring package libkeyutils1 P: Configuring package libkrb5support0 P: Configuring package libk5crypto3 P: Configuring package libkrb5-3 P: Configuring package libgssapi-krb5-2 P: Configuring package locales P: Configuring package openssh-client P: Configuring package bzip2 P: Configuring package dialog P: Configuring package libwrap0 P: Configuring package openssh-server P: Configuring package user-setup P: Configuring package perl-modules P: Configuring package perl P: Configuring package libui-dialog-perl P: Deconfiguring helper cdebootstrap-helper-apt P: Deconfiguring helper cdebootstrap-helper-makedev P: Writing apt sources.list P: Writing hosts P: Writing resolv.conf (Reading database ... 8838 files and directories currently installed.) Removing cdebootstrap-helper-rc.d ... Download complete. Get:1 http://ftp.ch.debian.org squeeze Release.gpg [1672 B] Ign http://ftp.ch.debian.org/debian/ squeeze/main Translation-en Get:2 http://ftp.ch.debian.org squeeze Release [99.8 kB] Get:3 http://ftp.ch.debian.org squeeze/main amd64 Packages [6539 kB] Fetched 6641 kB in 10s (639 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Hit http://ftp.ch.debian.org squeeze Release.gpginer/rootfs... Ign http://ftp.ch.debian.org/debian/ squeeze/main Translation-en Get:1 http://ftp.ch.debian.org squeeze/updates Release.gpg [836 B] Ign http://ftp.ch.debian.org/debian-security/ squeeze/updates/main Translation-en Get:2 http://ftp.ch.debian.org squeeze-updates Release.gpg [836 B] Ign http://ftp.ch.debian.org/debian/ squeeze-updates/main Translation-en Get:3 http://ftp.ch.debian.org squeeze-backports Release.gpg [836 B] Ign http://ftp.ch.debian.org/debian-backports/ squeeze-backports/main Translation-en Hit http://ftp.ch.debian.org squeeze Release Get:4 http://ftp.ch.debian.org squeeze/updates Release [86.9 kB] Get:5 http://ftp.ch.debian.org squeeze-updates Release [113 kB] Get:6 http://ftp.ch.debian.org squeeze-backports Release [77.6 kB] Hit http://ftp.ch.debian.org squeeze/main amd64 Packages Get:7 http://ftp.ch.debian.org squeeze/updates/main amd64 Packages [269 kB] Get:8 http://ftp.ch.debian.org squeeze-updates/main amd64 Packages [4661 B] Get:9 http://ftp.ch.debian.org squeeze-backports/main amd64 Packages [474 kB] Fetched 1028 kB in 2s (511 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: isc-dhcp-client isc-dhcp-common tzdata 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 1263 kB of archives. After this operation, 295 kB disk space will be freed. Get:1 http://ftp.ch.debian.org/debian/ squeeze-updates/main tzdata all 2012g-0squeeze1 [642 kB] Get:2 http://ftp.ch.debian.org/debian-security/ squeeze/updates/main isc-dhcp-client amd64 4.1.1-P1-15+squeeze8 [281 kB] Get:3 http://ftp.ch.debian.org/debian-security/ squeeze/updates/main isc-dhcp-common amd64 4.1.1-P1-15+squeeze8 [339 kB] Fetched 1263 kB in 1s (721 kB/s) debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 8837 files and directories currently installed.) Preparing to replace tzdata 2012c-0squeeze1 (using .../tzdata_2012g-0squeeze1_all.deb) ... Unpacking replacement tzdata ... Setting up tzdata (2012g-0squeeze1) ... Current default time zone: 'Etc/UTC' Local time is now: Mon Oct 29 09:18:14 UTC 2012. Universal Time is now: Mon Oct 29 09:18:14 UTC 2012. Run 'dpkg-reconfigure tzdata' if you wish to change it. (Reading database ... 8837 files and directories currently installed.) Preparing to replace isc-dhcp-client 4.1.1-P1-15+squeeze6 (using .../isc-dhcp-client_4.1.1-P1-15+squeeze8_amd64.deb) ... Unpacking replacement isc-dhcp-client ... Preparing to replace isc-dhcp-common 4.1.1-P1-15+squeeze6 (using .../isc-dhcp-common_4.1.1-P1-15+squeeze8_amd64.deb) ... Unpacking replacement isc-dhcp-common ... Setting up isc-dhcp-common (4.1.1-P1-15+squeeze8) ... Setting up isc-dhcp-client (4.1.1-P1-15+squeeze8) ... Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Use of uninitialized value in numeric ge (>=) at /usr/share/perl5/Debconf/Priority.pm line 24, line 5. Use of uninitialized value in numeric ge (>=) at /usr/share/perl5/Debconf/Priority.pm line 24, line 8. Current default time zone: 'Etc/UTC' Local time is now: Mon Oct 29 09:18:22 UTC 2012. Universal Time is now: Mon Oct 29 09:18:22 UTC 2012. Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package live-debconfig /usr/bin/env: live-debconfig: No such file or directory /usr/bin/env: live-debconfig: No such file or directory Shadow passwords are now on. Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 'debian' template installed 'myfirstcontainer' created josch at hoothoot> sudo lxc-start -n myfirstcontainer Mount failed for selinuxfs on /selinux: Operation not permitted INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. mount: permission denied mount: permission denied hostname: you must be root to change the host name Setting the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Unable to set System Clock to: Mon Oct 29 09:18:54 UTC 2012 ... (warning). Activating swap...done. mount: permission denied Cleaning up ifupdown.... Setting the system clock. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Unable to set System Clock to: Mon Oct 29 09:18:54 UTC 2012 ... (warning). Setting up networking.... Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 done. Mounting local filesystems...done. Activating swapfile swap...done. Cleaning up temporary files.... Configuring network interfaces...done. Cleaning up temporary files.... Setting kernel variables ...done. startpar: service(s) returned failure: hostname.sh ... failed! INIT: Entering runlevel: 2 Using makefile-style concurrent boot in runlevel 2. Starting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key . INIT: Id "6" respawning too fast: disabled for 5 minutes INIT: Id "1" respawning too fast: disabled for 5 minutes INIT: Id "5" respawning too fast: disabled for 5 minutes INIT: Id "3" respawning too fast: disabled for 5 minutes INIT: Id "4" respawning too fast: disabled for 5 minutes INIT: Id "2" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel INIT: Id "2" respawning too fast: disabled for 5 minutes INIT: Id "5" respawning too fast: disabled for 5 minutes INIT: Id "4" respawning too fast: disabled for 5 minutes INIT: Id "1" respawning too fast: disabled for 5 minutes INIT: Id "3" respawning too fast: disabled for 5 minutes INIT: Id "6" respawning too fast: disabled for 5 minutes From kalyanceg at gmail.com Mon Oct 29 10:22:38 2012 From: kalyanceg at gmail.com (Kalyana sundaram) Date: Mon, 29 Oct 2012 15:52:38 +0530 Subject: [Lxc-users] Regarding connecting containers to vlan Message-ID: Hi I am pretty new to lxc I have set up lxc centos containers on centos host. The centos host is connected to our private network (vlan id 211) How could I make these containers also to connect to the same private network -- Kalyanasundaram http://blogs.eskratch.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Mon Oct 29 10:26:38 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Mon, 29 Oct 2012 17:26:38 +0700 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: On Mon, Oct 29, 2012 at 5:22 PM, Kalyana sundaram wrote: > > Hi > I am pretty new to lxc > I have set up lxc centos containers on centos host. The centos host is > connected to our private network (vlan id 211) What do you use on the host? eth0, or eth0.211? > How could I make these containers also to connect to the same private > network Simply put: create a bridge for that interface (Google "centos bridge howto"), and set the container to use that bridge (lxc.network.link) -- Fajar From kalyanceg at gmail.com Mon Oct 29 10:32:25 2012 From: kalyanceg at gmail.com (Kalyana sundaram) Date: Mon, 29 Oct 2012 16:02:25 +0530 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: Hey, I am trying to pass multiple vlans on to a single interface. My switch is already configured as a trunk and therefore is passing multiple vlans. * Do I need to set a bridge ip or can I just add to bridge_ports the physical interfaces * My container is set to use the lxc.network.link as the bridge. Do I also need to mention the vlan ? On Mon, Oct 29, 2012 at 3:56 PM, Fajar A. Nugraha wrote: > On Mon, Oct 29, 2012 at 5:22 PM, Kalyana sundaram > wrote: > > > > Hi > > I am pretty new to lxc > > I have set up lxc centos containers on centos host. The centos host is > > connected to our private network (vlan id 211) > > What do you use on the host? eth0, or eth0.211? > > > How could I make these containers also to connect to the same private > > network > > Simply put: create a bridge for that interface (Google "centos bridge > howto"), and set the container to use that bridge (lxc.network.link) > > -- > Fajar > -- Kalyanasundaram http://blogs.eskratch.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kalyanceg at gmail.com Mon Oct 29 10:34:55 2012 From: kalyanceg at gmail.com (Kalyana sundaram) Date: Mon, 29 Oct 2012 16:04:55 +0530 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: By the way my interface is eth0.211 On Mon, Oct 29, 2012 at 4:02 PM, Kalyana sundaram wrote: > Hey, > > I am trying to pass multiple vlans on to a single interface. > My switch is already configured as a trunk and therefore is passing > multiple vlans. > > * Do I need to set a bridge ip or can I just add to bridge_ports the > physical interfaces > * My container is set to use the lxc.network.link as the bridge. Do I also > need to mention the vlan ? > > > On Mon, Oct 29, 2012 at 3:56 PM, Fajar A. Nugraha wrote: > >> On Mon, Oct 29, 2012 at 5:22 PM, Kalyana sundaram >> wrote: >> > >> > Hi >> > I am pretty new to lxc >> > I have set up lxc centos containers on centos host. The centos host is >> > connected to our private network (vlan id 211) >> >> What do you use on the host? eth0, or eth0.211? >> >> > How could I make these containers also to connect to the same private >> > network >> >> Simply put: create a bridge for that interface (Google "centos bridge >> howto"), and set the container to use that bridge (lxc.network.link) >> >> -- >> Fajar >> > > > > -- > Kalyanasundaram > http://blogs.eskratch.com/ > -- Kalyanasundaram http://blogs.eskratch.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.schauer at email.de Mon Oct 29 20:58:29 2012 From: j.schauer at email.de (Johannes Schauer) Date: Mon, 29 Oct 2012 21:58:29 +0100 Subject: [Lxc-users] creating debian container on debian sid In-Reply-To: <20121029093607.GA12924@hoothoot> References: <20121029093607.GA12924@hoothoot> Message-ID: <20121029205829.GA28398@hoothoot> Hi, On Mon, Oct 29, 2012 at 10:36:07AM +0100, Johannes Schauer wrote: > I'm using LXC 0.8.0~rc1-13 on Debian Sid but after running: > > sudo lxc-create -n myfirstcontainer -t debian -- --preseed-file /usr/share/doc/lxc/examples/lxc-debian.cfg > > and then: > > sudo lxc-start -n myfirstcontainer > > But the login prompt never appears. Is this a problem in the preseed > file? Or a problem with the configuration script? Maybe the problem is, that the package live-debconfig is only available in Debian Sid and not in wheezy? With a modified preseed file that selects sid instead of wheezy everything works like a charm. An additional question though: Even though I have the following lines in my preseed file: live-debconfig live-debconfig/hostname/hostname string debian live-debconfig live-debconfig/ifupdown/eth0-method select dhcp live-debconfig live-debconfig/selinux/enable boolean false live-debconfig live-debconfig/sysvinit/lxc-enable boolean true live-debconfig live-debconfig/sysvinit/lxc-consoles string 6 the live-debconfig configuration still asks for all those values. How do I avoid that it asks for them but instead uses the values I supply in my preseed file? cheers, josch From daniel.baumann at progress-technologies.net Tue Oct 30 05:46:11 2012 From: daniel.baumann at progress-technologies.net (Daniel Baumann) Date: Tue, 30 Oct 2012 06:46:11 +0100 Subject: [Lxc-users] creating debian container on debian sid In-Reply-To: <20121029205829.GA28398@hoothoot> References: <20121029093607.GA12924@hoothoot> <20121029205829.GA28398@hoothoot> Message-ID: <508F69A3.4060500@progress-technologies.net> On 10/29/2012 09:58 PM, Johannes Schauer wrote: > the live-debconfig configuration still asks for all those values. How do > I avoid that it asks for them but instead uses the values I supply in my > preseed file? you need to preseed debconf priority an frontend in the preseed file, plus this: http://sources.progress-linux.org/gitweb/?p=people/daniel/packages/lxc.git;a=commitdiff;h=a8a9b50a0a8934abc531ecdb3724801806189ee5 -- Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baumann at progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ From mhw at WittsEnd.com Tue Oct 30 17:23:41 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Tue, 30 Oct 2012 13:23:41 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121028220232.GA4638@serge-ThinkPad-X130e> References: <1351186511.5181.51.camel@canyon.wittsend.com> <20121025190221.GA11683@sergelap> <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> Message-ID: <1351617821.5001.178.camel@canyon.wittsend.com> On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): : > > I did see some errors setting up that dev... > > > > -- > > [root at forest mhw]# lxc-start -n Alcove > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > -- > > > > Not sure what that's all about but, since systemd isn't going to start > > getty's on the tty? interfaces anyways, it probably doesn't make much > > difference. > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > we should create the tty files. I need to fix that. Well... I'm not sure I understand what you mean by that. The /dev/pts/* entries do does exist in the host system. But the bind mount fails saying they do not exist. Not sure I understand what the problem is here but I would like them connected even if systemd doesn't start getty's on them. I've used them for other purposes in the past. > Of course in your case since systemd isn't going to start getty's on > them, you should not have the lxc.tty = 6 in your container config, > which it looks like you still do? Actually, I've decided this is worthy of debugging and there may be other ways to start a getty (or something else) on that tty. It really should work. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From bmullan.mail at gmail.com Tue Oct 30 17:39:15 2012 From: bmullan.mail at gmail.com (brian mullan) Date: Tue, 30 Oct 2012 13:39:15 -0400 Subject: [Lxc-users] Regarding connecting containers to vlan Message-ID: Kalyana & Fajar I know this answer isn't about VLAN specifically but it might interest you. I'd stumbled upon it a few weeks ago and the title was *"Connecting containers on several hosts with Open vSwitch"* http://s3hh.wordpress.com/2012/05/28/connecting-containers-on-several-hosts-with-open-vswitch/ There was also a newer post regarding Open vSwitch and LXC: http://s3hh.wordpress.com/ ---------- Forwarded message ---------- From: Kalyana sundaram To: "Fajar A. Nugraha" Cc: lxc-users at lists.sourceforge.net Date: Mon, 29 Oct 2012 16:02:25 +0530 Subject: Re: [Lxc-users] Regarding connecting containers to vlan Hey, I am trying to pass multiple vlans on to a single interface. My switch is already configured as a trunk and therefore is passing multiple vlans. * Do I need to set a bridge ip or can I just add to bridge_ports the physical interfaces * My container is set to use the lxc.network.link as the bridge. Do I also need to mention the vlan ? On Mon, Oct 29, 2012 at 3:56 PM, Fajar A. Nugraha wrote: > On Mon, Oct 29, 2012 at 5:22 PM, Kalyana sundaram > wrote: > > > > Hi > > I am pretty new to lxc > > I have set up lxc centos containers on centos host. The centos host is > > connected to our private network (vlan id 211) > > What do you use on the host? eth0, or eth0.211? > > > How could I make these containers also to connect to the same private > > network > > Simply put: create a bridge for that interface (Google "centos bridge > howto"), and set the container to use that bridge (lxc.network.link) > > -- > Fajar > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 493 bytes Desc: not available URL: From serge.hallyn at canonical.com Tue Oct 30 18:35:45 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Tue, 30 Oct 2012 19:35:45 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351617821.5001.178.camel@canyon.wittsend.com> References: <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351617821.5001.178.camel@canyon.wittsend.com> Message-ID: <20121030183545.GA17522@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > : > > > > I did see some errors setting up that dev... > > > > > > -- > > > [root at forest mhw]# lxc-start -n Alcove > > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > > > -- > > > > > > Not sure what that's all about but, since systemd isn't going to start > > > getty's on the tty? interfaces anyways, it probably doesn't make much > > > difference. > > > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > > we should create the tty files. I need to fix that. > > Well... I'm not sure I understand what you mean by that. > The /dev/pts/* entries do does exist in the host system. But the bind > mount fails saying they do not exist. Not sure I understand what the In Ubuntu, we use lxc.ttydir = lxc. That means the actual /dev/ttyN in the container is a symlink to /dev/lxc/ttyN (to allow package upgrades which insist on removing /dev/ttyN to succeed - they will fail if /dev/ttyN is mounted over). When /dev was pre-populated, /dev/ttyN existed. But when we are populating it, it does not. So before we try tomount /dev/pts/NN from the host onto /dev/ttyN in the container, we have to create a file to bind mount over. I didn't put that in the patch. Yet. > problem is here but I would like them connected even if systemd doesn't > start getty's on them. I've used them for other purposes in the past. > > > Of course in your case since systemd isn't going to start getty's on > > them, you should not have the lxc.tty = 6 in your container config, > > which it looks like you still do? > > Actually, I've decided this is worthy of debugging and there may be > other ways to start a getty (or something else) on that tty. It really > should work. > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users From mhw at WittsEnd.com Tue Oct 30 18:39:48 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Tue, 30 Oct 2012 14:39:48 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121030183545.GA17522@serge-ThinkPad-X130e> References: <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351617821.5001.178.camel@canyon.wittsend.com> <20121030183545.GA17522@serge-ThinkPad-X130e> Message-ID: <1351622388.5001.179.camel@canyon.wittsend.com> On Tue, 2012-10-30 at 19:35 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote: > > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > > > : > > > > > > I did see some errors setting up that dev... > > > > > > > > -- > > > > [root at forest mhw]# lxc-start -n Alcove > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > > > > > -- > > > > > > > > Not sure what that's all about but, since systemd isn't going to start > > > > getty's on the tty? interfaces anyways, it probably doesn't make much > > > > difference. > > > > > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > > > we should create the tty files. I need to fix that. > > > > Well... I'm not sure I understand what you mean by that. > > The /dev/pts/* entries do does exist in the host system. But the bind > > mount fails saying they do not exist. Not sure I understand what the > In Ubuntu, we use lxc.ttydir = lxc. That means the actual /dev/ttyN in the > container is a symlink to /dev/lxc/ttyN (to allow package upgrades which > insist on removing /dev/ttyN to succeed - they will fail if /dev/ttyN is > mounted over). > When /dev was pre-populated, /dev/ttyN existed. But when we are populating > it, it does not. So before we try tomount /dev/pts/NN from the host onto > /dev/ttyN in the container, we have to create a file to bind mount over. > I didn't put that in the patch. Yet. Got it! You and I both did the same thing. I'm thinking from the view of Fedora and you're thinking from the view of Ubuntu. Got it. We'll get this right yet. :-)=) > > problem is here but I would like them connected even if systemd doesn't > > start getty's on them. I've used them for other purposes in the past. > > > > > Of course in your case since systemd isn't going to start getty's on > > > them, you should not have the lxc.tty = 6 in your container config, > > > which it looks like you still do? > > > > Actually, I've decided this is worthy of debugging and there may be > > other ways to start a getty (or something else) on that tty. It really > > should work. > > > > Regards, > > Mike > > -- > > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > _______________________________________________ > > Lxc-users mailing list > > Lxc-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-users > > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From mhw at WittsEnd.com Tue Oct 30 20:59:14 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Tue, 30 Oct 2012 16:59:14 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121029091845.GA7338@serge-ThinkPad-X130e> References: <1351194174.5181.55.camel@canyon.wittsend.com> <1351220366.5181.63.camel@canyon.wittsend.com> <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> Message-ID: <1351630754.5001.196.camel@canyon.wittsend.com> On Mon, 2012-10-29 at 10:18 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at WittsEnd.com): > ... > > Yeah, I don't think I "need to play a game like this" anymore. I'd have > > to go back through some old old E-Mails to see why I did that before. I > > seem to recall we were playing with all sorts of bind mount options for > > some PRIVATE thing or another. It may not be necessary at all any > > longer. IAC, it's minor to switch it back. I seem to recall switching > > back and forth using bind mounts several times back when that got done > > that way. > > > > I may play with the pre-mount hook just for giggles and see how that > > might work as well. Any idea why I was experiencing the problem with > > the mount hook when trying to populate /dev? I know it wouldn't have > The only idea I have is that perhaps your root is MS_SHARED by default? > Can you post the script you were using and the container config? Another point on the curve... The documentation says that "pre-mount" takes place before the mount occurs and "mount takes place after the mount occurs. Only problem is that "pre-mount" is not being recognized. lxc-start 1351627853.032 ERROR lxc_confile - unknown key lxc.hook.pre-mount This is the same binaries from git that recognize lxc.hook.mount so I'm assuming the doco and the code don't match at this point. Even without my original bind mount, if I have a mount hook that does something in a newly mounted tmpfs directory, it doesn't show up in that directory it shows up in the parent directory as if it ran before the mounts took place. I could put the mount in the hook.mount script and then do it but it's seriously acting like the pre-mount hook isn't even there (parameter unknown) and the mount hook is running before the mounts are complete. Simple exerts from some test scripts doing, really, nothing but testing sequencing... Ok... Lets try this. I won't post entire configs but... For machine Alcove (my testbed)... -- lxc.tty = 6 lxc.pts = 64 lxc.rootfs = /srv/lxc/private/Alcove lxc.mount.entry=none /srv/lxc/private/Alcove/dev.tmp tmpfs defaults 0 0 lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 lxc.autodev = 1 # lxc.hook.pre-mount = /var/lib/lxc/Alcove/pre-mount lxc.hook.mount = /var/lib/lxc/Alcove/mount lxc.mount.entry=shmfs /var/lib/lxc/private/Alcove/dev/shm tmpfs mode=0644 0 0 -- Now /var/lib/lxc/Alcove/mount: -- #!/bin/sh - touch /srv/lxc/private/Alcove/dev.tmp/mounted -- In that directory on the host fs I have this: [root at forest mhw]# touch /srv/lxc/private/Alcove/dev.tmp/no-mounted [root at forest mhw]# ls /srv/lxc/private/Alcove/dev.tmp/ no-mounted Now, when I start the container, the tmpfs should get mounted on /dev.tmp in the container (relative to the container rootfs) and should have the single file "mounted" in it while the parent file system back on the host should have the single file "not-mounted" in it. Let's see... lxc-start -n Alcove... In the container... [mhw at alcove ~]$ mount | grep tmpfs none on /dev type tmpfs (rw,relatime,seclabel,size=100k) none on /dev.tmp type tmpfs (rw,relatime,seclabel) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel) tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755) Looks like the mount took place. I have tmpfs on /dev.tmp [mhw at alcove ~]$ ls /dev.tmp/ [mhw at alcove ~]$ Opps... Where did the file end up? Let's look on the host... [mhw at forest ~]$ ls /srv/lxc/private/Alcove/dev.tmp/ mounted no-mounted Arg... Wrong answer. It ended up in the parent file system before tmpfs was mounted. But, the documentation says hook.mount runs after the mounts have completed. There's something wrong here or I am badly mistaken in my understanding... (Probably the later, I'll admit.) Regards, Mike > > worked because of the /dev/pts mount but I have more heartburn in that > > it looks like it ran too early and the mount on /dev had not even taken > > place at that time. > > > > > > I believe I can see why... You're doing the autodev populate prior to > > > > any of the mounts being performed, so that "private" root file system is > > > > not bound to the directory at that time. > > > > > > > > Drop that bind mount for the rootfs and this then worked like a charm: > > > > > > > > -- > > > > lxc.rootfs = /srv/lxc/private/Alcove > > > > lxc.mount.entry=/home/shared /srv/lxc/private/Alcove/srv/shared none ro,bind 0 0 > > > > > > > > lxc.autodev = 1 > > > > -- > > > > > > > > I think that rootfs directory bind was an effort to more fully match the > > > > OpenVZ behavior but also trying to deal with some of the read-only > > > > problems were where having in the past with shutdowns. If it won't > > > > work, it won't work and I won't miss it. > > > > > > > > I did see some errors setting up that dev... > > > > > > > > -- > > > > [root at forest mhw]# lxc-start -n Alcove > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/59'->'/usr/lib64/lxc/rootfs/dev/tty1' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/60'->'/usr/lib64/lxc/rootfs/dev/tty2' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/61'->'/usr/lib64/lxc/rootfs/dev/tty3' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/62'->'/usr/lib64/lxc/rootfs/dev/tty4' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/63'->'/usr/lib64/lxc/rootfs/dev/tty5' > > > > lxc-start: No such file or directory - failed to mount '/dev/pts/64'->'/usr/lib64/lxc/rootfs/dev/tty6' > > > > systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora) > > > > > > > > Welcome to Fedora 17 (Beefy Miracle)! > > > > > > > > -- > > > > > > > > Not sure what that's all about but, since systemd isn't going to start > > > > getty's on the tty? interfaces anyways, it probably doesn't make much > > > > difference. > > > > > Oh, I see. Yeah, in the !lxc.ttydir case, when we created our own /dev > > > we should create the tty files. I need to fix that. > > > > Cool. Once again... Looks like we got some real progress here with > > this one. I've still got more testing to do, undoing some of my changes > > in the container itself and making sure it all still works. > > > > Also looks like I can stop and restart one of these containers now > > without the hung cgroup directory. I suspected it was some stray > > devices behind that. This is good. > > > > > Of course in your case since systemd isn't going to start getty's on > > > them, you should not have the lxc.tty = 6 in your container config, > > > which it looks like you still do? > > > > Yeah. I was taking it one step at a time. I wish they WOULD fire up > > some getty's on those tty's since that basically makes lxc-console kinda > > As I recall, you can specify gettys to start on any tty by creating a > magical symlink, something like > > $ETC/getty.target.wants/getty\@tty{1,2,3,4,5,6}.service > > > useless and the one on /dev/console is kinda useless in disconnected > > mode with the console redirected to a file. Maybe we need some what for > > lxc-console to be able to grab that? I'll have to look deeper at > > systemd and figure out if it can be parameterized or conditionalized in > > some way. ITMT, I probably will just turn them off. > > > > Many thanks! > > > > Regards, > > Mike > > -- > > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! > > > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From gt0057 at gmail.com Tue Oct 30 21:55:34 2012 From: gt0057 at gmail.com (Giuseppe Tofoni) Date: Tue, 30 Oct 2012 22:55:34 +0100 Subject: [Lxc-users] Lxc with Slackware 14 64bit will not start. In-Reply-To: References: <20121028175306.GB3007@serge-ThinkPad-X130e> Message-ID: 2012/10/30 Giuseppe Tofoni : > 2012/10/28 Serge Hallyn : >> Quoting Giuseppe Tofoni (gt0057 at gmail.com): >>> Hello, >>> >>> First thanks for your great work. >>> >>> I am a happy user of LXC with Slackware 13.37 and lxc-0.7.4.2, but >>> with slack64 14.0 and lxc-0.8.0-rc2 I get the following errors: >>> >>> lxc-start: No such file or directory - failed to exec /sbin/init >>> lxc-start: invalid sequence number 1. expected 2 >>> lxc-start: failed to spawn 'lxc_999' >>> lxc-start: No such file or directory - failed to remove cgroup >>> '/cgroup//lxc/lxc_999' >> >> Hi, >> >> can you tell us your cgroup setup in detail, and do >> >> lxc-start -n lxc_999 -l debug -o outout >> >> and then send us outout? >> >> thanks, >> -serge > Hi Serge, I have not recompiled the kernel is the standard of slackware64bit. In attachment I put the output of "lxc-start -n lxc_999 -l debug -o outout" the output of the command lxc-checkconfig and the file .config. Thanks again Giuseppe -------------- next part -------------- A non-text attachment was scrubbed... Name: lxc.txt.gz Type: application/x-gzip Size: 32944 bytes Desc: not available URL: From serge.hallyn at canonical.com Wed Oct 31 03:45:25 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Wed, 31 Oct 2012 04:45:25 +0100 Subject: [Lxc-users] Lxc with Slackware 14 64bit will not start. In-Reply-To: References: <20121028175306.GB3007@serge-ThinkPad-X130e> Message-ID: <20121031034525.GA24321@serge-ThinkPad-X130e> Quoting Giuseppe Tofoni (gt0057 at gmail.com): > 2012/10/28 Serge Hallyn : > > Quoting Giuseppe Tofoni (gt0057 at gmail.com): > >> Hello, > >> > >> First thanks for your great work. > >> > >> I am a happy user of LXC with Slackware 13.37 and lxc-0.7.4.2, but > >> with slack64 14.0 and lxc-0.8.0-rc2 I get the following errors: > >> > >> lxc-start: No such file or directory - failed to exec /sbin/init > >> lxc-start: invalid sequence number 1. expected 2 > >> lxc-start: failed to spawn 'lxc_999' > >> lxc-start: No such file or directory - failed to remove cgroup > >> '/cgroup//lxc/lxc_999' > > > > Hi, > > > > can you tell us your cgroup setup in detail, and do > > > > lxc-start -n lxc_999 -l debug -o outout > > > > and then send us outout? > > > > thanks, > > -serge > > Hi Serge, > > I have not recompiled the kernel is the standard of slackware64bit. > In attachment I put the output of "lxc-start -n lxc_999 -l debug -o Thanks - the output file shows lxc-start 1351632919.916 NOTICE lxc_start - exec'ing '/sbin/init' lxc-start 1351632919.916 ERROR lxc_start - No such file or directory - failed to exec /sbin/init /sbin did get bind-mounted from the host - does it not have an init? -serge From list at fajar.net Wed Oct 31 04:09:09 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Wed, 31 Oct 2012 11:09:09 +0700 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 12:39 AM, brian mullan wrote: > Kalyana & Fajar > > I know this answer isn't about VLAN specifically but it might interest you. > I'd stumbled upon it a few weeks ago and the title was > "Connecting containers on several hosts with Open vSwitch" > > http://s3hh.wordpress.com/2012/05/28/connecting-containers-on-several-hosts-with-open-vswitch/ > > There was also a newer post regarding Open vSwitch and LXC: > http://s3hh.wordpress.com/ Last time I tested, openvswicth is more powerful, but kinda complicated for new users who are used to linux bridge. Anyway, back to Kalyana's requirement, you can either: - bridge the trunk (eth0) to the container, and create vlan on the interface in container side (i.e. create eth0.100 in the container) - bridge the vlan interface (eth0.100) to the container, and use the interface on container side (eth0) directly as regular interface -- Fajar From kalyanceg at gmail.com Wed Oct 31 12:11:28 2012 From: kalyanceg at gmail.com (Kalyana sundaram) Date: Wed, 31 Oct 2012 17:41:28 +0530 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: Thanks Fajar. Atlast I got the vlan thingy working I added 2 vlans to eth0 (eth0.211 and eth0.103) and connected them to bridge br0 and used br0 as a link to container(veth) To reach the host I used another interface eth1(probably assigning ip to bridge br0 would have solved that problem) i should give openvswitch a try. Thanks for the link On Wed, Oct 31, 2012 at 9:39 AM, Fajar A. Nugraha wrote: > On Wed, Oct 31, 2012 at 12:39 AM, brian mullan > wrote: > > Kalyana & Fajar > > > > I know this answer isn't about VLAN specifically but it might interest > you. > > I'd stumbled upon it a few weeks ago and the title was > > "Connecting containers on several hosts with Open vSwitch" > > > > > http://s3hh.wordpress.com/2012/05/28/connecting-containers-on-several-hosts-with-open-vswitch/ > > > > There was also a newer post regarding Open vSwitch and LXC: > > http://s3hh.wordpress.com/ > > > Last time I tested, openvswicth is more powerful, but kinda > complicated for new users who are used to linux bridge. > > Anyway, back to Kalyana's requirement, you can either: > - bridge the trunk (eth0) to the container, and create vlan on the > interface in container side (i.e. create eth0.100 in the container) > - bridge the vlan interface (eth0.100) to the container, and use the > interface on container side (eth0) directly as regular interface > > -- > Fajar > -- Kalyanasundaram http://blogs.eskratch.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at fajar.net Wed Oct 31 12:48:31 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Wed, 31 Oct 2012 19:48:31 +0700 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 7:11 PM, Kalyana sundaram wrote: > Thanks Fajar. Atlast I got the vlan thingy working > I added 2 vlans to eth0 (eth0.211 and eth0.103) and connected them to bridge You assigned eth0 (the trunk) to the bridge, right? Just checking. Cause if you DON'T assign the trunk, but rather BOTH vlan interface (eth0.211 AND eth0.103) to the SAME bridge, bad things WILL happen :) > br0 and used br0 as a link to container(veth) > To reach the host I used another interface eth1 That's the easy way. > (probably assigning ip to > bridge br0 would have solved that problem) If eth0 is the trunk, and you assign it on br0, you should be able to create a vlan interface (e.g. br0.100) and put ip on that vlan interface instead. Note that if you use this approach, you should NOT create a vlan interface on top of the bridge using the vlan that you pass thru to the container. That is, you must NOT create br0.211 and br0.103. There are ways around this though. For example, by creating another veth pair, assigining one to the bridge, and create vlan on the pair interface. It's somewhat a hassle, but should work. Confused? Welcome to linux bridge :D Openvswitch should be able to work around this cleanly, if you can master the interface (don't rely on linux bridge compatibility code). -- Fajar From kalyanceg at gmail.com Wed Oct 31 14:24:44 2012 From: kalyanceg at gmail.com (Kalyana sundaram) Date: Wed, 31 Oct 2012 19:54:44 +0530 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: My bad, I bridged eth0.211 and eth0.103 with br0. Could I know the problems it would cause? I love the way of creating a vlan interface and putting an ip over it. should try that On Wed, Oct 31, 2012 at 6:18 PM, Fajar A. Nugraha wrote: > On Wed, Oct 31, 2012 at 7:11 PM, Kalyana sundaram > wrote: > > Thanks Fajar. Atlast I got the vlan thingy working > > I added 2 vlans to eth0 (eth0.211 and eth0.103) and connected them to > bridge > > You assigned eth0 (the trunk) to the bridge, right? > > Just checking. Cause if you DON'T assign the trunk, but rather BOTH > vlan interface (eth0.211 AND eth0.103) to the SAME bridge, bad things > WILL happen :) > > > br0 and used br0 as a link to container(veth) > > To reach the host I used another interface eth1 > > That's the easy way. > > > (probably assigning ip to > > bridge br0 would have solved that problem) > > If eth0 is the trunk, and you assign it on br0, you should be able to > create a vlan interface (e.g. br0.100) and put ip on that vlan > interface instead. Note that if you use this approach, you should NOT > create a vlan interface on top of the bridge using the vlan that you > pass thru to the container. That is, you must NOT create br0.211 and > br0.103. > > There are ways around this though. For example, by creating another > veth pair, assigining one to the bridge, and create vlan on the pair > interface. It's somewhat a hassle, but should work. > > Confused? Welcome to linux bridge :D > > Openvswitch should be able to work around this cleanly, if you can > master the interface (don't rely on linux bridge compatibility code). > > -- > Fajar > -- Kalyanasundaram http://blogs.eskratch.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.lezcano at free.fr Wed Oct 31 16:22:46 2012 From: daniel.lezcano at free.fr (Daniel Lezcano) Date: Wed, 31 Oct 2012 17:22:46 +0100 Subject: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053 In-Reply-To: References: Message-ID: <50915056.2040100@free.fr> Thanks to everyone for fixing this. I am about to release the 0.8.0 version. I will wait a couple of days before adding a tag and release it in case there are some fixes to add. Please test. Thanks ! -- Daniel On 10/31/2012 04:45 PM, Daniel Lezcano wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "lxc". > > The branch, master has been updated > via 7f99e339363d9f005c9386f60a1d8c0953c85053 (commit) > via 773fb9cad76f43540fddb78c7ffef7237a51a06d (commit) > via 8215fe8e4186ebe8cb79fe4b773f5bcffcdc723b (commit) > via 192df6e2eb8ebb1a337c7ba025c57852d38e0d26 (commit) > via c215bff6dfc298bdd6150e11b8c0f76c9d013a0a (commit) > via 0b53175846e704fc4dd4cf8b4590a86db63e50e6 (commit) > via a1bd64823cd5e5afc53ba24940a51151e34b8103 (commit) > via bf7d76cf3ae180820c0a29e0bfbaa97c20ce6a3d (commit) > via d4eb4ab1290def213396611f5946ef3b7f0d83ef (commit) > via 5ae26abb52046b6f21afa06bcbac221c3cf8f1c0 (commit) > via 06a1e1db99844b95e21c3b67964974f9032720ea (commit) > via 3b9bad3d638ea442bfe6ba7e677cd5c6d39c0916 (commit) > via c12e775237976bc0c1cf8afdc7aa766de46d3d40 (commit) > via c6ed4d048deea85ed3bec67c7a04fb6c97009321 (commit) > via 3f16e26c7063f5004cafe4cfd6d084b7e4d08d1f (commit) > via 91a5df88ad29bcbc485baa51eacf0b851c6f4834 (commit) > via 1bd051a6b0a34cb2b2e80584b9fb4643abf1a827 (commit) > via 5d38621d0bb9b398393806b875d612a05e76c06e (commit) > via 8aba484aeaccda2881300ff80e9d7dfaaa842b40 (commit) > via 5d01f6167c2354637e777650558be6d7d69e2579 (commit) > via 6bc424b5c7c8130ffdb6390eae53b32370a755f8 (commit) > via d595c68add4ef33cf273c455238b018729de00a5 (commit) > via b9cb4325d74fb01dc4e71adc211e7e7052471778 (commit) > via b4578c5b380130a41a69b5b49c970157acaf1dbb (commit) > via b97b78abdac34fabcbbf64ba49ec8c78939124b4 (commit) > via 87af3ecd48587775970c0ca731d50183bd24017e (commit) > via 435d40f7e3dc5b99a5fcbc459f79ba6b04238502 (commit) > via 6bf8daf9a2aa0d226bfd5b60c4b1580d17105320 (commit) > via 70542ef9a1d09ce87c7d40ac5ea1706860edec74 (commit) > via 55116c42e767ce795f796fc51cd2ef7d76cf18af (commit) > via b942e67226af9e690bd63ac440b99aedb6becbb3 (commit) > via fbef4590b7b7186890a7d0cb8be0af2780a2df5f (commit) > via d0a36f2c8b2f41399ae709280cd8b4a2f3bb0165 (commit) > via cb26f1a5eee13afe1a561ebf57245cb8629797b9 (commit) > via 337e14712e2bf568db73dd57c709b3364e26d798 (commit) > via 9ac3ffb51777ee48ffbd42ff3625f63dfe948837 (commit) > via 10f73bfa4aece7707f48379b82e5858d1909d98f (commit) > via e7f40d8aaba2c17b8ccb323b5df20a423ef5d0a0 (commit) > via f02ce27d4b1a9d01b88d0ffaf626e5bafa671bf0 (commit) > via 33f3de4eaaa4e2084ea6e3695e29da5b736f1095 (commit) > via e470cba076535e4e9732173e0e314e473165478c (commit) > via 542939c31bb73bab55f2fd71243b98f5559597d1 (commit) > via b4df0a1eda252bb7efbd4d7453e9e8a57143c528 (commit) > via 06f5c6328b73aad7b138096295357d803db26efa (commit) > via f1ccde27c038e7fb7e538913505248b36ddd9e65 (commit) > via 4a311c1241805dac5893918854fd40f77b2b6f49 (commit) > via 4d5fb23ad827eda17b64676f527c3f168cd56ebd (commit) > via 8b892c55b077d1716eb130e76f9c9725ecb0f73a (commit) > from 60a742e0afd34e02299f64536df35116d68d888d (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 7f99e339363d9f005c9386f60a1d8c0953c85053 > Merge: 60a742e 773fb9c > Author: Daniel Lezcano > Date: Wed Oct 31 16:39:50 2012 +0100 > > Merge branch 'upstream-bugfix' of https://github.com/lxc/lxc > > * 'upstream-bugfix' of https://github.com/lxc/lxc: (47 commits) > replace HOOK define with proper code. > Remove lxc-start-ephemeral from configure.ac > revert devtmpfs in ubuntu templates > lxc-ubuntu{-cloud}: Fix missing "fi" in new devtmpfs code > fix "make rpm" > display warning when yum missing in fedora template > templates: mount devtmpfs in ubuntu containers > handle clone of btrfs snapshots > if the rootfs is a btrfs subvolume, delete it instead of rm -rf > lxc-debian: replace isc-dhcp-server by isc-dhcp-client > lxc-ls: Scan cgroup mount points from fstype and not device > Allow short -h and -n options to lxc-ps > lxc-ubuntu: fix printing of default user > lxc-debian: specify isc-dhcp-server in package list > try to better handle out of date container caches. > link /dev/kmsg to /dev/console in the container > lxc-clone: fix the '--name' parameter > lxc-ls: Use readlink on $directory > lxc-busybox: Use relative mounts in lxc.mount.entry > busybox: for all lib dirs create mounts only if directories exist > ... > > Signed-off-by: Daniel Lezcano > > commit 773fb9cad76f43540fddb78c7ffef7237a51a06d > Author: Serge Hallyn > Date: Tue Sep 4 13:57:39 2012 -0500 > > replace HOOK define with proper code. > > Signed-off-by: Serge Hallyn > > commit 8215fe8e4186ebe8cb79fe4b773f5bcffcdc723b > Author: St??phane Graber > Date: Thu Oct 25 10:43:59 2012 +0200 > > Remove lxc-start-ephemeral from configure.ac > > lxc-start-ephemeral.in ended up in configure.ac as a result of the > cherry-pick. This new tool hasn't been pulled in yet. > > Signed-off-by: St??phane Graber > > commit 192df6e2eb8ebb1a337c7ba025c57852d38e0d26 > Author: Serge Hallyn > Date: Wed Oct 24 11:05:38 2012 -0500 > > revert devtmpfs in ubuntu templates > > devtmpfs is shared between host and containers, and it messes up > lucid containers too. > > Signed-off-by: Serge Hallyn > > commit c215bff6dfc298bdd6150e11b8c0f76c9d013a0a > Author: St??phane Graber > Date: Wed Oct 24 13:05:03 2012 +0200 > > lxc-ubuntu{-cloud}: Fix missing "fi" in new devtmpfs code > > The "if" statement to add devtmpfs was missing a matching "fi" causing parsing > error when using the template. > > Signed-off-by: St??phane Graber > > commit 0b53175846e704fc4dd4cf8b4590a86db63e50e6 > Author: Dwight Engen > Date: Thu Oct 4 12:28:38 2012 -0400 > > fix "make rpm" > > RPM doesn't like "-" in the version number and gives: > "error: line 24: Illegal char '-' in: Version: 0.8.0-rc2" > Other packages (bind-utils for example) have used . instead > of - as a seperator. > > Signed-off-by: Dwight Engen > Signed-off-by: Serge Hallyn > > commit a1bd64823cd5e5afc53ba24940a51151e34b8103 > Author: Dwight Engen > Date: Thu Oct 4 13:12:41 2012 -0400 > > display warning when yum missing in fedora template > > This early exit is preventing the warning message that follows it from > being shown. > > Signed-off-by: Dwight Engen > > commit bf7d76cf3ae180820c0a29e0bfbaa97c20ce6a3d > Author: Serge Hallyn > Date: Thu Oct 4 13:54:00 2012 -0500 > > templates: mount devtmpfs in ubuntu containers > > That way /dev/disk/ exists, and update-grub can succeed. > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1060404 > > commit d4eb4ab1290def213396611f5946ef3b7f0d83ef > Author: Dwight Engen > Date: Wed Sep 26 13:20:30 2012 -0400 > > handle clone of btrfs snapshots > > Fix determination of $oldroot from the config file. The old code had the ' > in the wrong place and didn't account for whitespace between the = and > the rootfs. > > Set $rootfs based on $oldroot instead of forcing it to be in > $lxc_path/$lxc_new/rootfs. This allows for btrfs snapshot to be made even if > $lxc_path isn't on the same filesystem. If $oldroot isn't a subvolume, > fall back to making a copy. > > Signed-off-by: Dwight Engen > > commit 5ae26abb52046b6f21afa06bcbac221c3cf8f1c0 > Author: Dwight Engen > Date: Wed Sep 26 12:59:28 2012 -0400 > > if the rootfs is a btrfs subvolume, delete it instead of rm -rf > > Check if the rootfs is btrfs subvolume, and if so delete it. Otherwise > fall back to the rm -rf. > > Signed-off-by: Dwight Engen > > commit 06a1e1db99844b95e21c3b67964974f9032720ea > Author: St??phane Graber > Date: Mon Sep 24 15:16:25 2012 -0400 > > lxc-debian: replace isc-dhcp-server by isc-dhcp-client > > The DHCP client should be isc-dhcp-client, not isc-dhcp-server. > > Signed-off-by: Serge Hallyn > Signed-off-by: St??phane Graber > > commit 3b9bad3d638ea442bfe6ba7e677cd5c6d39c0916 > Author: Christian Seiler > Date: Mon Sep 24 11:21:48 2012 +0200 > > lxc-ls: Scan cgroup mount points from fstype and not device > > lxc-ls --active now scans mount points that have the 'cgroup' filesystem > type and not the 'cgroup' device name (which is ignored anyway and may be > anything). > > Signed-off-by: Christian Seiler > Cc: Serge Hallyn > > commit c12e775237976bc0c1cf8afdc7aa766de46d3d40 > Author: Dwight Engen > Date: Tue Sep 18 15:58:17 2012 -0400 > > Allow short -h and -n options to lxc-ps > > Signed-off-by: Dwight Engen > > commit c6ed4d048deea85ed3bec67c7a04fb6c97009321 > Author: Serge Hallyn > Date: Wed Sep 19 12:15:51 2012 -0500 > > lxc-ubuntu: fix printing of default user > > If a user is bound into the container, don't claim the default user is > ubuntu. > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1052315 > > Signed-off-by: Serge Hallyn > > commit 3f16e26c7063f5004cafe4cfd6d084b7e4d08d1f > Author: Serge Hallyn > Date: Wed Sep 19 12:14:58 2012 -0500 > > lxc-debian: specify isc-dhcp-server in package list > > dhcp3-client does not exist in testing. > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1052972 > > Signed-off-by: Serge Hallyn > > commit 91a5df88ad29bcbc485baa51eacf0b851c6f4834 > Author: Serge Hallyn > Date: Fri Sep 14 14:43:45 2012 -0500 > > try to better handle out of date container caches. > > For a lucid container, apt-get update before installing the source package for > add-apt-repository, so that apt-get does not fail. > > If apt-get dist-upgrade fails, suggest running lxc-create with -F. > > Signed-off-by: Serge Hallyn > > commit 1bd051a6b0a34cb2b2e80584b9fb4643abf1a827 > Author: Serge Hallyn > Date: Thu Sep 13 09:39:07 2012 -0500 > > link /dev/kmsg to /dev/console in the container > > This way init log messages can be seen on the console. If containerized > syslog ever comes around, we can get rid of this. > > Signed-off-by: Serge Hallyn > > commit 5d38621d0bb9b398393806b875d612a05e76c06e > Author: Serge Hallyn > Date: Thu Sep 13 09:38:11 2012 -0500 > > lxc-clone: fix the '--name' parameter > > The long opt for --name was being incorrectly compared to --new. > > Signed-off-by: Serge Hallyn > > commit 8aba484aeaccda2881300ff80e9d7dfaaa842b40 > Author: St??phane Graber > Date: Wed Sep 12 18:21:00 2012 -0400 > > lxc-ls: Use readlink on $directory > > lxc-ls was failing in cases where $directory is a symlink to another > directory. Instead have $directory be generated from the output of > readlink -f "$lxc_path". > > Signed-off-by: St??phane Graber > > commit 5d01f6167c2354637e777650558be6d7d69e2579 > Author: St??phane Graber > Date: Wed Sep 12 15:22:15 2012 -0400 > > lxc-busybox: Use relative mounts in lxc.mount.entry > > To make it easier to clone/rename the container, replace hardcoded > entries (with rootfs in the destination path) by rootfs-relative entries. > > Signed-off-by: St??phane Graber > > commit 6bc424b5c7c8130ffdb6390eae53b32370a755f8 > Author: Stuart Yoder > Date: Wed Sep 12 13:15:12 2012 -0500 > > busybox: for all lib dirs create mounts only if directories exist > > Signed-off-by: Stuart Yoder > > commit d595c68add4ef33cf273c455238b018729de00a5 > Author: Dwight Engen > Date: Tue Sep 11 17:06:05 2012 -0400 > > fix expansion of LXCPATH,LXCROOTFSMOUNT,LXCTEMPLATEDIR > > These variables are not expanded correctly in doc/lxc-create.sgml.in > and a workaround is in place to ensure ${localstatedir}, and ${datadir} > are set in the various shell scripts that use it. There is no workaround > to ensure ${datadir} is set in src/lxc/lxc-create.in, nor is > ${localstatedir} set in templates/lxc-altlinux.in so I think that these > are currently broken. > > Using AS_AC_EXPAND instead of AC_SUBST fixes these problems and removes > the need for the workarounds. In addition the lxc-start-ephemeral.in > script can be autoconf'ed instead of sed'ed by the makefile. > > Signed-off-by: Dwight Engen > > commit b9cb4325d74fb01dc4e71adc211e7e7052471778 > Author: Dwight Engen > Date: Tue Sep 11 14:30:22 2012 -0400 > > lxc-rpm-build > > Fix building of rpm by non-root user. Include templates in rpm, fix rpm path of > lxc-init. > > Signed-off-by: Dwight Engen > > commit b4578c5b380130a41a69b5b49c970157acaf1dbb > Author: Dwight Engen > Date: Mon Sep 10 16:49:31 2012 -0400 > > lxc-doc-synopsis-args > > I was getting raw nroff ".SH DESCRIPTION" in my man pages. This fixes > the synopsis cmd args so that doesn't happen. Added replaceable to a few > arguments. > > Signed-off-by: Dwight Engen > > commit b97b78abdac34fabcbbf64ba49ec8c78939124b4 > Author: Dwight Engen > Date: Mon Sep 10 10:28:37 2012 -0400 > > lxc-pkgconfig-dir > > Put pkg-config .pc file in libdir. > > Signed-off-by: Dwight Engen > > commit 87af3ecd48587775970c0ca731d50183bd24017e > Author: Serge Hallyn > Date: Thu Sep 6 22:16:55 2012 -0500 > > log errno when pclose fails > > When lxc is executing a script and pclose fails, log the > errno to help debug what happened. > > Signed-off-by: Serge Hallyn > > commit 435d40f7e3dc5b99a5fcbc459f79ba6b04238502 > Author: St??phane Graber > Date: Thu Sep 6 10:59:57 2012 -0400 > > Pass the container name to copy_configuration in lxc-lenny > > This fixes a case where lxc.utsname would be set empty as copy_configuration > wasn't getting the container name. > > Signed-off-by: Rex Tsai (?????????) > Acked-by: St??phane Graber > > commit 6bf8daf9a2aa0d226bfd5b60c4b1580d17105320 > Author: St??phane Graber > Date: Thu Sep 6 10:57:20 2012 -0400 > > Add SIGINT and SIGPWR handler in lxc-debian > > This adds a SIGINIT and SIGPWR handler in the default inittab for > the Debian template. This allows lxc-shutdown/lxc-restart and their API calls > to properly shutdown or reboot the container. > > Signed-off-by: Rex Tsai (?????????) > Acked-by: St??phane Graber > > commit 70542ef9a1d09ce87c7d40ac5ea1706860edec74 > Author: St??phane Graber > Date: Wed Sep 5 23:54:51 2012 -0400 > > Don't hardcode path to templates > > configure.ac used to set the template path to /usr/share/lxc/templates. > Instead use ${datadir} to make it follow ${prefix}. > > Signed-off-by: St??phane Graber > > commit 55116c42e767ce795f796fc51cd2ef7d76cf18af > Author: Serge Hallyn > Date: Wed Sep 5 21:59:13 2012 -0500 > > lxc-destroy: Separately rm rootfs if it is a symlink > > If rootfs is a symbolic link but not to a block device, then do a separate > rm of its contents. We have to do this because, out of cowardice, we call > rm with --one-filesystem. > > Removing the '-o -h $rootdev' is ok, because if $rootdev is a symbolic > link to a block device (including lvm blockdev) then -b will still return > true. > > Signed-off-by: Serge Hallyn > > commit b942e67226af9e690bd63ac440b99aedb6becbb3 > Author: Scott Moser > Date: Tue Sep 4 15:44:25 2012 -0500 > > ubuntu-cloud template cleanups > > Fix for quantal images which do not have the user 'ubuntu' present. > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1045955 > > Signed-off-by: Serge Hallyn > > commit fbef4590b7b7186890a7d0cb8be0af2780a2df5f > Author: Serge Hallyn > Date: Tue Sep 4 14:06:29 2012 -0500 > > add prototype for clone(2) as per manpage > > Signed-off-by: Serge Hallyn > > commit d0a36f2c8b2f41399ae709280cd8b4a2f3bb0165 > Author: St??phane Graber > Date: Sat Sep 1 20:15:31 2012 -0400 > > Add missing include for apparmor.h in conf.c > > This include is conditional on apparmor being selected. > > Signed-off-by: St??phane Graber > > commit cb26f1a5eee13afe1a561ebf57245cb8629797b9 > Author: St??phane Graber > Date: Fri Aug 31 09:17:38 2012 -0700 > > Various fedora template improvements > > 1. don't add network segment to config > 2. check for 'curl' > 3. don't add $name to $path, it's already in there > 4. don't add devpts to fstab, that's wrong. > 5. $UTSNAME doesn't exist > 6. set root pwd to root instead of rooter. > 7. install fedora-release package. > 8. add a console on /dev/console. > 9. create empty fstab > 10. don't mount devpts in rc.sysinit. > > Signed-off-by: Serge Hallyn > Acked-by: St??phane Graber > > commit 337e14712e2bf568db73dd57c709b3364e26d798 > Author: St??phane Graber > Date: Fri Aug 31 09:09:34 2012 -0700 > > sshd: run dhclient; allow adding a root ssh key > > Signed-off-by: Serge Hallyn > Acked-by: St??phane Graber > > commit 9ac3ffb51777ee48ffbd42ff3625f63dfe948837 > Author: St??phane Graber > Date: Fri Aug 31 08:58:56 2012 -0700 > > Make lxc-execute without rootfs work. > > That means, don't try to pin a null rootfs, and don't try to mount /proc > since /var/lib/lxc/root/proc doesn't exist to be mounted onto. > The apparmor patches are not yet upstream, so this patch will not go > upstream by itself. > > Signed-off-by: Serge Hallyn > Acked-by: St??phane Graber > > commit 10f73bfa4aece7707f48379b82e5858d1909d98f > Author: Serge Hallyn > Date: Thu Aug 30 11:02:24 2012 -0500 > > lxc-ubuntu-cloud: get full pathname to userdata file > > When passing '--userdata somefile' to the ubuntu-cloud template, a user > may pass a relative pathname. The template uses the filename after > changing current directory, so store the full pathname for the userdata > file instead of a potential relative pathname. > > Signed-off-by: Serge Hallyn > > commit e7f40d8aaba2c17b8ccb323b5df20a423ef5d0a0 > Author: St??phane Graber > Date: Wed Aug 29 14:42:59 2012 -0700 > > When creating the lxc cgroup directory, ignore -EEXIST > > Signed-off-by: Serge Hallyn > Acked-by: St??phane Graber > commit f02ce27d4b1a9d01b88d0ffaf626e5bafa671bf0 > Author: St??phane Graber > Date: Wed Aug 29 09:27:53 2012 -0700 > > Add lxc.aa_profile example to all templates > > LXC has optional apparmor support, default profile is lxc-container-default. > This change adds a commented "lxc.aa_profile = default" line to all templates, > uncommenting this will bypass apparmor for the container. > > Signed-off-by: St??phane Graber > > commit 33f3de4eaaa4e2084ea6e3695e29da5b736f1095 > Author: St??phane Graber > Date: Wed Aug 29 13:51:37 2012 -0700 > > Don't update the host-name field in dhclient.conf when not hardcoded. > > On Debian and Ubuntu, the default host-name field in dhclient.conf is > set to either "" or "gethostname()" both of which get replaced > by the machine's hostname at query time. > > The sed call currently present in lxc-clone hardcodes the hostname in > dhclient.conf, causing dpkg to prompt on isc-dhcp updates. > > Signed-off-by: St??phane Graber > > commit e470cba076535e4e9732173e0e314e473165478c > Author: St??phane Graber > Date: Tue Aug 28 13:46:59 2012 -0400 > > Use lxc_putold as the pivot_root put dir in the ubuntu templates > > By default we use mnt, but that means that lxc fstab entries do not work > when placed under the container's /mnt/. > > Signed-off-by: Serge Hallyn > Acked-by: St??phane Graber > > commit 542939c31bb73bab55f2fd71243b98f5559597d1 > Author: St??phane Graber > Date: Tue Aug 28 13:42:27 2012 -0400 > > Fix lxc-ubuntu and lxc-ubuntu-cloud to properly deal with /dev/shm. > > Now that initscripts in Debian and Ubuntu has been updated to no longer > do silly things with /dev/shm and /run/shm on installation/update, the > check needs updating to detect any remaining broken case and fix it. > > Signed-off-by: St??phane Graber > > commit b4df0a1eda252bb7efbd4d7453e9e8a57143c528 > Author: Serge Hallyn > Date: Tue Aug 21 10:05:19 2012 -0500 > > lxc_start: exit early if insufficient privs in daemon mode > > Starting a container with insufficient privilege (correctly) fails > during lxc_init. However, if starting a daemonized container, we > daemonize before we get to that check. Therefore while the > container will fail to start, and the logfile will show this, the > 'lxc-start -n x -d' command will return success. For ease of > scripting, do a check for the required privilege before we exit. > > Signed-off-by: Serge Hallyn > > commit 06f5c6328b73aad7b138096295357d803db26efa > Author: Serge Hallyn > Date: Tue Aug 21 09:59:43 2012 -0500 > > ubuntu template: apt-get clean after debootstrapping a cache > > This saves quite a bit of space in the cache and containers. > > See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1037626 for the > original bug report. > > Reported-by: Fajar A. Nugraha > Signed-off-by: Serge Hallyn > > commit f1ccde27c038e7fb7e538913505248b36ddd9e65 > Author: Serge Hallyn > Date: Tue Aug 21 09:56:03 2012 -0500 > > ubuntu and debian templates: Clean up cache if cache build is interrupted > > Otherwise the next lxc-create may rsync a bad cache. > > Signed-off-by: Serge Hallyn > > commit 4a311c1241805dac5893918854fd40f77b2b6f49 > Author: Serge Hallyn > Date: Thu Aug 16 21:11:50 2012 -0500 > > Cleanup partial container if -h was passed to template > > If user calls 'lxc-create -t ubuntu -- -h' (as opposed to > 'lxc-create -t ubuntu -h') then the ubuntu template will print its > help then exit 0. Then lxc-create does not cleanup. So detect this > in lxc-create. > > commit 4d5fb23ad827eda17b64676f527c3f168cd56ebd > Author: Serge Hallyn > Date: Fri Jul 20 10:38:15 2012 -0500 > > lxc-clone: fix handling of lxc.mount entries > > The 'lxc.mount =' entry can have more than one space, or tabs, before the =. > We only need to disambiguate from 'lxc.mount.entry'. So just check for a > space or tab after mount. > > Signed-off-by: Serge Hallyn > > commit 8b892c55b077d1716eb130e76f9c9725ecb0f73a > Author: Serge Hallyn > Date: Thu Jul 19 17:54:54 2012 -0500 > > lxc-clone: change uuid on xfs > > Otherwise after cloning an lvm+xfs container you can't run the > original and clone at the same time. > > Based on a patch by Maurizio Sambati posted at > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1013549 > > Signed-off-by: Serge Hallyn > > ----------------------------------------------------------------------- > > Summary of changes: > Makefile.am | 2 +- > configure.ac | 8 +- > doc/lxc-attach.sgml.in | 11 ++- > doc/lxc-cgroup.sgml.in | 7 +- > doc/lxc-checkpoint.sgml.in | 8 +- > doc/lxc-console.sgml.in | 8 +- > doc/lxc-create.sgml.in | 12 ++-- > doc/lxc-destroy.sgml.in | 7 +- > doc/lxc-execute.sgml.in | 10 ++-- > doc/lxc-freeze.sgml.in | 4 +- > doc/lxc-kill.sgml.in | 4 +- > doc/lxc-ls.sgml.in | 5 +- > doc/lxc-monitor.sgml.in | 4 +- > doc/lxc-ps.sgml.in | 14 ++-- > doc/lxc-restart.sgml.in | 11 ++-- > doc/lxc-shutdown.sgml.in | 7 +- > doc/lxc-start.sgml.in | 16 +++-- > doc/lxc-stop.sgml.in | 4 +- > doc/lxc-unfreeze.sgml.in | 4 +- > doc/lxc-wait.sgml.in | 6 +- > lxc.spec.in | 16 +++-- > src/lxc/cgroup.c | 9 ++- > src/lxc/conf.c | 51 +++++++++++++- > src/lxc/conf.h | 6 -- > src/lxc/lxc-clone.in | 34 ++++++---- > src/lxc/lxc-create.in | 14 ++++- > src/lxc/lxc-destroy.in | 17 ++++-- > src/lxc/lxc-ls.in | 5 +- > src/lxc/lxc-ps.in | 4 +- > src/lxc/lxc-setcap.in | 3 - > src/lxc/lxc-setuid.in | 3 - > src/lxc/lxc_start.c | 16 ++++- > src/lxc/namespace.h | 4 + > src/lxc/start.c | 15 +++- > templates/lxc-altlinux.in | 4 + > templates/lxc-archlinux.in | 4 + > templates/lxc-busybox.in | 30 ++++----- > templates/lxc-debian.in | 19 +++++- > templates/lxc-fedora.in | 55 +++++++++++----- > templates/lxc-lenny.in | 6 ++- > templates/lxc-opensuse.in | 3 + > templates/lxc-sshd.in | 48 ++++++++++++-- > templates/lxc-ubuntu-cloud.in | 144 ++++++++++++++++++++++++----------------- > templates/lxc-ubuntu.in | 43 +++++++++--- > 44 files changed, 465 insertions(+), 240 deletions(-) > > > hooks/post-receive > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > _______________________________________________ > Lxc-devel mailing list > Lxc-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel From mhw at WittsEnd.com Wed Oct 31 16:46:44 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Wed, 31 Oct 2012 12:46:44 -0400 Subject: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053 In-Reply-To: <50915056.2040100@free.fr> References: <50915056.2040100@free.fr> Message-ID: <1351702004.5001.228.camel@canyon.wittsend.com> Wow... Pulling for testing. I see some stuff related to devtmpfs that relates to the systemd / Fedora 17 issues Serge and I have been working on for the last couple of weeks. I'm going to test these out. It's been an intense couple of weeks getting THAT to work. Even without some of the addition tweeks that have been discussed, this is a big step forward. I'm looking forward to 0.80. Regards, Mike On Wed, 2012-10-31 at 17:22 +0100, Daniel Lezcano wrote: > Thanks to everyone for fixing this. > > I am about to release the 0.8.0 version. > > I will wait a couple of days before adding a tag and release it in case > there are some fixes to add. > > Please test. > > Thanks ! > > -- Daniel > > On 10/31/2012 04:45 PM, Daniel Lezcano wrote: > > This is an automated email from the git hooks/post-receive script. It was > > generated because a ref change was pushed to the repository containing > > the project "lxc". > > > > The branch, master has been updated > > via 7f99e339363d9f005c9386f60a1d8c0953c85053 (commit) > > via 773fb9cad76f43540fddb78c7ffef7237a51a06d (commit) > > via 8215fe8e4186ebe8cb79fe4b773f5bcffcdc723b (commit) > > via 192df6e2eb8ebb1a337c7ba025c57852d38e0d26 (commit) > > via c215bff6dfc298bdd6150e11b8c0f76c9d013a0a (commit) > > via 0b53175846e704fc4dd4cf8b4590a86db63e50e6 (commit) > > via a1bd64823cd5e5afc53ba24940a51151e34b8103 (commit) > > via bf7d76cf3ae180820c0a29e0bfbaa97c20ce6a3d (commit) > > via d4eb4ab1290def213396611f5946ef3b7f0d83ef (commit) > > via 5ae26abb52046b6f21afa06bcbac221c3cf8f1c0 (commit) > > via 06a1e1db99844b95e21c3b67964974f9032720ea (commit) > > via 3b9bad3d638ea442bfe6ba7e677cd5c6d39c0916 (commit) > > via c12e775237976bc0c1cf8afdc7aa766de46d3d40 (commit) > > via c6ed4d048deea85ed3bec67c7a04fb6c97009321 (commit) > > via 3f16e26c7063f5004cafe4cfd6d084b7e4d08d1f (commit) > > via 91a5df88ad29bcbc485baa51eacf0b851c6f4834 (commit) > > via 1bd051a6b0a34cb2b2e80584b9fb4643abf1a827 (commit) > > via 5d38621d0bb9b398393806b875d612a05e76c06e (commit) > > via 8aba484aeaccda2881300ff80e9d7dfaaa842b40 (commit) > > via 5d01f6167c2354637e777650558be6d7d69e2579 (commit) > > via 6bc424b5c7c8130ffdb6390eae53b32370a755f8 (commit) > > via d595c68add4ef33cf273c455238b018729de00a5 (commit) > > via b9cb4325d74fb01dc4e71adc211e7e7052471778 (commit) > > via b4578c5b380130a41a69b5b49c970157acaf1dbb (commit) > > via b97b78abdac34fabcbbf64ba49ec8c78939124b4 (commit) > > via 87af3ecd48587775970c0ca731d50183bd24017e (commit) > > via 435d40f7e3dc5b99a5fcbc459f79ba6b04238502 (commit) > > via 6bf8daf9a2aa0d226bfd5b60c4b1580d17105320 (commit) > > via 70542ef9a1d09ce87c7d40ac5ea1706860edec74 (commit) > > via 55116c42e767ce795f796fc51cd2ef7d76cf18af (commit) > > via b942e67226af9e690bd63ac440b99aedb6becbb3 (commit) > > via fbef4590b7b7186890a7d0cb8be0af2780a2df5f (commit) > > via d0a36f2c8b2f41399ae709280cd8b4a2f3bb0165 (commit) > > via cb26f1a5eee13afe1a561ebf57245cb8629797b9 (commit) > > via 337e14712e2bf568db73dd57c709b3364e26d798 (commit) > > via 9ac3ffb51777ee48ffbd42ff3625f63dfe948837 (commit) > > via 10f73bfa4aece7707f48379b82e5858d1909d98f (commit) > > via e7f40d8aaba2c17b8ccb323b5df20a423ef5d0a0 (commit) > > via f02ce27d4b1a9d01b88d0ffaf626e5bafa671bf0 (commit) > > via 33f3de4eaaa4e2084ea6e3695e29da5b736f1095 (commit) > > via e470cba076535e4e9732173e0e314e473165478c (commit) > > via 542939c31bb73bab55f2fd71243b98f5559597d1 (commit) > > via b4df0a1eda252bb7efbd4d7453e9e8a57143c528 (commit) > > via 06f5c6328b73aad7b138096295357d803db26efa (commit) > > via f1ccde27c038e7fb7e538913505248b36ddd9e65 (commit) > > via 4a311c1241805dac5893918854fd40f77b2b6f49 (commit) > > via 4d5fb23ad827eda17b64676f527c3f168cd56ebd (commit) > > via 8b892c55b077d1716eb130e76f9c9725ecb0f73a (commit) > > from 60a742e0afd34e02299f64536df35116d68d888d (commit) > > > > Those revisions listed above that are new to this repository have > > not appeared on any other notification email; so we list those > > revisions in full, below. > > > > - Log ----------------------------------------------------------------- > > commit 7f99e339363d9f005c9386f60a1d8c0953c85053 > > Merge: 60a742e 773fb9c > > Author: Daniel Lezcano > > Date: Wed Oct 31 16:39:50 2012 +0100 > > > > Merge branch 'upstream-bugfix' of https://github.com/lxc/lxc > > > > * 'upstream-bugfix' of https://github.com/lxc/lxc: (47 commits) > > replace HOOK define with proper code. > > Remove lxc-start-ephemeral from configure.ac > > revert devtmpfs in ubuntu templates > > lxc-ubuntu{-cloud}: Fix missing "fi" in new devtmpfs code > > fix "make rpm" > > display warning when yum missing in fedora template > > templates: mount devtmpfs in ubuntu containers > > handle clone of btrfs snapshots > > if the rootfs is a btrfs subvolume, delete it instead of rm -rf > > lxc-debian: replace isc-dhcp-server by isc-dhcp-client > > lxc-ls: Scan cgroup mount points from fstype and not device > > Allow short -h and -n options to lxc-ps > > lxc-ubuntu: fix printing of default user > > lxc-debian: specify isc-dhcp-server in package list > > try to better handle out of date container caches. > > link /dev/kmsg to /dev/console in the container > > lxc-clone: fix the '--name' parameter > > lxc-ls: Use readlink on $directory > > lxc-busybox: Use relative mounts in lxc.mount.entry > > busybox: for all lib dirs create mounts only if directories exist > > ... > > > > Signed-off-by: Daniel Lezcano > > > > commit 773fb9cad76f43540fddb78c7ffef7237a51a06d > > Author: Serge Hallyn > > Date: Tue Sep 4 13:57:39 2012 -0500 > > > > replace HOOK define with proper code. > > > > Signed-off-by: Serge Hallyn > > > > commit 8215fe8e4186ebe8cb79fe4b773f5bcffcdc723b > > Author: St??phane Graber > > Date: Thu Oct 25 10:43:59 2012 +0200 > > > > Remove lxc-start-ephemeral from configure.ac > > > > lxc-start-ephemeral.in ended up in configure.ac as a result of the > > cherry-pick. This new tool hasn't been pulled in yet. > > > > Signed-off-by: St??phane Graber > > > > commit 192df6e2eb8ebb1a337c7ba025c57852d38e0d26 > > Author: Serge Hallyn > > Date: Wed Oct 24 11:05:38 2012 -0500 > > > > revert devtmpfs in ubuntu templates > > > > devtmpfs is shared between host and containers, and it messes up > > lucid containers too. > > > > Signed-off-by: Serge Hallyn > > > > commit c215bff6dfc298bdd6150e11b8c0f76c9d013a0a > > Author: St??phane Graber > > Date: Wed Oct 24 13:05:03 2012 +0200 > > > > lxc-ubuntu{-cloud}: Fix missing "fi" in new devtmpfs code > > > > The "if" statement to add devtmpfs was missing a matching "fi" causing parsing > > error when using the template. > > > > Signed-off-by: St??phane Graber > > > > commit 0b53175846e704fc4dd4cf8b4590a86db63e50e6 > > Author: Dwight Engen > > Date: Thu Oct 4 12:28:38 2012 -0400 > > > > fix "make rpm" > > > > RPM doesn't like "-" in the version number and gives: > > "error: line 24: Illegal char '-' in: Version: 0.8.0-rc2" > > Other packages (bind-utils for example) have used . instead > > of - as a seperator. > > > > Signed-off-by: Dwight Engen > > Signed-off-by: Serge Hallyn > > > > commit a1bd64823cd5e5afc53ba24940a51151e34b8103 > > Author: Dwight Engen > > Date: Thu Oct 4 13:12:41 2012 -0400 > > > > display warning when yum missing in fedora template > > > > This early exit is preventing the warning message that follows it from > > being shown. > > > > Signed-off-by: Dwight Engen > > > > commit bf7d76cf3ae180820c0a29e0bfbaa97c20ce6a3d > > Author: Serge Hallyn > > Date: Thu Oct 4 13:54:00 2012 -0500 > > > > templates: mount devtmpfs in ubuntu containers > > > > That way /dev/disk/ exists, and update-grub can succeed. > > > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1060404 > > > > commit d4eb4ab1290def213396611f5946ef3b7f0d83ef > > Author: Dwight Engen > > Date: Wed Sep 26 13:20:30 2012 -0400 > > > > handle clone of btrfs snapshots > > > > Fix determination of $oldroot from the config file. The old code had the ' > > in the wrong place and didn't account for whitespace between the = and > > the rootfs. > > > > Set $rootfs based on $oldroot instead of forcing it to be in > > $lxc_path/$lxc_new/rootfs. This allows for btrfs snapshot to be made even if > > $lxc_path isn't on the same filesystem. If $oldroot isn't a subvolume, > > fall back to making a copy. > > > > Signed-off-by: Dwight Engen > > > > commit 5ae26abb52046b6f21afa06bcbac221c3cf8f1c0 > > Author: Dwight Engen > > Date: Wed Sep 26 12:59:28 2012 -0400 > > > > if the rootfs is a btrfs subvolume, delete it instead of rm -rf > > > > Check if the rootfs is btrfs subvolume, and if so delete it. Otherwise > > fall back to the rm -rf. > > > > Signed-off-by: Dwight Engen > > > > commit 06a1e1db99844b95e21c3b67964974f9032720ea > > Author: St??phane Graber > > Date: Mon Sep 24 15:16:25 2012 -0400 > > > > lxc-debian: replace isc-dhcp-server by isc-dhcp-client > > > > The DHCP client should be isc-dhcp-client, not isc-dhcp-server. > > > > Signed-off-by: Serge Hallyn > > Signed-off-by: St??phane Graber > > > > commit 3b9bad3d638ea442bfe6ba7e677cd5c6d39c0916 > > Author: Christian Seiler > > Date: Mon Sep 24 11:21:48 2012 +0200 > > > > lxc-ls: Scan cgroup mount points from fstype and not device > > > > lxc-ls --active now scans mount points that have the 'cgroup' filesystem > > type and not the 'cgroup' device name (which is ignored anyway and may be > > anything). > > > > Signed-off-by: Christian Seiler > > Cc: Serge Hallyn > > > > commit c12e775237976bc0c1cf8afdc7aa766de46d3d40 > > Author: Dwight Engen > > Date: Tue Sep 18 15:58:17 2012 -0400 > > > > Allow short -h and -n options to lxc-ps > > > > Signed-off-by: Dwight Engen > > > > commit c6ed4d048deea85ed3bec67c7a04fb6c97009321 > > Author: Serge Hallyn > > Date: Wed Sep 19 12:15:51 2012 -0500 > > > > lxc-ubuntu: fix printing of default user > > > > If a user is bound into the container, don't claim the default user is > > ubuntu. > > > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1052315 > > > > Signed-off-by: Serge Hallyn > > > > commit 3f16e26c7063f5004cafe4cfd6d084b7e4d08d1f > > Author: Serge Hallyn > > Date: Wed Sep 19 12:14:58 2012 -0500 > > > > lxc-debian: specify isc-dhcp-server in package list > > > > dhcp3-client does not exist in testing. > > > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1052972 > > > > Signed-off-by: Serge Hallyn > > > > commit 91a5df88ad29bcbc485baa51eacf0b851c6f4834 > > Author: Serge Hallyn > > Date: Fri Sep 14 14:43:45 2012 -0500 > > > > try to better handle out of date container caches. > > > > For a lucid container, apt-get update before installing the source package for > > add-apt-repository, so that apt-get does not fail. > > > > If apt-get dist-upgrade fails, suggest running lxc-create with -F. > > > > Signed-off-by: Serge Hallyn > > > > commit 1bd051a6b0a34cb2b2e80584b9fb4643abf1a827 > > Author: Serge Hallyn > > Date: Thu Sep 13 09:39:07 2012 -0500 > > > > link /dev/kmsg to /dev/console in the container > > > > This way init log messages can be seen on the console. If containerized > > syslog ever comes around, we can get rid of this. > > > > Signed-off-by: Serge Hallyn > > > > commit 5d38621d0bb9b398393806b875d612a05e76c06e > > Author: Serge Hallyn > > Date: Thu Sep 13 09:38:11 2012 -0500 > > > > lxc-clone: fix the '--name' parameter > > > > The long opt for --name was being incorrectly compared to --new. > > > > Signed-off-by: Serge Hallyn > > > > commit 8aba484aeaccda2881300ff80e9d7dfaaa842b40 > > Author: St??phane Graber > > Date: Wed Sep 12 18:21:00 2012 -0400 > > > > lxc-ls: Use readlink on $directory > > > > lxc-ls was failing in cases where $directory is a symlink to another > > directory. Instead have $directory be generated from the output of > > readlink -f "$lxc_path". > > > > Signed-off-by: St??phane Graber > > > > commit 5d01f6167c2354637e777650558be6d7d69e2579 > > Author: St??phane Graber > > Date: Wed Sep 12 15:22:15 2012 -0400 > > > > lxc-busybox: Use relative mounts in lxc.mount.entry > > > > To make it easier to clone/rename the container, replace hardcoded > > entries (with rootfs in the destination path) by rootfs-relative entries. > > > > Signed-off-by: St??phane Graber > > > > commit 6bc424b5c7c8130ffdb6390eae53b32370a755f8 > > Author: Stuart Yoder > > Date: Wed Sep 12 13:15:12 2012 -0500 > > > > busybox: for all lib dirs create mounts only if directories exist > > > > Signed-off-by: Stuart Yoder > > > > commit d595c68add4ef33cf273c455238b018729de00a5 > > Author: Dwight Engen > > Date: Tue Sep 11 17:06:05 2012 -0400 > > > > fix expansion of LXCPATH,LXCROOTFSMOUNT,LXCTEMPLATEDIR > > > > These variables are not expanded correctly in doc/lxc-create.sgml.in > > and a workaround is in place to ensure ${localstatedir}, and ${datadir} > > are set in the various shell scripts that use it. There is no workaround > > to ensure ${datadir} is set in src/lxc/lxc-create.in, nor is > > ${localstatedir} set in templates/lxc-altlinux.in so I think that these > > are currently broken. > > > > Using AS_AC_EXPAND instead of AC_SUBST fixes these problems and removes > > the need for the workarounds. In addition the lxc-start-ephemeral.in > > script can be autoconf'ed instead of sed'ed by the makefile. > > > > Signed-off-by: Dwight Engen > > > > commit b9cb4325d74fb01dc4e71adc211e7e7052471778 > > Author: Dwight Engen > > Date: Tue Sep 11 14:30:22 2012 -0400 > > > > lxc-rpm-build > > > > Fix building of rpm by non-root user. Include templates in rpm, fix rpm path of > > lxc-init. > > > > Signed-off-by: Dwight Engen > > > > commit b4578c5b380130a41a69b5b49c970157acaf1dbb > > Author: Dwight Engen > > Date: Mon Sep 10 16:49:31 2012 -0400 > > > > lxc-doc-synopsis-args > > > > I was getting raw nroff ".SH DESCRIPTION" in my man pages. This fixes > > the synopsis cmd args so that doesn't happen. Added replaceable to a few > > arguments. > > > > Signed-off-by: Dwight Engen > > > > commit b97b78abdac34fabcbbf64ba49ec8c78939124b4 > > Author: Dwight Engen > > Date: Mon Sep 10 10:28:37 2012 -0400 > > > > lxc-pkgconfig-dir > > > > Put pkg-config .pc file in libdir. > > > > Signed-off-by: Dwight Engen > > > > commit 87af3ecd48587775970c0ca731d50183bd24017e > > Author: Serge Hallyn > > Date: Thu Sep 6 22:16:55 2012 -0500 > > > > log errno when pclose fails > > > > When lxc is executing a script and pclose fails, log the > > errno to help debug what happened. > > > > Signed-off-by: Serge Hallyn > > > > commit 435d40f7e3dc5b99a5fcbc459f79ba6b04238502 > > Author: St??phane Graber > > Date: Thu Sep 6 10:59:57 2012 -0400 > > > > Pass the container name to copy_configuration in lxc-lenny > > > > This fixes a case where lxc.utsname would be set empty as copy_configuration > > wasn't getting the container name. > > > > Signed-off-by: Rex Tsai (?????????) > > Acked-by: St??phane Graber > > > > commit 6bf8daf9a2aa0d226bfd5b60c4b1580d17105320 > > Author: St??phane Graber > > Date: Thu Sep 6 10:57:20 2012 -0400 > > > > Add SIGINT and SIGPWR handler in lxc-debian > > > > This adds a SIGINIT and SIGPWR handler in the default inittab for > > the Debian template. This allows lxc-shutdown/lxc-restart and their API calls > > to properly shutdown or reboot the container. > > > > Signed-off-by: Rex Tsai (?????????) > > Acked-by: St??phane Graber > > > > commit 70542ef9a1d09ce87c7d40ac5ea1706860edec74 > > Author: St??phane Graber > > Date: Wed Sep 5 23:54:51 2012 -0400 > > > > Don't hardcode path to templates > > > > configure.ac used to set the template path to /usr/share/lxc/templates. > > Instead use ${datadir} to make it follow ${prefix}. > > > > Signed-off-by: St??phane Graber > > > > commit 55116c42e767ce795f796fc51cd2ef7d76cf18af > > Author: Serge Hallyn > > Date: Wed Sep 5 21:59:13 2012 -0500 > > > > lxc-destroy: Separately rm rootfs if it is a symlink > > > > If rootfs is a symbolic link but not to a block device, then do a separate > > rm of its contents. We have to do this because, out of cowardice, we call > > rm with --one-filesystem. > > > > Removing the '-o -h $rootdev' is ok, because if $rootdev is a symbolic > > link to a block device (including lvm blockdev) then -b will still return > > true. > > > > Signed-off-by: Serge Hallyn > > > > commit b942e67226af9e690bd63ac440b99aedb6becbb3 > > Author: Scott Moser > > Date: Tue Sep 4 15:44:25 2012 -0500 > > > > ubuntu-cloud template cleanups > > > > Fix for quantal images which do not have the user 'ubuntu' present. > > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1045955 > > > > Signed-off-by: Serge Hallyn > > > > commit fbef4590b7b7186890a7d0cb8be0af2780a2df5f > > Author: Serge Hallyn > > Date: Tue Sep 4 14:06:29 2012 -0500 > > > > add prototype for clone(2) as per manpage > > > > Signed-off-by: Serge Hallyn > > > > commit d0a36f2c8b2f41399ae709280cd8b4a2f3bb0165 > > Author: St??phane Graber > > Date: Sat Sep 1 20:15:31 2012 -0400 > > > > Add missing include for apparmor.h in conf.c > > > > This include is conditional on apparmor being selected. > > > > Signed-off-by: St??phane Graber > > > > commit cb26f1a5eee13afe1a561ebf57245cb8629797b9 > > Author: St??phane Graber > > Date: Fri Aug 31 09:17:38 2012 -0700 > > > > Various fedora template improvements > > > > 1. don't add network segment to config > > 2. check for 'curl' > > 3. don't add $name to $path, it's already in there > > 4. don't add devpts to fstab, that's wrong. > > 5. $UTSNAME doesn't exist > > 6. set root pwd to root instead of rooter. > > 7. install fedora-release package. > > 8. add a console on /dev/console. > > 9. create empty fstab > > 10. don't mount devpts in rc.sysinit. > > > > Signed-off-by: Serge Hallyn > > Acked-by: St??phane Graber > > > > commit 337e14712e2bf568db73dd57c709b3364e26d798 > > Author: St??phane Graber > > Date: Fri Aug 31 09:09:34 2012 -0700 > > > > sshd: run dhclient; allow adding a root ssh key > > > > Signed-off-by: Serge Hallyn > > Acked-by: St??phane Graber > > > > commit 9ac3ffb51777ee48ffbd42ff3625f63dfe948837 > > Author: St??phane Graber > > Date: Fri Aug 31 08:58:56 2012 -0700 > > > > Make lxc-execute without rootfs work. > > > > That means, don't try to pin a null rootfs, and don't try to mount /proc > > since /var/lib/lxc/root/proc doesn't exist to be mounted onto. > > The apparmor patches are not yet upstream, so this patch will not go > > upstream by itself. > > > > Signed-off-by: Serge Hallyn > > Acked-by: St??phane Graber > > > > commit 10f73bfa4aece7707f48379b82e5858d1909d98f > > Author: Serge Hallyn > > Date: Thu Aug 30 11:02:24 2012 -0500 > > > > lxc-ubuntu-cloud: get full pathname to userdata file > > > > When passing '--userdata somefile' to the ubuntu-cloud template, a user > > may pass a relative pathname. The template uses the filename after > > changing current directory, so store the full pathname for the userdata > > file instead of a potential relative pathname. > > > > Signed-off-by: Serge Hallyn > > > > commit e7f40d8aaba2c17b8ccb323b5df20a423ef5d0a0 > > Author: St??phane Graber > > Date: Wed Aug 29 14:42:59 2012 -0700 > > > > When creating the lxc cgroup directory, ignore -EEXIST > > > > Signed-off-by: Serge Hallyn > > Acked-by: St??phane Graber > > > commit f02ce27d4b1a9d01b88d0ffaf626e5bafa671bf0 > > Author: St??phane Graber > > Date: Wed Aug 29 09:27:53 2012 -0700 > > > > Add lxc.aa_profile example to all templates > > > > LXC has optional apparmor support, default profile is lxc-container-default. > > This change adds a commented "lxc.aa_profile = default" line to all templates, > > uncommenting this will bypass apparmor for the container. > > > > Signed-off-by: St??phane Graber > > > > commit 33f3de4eaaa4e2084ea6e3695e29da5b736f1095 > > Author: St??phane Graber > > Date: Wed Aug 29 13:51:37 2012 -0700 > > > > Don't update the host-name field in dhclient.conf when not hardcoded. > > > > On Debian and Ubuntu, the default host-name field in dhclient.conf is > > set to either "" or "gethostname()" both of which get replaced > > by the machine's hostname at query time. > > > > The sed call currently present in lxc-clone hardcodes the hostname in > > dhclient.conf, causing dpkg to prompt on isc-dhcp updates. > > > > Signed-off-by: St??phane Graber > > > > commit e470cba076535e4e9732173e0e314e473165478c > > Author: St??phane Graber > > Date: Tue Aug 28 13:46:59 2012 -0400 > > > > Use lxc_putold as the pivot_root put dir in the ubuntu templates > > > > By default we use mnt, but that means that lxc fstab entries do not work > > when placed under the container's /mnt/. > > > > Signed-off-by: Serge Hallyn > > Acked-by: St??phane Graber > > > > commit 542939c31bb73bab55f2fd71243b98f5559597d1 > > Author: St??phane Graber > > Date: Tue Aug 28 13:42:27 2012 -0400 > > > > Fix lxc-ubuntu and lxc-ubuntu-cloud to properly deal with /dev/shm. > > > > Now that initscripts in Debian and Ubuntu has been updated to no longer > > do silly things with /dev/shm and /run/shm on installation/update, the > > check needs updating to detect any remaining broken case and fix it. > > > > Signed-off-by: St??phane Graber > > > > commit b4df0a1eda252bb7efbd4d7453e9e8a57143c528 > > Author: Serge Hallyn > > Date: Tue Aug 21 10:05:19 2012 -0500 > > > > lxc_start: exit early if insufficient privs in daemon mode > > > > Starting a container with insufficient privilege (correctly) fails > > during lxc_init. However, if starting a daemonized container, we > > daemonize before we get to that check. Therefore while the > > container will fail to start, and the logfile will show this, the > > 'lxc-start -n x -d' command will return success. For ease of > > scripting, do a check for the required privilege before we exit. > > > > Signed-off-by: Serge Hallyn > > > > commit 06f5c6328b73aad7b138096295357d803db26efa > > Author: Serge Hallyn > > Date: Tue Aug 21 09:59:43 2012 -0500 > > > > ubuntu template: apt-get clean after debootstrapping a cache > > > > This saves quite a bit of space in the cache and containers. > > > > See https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1037626 for the > > original bug report. > > > > Reported-by: Fajar A. Nugraha > > Signed-off-by: Serge Hallyn > > > > commit f1ccde27c038e7fb7e538913505248b36ddd9e65 > > Author: Serge Hallyn > > Date: Tue Aug 21 09:56:03 2012 -0500 > > > > ubuntu and debian templates: Clean up cache if cache build is interrupted > > > > Otherwise the next lxc-create may rsync a bad cache. > > > > Signed-off-by: Serge Hallyn > > > > commit 4a311c1241805dac5893918854fd40f77b2b6f49 > > Author: Serge Hallyn > > Date: Thu Aug 16 21:11:50 2012 -0500 > > > > Cleanup partial container if -h was passed to template > > > > If user calls 'lxc-create -t ubuntu -- -h' (as opposed to > > 'lxc-create -t ubuntu -h') then the ubuntu template will print its > > help then exit 0. Then lxc-create does not cleanup. So detect this > > in lxc-create. > > > > commit 4d5fb23ad827eda17b64676f527c3f168cd56ebd > > Author: Serge Hallyn > > Date: Fri Jul 20 10:38:15 2012 -0500 > > > > lxc-clone: fix handling of lxc.mount entries > > > > The 'lxc.mount =' entry can have more than one space, or tabs, before the =. > > We only need to disambiguate from 'lxc.mount.entry'. So just check for a > > space or tab after mount. > > > > Signed-off-by: Serge Hallyn > > > > commit 8b892c55b077d1716eb130e76f9c9725ecb0f73a > > Author: Serge Hallyn > > Date: Thu Jul 19 17:54:54 2012 -0500 > > > > lxc-clone: change uuid on xfs > > > > Otherwise after cloning an lvm+xfs container you can't run the > > original and clone at the same time. > > > > Based on a patch by Maurizio Sambati posted at > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1013549 > > > > Signed-off-by: Serge Hallyn > > > > ----------------------------------------------------------------------- > > > > Summary of changes: > > Makefile.am | 2 +- > > configure.ac | 8 +- > > doc/lxc-attach.sgml.in | 11 ++- > > doc/lxc-cgroup.sgml.in | 7 +- > > doc/lxc-checkpoint.sgml.in | 8 +- > > doc/lxc-console.sgml.in | 8 +- > > doc/lxc-create.sgml.in | 12 ++-- > > doc/lxc-destroy.sgml.in | 7 +- > > doc/lxc-execute.sgml.in | 10 ++-- > > doc/lxc-freeze.sgml.in | 4 +- > > doc/lxc-kill.sgml.in | 4 +- > > doc/lxc-ls.sgml.in | 5 +- > > doc/lxc-monitor.sgml.in | 4 +- > > doc/lxc-ps.sgml.in | 14 ++-- > > doc/lxc-restart.sgml.in | 11 ++-- > > doc/lxc-shutdown.sgml.in | 7 +- > > doc/lxc-start.sgml.in | 16 +++-- > > doc/lxc-stop.sgml.in | 4 +- > > doc/lxc-unfreeze.sgml.in | 4 +- > > doc/lxc-wait.sgml.in | 6 +- > > lxc.spec.in | 16 +++-- > > src/lxc/cgroup.c | 9 ++- > > src/lxc/conf.c | 51 +++++++++++++- > > src/lxc/conf.h | 6 -- > > src/lxc/lxc-clone.in | 34 ++++++---- > > src/lxc/lxc-create.in | 14 ++++- > > src/lxc/lxc-destroy.in | 17 ++++-- > > src/lxc/lxc-ls.in | 5 +- > > src/lxc/lxc-ps.in | 4 +- > > src/lxc/lxc-setcap.in | 3 - > > src/lxc/lxc-setuid.in | 3 - > > src/lxc/lxc_start.c | 16 ++++- > > src/lxc/namespace.h | 4 + > > src/lxc/start.c | 15 +++- > > templates/lxc-altlinux.in | 4 + > > templates/lxc-archlinux.in | 4 + > > templates/lxc-busybox.in | 30 ++++----- > > templates/lxc-debian.in | 19 +++++- > > templates/lxc-fedora.in | 55 +++++++++++----- > > templates/lxc-lenny.in | 6 ++- > > templates/lxc-opensuse.in | 3 + > > templates/lxc-sshd.in | 48 ++++++++++++-- > > templates/lxc-ubuntu-cloud.in | 144 ++++++++++++++++++++++++----------------- > > templates/lxc-ubuntu.in | 43 +++++++++--- > > 44 files changed, 465 insertions(+), 240 deletions(-) > > > > > > hooks/post-receive > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > > > > > _______________________________________________ > > Lxc-devel mailing list > > Lxc-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-devel > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Lxc-users mailing list > Lxc-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Wed Oct 31 17:15:39 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Wed, 31 Oct 2012 18:15:39 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351630754.5001.196.camel@canyon.wittsend.com> References: <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> <1351630754.5001.196.camel@canyon.wittsend.com> Message-ID: <20121031171507.GB20848@serge-ThinkPad-X130e> Can you tell me the exact git tree and branch you are using? The results you're getting don't make sense to me... Hoping I can find a simple answer. -serge From mhw at wittsend.com Wed Oct 31 17:17:54 2012 From: mhw at wittsend.com (Michael H. Warfield) Date: Wed, 31 Oct 2012 13:17:54 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121031171507.GB20848@serge-ThinkPad-X130e> References: <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> <1351630754.5001.196.camel@canyon.wittsend.com> <20121031171507.GB20848@serge-ThinkPad-X130e> Message-ID: <1351703874.5001.230.camel@canyon.wittsend.com> On Wed, 2012-10-31 at 18:15 +0100, Serge Hallyn wrote: > Can you tell me the exact git tree and branch you are using? I'm using head. I'm not specifying a tree. > The results you're getting don't make sense to me... Hoping I can find > a simple answer. Me too. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Wed Oct 31 17:30:46 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Wed, 31 Oct 2012 18:30:46 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351703874.5001.230.camel@canyon.wittsend.com> References: <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> <1351630754.5001.196.camel@canyon.wittsend.com> <20121031171507.GB20848@serge-ThinkPad-X130e> <1351703874.5001.230.camel@canyon.wittsend.com> Message-ID: <20121031173010.GA22042@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at wittsend.com): > On Wed, 2012-10-31 at 18:15 +0100, Serge Hallyn wrote: > > Can you tell me the exact git tree and branch you are using? > > I'm using head. I'm not specifying a tree. ? I'm not sure what you mean - are you using git://github.com/lxc/lxc, or the tree on lxc.sf.net? > > The results you're getting don't make sense to me... Hoping I can find > > a simple answer. > > Me too. > > > -serge > > Regards, > Mike > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! From mhw at WittsEnd.com Wed Oct 31 17:33:43 2012 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Wed, 31 Oct 2012 13:33:43 -0400 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <20121031173010.GA22042@serge-ThinkPad-X130e> References: <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> <1351630754.5001.196.camel@canyon.wittsend.com> <20121031171507.GB20848@serge-ThinkPad-X130e> <1351703874.5001.230.camel@canyon.wittsend.com> <20121031173010.GA22042@serge-ThinkPad-X130e> Message-ID: <1351704823.5001.232.camel@canyon.wittsend.com> On Wed, 2012-10-31 at 18:30 +0100, Serge Hallyn wrote: > Quoting Michael H. Warfield (mhw at wittsend.com): > > On Wed, 2012-10-31 at 18:15 +0100, Serge Hallyn wrote: > > > Can you tell me the exact git tree and branch you are using? > > > > I'm using head. I'm not specifying a tree. > > ? > > I'm not sure what you mean - are you using git://github.com/lxc/lxc, or > the tree on lxc.sf.net? IOW, I'm not using a branch in the tree. I'm using the main trunk. Created my tree with - git clone git://github.com/lxc/lxc So the former, not the later. > > > The results you're getting don't make sense to me... Hoping I can find > > > a simple answer. > > > > Me too. > > > > > -serge Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From serge.hallyn at canonical.com Wed Oct 31 17:34:45 2012 From: serge.hallyn at canonical.com (Serge Hallyn) Date: Wed, 31 Oct 2012 18:34:45 +0100 Subject: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container. In-Reply-To: <1351630754.5001.196.camel@canyon.wittsend.com> References: <1351258337.5181.68.camel@canyon.wittsend.com> <1351359655.5001.16.camel@canyon.wittsend.com> <1351360308.5001.20.camel@canyon.wittsend.com> <1351361393.5001.30.camel@canyon.wittsend.com> <20121028175257.GA3007@serge-ThinkPad-X130e> <1351460035.5001.57.camel@canyon.wittsend.com> <20121028220232.GA4638@serge-ThinkPad-X130e> <1351474550.5001.73.camel@canyon.wittsend.com> <20121029091845.GA7338@serge-ThinkPad-X130e> <1351630754.5001.196.camel@canyon.wittsend.com> Message-ID: <20121031173445.GB22042@serge-ThinkPad-X130e> Quoting Michael H. Warfield (mhw at WittsEnd.com): > On Mon, 2012-10-29 at 10:18 +0100, Serge Hallyn wrote: > > Quoting Michael H. Warfield (mhw at WittsEnd.com): > > ... > > > Yeah, I don't think I "need to play a game like this" anymore. I'd have > > > to go back through some old old E-Mails to see why I did that before. I > > > seem to recall we were playing with all sorts of bind mount options for > > > some PRIVATE thing or another. It may not be necessary at all any > > > longer. IAC, it's minor to switch it back. I seem to recall switching > > > back and forth using bind mounts several times back when that got done > > > that way. > > > > > > I may play with the pre-mount hook just for giggles and see how that > > > might work as well. Any idea why I was experiencing the problem with > > > the mount hook when trying to populate /dev? I know it wouldn't have > > > The only idea I have is that perhaps your root is MS_SHARED by default? > > Can you post the script you were using and the container config? > > Another point on the curve... The documentation says that "pre-mount" > takes place before the mount occurs and "mount takes place after the > mount occurs. Only problem is that "pre-mount" is not being recognized. I have serge at serge-ThinkPad-X130e:~$ cat /var/lib/lxc/premount #!/bin/bash echo 'hi there' > /tmp/hw serge at serge-ThinkPad-X130e:~$ head -2 /var/lib/lxc/q4/config lxc.hook.pre-mount = /var/lib/lxc/premount lxc.network.type=veth serge at serge-ThinkPad-X130e:~$ sudo lxc-start -n q4 -d serge at serge-ThinkPad-X130e:~$ cat /tmp/hw hi there (This is using lxc 0.8.0~rc1-4ubuntu39 in ubuntu quantal) -serge From list at fajar.net Wed Oct 31 21:38:40 2012 From: list at fajar.net (Fajar A. Nugraha) Date: Thu, 1 Nov 2012 04:38:40 +0700 Subject: [Lxc-users] Regarding connecting containers to vlan In-Reply-To: References: Message-ID: On Wed, Oct 31, 2012 at 9:24 PM, Kalyana sundaram wrote: > My bad, I bridged eth0.211 and eth0.103 with br0. Could I know the > problems it would cause? > > At the very least, you effectively merge vlan 211 and 103. No point in using vlans any more. Worst case scenario, depending on your exact config, the switch might detect a loop and block some ports. -- Fajar -------------- next part -------------- An HTML attachment was scrubbed... URL: