Re: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
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 m...@wittsend.com 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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address )
On Mon, Oct 22, 2012 at 5:11 PM, swair shah swairs...@gmail.com 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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address )
On Mon, Oct 22, 2012 at 3:56 PM, swair shah swairs...@gmail.com wrote: On Mon, Oct 22, 2012 at 3:49 PM, Fajar A. Nugraha l...@fajar.net wrote: On Mon, Oct 22, 2012 at 5:11 PM, swair shah swairs...@gmail.com 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 roottty 136, 0 Oct 22 15:54 0 crw--w 1 swair tty 136, 7 Oct 22 15:52 7 c- 1 rootroot 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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] ssh'ing in the container ( ioctl operation not permitted /dev/tty failed - no such device or address )
On Mon, Oct 22, 2012 at 5:26 PM, swair shah swairs...@gmail.com 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 roottty 136, 0 Oct 22 15:54 0 crw--w 1 swair tty 136, 7 Oct 22 15:52 7 c- 1 rootroot 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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Using lxc on production
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Using lxc on production
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 signature.asc Description: OpenPGP digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Problems starting OL6.3 lxc container
On Sun, 21 Oct 2012 16:27:01 +0700 Fajar A. Nugraha l...@fajar.net wrote: On Sun, Oct 21, 2012 at 4:23 PM, C. L. Martinez carlopm...@gmail.com wrote: On Sun, Oct 21, 2012 at 9:20 AM, Fajar A. Nugraha l...@fajar.net 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 ERRORlxc_confile - unknow key lxc.devttydir lxc-start 1350810587.498 ERRORlxc_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). -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Using lxc on production
On Mon, Oct 22, 2012 at 6:48 PM, Michael H. Warfield m...@wittsend.comwrote: 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. Thishttp://pastebin.com/Qtue8g3P 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 | m...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] error message with dual bridge setting
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: [8106b7a7] ? warn_slowpath_common+0x87/0xc0 Oct 23 01:09:26 localhost kernel: [8106b7fa] ? warn_slowpath_null+0x1a/0x20 Oct 23 01:09:26 localhost kernel: [81076aa1] ? unregister_sysctl_table+0xb1/0x120 Oct 23 01:09:26 localhost kernel: [a02ff10b] ? __ipv6_dev_mc_dec+0xcb/0x120 [ipv6] Oct 23 01:09:26 localhost kernel: [81443e87] ? neigh_sysctl_unregister+0x27/0x50 Oct 23 01:09:26 localhost kernel: [a02e3fea] ? addrconf_ifdown+0x29a/0x3d0 [ipv6] Oct 23 01:09:26 localhost kernel: [a02e76bd] ? addrconf_notify+0xdd/0x970 [ipv6] Oct 23 01:09:26 localhost kernel: [810e1265] ? call_rcu_sched+0x15/0x20 Oct 23 01:09:26 localhost kernel: [810e127e] ? call_rcu+0xe/0x10 Oct 23 01:09:26 localhost kernel: [815038f5] ? notifier_call_chain+0x55/0x80 Oct 23 01:09:26 localhost kernel: [810981b6] ? raw_notifier_call_chain+0x16/0x20 Oct 23 01:09:26 localhost kernel: [8143b91b] ? call_netdevice_notifiers+0x1b/0x20 Oct 23 01:09:26 localhost kernel: [8143c397] ? rollback_registered+0x77/0x130 Oct 23 01:09:26 localhost kernel: [8143c472] ? unregister_netdevice+0x22/0x70 Oct 23 01:09:26 localhost kernel: [a03e222a] ? veth_dellink+0x1a/0x30 [veth] Oct 23 01:09:26 localhost kernel: [8143dd2a] ? default_device_exit+0x9a/0x100 Oct 23 01:09:26 localhost kernel: [81437410] ? cleanup_net+0x0/0xa0 Oct 23 01:09:26 localhost kernel: [8143747e] ? cleanup_net+0x6e/0xa0 Oct 23 01:09:26 localhost kernel: [8108c7f0] ? worker_thread+0x170/0x2a0 Oct 23 01:09:26 localhost kernel: [81092160] ? autoremove_wake_function+0x0/0x40 Oct 23 01:09:26 localhost kernel: [8108c680] ? worker_thread+0x0/0x2a0 Oct 23 01:09:26 localhost kernel: [81091df6] ? kthread+0x96/0xa0 Oct 23 01:09:26 localhost kernel: [8100c14a] ? child_rip+0xa/0x20 Oct 23 01:09:26 localhost kernel: [81091d60] ? kthread+0x0/0xa0 Oct 23 01:09:26 localhost kernel: [8100c140] ? 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 DEBUGlxc_cgroup - using cgroup mounted at '/cgroup' lxc-start 1350923335.375 DEBUGlxc_cgroup - lxc_cgroup_path_get: returning /cgroup/lxc63_01 for subsystem devices.allow lxc-start 1350923335.375 DEBUGlxc_conf - cgroup 'devices.allow' set to 'c 254:0 rwm' lxc-start 1350923335.375 INFO lxc_conf - cgroup has been
[Lxc-users] centos6 container and root login
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] centos6 container and root login
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] centos6 container and root login
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] centos6 container and root login
On Tue, 23 Oct 2012 03:15:06 +0700 Fajar A. Nugraha l...@fajar.net 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. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): Serge, On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: Quoting Serge Hallyn (serge.hal...@canonical.com): Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@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@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 devtmpfsdev 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 | m...@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 | m...@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! signature.asc Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Mon, 2012-10-22 at 22:50 +0200, Lennart Poettering wrote: On Mon, 22.10.12 11:48, Michael H. Warfield (m...@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 | m...@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! signature.asc Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): Serge, On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: Quoting Serge Hallyn (serge.hal...@canonical.com): Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@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@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 devtmpfsdev 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 | m...@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! signature.asc Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): Serge, On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: Quoting Serge Hallyn (serge.hal...@canonical.com): Quoting Michael H. Warfield (m...@wittsend.com): On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@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@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 devtmpfsdev 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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: Trimming some overhead we've seen enough of... How about just a devtmpfs? We actually now do this by default (as of very recently) in ubuntu by adding devtmpfsdev 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 | m...@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! signature.asc Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Using lxc on production
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: horlac...@rus.uni-stuttgart.de Universitaet Stuttgart Tel:++49-711-68565868 Allmandring 30aFax:++49-711-682357 70550 Stuttgart (Germany) WWW:http://www.rus.uni-stuttgart.de/ REF: cakrdmx8czra3gvtg+octjvu2z2b-yjmjv_+vg2yurtd44my...@mail.gmail.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Using lxc on production
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: horlac...@rus.uni-stuttgart.de Universitaet Stuttgart Tel:++49-711-68565868 Allmandring 30aFax:++49-711-682357 70550 Stuttgart (Germany) WWW:http://www.rus.uni-stuttgart.de/ REF: 508541dd.10...@ubuntu.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
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 (m...@wittsend.com): On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote: Trimming some overhead we've seen enough of... How about just a devtmpfs? We actually now do this by default (as of very recently) in ubuntu by adding devtmpfsdev 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 | m...@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! signature.asc Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] systemd inside LXC
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 (m...@wittsend.com):
On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
Trimming some overhead we've seen enough of...
How about just a devtmpfs? We actually now do this by default (as of
very
recently) in ubuntu by adding
devtmpfsdev 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 | m...@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!
signature.asc
Description: This is a digitally signed message part
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] centos6 container and root login
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
