from:"Michael H. Warfield"

operations are performed by brctl, based on some discussions I saw.
Certainly shouldn't be a problem in a server hosting environment where
the host MAC is used for the bridge MAC and unlikely to ever be removed
from the bridge.

AFAICT...  This should be fixed in the current releases and no longer a
problem.

 -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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] lxcbr0 MAC addr issue

On Wed, 2013-06-05 at 09:30 -0500, Serge Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
On Wed, 2013-06-05 at 07:40 -0500, Serge Hallyn wrote:
Now my question, could not lxc (at boot) setup a fixed MAC addr for the
host port?

Yeah, given how bad this was for libvirt/qemu I'm surprised I've not seen
this happen in lxc - but I haven't, and noone else has reported it.

Actually, this has come up on both the -devel list and here, the last
time about a year and a half ago:

On the -devel list...

Subject: Set high byte of mac addresses for host veth devices to 0xfe

It had a patch and referenced an open bug associated with it:

random veth device MAC addresses cause bridge problems - ID: 3411497
https://sourceforge.net/tracker/index.php?func=detailaid=3411497group_id=163076atid=826303

Christian Seiler included a proposed patch with his original posting to
the -devel list back in November of 2011 where he set the high order
byte to FE for a private locally administered MAC and some discussion
ensued. After a couple of bug fixes, it was Acked it on 01/03/2012.

It looks like it was applied. Right around line 3109 of src/lxc/conf.c:

static int setup_private_host_hw_addr(char *veth1)

...

ifr.ifr_hwaddr.sa_data[0] = 0xfe;
err = ioctl(sockfd, SIOCSIFHWADDR, ifr);
close(sockfd);

yes and it does this. The point is that lxcbr0 is not tied to any
physical nic. So the first container you start, however high the
macaddr is, lxcbr0 takes its mac. If the next container gets a
lower macaddr, lxcbr0's macaddr drops.

Right now I have:

lxcbr0Link encap:Ethernet HWaddr fe:02:72:77:79:ff
vethtdjU5K Link encap:Ethernet HWaddr fe:02:72:77:79:ff

Oh, yeah... I'm always using bridged mode with the host ethernet
address on the bridge, so that's never a problem. You're right. The
NAT mode is problematical there because it's not anchored to a physical
interface.

I think someone, at one point in those earlier threads, was suggesting
that they were using a dummy interface or a dummy container as a place
holder to lock the interface address for that reason. I just happen to
have enough IPv4 addresses, personally, that I bridge everything and
never really need to NAT anything where I can avoid it. :-P

Of course, in a server environment, where you are hosting a farm of
virtual servers, you would almost always want global public addresses on
the servers, I would imagine.

You're still going to have the problem that, if you shut down the
container that the bridge is using for the address, the address is going
to shift, static or not. The address of the bridge must be an address
of an interface on the bridge or you are going to have routing problems.
That was made clear in some discussion on some of the kernel mailing
lists. How do you deal with that then? Do you designate a container
that must never be shut down or the bridge hangs?

You could load the dummy module and bridge a dummy interface to the
bridge. That would guarantee a MAC address lower than the fe: private
addresses of the bridge and would be cheaper than a dummy container.
I've done that before a long time ago.

(We should still close that old bug, however.)

-serge

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j

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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] lxcbr0 MAC addr issue

On Wed, 2013-06-05 at 15:17 +, Jäkel, Guido wrote: 
 yes and it does this.  The point is that lxcbr0 is not tied to any
 physical nic.  So the first container you start, however high the
 macaddr is, lxcbr0 takes its mac.  If the next container gets a
 lower macaddr, lxcbr0's macaddr drops.

 This lxcbr0 is special to Ubuntu, right? And if not to a physical NIC, to 
 what is this bridge connected to on the host?

Not to the best of my knowledge.  It should be a simple bridge.

What do you get for this command?

brctl show

A bridge doesn 
 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] lxcbr0 MAC addr issue

Crap...  Bumped the keyboard and this one got away from me prematurely.

On Wed, 2013-06-05 at 11:23 -0400, Michael H. Warfield wrote: 
 On Wed, 2013-06-05 at 15:17 +, Jäkel, Guido wrote: 
  yes and it does this.  The point is that lxcbr0 is not tied to any
  physical nic.  So the first container you start, however high the
  macaddr is, lxcbr0 takes its mac.  If the next container gets a
  lower macaddr, lxcbr0's macaddr drops.

  This lxcbr0 is special to Ubuntu, right? And if not to a physical
 NIC, to what is this bridge connected to on the host?

 Not to the best of my knowledge.  It should be a simple bridge.

 What do you get for this command?

 brctl show

 A bridge doesn 

A bridge doesn't have to be attach to a device.  A bridge is its own
logical entity in the kernel to which you may attach devices.  You can
not attach a bridge to something else.  You can only attach something
else to the bridge.  There's a difference.

In the case of a NATing configuration, you set up a bridge (name it
whatever you want) and attach the containers to it.  Then you use the
NAT modules to route between the bridge and the external interface while
NATing the addresses.  I use lxcbr0 on my Fedora hosts.  It's just a
bridge.

I could see where Ubuntu might have some preconfigured setups for this
purpose where I have to set them up by hand in Fedora.  That's just a
matter of the distro specific support scripts.

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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] lxcbr0 MAC addr issue

On Wed, 2013-06-05 at 06:23 +, Hans Feldt wrote:
 It is a fact that the bridge takes the lowest MAC address from the
 attached ports for the host port. See for example
 http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/

 Thus if a container is restarted, the host port can potentially change
 its MAC address and containers will have a stale ARP cache. This of
 course causes problem for communication container-host.

 Tested the workaround mentioned in the link but then I got problem
 with network manager on a later Ubuntu version. Then I tried using a
 dummy container and reusing its MAC addr for the host port. Works
 but...

 Now my question, could not lxc (at boot) setup a fixed MAC addr for
 the host port?

There's a gotcha in there.  You can not set an arbitrary MAC address on
a bridge.  It can only be the MAC address of an attached interface.  It
has to do with how packets are routed down in the kernel and determining
if a packet is to be handled locally on the bridge or not.  It also may
have some ties in to the spanning tree algorithm protocol logic (whether
you are using STP or have it enabled or not).  If you set it to a fixed
MAC address of a container, you can't stop or reboot that container
without losing that static assignment on the bridge.

A dummy container is one option, if you don't have a host hardware
interface connected to the bridge.  But you need one with a MAC address
lower than any of the others.  Another alternative is to use a dummy
interface...

modprobe dummy
brctl addif lxcbr0 dummy0

The dummy0 interface doesn't even need to be up or have an IP address
assigned to it.

Since the container host-local addresses will all be private (fe:...)
and the dummy0 interface will have something lower, you should be good
to go.

 Thanks,
 Hans

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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] lxcbr0 MAC addr issue

On Wed, 2013-06-05 at 11:26 -0500, Serge Hallyn wrote: 
 Quoting Michael H. Warfield (m...@wittsend.com):
  Crap...  Bumped the keyboard and this one got away from me prematurely.
  
  On Wed, 2013-06-05 at 11:23 -0400, Michael H. Warfield wrote: 
   On Wed, 2013-06-05 at 15:17 +, Jäkel, Guido wrote: 
yes and it does this.  The point is that lxcbr0 is not tied to any
physical nic.  So the first container you start, however high the
macaddr is, lxcbr0 takes its mac.  If the next container gets a
lower macaddr, lxcbr0's macaddr drops.
  
This lxcbr0 is special to Ubuntu, right? And if not to a physical
   NIC, to what is this bridge connected to on the host?
  
   Not to the best of my knowledge.  It should be a simple bridge.
  
   What do you get for this command?
  
   brctl show
  
   A bridge doesn 
  
  A bridge doesn't have to be attach to a device.  A bridge is its own
  logical entity in the kernel to which you may attach devices.  You can
  not attach a bridge to something else.  You can only attach something
  else to the bridge.  There's a difference.
  
  In the case of a NATing configuration, you set up a bridge (name it
  whatever you want) and attach the containers to it.  Then you use the
  NAT modules to route between the bridge and the external interface while
  NATing the addresses.  I use lxcbr0 on my Fedora hosts.  It's just a
  bridge.
  
  I could see where Ubuntu might have some preconfigured setups for this
  purpose where I have to set them up by hand in Fedora.  That's just a
  matter of the distro specific support scripts.
 
 Right.  And we *could* attach a dummy device with mac starting with
 something lower.

 BUT I just did some testing, and even as I watch lxcbr0's addr go down
 when starting a new container, my ssh to the container which had the
 higher macaddr doesn't hiccough.

Hmmm...  It would be interesting to see what you get from arp -a on
the host and the container before and after that.  It would also be
interesting to see what happens if you ssh to a container with the
higher address first and then bring up a container with a lower mac
address and see if it impacts the existing connection.

It really all depends on how the host is managing the arp table and, if
the MAC address changes, how does the bridge change impact the arp
table.

In the case of ssh'ing to a container from the host, the host would
still have the correct arp entry for the container which would
facilitate the delivery of the initial SYN.  The container would have an
incorrect entry but that should correct itself as soon as that new
packet arrives connecting from the host, invalidating the containers arp
table entry, I would think.

It should also correct the MAC table entries for the bridge (used by the
STP) if it originates from the interface that changed.  It works the
same way over an eitherswitch externally.  The moment a packet is sent
with a new from MAC address, the switch (bridge) remembers what port
(attachment) that MAC address was last seen on and enters it into it's
mac switch table.

What would be interesting to know is how the container sees it, since
his arp table entry for the host is then wrong if he initiates a packet
first, after the change.  It could be that the tap/bridge connection
from container to host bridge would clear that up quickly.

 Perhaps it'll be a problem when connected from an outside host (through
 port forwarding).  In that case I'll happily do the dummy if hack.  But
 it seems possible that it just isn't needed.  (And since the iptables rule
 is --to-destination an ip address, I'm thinking it won't be)

Yeah, since the host exposed IP and MAC are not changing, it shouldn't
be, in the external case with NAT as you describe.  The external systems
will only be referencing the external IP address for which the MAC
doesn't change and the ARP tables are perfectly coherent, externally.
So NAT w/ port forwarding to a container should be covered.

It's where the MAC address of the host interface changes (because it's
attached to a bridge) where you get into trouble in the external case.
But, we have that case covered now with the fixes that are in-place
since 0.8.0 (assuming the OP is on a recent enough version of the lxc
tools).

So both of those should be covered.

That really just leaves the host - container case (container -
container should be a trivial non-issue).  Then I think it's an issue of
which side of the bridge is issuing the first packet after the MAC
address changes and what does the bridge logic do about it.  Seems like
a corner case to me.  I also don't know what role STP has in this game.
On my fedora system, my lxcbr0 bridge has STP disabled but the virbr0
bridge (used by libvirt and setup by default) has it enabled and I have
no idea why.  It's possible that these symptoms could vary depending on
that setting.  I've definitely heard it mentioned before.

Oh, and this is likely to get really ugly with IPv6.  With the host

Re: [Lxc-users] Routing issues

2013-06-04 Thread Michael H. Warfield

On Tue, 2013-06-04 at 11:21 +0100, Rory Campbell-Lange wrote: 
 On 03/06/13, Serge Hallyn (serge.hal...@ubuntu.com) wrote:
  Quoting Rory Campbell-Lange (r...@campbell-lange.net):
   On 04/06/13, Papp Tamas (tom...@martos.bme.hu) wrote:

What is the IP address of the container?
   
   The host is on aa.bb.cc.103 (a public net address)
   and the container is on aa.bb.cc.87.
   
   I can get from 87 to 103, but I can't ping the gateway from the
   container.
  
  Hm, here's an idea.  Lxc sets /proc/sys/net/ipv4/conf/$link/forwarding.
  Perhaps that isn't enough.  You might echo 1 
  /proc/sys/net/ipv4/conf/eth0/forwarding and
  /proc/sys/net/ipv4/ip_forward.
  
  But,
  
  1. what does 'route -n' in the container (and on the host) show?
  
  2. when you ping the ip address of your router, what does traceroute
  (wireshark, whatever) on the host show?

 Hi Serge

 Thanks very much for your email.

 Going through the steps above showed me I had a firewall problem. Dropping the
 firewall allowed the container to hit the internet. Apologies for this 
 beginner
 problem.

 I'd be grateful to know if anyone has some firewall (iptables) advice for
 allowing traffic to the container? I expect to run another firewall on the
 container itself.

That's probably your FORWARD chain there.  Set that policy to ACCEPT and
flush all the rules from the FORWARD chain like this:

iptables -P FORWARD ACCEPT
iptables -F FORWARD

FORWARD chain is going to affect packets forwarded over the host's
bridge to the containers.  The INPUT and OUTPUT chains will affect the
packets coming in and going out from the local host's OS interfaces.

Depending on your distro, track down your persistent rule storage and
make those changes permanent.  Fedora prior to firewalld (here we go
again), RedHat, and RH derivatives (CentOS et al) are generally
in /etc/sysconfig/iptables unless you've also installed one of the
sundry firewall toolkits.  Ubuntu, I'm not so sure about.

 Regards
 Rory
 
 -- 
 Rory Campbell-Lange
 r...@campbell-lange.net
 
 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
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

2013-06-02 Thread Michael H. Warfield

On Sun, 2013-06-02 at 11:18 +0530, Shridhar Daithankar wrote:
 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.

That's an interesting suggestion that might be worth consideration over
on the lxc-devel list where we are currently considering autostart
proposals.  Not sure if you're doing this under Arch Linux or Fedora (or
maybe CentOS) but we will need some suggestions for incorporating the
proposed boot management into the systemd based hosts.

Current proposal on the table is discussing having an autostart flag,
boot delay, and group name contained in the container's configuration
file.  If a container is then transported from one host to another, the
boot attributes are transported along with it.  It's also highly
desirable to have a uniform autoboot convention such that you're not
dependent on whether you're running systemd (CentOS, SL, Fedora, Arch)
or upstart (Ubuntu and others) or the older sysvinit scripts.  One
highly desirable characteristic is to have the processed more or less
consistent regardless of the host platform, keeping it as platform
agnostic as possible.  The current Ubuntu convention of having links
in /etc/lxc/boot/{container} to the container config
in /var/lib/lxc/{container}/config may or may not end up being part of
that proposal.

Under the proposed paradigm, we would not be using systemd unit files
for autostarting the containers and, rather, have a service that runs
our startup process that would then handling this.  Doing this purely as
systemd unit devices would not be portable from, say, a Fedora host to
an Ubuntu host.  Even moving this from a Fedora host to another Fedora
host (or Arch), we would have to also remove and rebuild unit files on
each host, as that wouldn't have been automatically transported.  This
also would be challenging to work with prioritizing or ordering the boot
order independent of the container name.

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.

 Thanks

Thank you.

 -
 #!/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

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!


--
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] frequent host machine kernel panic

2013-06-02 Thread Michael H. Warfield

