Re: [lxc-devel] Request for inclusion into mainline LXC utils
Suno Ano wrote: > Hi folks, > > when cloning from [0], there are a bunch of excellent tools like for > example lxc-status. What about including those into mainline lxc utils? > > > [0] git clone git://git.nigel.mcnie.name/lxc-debian.git Hi guys, there is people writing tools to create the container templates for lxc. * Nigel McNie is writting the lxc-debian and some more scripts: * Guillaume Zitta created a "lxc-provider" project https://sourceforge.net/projects/lxc-provider/ * And I am writing templates to be called by the lxc-create command I was wondering if we can join our effort, as there is a lot of templates to do and different behaviour depending the distros (udev, sysvrc/upstart, mountall, etc ...). And I would like to focus on the lxc core system more than creating templates scripts. Maybe we can elaborate a plan and define an api for the templates scripts to be called by lxc-create and include them in the lxc tree ? Thanks -- Daniel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [patch 3/3][RFC] implement lxc-cmd and lxc-enter using lxc_cinit daemon
Dietmar Maurer wrote: > After locking at the init-logger patches, it seems that it requires a > major rework because the lxc_start code changed quite much. Unfortunately, > I am not too familiar with the current code. > > Daniel, would you mind to rework the old patches to get at least the basic > functionality we had when I submitted the patches? > Dietmar, I was wondering if we shouldn't separate the "init-logger" features. For logging the container output, we can create a tty in lxc-start.c, map the slave endpoint to /dev/console and proxy the master to the real tty. That allows to: * solve the problem of the init process which stole the terminal tty, letting us in a terminal without the controling tty * we can redirect the master to file, a socket, a fifo, etc ... * we reuse most of the lxc-console code In this case, the "init-logger" becomes a "" and we keep separated the feature. What do you think ? -- Daniel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
Suno,
On Sun, 2010-01-24 at 23:27 +0100, Suno Ano wrote:
> Combining forces would be great. I just took a glance at
> https://sourceforge.net/projects/lxc-provider/ and the thing that sprung
> my eyes are
>
> - it is a bit Ubuntu focused as it is coded right now
> - assumes using a bridge i.e. also lxc.network.type=veth
> So, I am with Debian and in favor of macvlan, also totally annoyed by
> using bridges; I would rather not have to use a bride at all.
I don't want to start a flame war but, honestly, I feel that one follows
the other. I have used Debian (vanilla, Knoppix, and Ubuntu) and even
spun a custom distro based on Knoppix and I am not at all surprised
that, if you are with Debian, you find bridges annoying. I would too.
In my experience I find that, with that inane network subsystem centered
around the interfaces file, anything, outside of very simple networking
and routing, is excruciatingly painful to set up, and I do a LOT of
things that involve very complex network configurations with lots of
bridges and tunnels.
The custom distro that I did was an internal security related
distributed honeypot/honeynet project and the networking on that was my
biggest headache. Since then, that project got shelved and, if I do
another go at it (the bosses are talking about it - sigh...), future
versions will be based on NST, a Fedora based run-live. Because all the
internal communications with that distributed honeynet was purely IPv6
based, it will take half the work the Knoppix based effort was.
I have yet to figure out how to tell my Debian containers to set up
something as simple as an IPv6 autoconfigured interface. Fedora
containers work right OOTB. You would THINK it would be child's play.
But it insists that, if I define an inet6 interface, it either wants
dhcp or static and it doesn't like it if you tell it static and then
don't give it a static address. Leaving it undefined doesn't seem to
help, either. I get a link local address but it still won't autoconf.
I also don't see where the proper routing and structure for IPv6 is
suppose to get set up. IPv6 is up. I see the SIT0 device. But the
IPv6 routing table contains none of the stock IPv6 init scripts
initialization for things like 6to4 routing or local address handling.
Take a look on a Debian system with static IPv6 addresses set up and
look at the v6 routing table with "ip -6 route ls" and you'll see 3 or 4
routes. On a RedHat / Fedora system I've got something like a dozen
routes, most of which are there making sure certain things, like
compatibility addresses, DON'T get routed. I just don't get the feeling
that IPv6 has gotten set up properly.
I just find the whole networking model in Debian to be frustrating. It
is probably the number 1 primary reason why I don't use Debian more and
won't be incorporating it into future projects.
I had some problems with macvlan that may have been kernel rev related,
and I'm going to go back and retest some stuff, where I could ping and
connect to a host container from another physical system but nothing
worked from the host to the container. Bridges on Fedora / RedHat are
trivial to set up, so I took the easy way out. Sorry. I'm a lazy
bastard.
> IMHO first thing on the menu should really be about an API that allows
> to keep things generic enough for all users of lxc.
Oh... On that, I think we can totally agree. I heartily concur.
I'm working on some of my scripts that people are asking me to post.
I'm past the "works for me" stage, with the way I set things up, and
looking at "well, what if they don't want to do things the way I like to
do them". I've almost totally rewritten my initial script for
converting OpenVZ configuration files over to LXC configuration files.
Once I sort out the bloody mess with trying to deal with OpenVZ
${VEID}.mount files and the LXC fstabs, I just might finally get around
to posting it.
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
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
> I just find the whole networking model in Debian to be frustrating. It > is probably the number 1 primary reason why I don't use Debian more and > won't be incorporating it into future projects. Now, this is really offtopic on this list, but i feel that you might have missed how flexible the debian ifupdown approach is. For all the setup it uses scripts which can be changed or extended and you can add your own scripts to do all kind of fancy stuff. See for example the bridge-utils package which adds new keywords. You might also want to see ifupdown-extra or ifupdown-scripts-zg2 to get a feeling how easily you can create very complicated yet flebile setups. I haven't played with ipv6 for some years, but i'm sure that your problems can be fixed without much work. For starters i would try something like this: interface foo inet6 manual pre-up ifconfig foo up For the missing routes: Now i feel that when doing autoconfigure, all routes should be setup by the autoconfigure process. > I had some problems with macvlan that may have been kernel rev related, > and I'm going to go back and retest some stuff, where I could ping and > connect to a host container from another physical system but nothing > worked from the host to the container. In my test setup i used macvlan and i can connect to the container from the host. I remember having seen that this was a problem with older kernel versions and was fixed some time ago. > Bridges on Fedora / RedHat are trivial to set up, On debian they are trivial as well btw. Regards, Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
On Mon, 2010-01-25 at 02:18 +0100, Michael Holzt wrote: > > I just find the whole networking model in Debian to be frustrating. It > > is probably the number 1 primary reason why I don't use Debian more and > > won't be incorporating it into future projects. > Now, this is really offtopic on this list, but i feel that you might > have missed how flexible the debian ifupdown approach is. For all the > setup it uses scripts which can be changed or extended and you can > add your own scripts to do all kind of fancy stuff. It MIGHT be a little OT for the -devel list, very true, but I don't find it OT at all for the -user list for the simple fact of appliciblity to our containers. I have examined the Debian ifupdown approach in depth and found it confining, confusing, and inconsistent. But that's just me. YMMV. Like I said, I spun an entire custom distro on it and that was my #1 headache. I've done FreeBSD, OpenBSD, Solaris, AIX, HP/UX, even old SunOS 4 and SCO. Every one of them have pluses and minuses but, over the years (going on over 25 years now, long prior to even Linux) I have found the BSDish approach inferior to the SVr5ish approach in this particular arena (not in all). Yeah, the Redhat approach is not exactly SVr5ish either, but the philosophy is still there. I haven't found anything I could do under the Debian configs that couldn't be done under the RedHat configs so the "flexibility" question is somewhat moot. > See for example the bridge-utils package which adds new keywords. You > might also want to see ifupdown-extra or ifupdown-scripts-zg2 to get > a feeling how easily you can create very complicated yet flebile > setups. I will look into that. I'm always open to looking at new things and always open to changing my mind (which quite often happens as often as I change my shorts). > I haven't played with ipv6 for some years, but i'm sure that your > problems can be fixed without much work. For starters i would try > something like this: > interface foo inet6 manual > pre-up ifconfig foo up Now THAT's worth checking out. I will do that. Thank you sir! I have a Debian container spun up and hot right now to play with. Just the thing I needed. > For the missing routes: Now i feel that when doing autoconfigure, > all routes should be setup by the autoconfigure process. I think you misunderstand that process. Autoconf is very specific thing wrt IPv6 and is a whole IPv6 protocol of neighbor discovery and router announcements, solicitation, and discovery specified by RFC. It inherently can NOT do things like configure link local routes or 6to4 routes. Those are the responsibility of the the local system. That the system "automatically configures" it's interfaces and routes - I agree with you. But that is NOT IPv6 "autoconf". Think of IPv6 autoconf as IPv4 ARP on steriods. > > I had some problems with macvlan that may have been kernel rev related, > > and I'm going to go back and retest some stuff, where I could ping and > > connect to a host container from another physical system but nothing > > worked from the host to the container. > In my test setup i used macvlan and i can connect to the container from > the host. I remember having seen that this was a problem with older > kernel versions and was fixed some time ago. That's what I'm strongly suspecting. The system in question was a Fedora 11 system running a 2.6.30 kernel. I wouldn't expect something like that to remain broken for long. > > Bridges on Fedora / RedHat are trivial to set up, > On debian they are trivial as well btw. I'll check it out. Things may have well improved and I may have to reassess my opinion! Thank you! > Regards, > Michael (Too many secrets? Too many MIKES! >;->=> Very confusing...) 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 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
On Mon, 2010-01-25 at 02:18 +0100, Michael Holzt wrote: : - snip > I haven't played with ipv6 for some years, but i'm sure that your > problems can be fixed without much work. For starters i would try > something like this: > interface foo inet6 manual > pre-up ifconfig foo up Well, it was a good shot. But, unfortunately, all for naught. It still no workie. The Debian container: eth0 Link encap:Ethernet HWaddr 00:04:08:01:02:40 inet addr:172.20.38.130 Bcast:172.20.38.255 Mask:255.255.255.0 inet6 addr: fe80::204:8ff:fe01:240/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:246 errors:0 dropped:0 overruns:0 frame:0 TX packets:186 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21383 (21.3 KB) TX bytes:23934 (23.9 KB) The Fedora container: eth0 Link encap:Ethernet HWaddr 00:04:08:01:02:0A inet addr:172.20.38.131 Bcast:172.20.38.255 Mask:255.255.255.0 inet6 addr: 2001:4830:3000:8202:204:8ff:fe01:20a/64 Scope:Global inet6 addr: fe80::204:8ff:fe01:20a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:127 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12396 (12.1 KiB) TX bytes:1008 (1008.0 b) I DON'T understand this. It makes NO sense to me. At that point EVERYTHING SHOULD BE under control of the kernel. But... Somehow the Debian configuration fails, even if I restart the routing daemon and re-advertise those routes. At that point, everything should just autoconf with no action from the user space at all. There is one other very important weirdism. IPv6 stateless autoconf, by design and by intent, is disabled if IPv6 forwarding is enabled in the kernel (remember too, this is a 2.6.30 kernel) and these containers are residing on a machine acting as an IPv6 router (recurse back to my earlier comments about very complex configurations and routing) although they, themselves are not routers. The host machine is running a routing advertisement daemon (zebra) providing IPv6 routes. That host routes to and from REAL IPv6 networks as well as these virtual containers as well. In the host sysctl.conf: net.ipv6.conf.all.forwarding = 1 Confirmed by: [r...@complex ~]# cat /proc/sys/net/ipv6/conf/all/forwarding 1 In the Fedora container, I have not hat to set that to 0 but... [r...@alcove ~]# cat /proc/sys/net/ipv6/conf/all/forwarding 0 Like magic. And there it works. In the Debian container, it was NOT showing up as 1 but 0. So I set it in /etc/sysctl.conf. Now... r...@ubuntu:~# cat /proc/sys/net/ipv6/conf/all/forwarding 0 And there it still doesn't work. What is the difference? Why doesn't it work properly with Debian? These containers are running side by side in the same host environment (re-enforcing some relevance to the lxc-devel topic). 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 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Request for inclusion into mainline LXC utils
Sorry... Long quote of my own post with no snip. Too much is relevant... On Sun, 2010-01-24 at 23:43 -0500, Michael H. Warfield wrote: > On Mon, 2010-01-25 at 02:18 +0100, Michael Holzt wrote: > > : - snip > > > I haven't played with ipv6 for some years, but i'm sure that your > > problems can be fixed without much work. For starters i would try > > something like this: > > > interface foo inet6 manual > > pre-up ifconfig foo up > > Well, it was a good shot. But, unfortunately, all for naught. It still > no workie. > > The Debian container: > > eth0 Link encap:Ethernet HWaddr 00:04:08:01:02:40 > inet addr:172.20.38.130 Bcast:172.20.38.255 Mask:255.255.255.0 > inet6 addr: fe80::204:8ff:fe01:240/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:246 errors:0 dropped:0 overruns:0 frame:0 > TX packets:186 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:21383 (21.3 KB) TX bytes:23934 (23.9 KB) > > The Fedora container: > > eth0 Link encap:Ethernet HWaddr 00:04:08:01:02:0A > inet addr:172.20.38.131 Bcast:172.20.38.255 Mask:255.255.255.0 > inet6 addr: 2001:4830:3000:8202:204:8ff:fe01:20a/64 Scope:Global > inet6 addr: fe80::204:8ff:fe01:20a/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:127 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:12396 (12.1 KiB) TX bytes:1008 (1008.0 b) > I DON'T understand this. It makes NO sense to me. At that point > EVERYTHING SHOULD BE under control of the kernel. But... Somehow the > Debian configuration fails, even if I restart the routing daemon and > re-advertise those routes. At that point, everything should just > autoconf with no action from the user space at all. > There is one other very important weirdism. IPv6 stateless autoconf, by > design and by intent, is disabled if IPv6 forwarding is enabled in the > kernel (remember too, this is a 2.6.30 kernel) and these containers are > residing on a machine acting as an IPv6 router (recurse back to my > earlier comments about very complex configurations and routing) although > they, themselves are not routers. The host machine is running a routing > advertisement daemon (zebra) providing IPv6 routes. That host routes to > and from REAL IPv6 networks as well as these virtual containers as well. > In the host sysctl.conf: > net.ipv6.conf.all.forwarding = 1 > Confirmed by: > [r...@complex ~]# cat /proc/sys/net/ipv6/conf/all/forwarding > 1 > In the Fedora container, I have not hat to set that to 0 but... > [r...@alcove ~]# cat /proc/sys/net/ipv6/conf/all/forwarding > 0 > Like magic. And there it works. > In the Debian container, it was NOT showing up as 1 but 0. So I set it > in /etc/sysctl.conf. Now... > r...@ubuntu:~# cat /proc/sys/net/ipv6/conf/all/forwarding > 0 > And there it still doesn't work. What is the difference? Why doesn't > it work properly with Debian? These containers are running side by side > in the same host environment (re-enforcing some relevance to the > lxc-devel topic). This has been frustrating me for long, and I had to get to the bottom of it. It's something on the kernel level and it had to be resolvable, I just don't understand why it's peculiar to the Debian containers. FOUND IT! [r...@alcove ~]# cat /proc/sys/net/ipv6/conf/all/accept_ra 1 r...@ubuntu:~# cat /proc/sys/net/ipv6/conf/all/accept_ra 0 That's what was killing me and blocking autoconf in Debian. I set that to 1 for all and for eth0 and it all magically starts working. Leaves unresolved why this is required in the Debian containers and NOT in the Fedora containers but someone else can worry about that while I integrate this into my container "hacks". This is what I had to add to the container /etc/sysctl.conf to make this all work: net.ipv6.conf.all.forwarding=0 net.ipv6.conf.all.accept_ra=1 net.ipv6.conf.default.accept_ra=1 net.ipv6.conf.eth0.accept_ra=1 Had to add all of them. Leave any one of them out and it fails (which probably means, if there is an eth1 or eth2, they need to be there as well... Gag...) Which begs a question (not "begs the question" which is a logical conundrum of a different sort)... WHY is this necessary in Debian containers and not at all in Fedora containers? 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 --
