Re: [Lxc-users] [lxc-devel] Request for inclusion into mainline LXC utils
Mike I don't want to start a flame war but, honestly, I feel that one Mike follows the other. I have used Debian (vanilla, Knoppix, and Mike Ubuntu) and even spun a custom distro based on Knoppix and I am Mike not at all surprised that, if you are with Debian, you find Mike bridges annoying. I would too. 1) Bridges itself work flawlessly with Debian and I have used them quite often. If mandatory then I will do so in the future too. It is the fact that I do not want to add another piece to the stack if in fact I do not have to -- I do not want to take care of a bridge, maintain, monitor, etc. it, if networking also works excellent without using yet another layer of indirection in my networking stack. Therefore I will use macvlan. Simplicity is key ... 2) http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg8.html says that in fact all the benefits of bridges will be available with with macvlan in .33 as well. So not using a bridge makes sense since I do not need one for any kind of setup I will need to do - containers having public IP, talking to Internet - containers having private IP, talking to other containers on the host - containers having private IP, talking to host - arbitrary mixture of the above 3) This is simple and straight forward and I am going to adapt my - packet_filter http://github.com/sunoano/bash as well as - generic.sh, used by packet_filter - and probably vzbulk for all kinds of routing and firewalling I need. Setting things up is simple as well http://sunoano.name/ws/public_xhtml/firewall.html#sunos_rule_set_and_how_it_is_applied -- 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-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] Request for inclusion into mainline LXC utils
On Mon, 2010-01-25 at 01:01 -0500, Michael H. Warfield wrote: : - Snip... 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? And found the answer to this one too and it raises a serious (to me) issue for the lxc developers... The problem is rooted in the differences between network setup between Debian and Fedora / RedHat et al. The later initializes the IPv6 subsystem based on the excellent and comprehensive IPv6 init scripts by Peter Bieringer and company. Debian basically does nothing, which is OK but somewhat suboptimal (doesn't set up local routes or block private address 6to4 routes amongst others which can cause problems if you are not connected to a real IPv6 network) in most cases. In the Fedora case, if you have NETWORKING_IPV6=yes and IPV6FORWARDING=no, it simply does the right thing and sets those up properly, even though it's somewhat redundant in that it's explicitly setting some values to their default values. In the Debian case, it depends on those values defaulting to a reasonable host leaf node, as if it were not a router, and expects you to manually set it correctly if it is a router. That is very true in most cases. It's not true in this case. It's a corner case of running a virtualized leaf node on a host system that is acting as an IPv6 router, which shouldn't be that common. The Debian container is booting up with sysctl values which are not normally default for a real, non-virtualized, system. It means that a Debian container will behave differently if it is migrated between hosts which are and are not routers. That's where the question comes for the lxc developers. Should it? Or should LXC have something in it to set these sysctl values or configure these sysctl values back to reasonable defaults so it behaves the same? Apparently, the container virtualization is working properly and we can change them in the containers. Should there be something in the lxc configurations for setting sysctl values as part of the lxc container initialization? 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-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] [lxc-devel] Request for inclusion into mainline LXC utils
Hi Daniel, Suno, list. I am happy for my efforts to be pillaged and merged with a unified effort. Just let me know where to look. I might be able to contribute some effort over time, though I'm not using containers day-to-day any more. Hopefully as lxc improves, I'll be able to change back :) Regarding bridges and stuff: the reason why I used a bridge is because I didn't find it too hard to set up, and it worked. No overwhelming reason otherwise - if there is a new method that is better then I'm all for it. 2010/1/25 Daniel Lezcano daniel.lezc...@free.fr: 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 -- Regards, Nigel McNie -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