On Sun, 2013-06-02 at 17:02 +0530, Kalyana sundaram wrote:
lxc 0.8.0

I saw from your original post that you're running CentOS 6.2. WHY?
CentOS is on rolling release and you should be on 6.4. That tells me
you are fairly out of date.

What version kernel are you running? Seems like it's a kernel bug and
there's always a possibility that it's been fixed.

Have you tried updating to 6.4?

What are the distributions and versions you are attempting to run in the
containers?

How did you install lxc on CentOS? I don't see it in the CentOS
repositories and 0.8.0 seems newer than I would expect, even if it were.

What were the instructions you followed to create your containers?
Reason I'm asking is that the CentOS wiki page on creating lxc
containers is referring to the libvirt lxc and not this lxc. If you
followed the instructions on this page, then you are using the libvirt
lxc which is a different project and not this one!

http://wiki.centos.org/HowTos/LXC-on-CentOS6

Yes, it's confusing. Not sure who's to blame for two projects with the
same name for the same functionality.

There are some recent (from back in March) instructions out there that
refer to setting up this lxc flavor on CentOS 6.2 which baffle the crap
out of me that they hadn't used or recommended using the latest version
of CentOS. They also recommended using the OpenVZ CentOS 5 templates.
I'm not really sure I would follow those instructions.

http://www.techrepublic.com/blog/opensource/how-to-create-lxc-system-containers-to-isolate-services/1299

CentOS 6 is still upstart based. You could probably get away with 0.7.5
which is what I would have expected in the repos. We haven't created an
lxc-centos template (yet) for lxc-create but I've been considering it
based on the lxc-fedora template (the differences are rather ugly). The
procedures for creating the container are significantly different
between those two sets of instructions (the CentOS wiki and that set at
TechRepublic.

I have used the OpenVZ CentOS 6 templates to create LXC containers but
I'm running on a Fedora 17 host with very up-to-date kernels. At the
very least, you should update those host systems to the latest CentOS
release and kernels in order to get any help analyzing what the problem
is.

On Sun, Jun 2, 2013 at 12:02 PM, Papp Tamas tom...@martos.bme.hu wrote:

On 06/02/2013 06:06 AM, Kalyana sundaram wrote:

No actually kernel panics happen in more than one host.

Please keep the mailing list in the address list and don't use toppost.

What version do you use?

tamas

--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/

--
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] Anyone with some prebuilt templates laying around they could share?

2013-06-02 Thread Michael H. Warfield

A recent threat on the lxc-users reminded me that I'm lacking a few
templates for testing under LXC.  OpenVZ has a number of prebuilt
containers (like CentOS) for download which some people (myself) have
used to create containers where we don't have prebuilt templates or the
lxc-templates we have do not function cross-distro.

For example...

On a Fedora host, I can create an Ubuntu container, thanks to deboot.

On an Ubuntu host, I can create a Fedora container using feboot.

I don't see an equivalent for Arch on either.  I can tell you that
trying to create an Arch container on Fedora host will fail miserably
trying to use lxc-create.  That template seems to be strictly
like-on-like, which is sad.  There is no Arch template in OpenVZ to even
give me a start, so I'm out of luck there.  How do we bootstrap an Arch
system with packman on a system which does not have packman?

Anyone with an Arch container prebuilt template they could share?

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!


--
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] list admin

2013-05-24 Thread Michael H. Warfield

On Fri, 2013-05-24 at 08:31 +0200, Tamas Papp wrote: 
 On 05/24/2013 02:06 AM, Daniel Lezcano wrote:
  Yes, sure.
 
  Sorry, I have been more and more busy with other stuff and flooded by
  emails, so I did not followed the discussion closely.
 
  Can you explain in a few words what do you need ?
 
 
 I'd like to be sure, there is no SPOF in the listadmin position:)

 Personally I want to kick off the invalid email address, like Mike said.
 Also I think it would be a good idea to change the Reply-To: header to the 
 list address.

There are, in my experience, always arguments for and against setting
the Reply-To: header as you suggest.  However, I was just reminded by a
bounce catch over on the -devel list, that the bounce catcher does work
pretty good in the majority of the cases when bounces go back to the
list and the bad addresses get automagically unsubscribed.  So, that
idea of changing the Reply-To gets my endorsement.  I would just wait a
short while for anyone else to chime in with an opinion and then make it
so.

+1

 Cheers,
 tamas


-- 
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!


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
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

2013-05-24 Thread Michael H. Warfield

On Sat, 2013-05-18 at 12:09 -0700, jjs - mainphrame wrote: 
 Interesting. I didn't realize how spoiled I am and how easy I have it with
 lxc on ubuntu!

Don't get too too comfortable.  I don't know if Ubuntu is transitioning
to systemd yet or not (or planning to or creating a new alternative) but
this was a talk tease from a talk delivered by my friend and co-guru
Mark Torres (formerly of Suse fame) to the Atlanta Unix Users Group a
couple of months ago...

-- 
  Marc will be discussing some of the myths, uses and advantages of
  this replacement of the Linux sysvinit package.  Despite the best
  efforts of many (and a never ending supply of mailing list
  flames, holy water, silver bullets, wooden stakes, poisons and
  evil looks) it is coming soon to a Linux Distro near you.
-- 

You may have to deal with the likes of systemd sooner or later (or some
other variant in similar concept).  This is not something peculiar to
Fedora (OpenSuse, and Arch Linux both have systemd as will RHEL, CentOS,
Scientific Linux, etc...).  By the time it gets to Ubuntu, though, I
suspect it will be much more stable.

Seems like Fedora adopted it early (very much like Ubuntu with Unity)
and Fedora has sort of been the proving ground for systemd (that's what
Fedora is for).  Personally, I'm in the holy water and wooden stakes
category (and I have at least one flame war on the systemd list to back
me up) with regards to systemd but it is what it is.  We've been dealing
with it as it evolves.

It's worth noting that I've decided that I will never get Fedora 15 or
Fedora 16 running in a container (they will work as a host, however) due
to incompatible versions of systemd.  But F15 and F16 are EOL and thus
not worth any effort or stress.  They (systemd) obviously found
solutions for the havoc they caused in those versions and we have
managed to get F17 and F18 working with the recent versions of systemd.
It's not Fedora, it's systemd that create these problems.

OTOH...  Unity caused me to totally abandon Ubuntu.  It totally broke
freenx and the NX support and try as I might, I could not get it to work
after trying for 2 or 3 releases of Ubuntu.  Even though the freenx
package was still in the repos, several of the libraries upon which it
depended were gone or deprecated.  I tried all the manual patches and
source compiles and nothing worked or created irreconcilable conflicts.
If I can't use NX to get graphic desktops in a container or on a remote
host system, Ubuntu became useless to me and I had to rip it out where I
had it.  Even the laptops for my grandkids (which were running Ubuntu)
are now running on Fedora for that reason (so grandpa can have a remote
desktop on their laptop and do remote graphical administration).

Maybe they have since fixed it but they already lost me on that one
point alone.  I do need to get some (at least one) containers running
Ubuntu running just so I can run Oregano (Electronics Schematic CAD
program with simulation capabilities) which I can not get to work on
Fedora 18 (Fedora 19 might work) due to some gtk3+ library issues.  So
maybe I'll revisit Ubuntu again soon.  I have successfully built an
Ubuntu container on a Fedora host.  That's one of the nice things, that
I can cross build Ubuntu on a Fedora host.  I think (but I haven't
tried) the reverse is true.  If not, I may have to fix that in the
Fedora template.  That's not true of many of the other templates.  I
can't build an Arch Linux container on a Fedora host.  That's something
the container owners have to address.

We've gotten it (systemd) working and functional (maybe not totally
pretty) and now it's more a matter of getting the updated revs into
the downstream releases to make it just as easy.  That's the way it
works.  All the template maintainers (and I'm just a contributor) are
shooting at moving targets.  What's in the git repo right now for the
Fedora template is pretty sweet (if I do say so myself) and will build
Fedora containers out of the box.

Which reminds me.  The dudes that do the Fedora Remix for the Raspberry
Pi just renamed their distribution to Pidor (shades of Kubuntu, Edubuntu
and the other remixes of Ubuntu).  That's going to break the lxc-fedora
template on the Raspberry Pi (yet again - pounding head on desk).  Right
now, AFAICT, the ARM support for Ubuntu is only for ARM7 and up which
leaves out the RPi (ARM6).  Oh well.  It never ends.

 Joe

Regards,
Mike 

 On Sat, May 18, 2013 at 11:19 AM, Michael H. Warfield 
 m...@wittsend.comwrote:
 
  On Sat, 2013-05-18 at 19:41 +0530, Ajith Adapa wrote:
   Hmm sounds one more road block for using lxc in fedora 17 because of
   systemd.
 
  It's not a roadblock.  More like a mile long stretch of stingers (stop
  spike strips / tire deflators).  We're getting there.  It's just one
  more unnecessary puzzle to solve.  Sigh...
 
   Currently there is no place where there is a guide for starting up
   with LXC for latest fedora versions. I think a page in fedoraproject

Re: [Lxc-users] list admin

2013-05-23 Thread Michael H. Warfield

On Thu, 2013-05-23 at 22:33 +0200, Tamas Papp wrote:
 hi Guys,

 Please, someone!
 Who is the owner/admin of this list?

Last I knew, it was Daniel who created the list and most likely owns
it.  It was created at my suggestion to move user questions off the
devel list ages and ages ago.  Lately he's typically been buried over
his head busy that he doesn't show up much even in the -devel list
lately other than to cut a release, must less this list.  You're
probably complaining about that bad E-Mail address that's been on the
list for like forever.  It's been mentioned before.  It's a mailman list
so we just need someone with owner privs and the password.

 Thanks,
 tamas

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
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] list admin

2013-05-23 Thread Michael H. Warfield

On Fri, 2013-05-24 at 02:06 +0200, Daniel Lezcano wrote: 
 On 05/23/2013 11:44 PM, Tamas Papp wrote:
  On 05/23/2013 11:13 PM, Michael H. Warfield wrote:
  Last I knew, it was Daniel who created the list and most likely owns
  it.  It was created at my suggestion to move user questions off the
  devel list ages and ages ago.  Lately he's typically been buried over
  his head busy that he doesn't show up much even in the -devel list
  lately other than to cut a release, must less this list.  You're
  probably complaining about that bad E-Mail address that's been on the
  list for like forever.  It's been mentioned before.  It's a mailman list
  so we just need someone with owner privs and the password.
 
  I already offered my service on the list a couple of months ago, but
  no answer was received:(
  I would be glad to kick off that address:)
 
  Also I think replies should be addressed to the list, though whose
  decision it is.
 
  Daniel, can you help in this?

 Yes, sure.

 Sorry, I have been more and more busy with other stuff and flooded by
 emails, so I did not followed the discussion closely.

Hasn't been much discussion.  Just alot of random complaints about one
particular E-mail address on the -users list which has not be valid and
has been bouncing for ages.

 Can you explain in a few words what do you need ?

If you can nuke off msklizman...@ebuddy.com, that would be great.

Longer term, you might want to share list ownership or moderator with
one of us, like Tamas, so we can handle some of the administrivia for
you when you are up to your eyeballs in fecal matter.  :-P

I've managed numerous mailman, ezmlm (yuck), and majordomo lists down
through the years but Tamas has also volunteered to help out.

 Thanks
   -- Daniel

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!


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] Is there a way to get the container name from inside the container?

2013-05-21 Thread Michael H. Warfield

On Mon, 2013-05-20 at 21:30 -0700, Masood Mortazavi wrote:
 I seem recall that the host name is the same as container name.
 Try to print/view the host name while in the conatiner.
 You can also configure your .bash_profile to ensure the host name (i.e the
 container name in this case) appears on your bash command prompt.

By default it is but that's not required.  If you create it with
lxc-create, then the container name, the lxc.utsname in the config and
the hostname of the system will be the same.  After the container has
been created, these can be changed independently.  The question has also
been raised (by me) over on the -devel list of setting the utsname and
the host name to an FQDN (Fully Qualified Domain Name) based on the
container name and the domain name of the host or by an independent
template creation object (--fqdn), since it's generally desirable for
those two to be an FQDN while keeping the container name to a simple
name.  I would not depend on the host name to match the container name
unless this is a site convention you enforce locally.

Regards,
Mike

 Good luck,
 m.
 
 
 
 On Thu, May 16, 2013 at 2:08 PM, Vallevand, Mark K 
 mark.vallev...@unisys.com wrote:
 
  Is there a way to get the container name from inside the container?
 
  ** **
 
  Regards.
  Mark K Vallevand   mark.vallev...@unisys.com
 
  May you live in interesting times, may you come to the attention of
  important people and may all your wishes come true.
 
  THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
  MATERIAL and is thus for use only by the intended recipient. If you
  received this in error, please contact the sender and delete the e-mail and
  its attachments from all computers.
 
  ** **
 
 
  --
  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
 
 
 
 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___ Lxc-users mailing list 
 Lxc-users@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/lxc-users

-- 
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
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
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

2013-05-19 Thread Michael H. Warfield

On Sun, 2013-05-19 at 09:26 +0530, Shridhar Daithankar wrote:
 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.

Or, after reading that first document, another idea that comes to mind.
This is one that could be implemented in the lxc-fedora template.  The
idea is based on the section near the bottom of that document titled
Serial Terminals and mentions However, sometimes there's the need to
manually configure a serial getty...  That can be adapted and used with
getty@.service like this...

cp /lib/systemd/system/getty@.service /etc/systemd/system

Now edit /etc/systemd/system/getty@.service and delete or comment out
the ConditionPathExists=/dev/tty0 line.

Finally...

cd /etc/systemd/system/getty.target.wants/
ln -sf ../getty\@.service getty@tty1.service
ln -sf ../getty\@.service getty@tty2.service
ln -sf ../getty\@.service getty@tty3.service
ln -sf ../getty\@.service getty@tty4.service
...  For the number of vty logins you want up to the number of ttys you
have specified in lxc.tty.

That overrides the getty@.service in /lib/systemd/system/

Tested out with a Fedora 17 container I have running hear now and it
works like a charm.  You do end up with multiple agetty processes
running that way.  I can then use lxc-console to connect to those
consoles.  This would seem to be a cheap and dirty way to get it to
work.

Looks like we could try with some virtual console devices they mention
in that document as well but that recurses back to needing to modify
lxc-start and the autodev logic.

 -- 
 Regards
  Shridhar
 

-- 
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
--
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

