[Lxc-users] lxc-centos/lxc-rhel?
Hi, Recently I had to set up containers on centos and discovered that there is no template for centos/rhel in lxc-source. Googling turned up quite a few templates but I am not sure which one is preferred. I tried one which created the container alright but on starting the container, killed the host X and it didn't continue working afterwards i.e. it was stopped. The host OS is centos as well. Would there be a official centos/rhel template bundled with lxc? If not, which one is most preferred one? -- Regards Shridhar -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] Working LXC templates?
On Monday, September 09, 2013 07:28:43 AM Michael H. Warfield wrote:
In the git-stage current Fedora template, the entire problem is embodied
in the download_fedora function starting around line 201... The
gotcha's are three commands around line 272 after we've identified and
downloaded the initial release rpm. We have this:
mkdir -p $INSTALL_ROOT/var/lib/rpm
rpm --root $INSTALL_ROOT --initdb
rpm --root $INSTALL_ROOT -ivh ${INSTALL_ROOT}/${RELEASE_RPM}
$YUM install $PKG_LIST
Ok... Those are running in the host local run time environment.
Obviously, if the host does not have a (compatible) version of rpm
and/or yum in the host local environment, you're screwed. That's the
catch-22 situation and it's the same situation with zypper in the
OpenSuse template. That short space of code has to be recreated in a
totally distro-agnostic manner so it runs on any distro to create our
initial rootfs. After that, we can do what ever distro (Fedora)
specific commands we want by chrooting into the target container first
(including rebuilding the rpm database to the target version). That's
only even needed if you don't already have a cached rootfs for that
distro and version.
Another approach could be to popularize the container downloads by the distro.
If each distro. could add a .tar.gz for a working container of a given
release, one could just download and configure them, no?
then the lxc project upstream, could just list those links or include them in
the a separate tool, that just downloads and untars the same?
That would completely sidestep the bootstrapping one-distro.-on-another
problem.
--
Regards
Shridhar
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Script to generate systemd unit file for containers
On Sunday, June 02, 2013 09:25:47 AM Michael H. Warfield wrote: Nice suggestion, however. I may play with it on some of my hosts (I run Fedora and I've been working on the Fedora lxc-create template). I don't think I would incorporate it into the container creation templates, however, because of the current discussions underway. This is one of the things we need to hash out before cutting 1.0. Of course.. if there is a mechanism that provides a superset functionality, it is better from a general-purpose perspective. I just needed something for my small needs, and developed/debugged/tested this(systemd service types took some time to iron out). Just shared an experiement that worked-for-me.. -- Regards Shridhar -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Script to generate systemd unit file for containers
Hi All,
I looked around and didn't find a script that generates systemd unit files for
containers.
Here is the script. I hope people find it useful and it is included by default
in lxc upstream.
Thanks
-
#!/bin/bash
function usage()
{
echo Usage:$0 enable|disable container name
}
if [ $# -lt 2 ] ;
then
usage
exit -1;
fi
export UNITFILE=/etc/systemd/system/multi-user.target.wants/$2_container.service
case $1 in
enable)
cat EOF $UNITFILE
[Unit]
Description=Container $2 service
[Service]
Type=forking
ExecStart=/usr/bin/lxc-start -d -n $2
ExecStop=/usr/bin/lxc-stop -n $2
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
;;
disable)
rm $UNITFILE
;;
*)
usage
;;
esac
-
--
Regards
Shridhar
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Regarding creating a LXC container in fedora 17
On Friday, May 31, 2013 10:44:54 AM Fajar A. Nugraha wrote: On Fri, May 31, 2013 at 10:19 AM, Shridhar Daithankar And I finally managed to complete it. Its posted at http://www.ghodechhap.net/blog/?p=4 Thanks for writing the post. One thing though, is the edit /etc/ssh/sshd_config part really necessary? AFAIK ssh should listen to all available IP by default, and the container will have separate IP address from the host (i.e. the host doesn't use container's IP address, and vice versa), so it should work even without manually binding ssh to an IP address. Its not strictly necessary. squid does not offer such a setting and I can run two instances, one in host and one in container just fine. I just find it to be logically cleaner.. -- Regards Shridhar -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Regarding creating a LXC container in fedora 17
On Sunday, May 19, 2013 12:02:47 AM Shridhar Daithankar wrote: First of all, let me say thank you for your concise message upthread. It renewed my interest in lxc and I managed to get a working container for the first time. I will post a detailed HOWTO shortly. And I finally managed to complete it. Its posted at http://www.ghodechhap.net/blog/?p=4 Hope people find it useful. -- Regards Shridhar -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Regarding creating a LXC container in fedora 17
On Saturday, May 18, 2013 09:58:26 AM Michael H. Warfield wrote: On Sat, 2013-05-18 at 19:02 +0530, Ajith Adapa wrote: Then I have started the container using below command and tried to connect to its shell using lxc-console command but I ended up with below message. Ideally I should see a prompt but its just hangs down there. Ctl+a q works and nothing else. [root@ipiblr ~]# lxc-start -n TEST -d [root@ipiblr ~]# lxc-console -n TEST Type Ctrl+a q to exit the console, Ctrl+a Ctrl+a to enter Ctrl+a itself Oh, crap... I keep forgetting about that (because I don't use it). That needs to be noted somewhere in the documentation. That's yet another BAD decision on the part of the systemd crowd, lxc-console is probably not going to work, at least for the time being. They (systemd) intentionally, with documented malice a forethought, disable gettys on the vtys in the container if systemd detects that it's in a container. However, /dev/console in the container is still active and is connected to lxc-start and I'm able to log in there but I have never gotten lxc-console to work with a systemd container and I don't know of anything I can do about it. You would need some way to force the container to start gettys on the vtys. Maybe, if I (or someone else) can figure out a way to do that (force the gettys to start on the vtys), it could be integrated into the Fedora template. My patches for the autodev stuff (plus other stuff) have now been accepted and applied by Serge, so that's done. Maybe I can look deeper into this morass now. First of all, let me say thank you for your concise message upthread. It renewed my interest in lxc and I managed to get a working container for the first time. I will post a detailed HOWTO shortly. I ran into the same lxc-console issue and managed to solve it by commenting out ConditionPathExists line in /etc/systemd/system/getty.target.wants/getty\@tty1.service first I had to start the container in foreground, login, comment out aforementioned line and restart it in daemon mode. After that lxc-console worked. If I changed the systemd unit from the chroot itself, it didn't reflect somehow. Also the line referred to /dev/tty0 but only /dev/tty and /dev/tty1 were available in the container. I don't understand systemd enough to comment on the reasons of it working or not-working. I just experimented around to get a working tty. My environment is arch linux and the details are as follows. kernel : 3.9.2-1 systemd : 204-1 lxc : 1:0.9.0-2 HTH -- Regards Shridhar -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Regarding creating a LXC container in fedora 17
On Saturday, May 18, 2013 04:06:30 PM Michael H. Warfield wrote: On Sun, 2013-05-19 at 00:02 +0530, Shridhar Daithankar wrote: I ran into the same lxc-console issue and managed to solve it by commenting out ConditionPathExists line in /etc/systemd/system/getty.target.wants/getty\@tty1.service first I had to start the container in foreground, login, comment out aforementioned line and restart it in daemon mode. After that lxc-console worked. If I changed the systemd unit from the chroot itself, it didn't reflect somehow. Also the line referred to /dev/tty0 but only /dev/tty and /dev/tty1 were available in the container. I don't understand systemd enough to comment on the reasons of it working or not-working. I just experimented around to get a working tty. Oh, I understand why it's working and that's VERY interesting. I hadn't dug into that realm of the systemd files as yet. They're using the mere existence of /dev/tty0 as a logic switch to determine if they are going to start a getty on %I (/dev/tty1 in this case). Which is yet another case of them burying a magic cookie switch in the logic. They conditionalize it on a hard coded /dev/tty0 but then start a getty /sbin/agetty --noclear %I 38400. the %I is the unit name. Cute. Cheeky bastards. So, it basically means that if we create a tty0 under autodev, that should then enable any listed vty consoles we set up using systemd links. That could be a key to making that work without modifying files in the container but would require a (relatively minor but non trivial) change to the lxc source code, as opposed to merely a template. I'll run this up the flagpole on the -devel list and with Serge and get their opinions. This is doable. I think I'll try this out in my sources first and then post a request for comments over on -devel. The problem is in the routine setup_tty in conf.c that's going to need some massaging to make it 0 based instead of 1 based and adjust for the additional tty count. :-/ digging a bit deeper in this and quoting from http://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html and http://0pointer.de/blog/projects/serial-console.html It looks like systemd is generating that unit file on demand during boot(thats why editing it before starting the container did not work for me) and it is looking into /sys/class/tty/console/active which indeed reports tty0 inside a container. So the real question is how can lxc/kernel make the container report tty1 there so that systemd would work out of the box. or.. as you have proposed, lxc could expose tty0. -- Regards Shridhar -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