Re: [Lxc-users] Regarding creating a LXC container in fedora 17

] ip_rcv+0x24c/0x370
 [1281973.370052]  [c088d5db] __netif_receive_skb+0x5bb/0x740
 [1281973.370052]  [c088d8ce] netif_receive_skb+0x2e/0x90
 [1281973.370052]  [f7c36a49] virtnet_poll+0x449/0x6a0 [virtio_net]
 [1281973.370052]  [c044d6aa] ? run_timer_softirq+0x1a/0x210
 [1281973.370052]  [c088decd] net_rx_action+0x11d/0x1f0
 [1281973.370052]  [c044695b] __do_softirq+0xab/0x1c0
 [1281973.370052]  [c04468b0] ? local_bh_enable_ip+0x90/0x90
 [1281973.370052]  IRQ
 [1281973.370052]  [c0446bdd] ? irq_exit+0x9d/0xb0
 [1281973.370052]  [c04258ee] ? smp_apic_timer_interrupt+0x5e/0x90
 [1281973.370052]  [c097a440] ? apic_timer_interrupt+0x34/0x3c
 [1281973.370052]  [c044007b] ? console_start+0xb/0x20
 [1281973.370052]  [c0979bbf] ? _raw_spin_unlock_irqrestore+0xf/0x20
 [1281973.370052]  [c07918d6] ? ata_scsi_queuecmd+0x96/0x250
 [1281973.370052]  [c076ad18] ? scsi_dispatch_cmd+0xb8/0x260
 [1281973.370052]  [c066007b] ? queue_store_random+0x4b/0x70
 [1281973.370052]  [c07711b3] ? scsi_request_fn+0x2c3/0x4b0
 [1281973.370052]  [c042f2b7] ? kvm_clock_read+0x17/0x20
 [1281973.370052]  [c0409448] ? sched_clock+0x8/0x10
 [1281973.370052]  [c065cace] ? __blk_run_queue+0x2e/0x40
 [1281973.370052]  [c066214a] ? blk_execute_rq_nowait+0x6a/0xd0
 [1281973.370052]  [c066221d] ? blk_execute_rq+0x6d/0xe0
 [1281973.370052]  [c06620b0] ? __raw_spin_unlock_irq+0x10/0x10
 [1281973.370052]  [c0446ba7] ? irq_exit+0x67/0xb0
 [1281973.370052]  [c04258ee] ? smp_apic_timer_interrupt+0x5e/0x90
 [1281973.370052]  [c097a440] ? apic_timer_interrupt+0x34/0x3c
 [1281973.370052]  [c076ffa0] ? scsi_execute+0xb0/0x140
 [1281973.370052]  [c0771429] ? scsi_execute_req+0x89/0x100
 [1281973.370052]  [c077f3d5] ? sr_check_events+0xb5/0x2e0
 [1281973.370052]  [c07a64cd] ? cdrom_check_events+0x1d/0x40
 [1281973.370052]  [c077f856] ? sr_block_check_events+0x16/0x20
 [1281973.370052]  [c06663c5] ? disk_check_events+0x45/0xf0
 [1281973.370052]  [c0666485] ? disk_events_workfn+0x15/0x20
 [1281973.370052]  [c045788e] ? process_one_work+0x12e/0x3d0
 [1281973.370052]  [c097a440] ? apic_timer_interrupt+0x34/0x3c
 [1281973.370052]  [c0459939] ? worker_thread+0x119/0x3b0
 [1281973.370052]  [c0459820] ? flush_delayed_work+0x50/0x50
 [1281973.370052]  [c045e2a4] ? kthread+0x94/0xa0
 [1281973.370052]  [c0980ef7] ? ret_from_kernel_thread+0x1b/0x28
 [1281973.370052]  [c045e210] ? kthread_create_on_node+0xc0/0xc0
 [1281973.370052] Code: 5d c3 8d b4 26 00 00 00 00 89 02 c3 90 8d 74 26 00
 81 fa ff ff 03 00 89 d1 77 2e 81 fa 00 00 01 00 76 0e 81 e2 ff ff 00 00 66
 ef c3 90 8d 74 26 00 55 ba 2c 5a b2 c0 89 e5 89 c8 e8 01 ff ff ff
 [1281991.139165] ata2: lost interrupt (Status 0x58)
 [1281991.148055] ata2: drained 12 bytes to clear DRQ
 [1281991.165039] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
 frozen
 [1281991.172924] sr 1:0:0:0: CDB:
 [1281991.172932] Get event status notification: 4a 01 00 00 10 00 00 00 08
 00
 [1281991.497342] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio
 16392 in
 [1281991.497342]  res 40/00:02:00:04:00/00:00:00:00:00/a0 Emask 0x4
 (timeout)
 [1281991.523767] ata2.00: status: { DRDY }
 [1281991.616161] ata2: soft resetting link
 [1281998.232648] ata2.01: qc timeout (cmd 0xec)
 [1281998.238559] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
 [1281998.247432] ata2: soft resetting link
 [1281998.575468] ata2.01: NODEV after polling detection
 [1281998.698009] ata2.00: configured for MWDMA2
 [1281998.714460] ata2: EH complete

Not sure what the deal is with that ATA error.  That's a hard drive lost
interrupt problem.  Looks to be on your CD Rom drive?  Looks like it
recovered.

 3. Last but not least after sometime my host kernel crashed as a result
 need to restart the VPC.

I don't understand what you are saying here.  You're saying your kernel
crashed but I don't understand the as a result of...  What did you do,
why did you do it, and what happened?

 Regards,
 Ajith

Regards,
Mike

 On Thu, May 16, 2013 at 8:09 PM, Ajith Adapa ajith.ad...@gmail.com wrote:
 
  Thanks @thomas and @michael.
 
  I will try the RPMs and steps provided to start a container.
 
  Regards,
  Ajith
 
 
  On Wed, May 15, 2013 at 2:01 PM, Thomas Moschny 
  thomas.mosc...@gmail.comwrote:
 
  2013/5/14 Michael H. Warfield m...@wittsend.com:
   What I would recommend as steps on Fedora 17...
  
   Download lxc-0.9.0 here:
  
   http://lxc.sourceforge.net/download/lxc/lxc-0.9.0.tar.gz
  
   You should have rpm-build and friends installed via yum on your system.
   Build the lxc rpms by running rpmbuild (as any user) as follows:
 
  You could also try using the pre-built packages I put here:
  http://thm.fedorapeople.org/lxc/ .
 
  Regards,
  Thomas
 
 
  --
  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

Re: [Lxc-users] Regarding creating a LXC container in fedora 17

On Sat, 2013-05-18 at 19:02 +0530, Ajith Adapa wrote:
 Sorry for the confusion.

 In case of issue 3, I felt host kernel crashed because of the soft
 lock issue mentioned in Issue 2.That's the reason I was saying as a
 result of ... Ideally speaking I haven't done anything other than
 creating the lxc-container at the time. Once I restarted the host
 machine after crash I havent observed any issues. 

 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.

Regards,
Mike

 Regards,
 Ajith
 
 
 
 
 On Sat, May 18, 2013 at 5:55 PM, Michael H. Warfield
 m...@wittsend.com wrote:
 Hello,
 
 On Sat, 2013-05-18 at 12:35 +0530, Ajith Adapa wrote:
  Hi,
 
  I have installed all the rpms created by @thomas and
 followed @michael
  steps to start a lxc container.
 
  I have a doubt.
 
  1. When I give lxc-create command I came across huge
 download of various
  files.
  As per my understanding rootfs is created for new container
 (where can i
  get the steps for it ? ).
 
 
 Steps for what?  It's in /var/lib/lxc/{Container}/rootfs/
 
  But I see below log. Is there any issue ?
 
  Copy /var/cache/lxc/fedora/i686/17/rootfs
 to /var/lib/lxc/TEST/TEST/rootfs
  ...
  Copying rootfs to /var/lib/lxc/TEST/TEST/rootfs ...setting
 root passwd to
  root
  installing fedora-release package
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
  warning: Failed to read auxiliary vector, /proc not mounted?
 
 
 The warnings are perfectly normal and harmless.  I ran into
 this with
 recent versions of yum and researched it.  It's because /proc
 is not
 mounted in the container itself when the container is being
 created.
 You can ignore them.
 
  Package fedora-release-17-2.noarch already installed and
 latest version
  Nothing to do
 
 
 Again, normal.
 
  container rootfs and config created
  'fedora' template installed
  'TEST' created
 
 
 Looks like your container was created.  I don't see a problem.
 
  2.I see a SOFT LOCK issue with latest version kernel shown
 below.
 
  # uname -a
  Linux blr 3.8.8-100.fc17.i686 #1 SMP Wed Apr 17 17:26:59 UTC
 2013 i686 i686
  i386 GNU/Linux
 
 
  [1098069.351017] SELinux: initialized (dev binfmt_misc, type
 binfmt_misc),
  uses genfs_contexts
  [1281973.370052] BUG: soft lockup - CPU#0 stuck for 23s!
 [kworker/0:1:2201]
 
 
 I've seen that on my Dell 610's but they haven't caused any
 real
 failures.  Not quite sure what that is.
 
  [1281973.370052] Modules linked in: binfmt_misc lockd sunrpc
 snd_intel8x0
  snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm
 i2c_piix4

Re: [Lxc-users] Regarding creating a LXC container in fedora 17

On Sat, 2013-05-18 at 19:41 +0530, Ajith Adapa wrote:
 Hmm sounds one more road block for using lxc in fedora 17 because of
 systemd.

It's not a roadblock.  More like a mile long stretch of stingers (stop
spike strips / tire deflators).  We're getting there.  It's just one
more unnecessary puzzle to solve.  Sigh...

 Currently there is no place where there is a guide for starting up
 with LXC for latest fedora versions. I think a page in fedoraproject
 would be of great help with the known issues and steps using lxc under
 various fedora versions.

First we get it working but, yeah, that would be incredibly nice and
then also add it to this project as well.

 I am really thinking to start using LXC containers in fedora 14. Build
 and Boot it up with latest stable kernel version (Might be 3.4) and
 LXC version (0.9) and try out using LXC- containers :)
 
 
 
 
 On Sat, May 18, 2013 at 7:28 PM, Michael H. Warfield
 m...@wittsend.com wrote:
 On Sat, 2013-05-18 at 19:02 +0530, Ajith Adapa wrote:
  Sorry for the confusion.
 
  In case of issue 3, I felt host kernel crashed because of
 the soft
  lock issue mentioned in Issue 2.That's the reason I was
 saying as a
  result of ... Ideally speaking I haven't done anything
 other than
  creating the lxc-container at the time. Once I restarted the
 host
  machine after crash I havent observed any issues.
 
  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.
 
 Regards,
 Mike
 
  Regards,
  Ajith
 
 
 
 
  On Sat, May 18, 2013 at 5:55 PM, Michael H. Warfield
  m...@wittsend.com wrote:
  Hello,
 
  On Sat, 2013-05-18 at 12:35 +0530, Ajith Adapa
 wrote:
   Hi,
 
   I have installed all the rpms created by @thomas
 and
  followed @michael
   steps to start a lxc container.
 
   I have a doubt.
 
   1. When I give lxc-create command I came across
 huge
  download of various
   files.
   As per my understanding rootfs is created for new
 container
  (where can i
   get the steps for it ? ).
 
 
  Steps for what?  It's
 in /var/lib/lxc/{Container}/rootfs/
 
   But I see below log. Is there any issue ?
 
   Copy /var/cache/lxc/fedora/i686/17/rootfs
  to /var/lib/lxc/TEST/TEST/rootfs
   ...
   Copying rootfs
 to /var/lib/lxc/TEST/TEST/rootfs ...setting
  root passwd to
   root
   installing fedora-release package
   warning: Failed to read auxiliary vector, /proc
 not mounted?
   warning: Failed to read auxiliary vector, /proc
 not mounted?
   warning: Failed to read auxiliary

Re: [Lxc-users] Regarding creating a LXC container in fedora 17

On Sun, 2013-05-19 at 00:02 +0530, Shridhar Daithankar wrote:
 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

NICE!  I'm going to look at that and see what I can do with it.  That
gives me a thread to pick at.  It should be possible to work that into
the Fedora template.  We've already got systemd related code in there
and this would be nice addition.

Many thanks!

Regards,
Mike

 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
 

-- 
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
--
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 Sun, 2013-05-19 at 00:02 +0530, Shridhar Daithankar wrote:
 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.

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.  :-/

 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
 

-- 
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
--
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

2013-05-15 Thread Michael H. Warfield

On Wed, 2013-05-15 at 10:31 +0200, Thomas Moschny wrote:
 2013/5/14 Michael H. Warfield m...@wittsend.com:
  What I would recommend as steps on Fedora 17...
 
  Download lxc-0.9.0 here:
 
  http://lxc.sourceforge.net/download/lxc/lxc-0.9.0.tar.gz
 
  You should have rpm-build and friends installed via yum on your system.
  Build the lxc rpms by running rpmbuild (as any user) as follows:

 You could also try using the pre-built packages I put here:
 http://thm.fedorapeople.org/lxc/ .

Nice!  I wasn't aware of them.  Many thanks.

 Regards,
 Thomas

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
--
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

2013-05-14 Thread Michael H. Warfield

On Tue, 2013-05-14 at 11:58 +0530, Ajith Adapa wrote:
 Hi,

 Sorry for my basic question as I am new to LXC.

 I would like to know the steps to create a LXC container using lxc in
 fedora 17.

 I have searched for the same in google but I am not able to find any useful
 posts to do the same.

 It would be more helpful if anyone can share the steps if they got any.

Reference other messages about lxc-create.

Fedora 17 has lxc 0.7.5 in the repos, which is NOT going to work.
You're going to run into multiple problems which, basically, you will
not be able to resolve thanks to systemd (init) running in the host and
systemd running in the container.  Fundamentally 0.7.5 is not compatible
with systemd.  You will need at least 0.9.0 (current) to get this to
work.

The Fedora template is not (yet) fully updated to support systemd in a
container.  After creating the container with lxc-create, you have to
edit the container config in /var/lib/lxc/{Container}/config and add an
entry as follows:

lxc.autodev = 1

Steps:

What I would recommend as steps on Fedora 17...

Download lxc-0.9.0 here:

http://lxc.sourceforge.net/download/lxc/lxc-0.9.0.tar.gz

You should have rpm-build and friends installed via yum on your system.
Build the lxc rpms by running rpmbuild (as any user) as follows:

rpmbuild -ta lxc-0.9.0

Resolve any dependencies until it builds and gives you a cluster of rpms
under ~/rpmbuild/RPMS/{arch}/.

Everything here down should now be done as root...

Install the lxc and lxc-libs rpm files using yum localupdate (file
names will be printed near the end of the rpmbuild command run above).

[Optional - install the lxc-devel package as well.]

It should looks sometime like this:

yum localupdate ~user/rpmbuild/RPMS/x86_64/lxc-libs-0.9.0-1.fc17.x86_64.rpm 
~user/rpmbuild/RPMS/x86_64/lxc-0.9.0-1.fc17.x86_64.rpm

Doing this with rpmbuild and yum will properly update the existing
binary packages and documentation while retaining your ability to update
and maintain once it hits the official repos.

Now create your container...

lxc-create -t fedora -n Fedora17 -R 17

(The -R 17 is the default if you're on Fedora 17 and you can leave it
off.)

That should run and create your container.

Now edit the container.

vi /var/lib/lxc/Fedora17/config

And add this line in the file somewhere (if it doesn't already exist):

lxc.autodev = 1

You should now be able to start the container:

lxc-start -n Fedora17


I still need to submit the patches for the Fedora template for the
autodev support and the ARM / Raspberry Pi support.  They'll eventually
get in there.  :-P

 Regards,
 Ajith

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
--
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] How long the dhcp lease lasts

2013-04-22 Thread Michael H. Warfield

On Mon, 2013-04-22 at 21:59 +0200, Robin Monjo wrote:
 Hello everyone,
 
 Using the default config, containers will have their IP attributed by
 the dnsmasq service. I'd like to write in the '/etc/hosts' file of the
 host system the hostname and the corresponding IP address of each
 container I start.

Why?  If you're using dnsmasq, it's in the DNS cache of the dnsmasq
server.  That's its purpose in life, to act as a DNS caching service.
Why do you need it in /etc/hosts when you've already got in in DNS?

 I will then use this hostname in an iptable rules for port forwarding.
 But what if dnsmasq change an IP at the end of the lease ?

 So the question is: how long an IP given by dnsmasq will last ?

What is your lease expiration configured for?  I've used anything for a
few hours (high turnover large WiFi sites) to several days to carry over
a weekend along with static leases for servers and permanent devices.
It depends on what you've configured it for.

 May I see one of my container have its IP changed ?

Maybe.  Depends on what you've configured it for.  I'm not so sure about
dnsmasq acting as the dhcp server (which is what you are talking about)
but dhcpd will notify you of things like this.  Most notably, you will
get deletes on old name/addresses and adds for new name/addresses both
forward and reverse, but it's all configuration driven.
 
 Any ways to have the dnsmasq table synced with the /etc/hosts file
 (container's host side) ?

Again...  Why?  Use the DNS cache in dnsmasq.  You have no need to refer
to /etc/hosts at all.

 Kind regards

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
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] Problem with: lxc.autodev=1

2013-04-20 Thread Michael H. Warfield

On Sat, 2013-04-20 at 22:01 +0200, Andreas Otto wrote:
 Hi,

 thanks for the fast answer,

Been kind-of deeply involved in the whole systemd / audodev thing so I'm
a bit sensitive to some of the bizarre nuances of systemd and various
versions.  You got my attention with that subject line.

They (systemd) really broke far too many things far too unnecessarily
(with little or no benefit from what I can discern) and then tried to
tell everyone else how they should be doing things.  It's been a real
mess.  You can probably tell, I'm not a fan of systemd at the moment.
Maybe when it grows up and matures a bit more...

I've got Fedora 14 (upstart - no systemd) working with and without
autodev, Fedora 15 working with upstart (with systemd only after painful
tweaking) and Fedora 16 not at all with systemd (major udev problems)
but working on Fedora 17 with systemd following their recommendations.
Problem is that their recommendations don't work for all versions of
systemd.  I've really given up on Fedora 15 and 16 in a container just
because systemd is not stable or consistent in its behavior.

 if lxc version is:

 host# rpm -q lxc
 lxc-0.8.0-3.5.1.x86_64
 - this is the version from opensuse 12.3

First recommendation is to get on 0.9.0.  We got a lot of fixes in there
so I can't tell if this was fixed or not.

 my 'guest' has ...

 guest# ps -eaf | grep systemd
 root 24  1  0 19:48 ?00:00:00 
 /usr/lib/systemd/systemd-logind
 message+ 28  1  0 19:48 ?00:00:00 /bin/dbus-daemon 
 --system --address=systemd: --nofork --nopidfile --systemd-activation
 root955  1  0 19:48 ?00:00:00 
 /usr/lib/systemd/systemd-journald

Any idea what version of systemd is running?  I've found there are a
number of versions that seem to be impossible to get to work and one
versions that works you find the next version doesn't.

I find this particular problem rather disturbing.  I have not seen the
permissions problem crop up in a systemd container with autodev enabled.
What I've seen was just the opposite.  This should have worked.  Not
sure what's causing it to be wrong, unless it's the lxc version but ever
0.8.0 worked if you had the right version of systemd.

I did retest a fresh Fedora 14 (upstart) container and it works with the
proper permissions in the /dev directory for both autodev settings.  But
that's under 0.9.0, so that would be my first check.

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
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] mknod inside systemd container

2013-04-04 Thread Michael H. Warfield

Hey John,

On Thu, 2013-04-04 at 09:07 +0100, John wrote:
 On 03/04/13 23:15, Michael H. Warfield wrote:
  On Wed, 2013-04-03 at 23:03 +0100, John wrote:
  On 02/04/13 23:59, Michael H. Warfield wrote:
  On Tue, 2013-04-02 at 16:02 +0100, John wrote:
  If my understanding is correctl, to stop systemd trying to launch udev
  and generally make a mess of everything inside a container, you need to
  remove the mknod capability from the container.
  Ah...  That's kind of old information and not really effective.
 
  But what if I want
  (need) to be able to use mknod inside a container, how can I do that
  with a systemd container?
  1) Get the latest lxc.  lxc 0.8 might suffice for systemd in a container
  but not with systemd in the host and I wouldn't recommend it.  0.9.0 is
  being pulled and bundled now.  It's not up yet but 0.9.0.rc1 is.
 
  2) You'll have to add lxc.autodev = 1 to your configuration file.
  I already do that. I am running lxc version: 0.9.0.alpha3
  That's strange.  What stops systemd from mounting devtmpfs and firing up
  udev is having a tmpfs mounted on /dev.  That's part of what autodev = 1
  is doing.
 I'm taking my understanding from here:
 http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
 where it says The udev unit files will check for CAP_SYS_MKNOD, and 
 skip udev if that is not available.

 But it sounds like you're saying that lxc.autodev = 1 should prevent 
 systemd from firing the udev systemd unit anyway.

Well, sort of.  I may have been a little off there.  I do find that
systemd-udevd is running in my systemd containers but that the actual
udevd process itself is not (as opposed to the host systems and other
systems).  I can run mknod in those containers.  So it is possible to do
this.

But...  A hint may be in the lxc-fedora template where there is
specifically a configure_systemd_fedora function that does this:

configure_fedora_systemd()
{
unlink ${rootfs_path}/etc/systemd/system/default.target
touch ${rootfs_path}/etc/fstab
chroot ${rootfs_path} ln -s /dev/null //etc/systemd/system/udev.service
chroot ${rootfs_path} ln -s /lib/systemd/system/multi-user.target 
/etc/systemd/system/default.target
#dependency on a device unit fails it specially that we disabled udev
sed -i 's/After=dev-%i.device/After=/' 
${rootfs_path}/lib/systemd/system/getty\@.service
}


Something similar does exist in the lxc-archlinux template:

# disable services unavailable for container
ln -s /dev/null /etc/systemd/system/systemd-udevd.service
ln -s /dev/null /etc/systemd/system/systemd-udevd-control.socket
ln -s /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
ln -s /dev/null /etc/systemd/system/proc-sys-fs-binfmt_misc.automount
# set default systemd target
ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

The lxc-archlinux template script seems very badly broken for me,
expecting an fixed bridge name of br0 and not using the defaults
from /etc/lxc/default.conf and looking for things that are not present
on my Fedora host.  So I haven't been able to build an archlinux
container on my host systems.

Did you build yours from lxc-create or did you roll your own?  Maybe you
might want to check those /dev/null links in that container.  Looks like
udevd should not even start if those have been set correctly.

  What distro is running in the container and what version of systemd?
  I've seen this with Fedora 16 but the latest systemd and Fedora 17 in
  the container are fine.
 
 I am running Arch Linux on both host and container:
 Linux 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 
 GNU/Linux
 
 On my host, systemctl --version reports:
 systemd 197
 +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

 And on the container, it's systemd 196

Those versions are congruent with what I'm running.

 I've just checked and the latest version in the Arch repo is 198. I 
 wonder if I should try and update to that?

Proabably won't make a difference.

This did give me some place to look over my headaches with Fedora 15 and
Fedora 16 upgraded containers though.  :-)=)

  I found that, without the removal of mknod capability, everything went
  crazy. I have working containers with systemd both on host and inside
  the container (I even run my full desktop inside a container). To get a
  systemd container working I found I needed three things:
  lxc.autodev = 1
  lxc.cap.drop = mknod
  I'm not having to do that but I'm avoiding F15 and F16 because they
  don't seem to play nice and start reliably.  F17 is doing well for me.
 
  lxc.pts = 1024
 
  It's alll working well except for the fact that I might need to allow a
  container to have mknod capability. Are you saying that with 0.9.0 there
  are changes that negate the requirement for lxc.cap.drop = mknod? The
  way I understood it was that it was systemd that behaved differently
  based on the availability of that capability

Re: [Lxc-users] LXC- ARM6 RaspberryPI Fedora core 14

2013-04-03 Thread Michael H. Warfield

On Wed, 2013-04-03 at 11:29 +0200, Benito wrote:
 Hi There

 I've been working on a project on the Raspberry PI , where we want to 
 run a 32-bit /64-bit fedora 14 container
 on the RaspberryPi .

32-bit / 64-bit?  Huh?  What do you think you're running?  You're going
to be running on the host architecture and host kernel.  The Raspberry
Pi (RPi) is an ARMv6 (at least mine is) and that's 32 bit.  That's going
to be the container as well as the host.  You're not thinking you'll be
running i686 or x86_64 binaries in a container like that, are you?

 I've had success with LXC on a Mint14 64-bit (which 
 is Ubuntu 12 based I believe) host  with Fedora 14 - 64bit container  ( 
 Downloaded FC14 with the template -t parameter below..,, It was as easy 
 as running :

 apt-get install yum
 lxc-create -t fedora -n fedora14

I've got a feeling that is not going to work (at least not yet or at
least now without some effort) for you for a number of reasons...

1) That command you gave won't install Fedora 14 unless you were running
on a Fedora 14 host.  Running that command on one of my F17 hosts
installed F17 into a container named fedora14 but it obviously was NOT
Fedora 14.  Below you say you tried it from a Fedora ARM Remix.  Was it
that the old F14 remix (no longer current or supported) or one of the
current F17 or F18 ones?

2) Why are you wanting to resort to F14?  That's been out of support and
past EOL for over a year now.  It was the last Fedora before they
started resorting to systemd.  If that's your concern, you should get
lxc 0.9.0 (still not on the web site yet - still at 0.9.0.rc1 but should
show up in a day or so) installed so you can support systemd in a
container.

3) The current Fedora ARM Remix is F17 and F18 with versions of systemd
that's going to require lxc 0.9.0 or higher.

4) The current version of lxc in the F18 Remix is only 0.7.5 and will
not support running systemd in a container (F17 or F18) or running on a
host system running recent versions of systemd.  Sigh...

5) I don't know about the Raspian flavor (I'm running Fedora ARM Remix
F17 on my 4 Raspberry PIs) but the F17 ARM Remix has cgroups in place
that should not require a recompiled kernel.  It is going to need a
newer version of lxc, though...

6) Sigh...  Looking at what got built by that lxc-create command, I
realize we also have a template problem for containers running systemd.
The config files have to have autodev = 1 in them.  Even if you
managed to create an F17 or F18 container and have the latest lxc, those
containers will not run properly without that option.  Damn...  I'll
take that up on the development list.

 Now I've been struggling with this for a few weeks , Compiled an LXC 
 friendly kernel on the Raspbian OS, - Debian wheezy ARM , also tried 
 with Fedora ARM remix.
 Is it even possible to run a fedora14 container on ARM (raspberry pi) 
 architecture ?

 If so can anyone point me in the right direction ?

I may see if I can pull this off on one of my F17 ARM Remix RPIs after
rebuilding lxc with the latest sources.  I think you can forget about
F14 (IMHO) though.

 Regards
 Benito

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
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] LXC- ARM6 RaspberryPI Fedora core 14

2013-04-03 Thread Michael H. Warfield

Cross posting over to the developers list, since this is definitely a
developer issue...

On Wed, 2013-04-03 at 11:29 +0200, Benito wrote:
 Hi There
 
 I've been working on a project on the Raspberry PI , where we want to 
 run a 32-bit /64-bit fedora 14 container
 on the RaspberryPi . I've had success with LXC on a Mint14 64-bit (which 
 is Ubuntu 12 based I believe) host  with Fedora 14 - 64bit container  ( 
 Downloaded FC14 with the template -t parameter below..,, It was as easy 
 as running :
 
 apt-get install yum
 lxc-create -t fedora -n fedora14

Ok...  Got the latest lxc compiled on my Raspberry Pi.  There seem to be
4 things broken with the fedora template on the RPi, two of which are
peculiar to running on the Fedora Remix but one big one will bite
Raspbian as well.  One is a version/config issue with the Fedora
container for supporting systemd in a container.

1) The architecture is reported by the OS as armv6l but this fails.  The
arm processors should be mapped to arch = arm.  That means adding an if
check in the template.  That applies to both Raspbian and Fedora Remix
hosts.  I don't know of other architechtures are similarly affected.

2) Running under Fedora Remix 17, the template can not find the release
information and doesn't recognize it as a Fedora family.  Instead of
being in /etc/fedora-release, it's
in /etc/raspberrypi-fedora-remix-release but could also be extracted
from /etc/redhat-release, which is a symlink.

3) On Fedora Remix, if it finds the release (I added a symlink to test),
it's extracting the wrong field for the version number from the release
file.

This is vanilla Fedora 17:

Fedora release 17 (Beefy Miracle)

This is the RPi Fedora Remix 17:

Fedora remix release 17 (Raspberrypi Fedora Remix)

The template script is extracting the third field (word) and is one off
in this case.  That also causes the yum downloads to bomb.

Both points 2  3 can be circumvented by including the -R release to the
template like this:

lxc-create -t fedora -n Fedora17 -- -R 17

But that still leaves the bad architecture which then causes the yum
downloads to blow up.  I added this to the template to get it to work
and it's building a container now.

  if [ $arch = i686 ]; then
  arch=i386
  fi

+ if [ $arch = armv6l ]; then
+ arch=arm
+ fi

That should probably be turned into a case statement.

Detecting the correct release file is probably going to be a little ugly
and, maybe, should fall back to /etc/redhat-release if fedora-release is
not present, detect the keyword Fedora and skip the optional word
Remix.

4) Finally, there's going to need to be a version check in there to add
autodev = 1 to container configs for versions greater than 14 or
systemd in the container will cause problems for the host system.

Regards,
Mike

 Now I've been struggling with this for a few weeks , Compiled an LXC 
 friendly kernel on the Raspbian OS, - Debian wheezy ARM , also tried 
 with Fedora ARM remix.
 Is it even possible to run a fedora14 container on ARM (raspberry pi) 
 architecture ?
 If so can anyone point me in the right direction ?
 
 Regards
 Benito
 
 
 
 --
 Minimize network downtime and maximize team effectiveness.
 Reduce network management and security costs.Learn how to hire 
 the most talented Cisco Certified professionals. Visit the 
 Employer Resources Portal
 http://www.cisco.com/web/learning/employer_resources/index.html
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] mknod inside systemd container

2013-04-03 Thread Michael H. Warfield

On Wed, 2013-04-03 at 23:03 +0100, John wrote:
 On 02/04/13 23:59, Michael H. Warfield wrote:
  On Tue, 2013-04-02 at 16:02 +0100, John wrote:
  If my understanding is correctl, to stop systemd trying to launch udev
  and generally make a mess of everything inside a container, you need to
  remove the mknod capability from the container.
  Ah...  That's kind of old information and not really effective.
 
  But what if I want
  (need) to be able to use mknod inside a container, how can I do that
  with a systemd container?
  1) Get the latest lxc.  lxc 0.8 might suffice for systemd in a container
  but not with systemd in the host and I wouldn't recommend it.  0.9.0 is
  being pulled and bundled now.  It's not up yet but 0.9.0.rc1 is.
 
  2) You'll have to add lxc.autodev = 1 to your configuration file.

 I already do that. I am running lxc version: 0.9.0.alpha3

That's strange.  What stops systemd from mounting devtmpfs and firing up
udev is having a tmpfs mounted on /dev.  That's part of what autodev = 1
is doing.

What distro is running in the container and what version of systemd?
I've seen this with Fedora 16 but the latest systemd and Fedora 17 in
the container are fine.

 I found that, without the removal of mknod capability, everything went 
 crazy. I have working containers with systemd both on host and inside 
 the container (I even run my full desktop inside a container). To get a 
 systemd container working I found I needed three things:

 lxc.autodev = 1
 lxc.cap.drop = mknod

I'm not having to do that but I'm avoiding F15 and F16 because they
don't seem to play nice and start reliably.  F17 is doing well for me.

 lxc.pts = 1024
 
 It's alll working well except for the fact that I might need to allow a 
 container to have mknod capability. Are you saying that with 0.9.0 there 
 are changes that negate the requirement for lxc.cap.drop = mknod? The 
 way I understood it was that it was systemd that behaved differently 
 based on the availability of that capability...
 
 
  I have found that this works to get recent systemd containers (Fedora
  17) to work but Fedora 15 and Fedora 16 (neither of which are supported
  any longer) work due to udev / systemd interaction.
 
  I would recommend waiting a couple of days until 0.9.0 is up and then
  pulling it down and building it.  That's your best shot with systemd.
 
  I have this container that is a builder of system images for other nodes
  (containers and/or metal boxes). In order to correctly do this it needs
  to execute mknod inside the image as it builds it. (note, device nodes
  created doesn't need to be usable in the context of the image being
  built - the builder just needs to be able to create it).
 
  I've been doing this for ages under sysvinit and it's been fine. I have
  just migrated this builder container to systemd and hit this problem...
  Is there another way to keep systemd in line other than removing the
  mknod capability ?
 
  Thanks,
  John
 
 
 
  --
  Own the Future-Intel(R) Level Up Game Demo Contest 2013
  Rise to greatness in Intel's independent game demo contest. Compete
  for recognition, cash, and the chance to get your game on Steam.
  $5K grand prize plus 10 genre and skill prizes. Submit your demo
  by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
  ___
  Lxc-users mailing list
  Lxc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/lxc-users
 
 
 
 --
 Minimize network downtime and maximize team effectiveness.
 Reduce network management and security costs.Learn how to hire 
 the most talented Cisco Certified professionals. Visit the 
 Employer Resources Portal
 http://www.cisco.com/web/learning/employer_resources/index.html
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] mknod inside systemd container

2013-04-02 Thread Michael H. Warfield

On Tue, 2013-04-02 at 16:02 +0100, John wrote:
 If my understanding is correctl, to stop systemd trying to launch udev 
 and generally make a mess of everything inside a container, you need to 
 remove the mknod capability from the container.

Ah...  That's kind of old information and not really effective.

 But what if I want 
 (need) to be able to use mknod inside a container, how can I do that 
 with a systemd container?

1) Get the latest lxc.  lxc 0.8 might suffice for systemd in a container
but not with systemd in the host and I wouldn't recommend it.  0.9.0 is
being pulled and bundled now.  It's not up yet but 0.9.0.rc1 is.

2) You'll have to add lxc.autodev = 1 to your configuration file.

I have found that this works to get recent systemd containers (Fedora
17) to work but Fedora 15 and Fedora 16 (neither of which are supported
any longer) work due to udev / systemd interaction.

I would recommend waiting a couple of days until 0.9.0 is up and then
pulling it down and building it.  That's your best shot with systemd.

 I have this container that is a builder of system images for other nodes 
 (containers and/or metal boxes). In order to correctly do this it needs 
 to execute mknod inside the image as it builds it. (note, device nodes 
 created doesn't need to be usable in the context of the image being 
 built - the builder just needs to be able to create it).
 
 I've been doing this for ages under sysvinit and it's been fine. I have 
 just migrated this builder container to systemd and hit this problem... 
 Is there another way to keep systemd in line other than removing the 
 mknod capability ?
 
 Thanks,
 John
 
 
 
 --
 Own the Future-Intel(R) Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest. Compete 
 for recognition, cash, and the chance to get your game on Steam. 
 $5K grand prize plus 10 genre and skill prizes. Submit your demo 
 by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] installation problem

2013-01-26 Thread Michael H. Warfield

Hello...

On Sat, 2013-01-26 at 22:09 +0800, Ryan Young wrote:
 Hello all,
 I am new to lxc and got some problem with the installation of lxc 0.8.0.
 My distribution is rhel5, when I implement ./configure, it returns
 asplease install libcap-devel, but I did have libcap-devel/libcap
 installed on my machine, its version is 1.10.26.
 Are there any issues regarding this problem?

RHEL 5?  I don't think so.

What kernel version are you running?  I'm not aware of any flavor of
RHEL 5 / CentOS 5/ SLS 5 that runs a kernel that will support LXC.  From
what I can tell, the latest kernel available on 5.9 is 2.6.18-348.1.1
and that's just not going to happen as it has no support for control
groups (cgroups).  Even if you solve the libpcap problem, you won't get
past this one without a more modern kernel.  You would be better off
upgrading to RHEL 6 / CentOS 6 than even attempting this. 

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
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] error starting lxc containers

2013-01-19 Thread Michael H. Warfield

On Sat, 2013-01-19 at 23:33 +0200, Ramez Hanna wrote:
 host: fedora 17
 kernel: 3.6.11-5.fc17.x86_64
 lxc: 0.9 alpha2
 systemd: systemd-44-23.fc17.x86_64
 selinux is disabled

I have a Fedora 17 host (and several other hosts as well as Fedora 18
for testing)...  The latest update to systemd broke lxc due to the
pivot_root problem with their use of the MS_SHARED mount attribute that
has been under active discussion for the last couple of weeks.  No, it
is not functional under 0.9.0 alpha2.  It is, more or less, fixed under
current staging (fixed with a lot of uglyness that we're trying to
address).

Your errors reported below don't seem to exactly correspond to the
errors I would expect but, I would expect that, if you had recently
upgraded that Fedora 17 host to the latest systemd, you are going to
fail, period.  Most likely, I would expect you to fail with a
pivot_root failure but anything is possible.  It's broken and we know
it.

 lxc-start -n build02
 build02 is a wheezy container built with the debina template was working
 fine both kernel and systemd were upgraded (can't tell which one broke it)

Most likely, it's the systemd upgrade that caused the failure.  Fedora
17 with the latest systemd from fedora-upgrades has broken lxc and even
0.9.0 alpha2 does not fix it.  You have to use staging from git and
build your own.

Regards,
Mike

 error is
 
   lxc-start 1358593239.324 INFO lxc_conf - cgroup has been setup
   lxc-start 1358593239.324 INFO lxc_conf - console has been setup
   lxc-start 1358593239.325 ERRORlxc_conf - Operation not permitted
 - error creating /usr/lib64/lxc/rootfs/dev/tty1
 
   lxc-start 1358593239.329 ERRORlxc_conf - Operation not permitted
 - error creating /usr/lib64/lxc/rootfs/dev/tty2
 
   lxc-start 1358593239.330 ERRORlxc_conf - Operation not permitted
 - error creating /usr/lib64/lxc/rootfs/dev/tty3
 
   lxc-start 1358593239.332 ERRORlxc_conf - Operation not permitted
 - error creating /usr/lib64/lxc/rootfs/dev/tty4
 
   lxc-start 1358593239.334 INFO lxc_conf - 4 tty(s) has been setup
   lxc-start 1358593239.334 DEBUGlxc_conf - mountpoint for old
 rootfs is '/usr/lib64/lxc/rootfs/lxc_putold'
   lxc-start 1358593239.334 ERRORlxc_conf - Invalid argument -
 pivot_root syscall failed
   lxc-start 1358593239.336 ERRORlxc_conf - failed to setup pivot
 root
   lxc-start 1358593239.337 ERRORlxc_conf - failed to set rootfs for
 'f17'
   lxc-start 1358593239.338 ERRORlxc_start - failed to setup the
 container
   lxc-start 1358593239.339 ERRORlxc_sync - invalid sequence number
 1. expected 2
   lxc-start 1358593239.340 ERRORlxc_start - failed to spawn 'f17'
 
 any pointers to where this comes from?
 
 -- 
 BR
 RH
 http://informatiq.org
 
 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. SALE $99.99 this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122912
 ___ Lxc-users mailing list 
 Lxc-users@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/lxc-users

-- 
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
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] CentOS init.d services not started upon start

2013-01-17 Thread Michael H. Warfield

On Thu, 2013-01-17 at 20:48 +0530, Shibashish wrote:
 Hi,

 My runlevel services, i.e. whatever is in /etc/init.d/ is not started when
 I start a container using /usr/bin/lxc-start -d -n myvm1. How do I start
 those automatically?

 I'm on CentOS 6.3, lxc built from git branch staging.

Strange.  I have a couple of CenOS 6.3 containers running just fine and
all the services that are configured to autostart are starting properly.

First question.  What runlevel is your container starting in?  Run the
runlevel command and you should see something like N 3.  The first
number is the previous level (none in this case) and the second number
is the current runlevel (3 in this case).

The services in /etc/init.d are available to start but must be linked to
startup links in the appropriate /etc/rc.d/rc[runlevel].d
(/etc/rc.d/rc3.d in my example above).  Links that begin with an S
followed by two numbers (like S55sshd) are startup links when entering
that runlevel.

Services to be autostarted are normally managed by chkconfig.  Just type
chkconfig and look down the column of services for your runlevel and
see what's on.  You can use chkconfig to turn services on or off as
well.

If you're in runlevel 1 or S (single user), you'll need to figure out
why and correct it.  You might check /etc/inittab for the id (init
default) line.  Most likely you are going to want 3.

If you are in runlevel 3 and you have services configured to start,
which are not starting, then you should probably look
in /var/log/messages to see if you're getting errors.

 Thanks.

 ShiB.
 while ( ! ( succeed = try() ) );

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
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] start order

2012-12-10 Thread Michael H. Warfield

On Mon, 2012-12-10 at 08:10 -0600, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  There has been very little discussion in the main project over how to
  manage autobooting containers (or maybe I've missed it).  Maybe it's
  time we had it.
 
  What I do now is specific to my constellations of 6 lxc hosts (about 4
  dozen guest containers) at two sites.  I would personally prefer this
  sort of information to be contained in the individual container config
  files, ala OpenVZ and Linux-Vservers, without creating an entirely new,
  distribution specific, configuration file.
  
  Primary argument with having it contained within the container config
  really concerns migration.  When I migrated a container from one host to
  another host in the same cluster, if all that information is in the
  container config, it follows along.  If you bury it in a common config,
  you then have to edit those configuration files on both the servers (the
  throwing and the catching) in order to properly complete the migration.
  I don't like that idea at all.
 
 Buried in a config, but it could be exposed by lxc-info so it wouldn't
 be so bad.  Though I guess it could be an issue for boot-speed fanatics
 who want to minimize random disk access during boot.

I won't say that I'm a boot speed fanatic but I can be (more than) a
little OCD with regards to getting certain critical containers up as
quickly as possible even where other delays dominate.

 A simple
 LXC_AUTOSTART=no default would probably make them happy (how many ppl
 really want autostart, and of those, how many of the systems they boot
 every day do they want it enabled on?)

Systems of this sort should not be be booted every day.  My test
systems - sure.  My production systems - Hell NO!  My monster host at my
colo site, berserker-base, was recently booted after upgrading a root
kernel in the host system and a distro upgrade.  It had been up over 500
days.  It took hours to fsck the various file systems just to boot and
some critical containers were down that entire time (I do have my
authoritative name servers scattered between multiple hosts with nice
long TTLs and I work with Hurricane Electric for slaves so I had no
disruption in service).  But it had close to 3 dozen containers.  It
took only a minute or so to bring them up, once the host was up, so,
against the hours of fsck, the minor difference between one machine
starting before another was a drop in the bucket, I will admit.  Still,
I wanted those name servers up first.  :-)  They can slow the other
containers down if the other containers need DNS services that these
provide.  There are dependencies in there for both DNS and routing.

Here's my problem.  System takes 3 hours to fsck those file systems.  I
still have to remember to come back to it once it's fully booted and
make sure those critical containers get booted up.  Yes, I need autoboot
badly there.  I do get distracted and I do forget.  It's happened more
than once that someone has called me on the phone asking why there
system is down (I have a dozen or so friends with playgrounds I host)
and I realized I had gotten distracted and forgot to finish firing
everything up.  Boot order is less important to me than simply having
raw autoboot.  I have a script but it's currently run by hand.  I always
meant to turn it into an init script but hadn't.

 It'd be great to have distro-independent boot startup and ordering built
 in, so that distros don't have to roll their own.  Sounds like you all
 have some great ideas so I'll look for patches :)

 What I think would be great is

   1. lxc.conf updates to indicate autostart delay and order or
  dependencies

This sounds reasonable for global configurations.  I think providing a
container by container delay may be a case where the precision is
exceeding the accuracy and may be entirely way too much overkill so a
global in lxc.conf is reasonable.  I still like having the autoboot
option and/or priority in the individual container configs though, since
it really is container specific.  Maybe there's a way to adapt to both
paradigms...  Give one a preference.  I think I could make that work.

   2. an lxc command to spit out containers which should be started,
  in order (to loop over)

O  I LIKE that idea.  I hadn't thought of that!  That makes a
lot of sense.  Something like lxc-boot where you pass it a level number
(0 for manual and 1 for boot maybe) and it passes back to you a list of
containers that need to be booted to meet the criterion (priority) and
in the order they should be booted.  That would simplify what I'm doing
now...  It's really almost a spin on the idea of lxc-ls only you list
them (the ones that need booting) out in boot order.

   3. lxc-info update to optionally list that information
   4. could package sysvinit, upstart, and systemd templates.

I'll look at the Fedora / RHEL / CentOS / SLS angle.  I need to get more

Re: [Lxc-users] start order

2012-12-10 Thread Michael H. Warfield

On Mon, 2012-12-10 at 11:35 -0600, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Mon, 2012-12-10 at 08:10 -0600, Serge Hallyn wrote:
   Quoting Michael H. Warfield (m...@wittsend.com):
There has been very little discussion in the main project over how to
manage autobooting containers (or maybe I've missed it).  Maybe it's
time we had it.
   
What I do now is specific to my constellations of 6 lxc hosts (about 4
dozen guest containers) at two sites.  I would personally prefer this
sort of information to be contained in the individual container config
files, ala OpenVZ and Linux-Vservers, without creating an entirely new,
distribution specific, configuration file.

Primary argument with having it contained within the container config
really concerns migration.  When I migrated a container from one host to
another host in the same cluster, if all that information is in the
container config, it follows along.  If you bury it in a common config,
you then have to edit those configuration files on both the servers (the
throwing and the catching) in order to properly complete the migration.
I don't like that idea at all.
   
   Buried in a config, but it could be exposed by lxc-info so it wouldn't
   be so bad.  Though I guess it could be an issue for boot-speed fanatics
   who want to minimize random disk access during boot.
  
  I won't say that I'm a boot speed fanatic but I can be (more than) a
  little OCD with regards to getting certain critical containers up as
  quickly as possible even where other delays dominate.

 Sorry, I think you misunderstood what I meant by that :)  By boot speed
 fanatics, I meant people who want to avoid having init scripts look under
 /etc/default/$pkg because that adds seeking which slows down boot.

 For those people, if any laptop that has some containers will, at boot,
 have to scan /var/lib/lxc/*/config to find lxc.boot entries, that will
 be unacceptable.  And TBH since my main laptop has an SSD but doesn't
 suspend/resume, 5 sec boot time is precious to me.  But I don't autostart
 containers on that laptop.

 With 'boot speed fanatics' I was not talking about people who want
 containers brought up at boot.

Oh, no...  I know EXACTLY who you were referring to.  I was just making
an orthogonal, oblique, point.  Maybe (probably) I was being too
obscure.  They're the ones that got us into this whole systemd the
system must boot in under 10 seconds mess (which I don't TOTALLY
disagree with).  I totally agree with you there.  If you autostart
containers in that sort of environment you have no room to bitch about
the boot time.  That's a self-inflicted injury and I agree the autoboot
option must default to off and you only autoboot those containers that
are enabled.

A fast grep on the config files is pretty small, time wise, but an
interesting point, even if you do it in the background.  Even if you
DON'T autostart containers, if you scan the directories with grep, that
can take (a little) time.  A global config for autostart might not be a
bad idea.  In RH/rpm-based land, this would probably be something in
an /etc/sysconfig/lxc file with LXC_AUTOBOOT=0 and I would support that
entirely.  Don't even look at the configuration files if that's the
case.  If it's set to autoboot, then digest the configuration files to
sort them out.  But it is something you have done yourself.  Even the
ls /etc/lxc/auto is not without cost but that may be the way Ubuntu
goes with that paradigm.

 -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
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] start order

2012-12-08 Thread Michael H. Warfield

) in order to properly complete the migration.
I don't like that idea at all.

 Where numbers mean secundums, eg. dns server receives 15 secundums to startup 
 properly.
 
 Essential services would be working before anything else and users would be 
 happy:)
 
 
 What do you think about that?
 
 Thanks,
 tamas

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
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] start order

2012-12-08 Thread Michael H. Warfield

On Sat, 2012-12-08 at 19:51 +0100, Daniel Baumann wrote:
 On 12/08/2012 06:24 PM, Michael H. Warfield wrote:
  It's possible to drop a full configuration file there into /etc/lxc/auto and
  not have it exist in /var/lib/lxc and then -f config file would work
  while -n  $c -d would fail.  That would be my guess there.

 that was the intention when i wrote it in debian (ubuntu at some point 
 took it over then).

  I've been imitating the way OpenVZ does this (on Fedora) by adding some
  parameters in the lxc configuration files like this:

 not convinced that a start order does actually matter (because your 
 stuff within containers should a) be graceful wrt/ to existence of other 
 services by other containers and b) be eventful), however, better and 
 simpler imho is to support using numbered prefixes.

I can see his desire for controlling start order.  In my real world
case, where I have to reboot one of my major hosts, I have certain
important containers I need up as soon as possible.  One is a null
router which is the /dev/null sink for my net-telescope (security
related stuff similar to a honeypot).  That's the first one that needs
to be up.  That one is followed by some authoritative name servers and
recursive name servers.  After that, there are processes which like to
chew on MySQL databases as they slowly come up.  The containers are
independent of one another but they're demand on the host resources can
have a significant real-time impact.  Not vital.  Everything comes up
anyways, but I can see his point.

 /etc/lxc/auto/0001-foo
 /etc/lxc/auto/0002-bar
 [...]

I like having the containers named for the host names (the old OpenVZ
paradigm really sucked) so listing give me better readability and
understandability.  I thought of the prefix idea too but discounted it
because it would then force you into a naming convention for the
containers themselves.  That's more of a hack than a solution in that
case where you have additional side effects like that.

 -- 
 Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
 Email:  daniel.baum...@progress-technologies.net
 Internet:   http://people.progress-technologies.net/~daniel.baumann/

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
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] Container sends login prompt to the system console

2012-12-06 Thread Michael H. Warfield

-start 1354793173.811 DEBUGlxc_cgroup - cgroup
 /sys/fs/cgroup/devices has flags 0x2
   lxc-start 1354793173.811 DEBUGlxc_cgroup - get_init_cgroup:
 found init cgroup for subsys devices at /
 
 
   lxc-start 1354793173.811 DEBUGlxc_cgroup - using cgroup mounted
 at '/sys/fs/cgroup/devices//lxc'
   lxc-start 1354793173.811 DEBUGlxc_cgroup - lxc_cgroup_path_get:
 returning /sys/fs/cgroup/devices//lxc/test1-18 for subsystem devices.allow
   lxc-start 1354793173.811 DEBUGlxc_conf - cgroup 'devices.allow'
 set to 'c 254:0 rwm'
   lxc-start 1354793173.811 INFO lxc_conf - cgroup has been setup
   lxc-start 1354793173.811 INFO lxc_conf - console has been setup
   lxc-start 1354793173.811 INFO lxc_conf - 4 tty(s) has been setup
   lxc-start 1354793173.811 DEBUGlxc_conf - created
 '/usr/local/lib/lxc/rootfs/lxc_putold' directory
   lxc-start 1354793173.811 DEBUGlxc_conf - mountpoint for old
 rootfs is '/usr/local/lib/lxc/rootfs/lxc_putold'
   lxc-start 1354793173.811 DEBUGlxc_conf - pivot_root syscall to
 '/usr/local/lib/lxc/rootfs' successful
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/dev/shm'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/dev/pts'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/dev/mqueue'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/dev/hugepages'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/proc/sys/fs/binfmt_misc'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/kernel/security'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/selinux'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/systemd'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/cpuset'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/cpu,cpuacct'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/memory'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/devices'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/freezer'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/net_cls'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/blkio'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup/perf_event'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/kernel/debug'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/kernel/config'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/fuse/connections'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/run/user/1000/gvfs'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/tmp'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/boot/efi'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/home'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/dev'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys/fs/cgroup'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/run'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/boot'
   lxc-start 1354793173.812 DEBUGlxc_conf - umounted
 '/lxc_putold/sys'
   lxc-start 1354793173.812 INFO lxc_conf - lazy unmount of
 '/lxc_putold'
   lxc-start 1354793173.812 WARN lxc_conf - failed to unmount
 '/lxc_putold/proc'
   lxc-start 1354793173.813 INFO lxc_conf - created new pts instance
   lxc-start 1354793173.813 DEBUGlxc_conf - capabilities has been
 setup
   lxc-start 1354793173.813 NOTICE   lxc_conf - 'test1-18' is setup.
   lxc-start 1354793173.813 NOTICE   lxc_start - exec'ing '/sbin/init'
   lxc-start 1354793173.813 NOTICE   lxc_start - '/sbin/init' started
 with pid '17431'
   lxc-start 1354793173.813 WARN lxc_start - invalid pid for SIGCHLD
 
 
 
 
 
 tahnks
 
 Benoit
 
 
 
 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@wittsend.com

Re: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-12-05 Thread Michael H. Warfield

On Wed, 2012-12-05 at 13:00 +, John wrote:
 On 04/12/12 21:29, Michael H. Warfield wrote:
  I raised the question about LXC/systemd a while back and have been
  trying to follow the conversation but I have to admit it's going
  somewhat over my head. I've also been away on another piece of work but
  would now like to understand where things lie with LXC and systemd
  inside a container.
  Ok...  I'll try to answer some of them...
 Thanks Mike, much appreciated.

  I have just updated my system to 0.8.0 and I can't see any changes to
  make a systemd container work. Are there changes in 0.8.0 ?
  There are very significant changes in 0.8.0 but, unfortunately, not the
  ones you need to get systemd to work in a container.  We've been testing
  a lot of these and they are in git but they are not in a release yet.
  Hopefully soon, just not yet.

  If so, I'd be grateful for some guidance on what I need to do to to my
  configuration to make it work.
  Right now, you'll have to build from git.
 I will go away and do a git build later today.
 I presume that would be from git://lxc.git.sourceforge.net/gitroot/lxc/lxc.

  I'm also happy to help test this if I can. If it helps I am on Arch Linux.
  There are two problems.  One is systemd in an lxc container.  I think we
  have a rope on this one and it's tied down.  The other is the more
  recent (195+) versions of systemd in the host that throw the pivot
  root errors.  That has not been addressed as yet.  I use Fedora.  Right
  now, I have Fedora 17 hosts with Fedora 17 containers.  Fedora 18
  (currently in beta) host (systemd 195) is going to be a train wreck
  until we sort the pivot root problem.  I don't know what you have with
  Arch Linux.  You'll have to tell us what versions of systemd you are
  running.

 Ah yes, the pivot root problem. I have worked around this for the time 
 being by doing a mount --make-rprivate /. I created a systemd service 
 on the host as an after dependency on systemd-remount-fs.service to 
 do this. I believe this is ok in the short term (it appears to work ok 
 for me).

Hmmm...  I was thinking someone ran into some problems doing that and
causing problems with the /dev/pts mounts or some such.  Good to note if
that worked for you.  I'm about to start playing with Fedora 18 Beta
where I expect problems.  I'll try that out.

 If I rebuild lxc from git, should I then expect my existing systemd 
 container to work or is there anything else that I need to do ?

Yeah, one other thing (in addition to following Serge's advice regarding
git and #stage)...

You have to add an option to the config file for your systemd
containers.

lxc.autodev = 1

 My versions:
 
 lxc version: 0.8.0
 Linux hydrogen 3.6.8-1-ARCH #1 SMP PREEMPT Mon Nov 26 22:10:40 CET 2012 
 x86_64 GNU/Linux
 systemd 196
 
  many thanks everyone.
  John
  Mike
 
 Thanks, I really appreciate the help.

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
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
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.

2012-12-05 Thread Michael H. Warfield

On Wed, 2012-12-05 at 11:09 -0600, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):

  You have to add an option to the config file for your systemd
  containers.
  
  lxc.autodev = 1

 Phrasing it this way makes me wonder, should lxc look for
 '$rootfs/dev/console' and automatically set lxc.autodev if
 that is not found?

I'm of two minds here (which, in my case, is a reduction in force and
those two minds are going where did everybody go?).

That might be an idea for jogging the default.  If you don't have
'$rootfs/dev/console' then set it.  In that obvious case, you need it.
If you do have it, obey what's on the config file?

We have a bit of a chicken and egg situation.  It's not just auto
populating /dev but it's also mounting a ramfs partition on it.  I'm not
sure I'm comfortable with the level of random acts of terrorism that
systemd has proven to be capable of if someone accidentally leaves
a .../dev/console in their file system so we don't then mount ramfs on
dev and we don't then auto populate dev.

But...  The same situation exists if the user doesn't manually provide
the autodev option.  But...  I would not want us to switch based on the
existence of systemd either.

Maybe there is some other way we can autodetect this that doesn't depend
on those static devices?

Overall, I like that idea.  It helps idiot proof the configuration
better.

 (Right now if lxc.autodev is 1 then the tmpfs /dev is mounted
 before all the lxc.mount.entries and /var/lib/lxc/$c/fstab
 entries, but I can't right now think of a reason why it has
 to stay that way.  If we were to always set lxc.autodev if
 /dev is empty, we'd want to make sure any separate /dev has
 been mounted, of course.)

Concur.  I think this is a good idea, we just have to watch some of the
corner cases.  The one I fear the most is the one where someone (ME!)
does a yum upgrade of a container that then becomes systemd (F14 - F15)
where it use to be Upstart with a static /dev populated.  Boom.  Flash
of light, mushroom cloud on the horizon.  But, again, if I don't fix the
bloody config, I'm screwed as well.  Self inflicted injury.  I see that.

I don't see a downside to adding it.  I'm just a little nudgey about
relying on it.  On the balance...  I'm in favor, yeah.

 -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
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] autodev (was Re: [lxc-devel] [GIT] lxc branch, master, updated.) 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-23 Thread Michael H. Warfield

Serge...

You need to go in for doing psychic readings or buy lots of lottery
ticks because I think you must have been channeling me and reading my
mind.  I've been close to posting on this off and on for the last couple
of days but kept going I need to test this and what about this
combination...

On Fri, 2012-11-23 at 12:30 -0600, Serge Hallyn wrote:
 Quoting Serge Hallyn (serge.hal...@canonical.com):
  Quoting Michael H. Warfield (m...@wittsend.com):

...  [big snip]  ...

   [root@forest Plover]# cat 2012-10-31-06:41:37.log
 lxc-start 1351680097.900 ERRORlxc_conf - Operation not 
   permitted - error creating /usr/lib64/lxc/rootfs/dev/tty6
   
   Still got the error creating /dev/tty6 but not 1-5.
   
   But wait.  In the container itself...
   
   [mhw@canyon mhw]$ ssh plover.ip6.wittsend.com
   Last login: Tue Oct 30 18:40:12 2012 from canyon.ip6.wittsend.com
   [mhw@plover ~]$ sudo -s
   [root@plover mhw]# ls -l /dev/tty?
   crw---. 1 root root 136, 36 Oct 31 06:41 /dev/tty1
   crw---. 1 root root 136, 37 Oct 31 06:41 /dev/tty2
   crw---. 1 root root 136, 38 Oct 31 06:41 /dev/tty3
   crw---. 1 root root 136, 39 Oct 31 06:41 /dev/tty4
   crw---. 1 root root 136, 40 Oct 31 06:41 /dev/tty5
   crw---. 1 root root 136, 41 Oct 31 06:41 /dev/tty6
   
   So it gave an error but did actual work.

  What error is it giving?  Does it list the errno?

I meant to track that down to the line that was generating it but the
error what was I gave you...  Operation not permitted - error
creating /usr/lib64/lxc/rootfs/dev/tty6 and I had not dug into it
deeper.  IAC, with your last change, I consider that error informative
and not critical.  It's just noise...  Seems like it's an off by one
error somewhere but I just don't see where...

The error seems to be printed from the statement on line 643 of
lxc/src/lxc/conf.c from that git branch you fed me...

if (access(path, F_OK)) {
ret = creat(path, 0660);
if (ret==-1) {
SYSERROR(error creating %s\n, path);
/* this isn't fatal, continue */
} else
close(ret);
}


So why does it get this error on the last one and not the previous 5?
No clue.

   I've got this narrowed down...  If devtty is defined you do one thing
   and, if not, you drop into the autodev logic.  Is that correct?  If I
  
  devtty can be used with autodev = 1, and was working fine for me in
  ubuntu containers using autodev = 1.  I just need to see if I can
  better consolidate those codepaths.
  
   use devtty, then the INFO dump says 0 ttys created and, in fact, none
   are, so I guess I don't know how to use that parameter.

  If you say

  lxc.devtty = joe

  then lxc will create a directory /dev/joe in the container, create
  /dev/joe/console and /dev/joe/tty{1-N}, bind mount the host ptys
  to those, and then symlink those into /dev.  The purpose of this
  sad hackery is to allow package upgrades which want to do

Strange, I tried this for several of my containers and it didn't seem to
actually do anything for me.  The directory was never created and
nothing obvious happened (tip of the hat to the old Colossal Caverns
Adventure game after which my entire domain, WittsEnd, is named).
Orthogonal issue at this point other than your comment about wanting to
add a patch.

  rm /dev/console
  MAKEDEV /dev/console

  to succeed.  If lxc has bind-mounted the lxc consoles onto /dev/console
  directly, then 'rm /dev/console' fails because you can't delete the
  mount target.

  (This of course results in bad console until a restart with lxc, but
  let's the container upgrade succeed.  Device namespaces, where are you?)

 Hi Michael,

 This seems to have stalled.  Let's try and get this fixed in staging right
 now.  Was the final patch (which I *believe* was the one in
 https://github.com/hallyn/lxc/tree/upstream.nov1.2012.autodev ) working for
 you?

The patch is working well.  I have some strangeness in some containers
which are NOT using systemd that, if I enable audodev when it is NOT
needed, the results have wrong (bad - weird) permissions.  I've looked
right at the code where you do the makedev.  It should work.  It doesn't
make sense.  Maybe it's a 32 bit / 64 bit thing (this is a 64 bit host),
I don't know.  I don't see why but that's an orthogonal issue as well.
It works in the containers I need it and I don't need it in the
containers where it doesn't work so I'm good with the patch as it
stands.

Next issue that's roaring up on us is going to be systemd 195+ and that
whole MS_SHARED and pivot root issue but, again, that's all orthogonal
to this issue.  That's going to bite us in the Fedora 18 time frame and
already in Arch Linux.  But we need this first.

 thanks,
 -serge

Sorry

Re: [Lxc-users] autodev (was Re: [lxc-devel] [GIT] lxc branch, master, updated.) 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-23 Thread Michael H. Warfield

On Fri, 2012-11-23 at 14:15 -0600, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  Serge...
  
  You need to go in for doing psychic readings or buy lots of lottery
  ticks because I think you must have been channeling me and reading my
  mind.  I've been close to posting on this off and on for the last couple
  of days but kept going I need to test this and what about this
  combination...

 All that says to me is that it takes me a few days longer to remember
 something :)

 ...
 
  The patch is working well.  I have some strangeness in some containers
  which are NOT using systemd that, if I enable audodev when it is NOT
  needed, the results have wrong (bad - weird) permissions.  I've looked
  right at the code where you do the makedev.  It should work.  It doesn't
  make sense.  Maybe it's a 32 bit / 64 bit thing (this is a 64 bit host),
  I don't know.  I don't see why but that's an orthogonal issue as well.
  It works in the containers I need it and I don't need it in the
  containers where it doesn't work so I'm good with the patch as it
  stands.

 Ok, I'll go ahead and post the patch one more time for review, then
 on monday or tuesday will push it to the staging branch and to the
 ubuntu raring package.  That should get it sufficient extra testing
 that if there are subtle issues, we'll shake them out better than we
 are with the patch sitting in an obscure branch.

Concur.

 thanks,
 -serge

Many thanks!

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
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
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.

2012-11-06 Thread Michael H. Warfield

On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote:

 Note that there are reports that LXC has issues with the fact that newer
 systemd enables shared mount propagation for all mounts by default (this
 should actually be beneficial for containers as this ensures that new
 mounts appear in the containers). LXC when run on such a system fails as
 soon as it tries to use pivot_root(), as that is incompatible with
 shared mount propagation. The needs fixing in LXC: it should use MS_MOVE
 or MS_BIND to place the new root dir in / instead. A short term
 work-around is to simply remount the root tree to private before
 invoking LXC.

In another thread, Serge had some heartburn over this shared mount
propagation which then rang a bell in my head about past problems we
have seen.

 On Mon, 2012-11-05 at 08:51 -0600, Serge Hallyn wrote: 
  Quoting Michael H. Warfield (m...@wittsend.com):
  ...
  This was from another threat with the systemd guys.
  
  On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote:
   Note that there are reports that LXC has issues with the fact that
   newer
   systemd enables shared mount propagation for all mounts by default
   (this
   should actually be beneficial for containers as this ensures that new
   mounts appear in the containers). LXC when run on such a system fails
 
 MS_SLAVE does this as well.  MS_SHARED means container mounts also
 propagate into the host, which is less desirable in most cases.

Here's where we've seen some problems in the past.  It's not just mounts
that are propagated but remounts as well.  The problem arose that some
of us had our containers on a separate partition.  When we would shut a
container down, that container tried to remount its file systems ro
which then propagated back into the host causing the hosts file system
to be ro (doesn't happen if you are running on the host's root fs for
the containers) and from there across into the other containers.

Are you using MS_SHARED or MS_SLAVE for this?  If you are using
MS_SHARED do you create a potential security problem where actions in
the container can bleed into the state of the host and into other
containers.  That's highly undesirable.  If a mount in a propagates back
into the host and is then reflected to another container sharing that
same mount tree (I have shared partitions specific to that sort of
thing) does that create an information disclosure situation of one
container mounts a new file system and the other container sees the new
mount?  I don't know if the mount propagation would reflect back up the
shared tree or not but I have certainly seen remounts do this.  I don't
see that as desirable.  Maybe I'm misunderstand how this is suppose to
work but I intend to test out those scenarios when I have a chance.  I
do know that, when testing that ro problem, I was able to remount a
partition ro in one container and it would switch in the host and the
other container and I could the remount it rw in the other container and
have it propagate back.  Not good.

Can you offer any clarity on this?

   as
   soon as it tries to use pivot_root(), as that is incompatible with
   shared mount propagation. The needs fixing in LXC: it should use
   MS_MOVE
   or MS_BIND to place the new root dir in / instead. A short term

 Actually not quite sure how this would work.  It should be possible
 to set up a set of conditions to work around this, but the kernel
 checks at do_pivotroot are pretty harsh - mnt-mnt_parent of both
 the new root and current root have to be not shared.  So perhaps
 we actually first chroot into a dir whose parent is non-shared,
 then pivot_root from there?  :)
 
 (Simple chroot in place of pivot_root still does not suffice, not
 only because of chroot escapes, but also different results in
 /proc/pid/mountinfo and friends)

Comments on Serge's points?

At this point, we see where this will become problematical in Fedora 18
but appears to already be problematical in NixOS that another user is
running and which containers systemd 195 in the host.

We've had problems with chroot in the past due to chroot escapes and
other problems years ago as Serge mentioned.

 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
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu

Re: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-04 Thread Michael H. Warfield

On Sun, 2012-11-04 at 23:09 +0100, Daniel Lezcano wrote:
 On 11/01/2012 09:41 PM, Michael H. Warfield wrote:
  On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
  On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
  I know, I KNOW this is an 11th hour request.  Can we please get Serge's
  autodev stuff into this release?  Please?
  release early, release often?
  just release current git as 0.8.0 now, and the one with the autofoo as 
  0.8.1 soon after that?
  That would be ideal but we've been sitting at 0.8.0rc2 for something
  like 3-1/2 months now.  I know Daniel (the other Daniel, the Daniel) has
  been incredibly busy.  I have no objection to getting this out the door
  as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but another
  several months is not good.  Can we get this fast bump?  We'll be
  staring Fedora 18 in the face by then.  The working versions of Fedora
  are no longer in support and we've got more distros adopting systemd.

 Yeah, I have to admit I have been a very maintainer the last months and
 I apologize for that.
 Thanks to Serge and Stephane who took the patches and consolidate the
 next version.

 I prefer to release a 0.8.0 right now and release a 0.8.1 in a couple of
 weeks.

 That would be ok for you Michael ?

PERFECT!  Sounds like Serge and I still have some details to work out
and I'm continuing to test like mad.  Maybe we can get some more of this
stuff figured out by then!  That would make the next release even
better.

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
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] pivot root failures when / is mounted as shared

2012-11-03 Thread Michael H. Warfield

On Sat, 2012-11-03 at 12:01 +0100, Peter Simons wrote:
 Hi guys,
 
 I've been using lxc for a while now, and it's a great tool. Thank you
 very much for the time and effort you have been dedicating to the
 development of that software!
 
 My Linux distribution (NixOS) is about to switch from upstart to
 systemd, and it this switch in the host system is going to break all my
 containers. It appears this is a well known problem that's been reported
 at

   
 http://sourceforge.net/tracker/?func=detailaid=3559833group_id=163076atid=826303

 and

   https://github.com/lxc/lxc/issues/4.

 Now, I wonder what the status of this issue is. Is it clear how that
 problem can be remedied? Is there maybe a patch that fixes this problem?
 Does anyone know a work-around that I could use to keep my containers
 running when that switch to systemd occurs on the host system?

Having JUST been up to my ears in this (and still am to some extent)
working with Serge and hammering out some of these issues over the last
couple of weeks, I think I can speak to some of this.

The issue regarding pivot root is not your only problem and may not yet
be a current problem.  It's really, more or less, something that's going
to become a problem (Fedora 19 time frame if I understand it properly
from the systemd gang).  Not sure what version of systemd where this
becomes a problem in but I'm running Fedora 17 with systemd 44 in the
host for some time with no problem.  If you've tested that and you've
seen how it breaks, could you post the version of systemd you are
running and the error messages along with some config examples here so
we can see them?

A real problem is in the systemd based containers where it wants to
mount devtmpfs on top of /dev and that breaks all sorts of things
(console conflicts, restarts X in the host, all sorts of mess).  Serge
was finally able to whip together a patch this last week that I've been
testing and I now have Fedora 17 containers using systemd running.
We've still got some minor gotchas like console ttys not working yet
(systemd won't start them in a container).  Currently lxc-console will
not work with a systemd container because of the systemd behavior wrt
starting getty processes on ttys when it detects that it's in a
container.

For your distro, the pivot root when / is mounted shared may or may not
be a problem but, as of systemd 44 for sure it is not.  I still need to
do some retesting with systemd 195 (Fedora Rawhide) but my early
indications are that it's not a problem or hasn't been for me (but then
my container / may not be mounted shared).  IAC, you're getting nowhere
with it (if you have systemd in the container) until you have the
devtmpfs fixes.

Right now...  To get this to work, you need Serge's autodev branch from
git here:

git://github.com/hallyn/lxc called upstream.nov1.2012.autodev

Build lxc from that.

Then, in your systemd based containers, you must add the parameter
lxc.autodev = 1 to the config.  That will cause tmpfs to be mounted on
top of /dev and populated with the device entries which are needed.
Adding that to your non-systemd containers should have no negative
impact but I have yet to test that fully.

Daniel is getting ready to cut the 0.8.0 release which will NOT have the
autodev fixes but we're hoping to get a quicker turnaround to get 0.9.0
or something similar out with them and other systemd fixes.

If you are having the pivot root problem, this may not help.  That will
probably have to be addressed sooner or later from what I've read from
the systemd guys.

 Take care,
 Peter

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
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] pivot root failures when / is mounted as shared

2012-11-03 Thread Michael H. Warfield

Additional comments specific to the pivot root issue...  Adding the
developers list as well, since this is a development issue...

On Sat, 2012-11-03 at 12:01 +0100, Peter Simons wrote:
 Hi guys,

 I've been using lxc for a while now, and it's a great tool. Thank you
 very much for the time and effort you have been dedicating to the
 development of that software!

 My Linux distribution (NixOS) is about to switch from upstart to
 systemd, and it this switch in the host system is going to break all my
 containers. It appears this is a well known problem that's been reported
 at

   
 http://sourceforge.net/tracker/?func=detailaid=3559833group_id=163076atid=826303

 and

   https://github.com/lxc/lxc/issues/4.

 Now, I wonder what the status of this issue is. Is it clear how that
 problem can be remedied? Is there maybe a patch that fixes this problem?
 Does anyone know a work-around that I could use to keep my containers
 running when that switch to systemd occurs on the host system?

This was from another threat with the systemd guys.

On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote:
 Note that there are reports that LXC has issues with the fact that
 newer
 systemd enables shared mount propagation for all mounts by default
 (this
 should actually be beneficial for containers as this ensures that new
 mounts appear in the containers). LXC when run on such a system fails
 as
 soon as it tries to use pivot_root(), as that is incompatible with
 shared mount propagation. The needs fixing in LXC: it should use
 MS_MOVE
 or MS_BIND to place the new root dir in / instead. A short term
 work-around is to simply remount the root tree to private before
 invoking LXC.
 
 Lennart

 -- 
 Lennart Poettering - Red Hat, Inc.

So there you have a suggested workaround for the shared mount
propagation problem, which is what you are referring to.

ITMT...

Daniel, Serge?

Any thoughts on those comments vis-a-vis the pivot function and using
MS_MOVE or MS_BIND instead?  IIRC, we switched to pivot_root() years ago
to deal with some other issues that were plaguing us.

 Take care,
 Peter
 
 
 --
 LogMeIn Central: Instant, anywhere, Remote PC access and management.
 Stay in control, update software, and manage PCs from one command center
 Diagnose problems and improve visibility into emerging IT issues
 Automate, monitor and manage. Do more in less time with Central
 http://p.sf.net/sfu/logmein12331_d2d
 ___
 Lxc-users mailing list
 Lxc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-02 Thread Michael H. Warfield

On Thu, 2012-11-01 at 20:15 -0400, Michael H. Warfield wrote:
 On Thu, 2012-11-01 at 19:17 -0400, Michael H. Warfield wrote:
  On Thu, 2012-11-01 at 23:28 +0100, Serge Hallyn wrote:
   Quoting Michael H. Warfield (m...@wittsend.com):
On Thu, 2012-11-01 at 22:44 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
   On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
I know, I KNOW this is an 11th hour request.  Can we please get 
Serge's
autodev stuff into this release?  Please?
  
   release early, release often?
  
   just release current git as 0.8.0 now, and the one with the 
   autofoo as 
   0.8.1 soon after that?
  
  That would be ideal but we've been sitting at 0.8.0rc2 for something
  like 3-1/2 months now.  I know Daniel (the other Daniel, the 
  Daniel) has
  been incredibly busy.  I have no objection to getting this out the 
  door
  as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but 
  another
  several months is not good.  Can we get this fast bump?  We'll be
  staring Fedora 18 in the face by then.  The working versions of 
  Fedora
  are no longer in support and we've got more distros adopting 
  systemd.

 I think this will end up slated for 0.9.0 (which we're hoping will be
 soon), but in any case I went ahead and created a branch at
 git://github.com/hallyn/lxc called upstream.nov1.2012.autodev, with
 an autodev patch on top of Daniel's latest push.

 I quickly tried my hand at fixing the error you had with /dev/ttyN.  I
 haven't tested that bit.  I will not be able to be online at all from
 now until weekend or monday, so if it needs more tweaks please feel
 free to 'just fix it'.

Problem.  Works for the systemd containers but not for my older
containers.  I get this...

[root@forest Plover]# cat 2012-10-30-18:17:46.log
  lxc-start 1351635466.998 ERRORlxc_conf - Operation not 
permitted - error 1 creating /usr/lib64/lxc/rootfs/dev/tty6

  lxc-start 1351635466.999 ERRORlxc_conf - failed to setup the 
ttys for 'Plover'
  lxc-start 1351635466.999 ERRORlxc_start - failed to setup the 
container
  lxc-start 1351635466.999 ERRORlxc_sync - invalid sequence 
number 1. expected 2
  lxc-start 1351635466.999 ERRORlxc_start - failed to spawn 
'Plover'

Alcove (the systemd container) was the first one started so it may be an
ordinal thing or it may be a systemd thing.  But it's a problem.
   \
   Hm, perhaps the container doesn't have mknod?
 
  They all should have, but I will investigate.  Those devices would have
  existed in the static file system with /dev.  Could it be a problem with
  the device already existing in the /dev directory?
 
 Ok...  Now this is just bloody weird.  I do not understand this.
 
 Yes the containers come up.  But...
 
 Here's what shows up in the detached container's log...
 
 [root@forest Audience]# cat 2012-10-30-18:52:41.log
   lxc-start 1351637562.011 ERRORlxc_conf - Operation not permitted - 
 error creating /usr/lib64/lxc/rootfs/dev/tty6

 Now wait a minute...  What about 1, 2, 3, 4, and 5???  They succeeded
 but 6 failed?  How does that make any sense.  In the container...

 crw-rw-rw- 1 root root   5,   0 Apr 13  2006 tty
 crw--w 1 root tty  136,  16 Oct 30  2012 tty1
 crw--w 1 root tty  136,  17 Oct 30  2012 tty2
 crw--w 1 root tty  136,  18 Oct 30  2012 tty3
 crw--w 1 root tty  136,  19 Oct 30  2012 tty4
 crw--w 1 root tty  136,  20 Oct 30  2012 tty5
 crw--w 1 root tty  136,  21 Oct 30  2012 tty6

 Ok...  That's probably from a couple of days ago.  But no error messages
 for the others and they are not freshly made either...  That was a
 CentOS 5 container.

 Trying it with another Fedora container but removed the tty? entries.
 No errors.  Hmmm...  Wait...  Another problem...  Container Plover...

 [mhw@plover ~]$ who
 mhw  pts/92012-10-30 19:47 (forest.ip6.wittsend.com)
 [mhw@plover ~]$ sudo -s
 sudo: sorry, you must have a tty to run sudo

 What?

Ok...  The problem with the container plover appears to have been an
error on my part.  I think I cleaned out too many tty devices.

Carefully only removed tty? devices from the static /dev in that
container and started it up...

[root@forest Plover]# cat 2012-10-31-06:41:37.log
  lxc-start 1351680097.900 ERRORlxc_conf - Operation not permitted - 
error creating /usr/lib64/lxc/rootfs/dev/tty6

Still got the error creating /dev/tty6 but not 1-5.

But wait.  In the container itself...

[mhw@canyon mhw]$ ssh plover.ip6.wittsend.com
Last login: Tue Oct 30 18:40:12 2012 from canyon.ip6.wittsend.com
[mhw@plover ~]$ sudo -s
[root@plover mhw]# ls -l /dev/tty?
crw---. 1 root root 136, 36 Oct 31 06:41 /dev

Re: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-01 Thread Michael H. Warfield

On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
 On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
  I know, I KNOW this is an 11th hour request.  Can we please get Serge's
  autodev stuff into this release?  Please?

 release early, release often?

 just release current git as 0.8.0 now, and the one with the autofoo as 
 0.8.1 soon after that?

That would be ideal but we've been sitting at 0.8.0rc2 for something
like 3-1/2 months now.  I know Daniel (the other Daniel, the Daniel) has
been incredibly busy.  I have no objection to getting this out the door
as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but another
several months is not good.  Can we get this fast bump?  We'll be
staring Fedora 18 in the face by then.  The working versions of Fedora
are no longer in support and we've got more distros adopting systemd.

 -- 
 Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
 Email:  daniel.baum...@progress-technologies.net
 Internet:   http://people.progress-technologies.net/~daniel.baumann/

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] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-01 Thread Michael H. Warfield

On Thu, 2012-11-01 at 22:44 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
   On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
I know, I KNOW this is an 11th hour request.  Can we please get Serge's
autodev stuff into this release?  Please?
  
   release early, release often?
  
   just release current git as 0.8.0 now, and the one with the autofoo as 
   0.8.1 soon after that?
  
  That would be ideal but we've been sitting at 0.8.0rc2 for something
  like 3-1/2 months now.  I know Daniel (the other Daniel, the Daniel) has
  been incredibly busy.  I have no objection to getting this out the door
  as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but another
  several months is not good.  Can we get this fast bump?  We'll be
  staring Fedora 18 in the face by then.  The working versions of Fedora
  are no longer in support and we've got more distros adopting systemd.

 I think this will end up slated for 0.9.0 (which we're hoping will be
 soon), but in any case I went ahead and created a branch at
 git://github.com/hallyn/lxc called upstream.nov1.2012.autodev, with
 an autodev patch on top of Daniel's latest push.

 I quickly tried my hand at fixing the error you had with /dev/ttyN.  I
 haven't tested that bit.  I will not be able to be online at all from
 now until weekend or monday, so if it needs more tweaks please feel
 free to 'just fix it'.

Problem.  Works for the systemd containers but not for my older
containers.  I get this...

[root@forest Plover]# cat 2012-10-30-18:17:46.log
  lxc-start 1351635466.998 ERRORlxc_conf - Operation not permitted - 
error 1 creating /usr/lib64/lxc/rootfs/dev/tty6

  lxc-start 1351635466.999 ERRORlxc_conf - failed to setup the ttys for 
'Plover'
  lxc-start 1351635466.999 ERRORlxc_start - failed to setup the 
container
  lxc-start 1351635466.999 ERRORlxc_sync - invalid sequence number 1. 
expected 2
  lxc-start 1351635466.999 ERRORlxc_start - failed to spawn 'Plover'

Alcove (the systemd container) was the first one started so it may be an
ordinal thing or it may be a systemd thing.  But it's a problem.

 (there are also some todos in the commit msg - if we're going to wait
 for 0.9.0 then I can handle those later, and port the patch on top of
 the 100 additional patches queued in github.com/lxc/lxc#staging)

 -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
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-11-01 Thread Michael H. Warfield

On Thu, 2012-11-01 at 19:17 -0400, Michael H. Warfield wrote:
 On Thu, 2012-11-01 at 23:28 +0100, Serge Hallyn wrote:
  Quoting Michael H. Warfield (m...@wittsend.com):
   On Thu, 2012-11-01 at 22:44 +0100, Serge Hallyn wrote:
Quoting Michael H. Warfield (m...@wittsend.com):
 On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
  On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
   I know, I KNOW this is an 11th hour request.  Can we please get 
   Serge's
   autodev stuff into this release?  Please?
 
  release early, release often?
 
  just release current git as 0.8.0 now, and the one with the autofoo 
  as 
  0.8.1 soon after that?
 
 That would be ideal but we've been sitting at 0.8.0rc2 for something
 like 3-1/2 months now.  I know Daniel (the other Daniel, the Daniel) 
 has
 been incredibly busy.  I have no objection to getting this out the 
 door
 as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but another
 several months is not good.  Can we get this fast bump?  We'll be
 staring Fedora 18 in the face by then.  The working versions of Fedora
 are no longer in support and we've got more distros adopting systemd.
   
I think this will end up slated for 0.9.0 (which we're hoping will be
soon), but in any case I went ahead and created a branch at
git://github.com/hallyn/lxc called upstream.nov1.2012.autodev, with
an autodev patch on top of Daniel's latest push.
   
I quickly tried my hand at fixing the error you had with /dev/ttyN.  I
haven't tested that bit.  I will not be able to be online at all from
now until weekend or monday, so if it needs more tweaks please feel
free to 'just fix it'.
   
   Problem.  Works for the systemd containers but not for my older
   containers.  I get this...
   
   [root@forest Plover]# cat 2012-10-30-18:17:46.log
 lxc-start 1351635466.998 ERRORlxc_conf - Operation not 
   permitted - error 1 creating /usr/lib64/lxc/rootfs/dev/tty6
   
 lxc-start 1351635466.999 ERRORlxc_conf - failed to setup the 
   ttys for 'Plover'
 lxc-start 1351635466.999 ERRORlxc_start - failed to setup the 
   container
 lxc-start 1351635466.999 ERRORlxc_sync - invalid sequence 
   number 1. expected 2
 lxc-start 1351635466.999 ERRORlxc_start - failed to spawn 
   'Plover'
   
   Alcove (the systemd container) was the first one started so it may be an
   ordinal thing or it may be a systemd thing.  But it's a problem.
  \
  Hm, perhaps the container doesn't have mknod?

 They all should have, but I will investigate.  Those devices would have
 existed in the static file system with /dev.  Could it be a problem with
 the device already existing in the /dev directory?

Ok...  Now this is just bloody weird.  I do not understand this.

Yes the containers come up.  But...

Here's what shows up in the detached container's log...

[root@forest Audience]# cat 2012-10-30-18:52:41.log
  lxc-start 1351637562.011 ERRORlxc_conf - Operation not permitted - 
error creating /usr/lib64/lxc/rootfs/dev/tty6

Now wait a minute...  What about 1, 2, 3, 4, and 5???  They succeeded
but 6 failed?  How does that make any sense.  In the container...

crw-rw-rw- 1 root root   5,   0 Apr 13  2006 tty
crw--w 1 root tty  136,  16 Oct 30  2012 tty1
crw--w 1 root tty  136,  17 Oct 30  2012 tty2
crw--w 1 root tty  136,  18 Oct 30  2012 tty3
crw--w 1 root tty  136,  19 Oct 30  2012 tty4
crw--w 1 root tty  136,  20 Oct 30  2012 tty5
crw--w 1 root tty  136,  21 Oct 30  2012 tty6

Ok...  That's probably from a couple of days ago.  But no error messages
for the others and they are not freshly made either...  That was a
CentOS 5 container.

Trying it with another Fedora container but removed the tty? entries.
No errors.  Hmmm...  Wait...  Another problem...  Container Plover...

[mhw@plover ~]$ who
mhw  pts/92012-10-30 19:47 (forest.ip6.wittsend.com)
[mhw@plover ~]$ sudo -s
sudo: sorry, you must have a tty to run sudo

What?

Sigh...

No problem in Alcove (F17):

[mhw@canyon mhw]$ ssh alcove.ip6.wittsend.com
Last login: Wed Oct 31 01:51:39 2012 from canyon.ip6.wittsend.com
[mhw@alcove ~]$ sudo -s
[root@alcove mhw]# 

Back to Audience (CentOS 5) and removed /dev/tty?:

No errors as seen before.

Successfully created tty1-6.

Sudo works.

WTH?

There's something wrong here.  Audience and Plover do not have autodev
enabled.  Why has this changed?  Shouldn't that be under the autodev
switch as well?

  I've updated the git tree to not fail when mknod is denied.  It should
  just spit out an error, and presumably another one when it next tries
  to bind mount the pty onto it, but that's ok.

  Does git://github.com/hallyn/lxc#upstream.nov1.2012.autodev work better
  now?  (I'm logging off now, so if not I probably won't know for some time)
 
 Working now.  All containers are up.
 
 When you get back

Re: [Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053

2012-10-31 Thread Michael H. Warfield

 f1ccde27c038e7fb7e538913505248b36ddd9e65
  Author: Serge Hallyn serge.ha...@ubuntu.com
  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 serge.hal...@ubuntu.com
 
  commit 4a311c1241805dac5893918854fd40f77b2b6f49
  Author: Serge Hallyn serge.hal...@ubuntu.com
  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 serge@amd1.(none)
  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 serge.hal...@ubuntu.com
 
  commit 8b892c55b077d1716eb130e76f9c9725ecb0f73a
  Author: Serge Hallyn serge.hal...@ubuntu.com
  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 serge.hal...@ubuntu.com
 
  ---
 
  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-de...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/lxc-users
 

-- 
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

Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-10-31 Thread Michael H. Warfield

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 |  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] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-10-31 Thread Michael H. Warfield

On Wed, 2012-10-31 at 18:30 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@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 |  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] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-10-30 Thread Michael H. Warfield

On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):

:

  I did see some errors setting up that dev...
  
  -- 
  [root@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 |  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] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-10-30 Thread Michael H. Warfield

On Tue, 2012-10-30 at 19:35 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@wittsend.com):
  On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote:
   Quoting Michael H. Warfield (m...@wittsend.com):
  
  :
  
I did see some errors setting up that dev...

-- 
[root@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 |  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
 
 

-- 
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] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

2012-10-30 Thread Michael H. Warfield

On Mon, 2012-10-29 at 10:18 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@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 ERRORlxc_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@forest mhw]# touch /srv/lxc/private/Alcove/dev.tmp/no-mounted
[root@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@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@alcove ~]$ ls /dev.tmp/
[mhw@alcove ~]$ 

Opps...  Where did the file end up?

Let's look on the host...

[mhw@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@forest mhw]# lxc-start -n Alcove
lxc-start: No such file or directory

Re: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@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:

snip

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
--
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@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 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@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 |  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
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

On Sun, 2012-10-28 at 18:52 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@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@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

Re: [Lxc-users] [lxc-devel] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

On Sun, 2012-10-28 at 23:02 +0100, Serge Hallyn wrote:
 Quoting Michael H. Warfield (m...@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@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

Re: [Lxc-users] [systemd-devel] Unable to run systemd in an LXC / cgroup container.

/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 |  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
--
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@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 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 |  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
--
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@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 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 |  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
--
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@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.