1323043621 M * chrissbx What's the name of the libc replacement for static linking again? 1323043650 M * chrissbx My memory has some issue. 1323043665 M * chrissbx It's not libowfat after all, right. 1323043689 M * Bertl dietlibc 1323043703 M * chrissbx ah 1323043709 M * chrissbx almost the same :~) 1323043830 A * chrissbx thinks it should come with the word "light" on packaging with silver and pale blue stripes. 1323045194 M * chrissbx I've made a chroot-breakout in C and put in my bundle of linux-vserver tests here: https://github.com/pflanze/vservertests/tree/master/guest 1323045225 M * chrissbx It allowed me to test the following case: 1323045248 M * chrissbx vnamespace -e t3 mount --bind /home/chris/.t3-cam-listen /var/lib/vservers/t3/home/chris/.tn/.t3-cam-listen 1323045272 M * chrissbx ^ from the host 1323045285 M * chrissbx in the guest: t3:~# chroot /home/chris/.tn/.t3-cam-listen /breakout 1323045302 M * chrissbx (Test was successful.) 1323045321 M * chrissbx (Meaning, it couldn't break out.) 1323045330 M * Bertl good :) 1323050791 M * Bertl off to bed now ... have a good one everyone! 1323050797 N * Bertl Bertl_zZ 1323051534 N * ensc Guest19338 1323051543 J * ensc ~irc-ensc@p4FEC764E.dip.t-dialin.net 1323051956 Q * Guest19338 Ping timeout: 480 seconds 1323054382 J * derjohn_foo ~aj@p578EF3CC.dip.t-dialin.net 1323054386 J * aj__ ~aj@p578EF3CC.dip.t-dialin.net 1323054756 Q * derjohn_mob Ping timeout: 480 seconds 1323054779 Q * derjohn_mobi Ping timeout: 480 seconds 1323056323 M * gucki Bertl_zZ: the bug report is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650982 1323056640 J * shadizzle ~shadizzle@c-68-60-232-92.hsd1.il.comcast.net 1323057065 P * shadizzle Leaving 1323058446 Q * derjohn_foo Ping timeout: 480 seconds 1323058906 Q * hparker Quit: Quit 1323058924 Q * aj__ Ping timeout: 480 seconds 1323063014 J * aj__ ~aj@80.187.148.126 1323067030 Q * DreamerC Ping timeout: 480 seconds 1323070520 Q * gucki Remote host closed the connection 1323070919 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it 1323071438 J * ghislain ~AQUEOS@adsl2.aqueos.com 1323073174 Q * ghislain Quit: Leaving. 1323073186 J * ghislain ~AQUEOS@adsl2.aqueos.com 1323074451 Q * aj__ Ping timeout: 480 seconds 1323074946 J * gucki ~gucki@80-218-125-247.dclient.hispeed.ch 1323079247 Q * renihs Quit: narf 1323081059 J * gucki_ ~gucki@80-218-125-247.dclient.hispeed.ch 1323081231 Q * gucki Ping timeout: 480 seconds 1323081243 Q * kcin Quit: ZNC - http://znc.in 1323081307 J * kcin ~kcin@91.118.96.132 1323081628 Q * kcin Quit: ZNC - http://znc.in 1323081769 J * kcin ~kcin@91.118.96.132 1323083431 N * Bertl_zZ Bertl 1323083434 M * Bertl morning folks! 1323084322 Q * chrissbx Ping timeout: 480 seconds 1323091365 M * ghislain hello bertl 1323092596 Q * Hunger Ping timeout: 480 seconds 1323092707 P * fanto666 1323095527 J * Hunger ~Hunger@proactivesec.com 1323100032 M * gucki_ hey there 1323100056 M * gucki_ is it a potential security problem when i grant SET_UTSNAME to all guests? why is it disabled by default? 1323100421 J * dowdle ~dowdle@scott.coe.montana.edu 1323100714 J * geos_one ~chatzilla@chello080109195117.4.graz.surfer.at 1323101054 Q * ncopa_ Quit: Leaving 1323105767 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1323105793 Q * gucki_ Remote host closed the connection 1323107040 J * chrissbx ~chrissbx@69-196-180-202.dsl.teksavvy.com 1323108875 M * LuckyLuke my vserver guest has an eth0 connected to the local lan (192.168.254.0/24) and a dummy0 that goes through an OpenVPN (172.16.1.0/24) running on the main host. somehow it started sending out traffic on the vpn using the lan ip source address (and that obviously prevents the traffic from getting any reply from the remote side) 1323108908 M * LuckyLuke could it be related to something in the kernel or vserver tools / versions / config? the main host works correctly. 1323108918 M * LuckyLuke (and the routing tables appear to be correct even in the guest) 1323108958 M * LuckyLuke I'm running 2.6.39.4-vs2.3.1-pre9.2 and right now I can't upgrade to >=3.0 1323110254 M * Bertl well, first, the dummy0 cannot 'go through' an OpenVPN 1323110307 M * Bertl because, by definition, the dummy0 will simply discard anything sent to it, and will not produce any traffic by itself 1323110361 M * Bertl second, the 2.6.39.4 kernel is a poor choice in general, as it was just a proof of concept backport, with no support or maintainance whatsoever 1323110413 M * Bertl and finally, most likely it's a configuration problem, but could be routing or guest config specfic, hard to tell without more information about the setup 1323110678 Q * Rockj Ping timeout: 480 seconds 1323110770 J * bonbons ~bonbons@2001:960:7ab:0:817d:8e3e:8b7a:3756 1323111090 M * LuckyLuke Bertl: this setup worked for some 18 months before, so I know it was working. The dummy0 gets created by the main host and it's some sort of internal lan on my vserver system. 1323111142 M * LuckyLuke I'm suspecting some kernel issue, and I'm waiting to see if I can make something newer work, otherwise I'll step back to something older but working 1323111234 M * LuckyLuke main host has 172.16.1.1 on its dummy0 and an openvpn tun from 172.16.1.1/24 (local side) and 172.16.0.10 (remote side) with 172.16.0.0/16 routed through 172.16.0.10 1323111266 M * LuckyLuke the vserver guest has 172.16.1.something and was able to speak to the whole remote 172.16.0.0/24 network via the vpn tunnel using 172.16.0.10 as gateway 1323111368 M * LuckyLuke basically I need a 172.16.1.0/24 'lan' on the vserver system between its hosts, a 172.16.0.0/24 lan in a remote rack, and route between them via an OpenVPN tunnel from the main vserver host and one host on the remote side 1323111430 M * LuckyLuke different subnets handle internet traffic (192.168.254.0/24 behind nat here, and directly connected public IPs on the remote side) 1323111581 M * LuckyLuke I can't remember where I read to setup the lan between vservers with dummyX interfaces but it's probably from linux-vserver.org :) 1323111630 P * meebey 1323111693 M * LuckyLuke Bertl: what would you recommend as the 'best' vserver kernel in the 2.6.x series? the 2.6.36.4-vs2.3.0.36.39 appears to be the most recent patch without "-pre" or "-rc" in its name 1323111967 M * LuckyLuke ah, there it goes, my setup more or less follows http://linux-vserver.org/Networking_vserver_guests#Optional:_Load_.27dummy.27_device.28s.29, but then the host routes through the OpenVPN tunnel instead of NATting to the internet 1323111993 J * Rockj rockj@rockj.net 1323112232 Q * qwerty1 Remote host closed the connection 1323112317 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com 1323112416 M * Bertl probably 2.6.38.x 1323112427 M * Bertl not sure why you want to stick to 2.6 though 1323112496 M * Bertl so you have a host based tunnel with tun0 or so, and you are s/dnat-ing the guest IP for the tunnel, yes? 1323112501 M * LuckyLuke also, the guest is correctly responding to traffic originated from the remote side. ie, if I run 'telnet 172.16.1.7 25' on 172.16.0.18, it gets routed to 172.16.0.10 over lan, then to 172.16.1.1 over vpn (this is the vserver root host) then goes to postfix in the vserver guest on 172.16.1.7 via dummy0 1323112525 M * LuckyLuke nope there's simple routing on the whole 172.16.x.y part 1323112540 M * Bertl you cannot really 'route' local traffic 1323112553 M * LuckyLuke ok I hope you got what I meant :) 1323112575 M * Bertl not really, the host has 172.16.1.1 on tun0? 1323112602 M * Bertl and the guest has 172.16.1.7 and is aware of that fact? 1323112617 M * LuckyLuke there's the 172.16.0.0/24 LAN (real hosts on real ethernet) on one side, and the 172.16.1.0/24 LAN (fake lan inside my linux-vserver host between its guests) on the other side, and a VPN between two hosts of the two subnets, those hosts are the routers (ipv4_forwarding) 1323112668 M * LuckyLuke Bertl: the host starts with 172.16.1.1 on dummy0, after that openvpn starts with 172.16.1.1 on tun0. yes I have the same local ip on both interfaces. tun0 is point-to-point, dummy0 is /24 1323112688 M * LuckyLuke route -n in every system shows what I expect to see. 1323112700 M * Bertl what are the guest assigned IPs? 1323112747 M * LuckyLuke 192.168.254.x on eth0 and 172.16.1.7 on dummy0, and the whole problem I'm facing it's that it's trying to reach 172.16.0.0/24 using the 192.168... source address 1323112755 M * LuckyLuke ie, wrong source address for that subnet 1323112780 M * LuckyLuke I still have to try today but I would bet that just rebooting on an older kernel makes it work 1323112795 M * Bertl well, that's not unexpected, the 192.168.254.x is the 'primary' IP for the guest, and it is well suited to reach the other network I guess 1323112825 M * Bertl so, if you want to change that, you need to give a preference for this route/source IP 1323112828 M * LuckyLuke Bertl: pardon me, but I seem to remember that standard routing always choose the most specific route 1323112875 M * Bertl 172.16.1. isnt different from 192.168.254. when reaching 172.16.0. 1323112945 M * LuckyLuke well you're not considering these two lines: 1323112945 M * LuckyLuke 172.16.0.0 172.16.0.10 255.255.255.0 UG 0 0 0 tun0 1323112945 M * LuckyLuke 172.16.0.10 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 1323112979 M * LuckyLuke so if the vserver wants to get to 172.16.0.x it knows to use 172.16.0.10 as gw and it has a very specific route to that 1323112988 M * LuckyLuke uhm 1323113005 M * LuckyLuke now that I read it, the problem is that it's routed through tun0, but the guest doesn't see tun0 just dummy0 1323113014 M * LuckyLuke that could be the difference with some older kernel! 1323113055 M * Bertl and unless you do s/dnet, there is no point in using dummy0 in the first place 1323113074 M * Bertl just have the IP on tun0, and be done 1323113088 M * LuckyLuke uhm 1323113109 M * LuckyLuke I think I avoided it because tun0 usually is managed directly by OpenVPN 1323113128 M * Bertl no problem there, no need to let util-vserver add the ip 1323113134 M * LuckyLuke will try to change the config 1323113167 M * Bertl i.e. have openvpn manage everything tun0 related 1323113187 M * Bertl (use nodev for the guest config) 1323113209 M * LuckyLuke well I'll change openvpn config and setup tun0 in the host system instead of letting OpenVPN bring it up - otherwise I could have problems if the vserver starts with openvpn down (and thus tun0 non existing) 1323113344 M * Bertl works fine too 1323113424 M * LuckyLuke ok. guest stopped, dummy0 removed, openvpn and tun0 running, gonna edit guest config and restart it 1323113920 M * LuckyLuke I'm not sure I'm understanding nodev. Without it, the guest ip gets added to tun0 as a secondary ip, but seems not to work. If I create an empty nodev, the guest does not even sees the network device 1323113965 M * LuckyLuke and the root vserver doesn't show the guest IP anywhere in the output of 'ip addr' 1323113983 M * LuckyLuke I guess we're just loosing time on a broken kernel or something like that 1323114010 M * LuckyLuke have to make this 3.x series working on HPPA or revert back to an older 2.6 1323114090 M * Bertl you use 'nodev' instead of 'dev' 1323114102 M * Bertl i.e. remove 'dev' and simply touch 'nodev' 1323114124 M * Bertl util-vserver will then add the IP to the guest, but not to the network stack 1323114152 M * Bertl i.e. you have to add the IP (secondary is fine) to tun0 by some other means (host config, openvpn, etc) 1323114161 M * LuckyLuke oh 1323114164 M * LuckyLuke I see. 1323114175 M * Bertl the guest will then see 'tun0' with that ip 1323114176 M * LuckyLuke I have to manually add the ip, ok. 1323114211 M * Bertl that's the way 'nodev' works, but it might not be what you actually want 1323114241 M * Bertl i.e. if all you would do is to add the IP manually _before_ starting the guest, you can let util-vserver handle that for you as well 1323114253 M * Bertl (with a 'dev' entry containing 'tun0') 1323114415 M * LuckyLuke manually added the ip and started the guest (with nodev, without dev), now it sees the ip on tun0, but it still spits out traffic from the wrong ip source 1323114436 M * LuckyLuke ie, on the REMOTE end of the vpn tunnel (not the vserver side, the other one) I see this: 1323114439 M * LuckyLuke 20:44:27.595204 IP 192.168.254.207 > 172.16.1.10: ICMP echo request, id 18254, seq 17, length 64 1323114453 M * LuckyLuke where 912.168.254.207 is the guest ip on the other network (eth0) 1323114455 M * LuckyLuke 192. 1323114500 M * Bertl so, 172.16.1.x is on the non-vserver end? 1323114561 M * LuckyLuke uh, sorry, wrong ping. that is 172.16.0.x on the non-vserver end. same result pinging 172.16.0.10 :) 1323114565 M * LuckyLuke 20:46:45.973662 IP 192.168.254.207 > 172.16.0.10: ICMP echo request, id 18708, seq 6, length 64 1323114589 M * Bertl well, as I said, there is no preference for either network IMHO 1323114602 M * LuckyLuke 172.16.1.0/24 should be the vserver-side network, it probably sent traffic over the tunnel because tun0 is PtP and not /24 so it considered it a non-local ip 1323114627 M * LuckyLuke actually the traffic goes in the right way 1323114628 M * Bertl which shows that the routing is somewhat flawed 1323114634 M * LuckyLuke it's the source address that's wrong 1323114664 M * LuckyLuke routing is right. the remote side is gateway for the whole 172.16.0.0/16 1323114678 M * Bertl what does 'ip r l' show on the host, and what do you get on the guest? 1323114693 M * LuckyLuke and since 172.16.1.10 is not on a local network (tun0 is not /24 it's point-to-point) it routed through the gateway 1323114722 J * qwerty1 ~werty@router-sun-nat-i.pilsfree.net 1323114741 M * LuckyLuke default via 192.168.254.254 dev eth0 metric 2 1323114741 M * LuckyLuke 127.0.0.0/8 via 127.0.0.1 dev lo 1323114741 M * LuckyLuke 172.16.0.0/24 via 172.16.0.10 dev tun0 1323114741 M * LuckyLuke 172.16.0.10 dev tun0 proto kernel scope link src 172.16.1.1 1323114741 M * LuckyLuke 172.16.1.0/24 dev tun0 proto kernel scope link src 172.16.1.7 1323114743 M * LuckyLuke 192.168.254.0/24 dev eth0 proto kernel scope link src 192.168.254.231 1323114746 M * LuckyLuke this is the host 1323114772 M * LuckyLuke the guest doesn't have iproute2 installed :| 1323114782 M * Bertl which is wrong 1323114818 M * Bertl or to be precise, incomplete 1323114856 M * Bertl i.e. the 172.16.0.0/24 via 172.16.0.10 dev tun0 doesn't say anything about preferred src IPs 1323114876 M * LuckyLuke uhm 1323114884 M * LuckyLuke shouldn't it choose an ip from dev tun0? 1323114891 M * Bertl and for that route, which is taken if you ping anything on that end, 192.168.254.x is as good as any other /24 1323114902 M * Bertl why? 1323114918 M * Bertl why should it pick an IP from that interface? 1323114918 M * LuckyLuke don't know, good old style routing? :) 1323114930 M * LuckyLuke let me see where that route comes from... 1323114945 M * Bertl try to add a specific route for the guest, just for testing 1323114974 M * LuckyLuke it gets setup by openvpn when it establish the tunnel, with these two lines of openvpn config: 1323114977 M * LuckyLuke ifconfig 172.16.1.1 172.16.0.10 1323114980 M * LuckyLuke route 172.16.0.0 255.255.255.0 1323114985 M * Chlorek Bertl: are you talking to yourself or some *!*@*.it mask? 1323114993 M * LuckyLuke yeah I'm from .it 1323115008 M * Bertl Chlorek: check the irc logs :) 1323115014 M * LuckyLuke why is that mask? does Chlorek hates Italians? 1323115020 M * Bertl probably 1323115041 M * LuckyLuke what a shame, we have such good wines 1323115052 M * Chlorek I see nothing here except you 1323115056 M * Chlorek ;) 1323115059 M * Chlorek nvm 1323115069 M * Bertl and most likely he's eating spaghetti as well :) 1323115077 M * LuckyLuke haha 1323115087 Q * hparker Remote host closed the connection 1323115112 M * LuckyLuke well, Bertl, I think I've used up enough of your time and goodwill. and speaking of that, it's about time I start making dinner. 1323115148 M * LuckyLuke I'll do some tests in both directions: better routing and older kernels. hppa devs just said to me that linux-3 is no good for us yet 1323115164 M * LuckyLuke I'll let you know how it goes in the next days 1323115170 M * Bertl any idea what the problem is with 3.x? 1323115181 M * Bertl (besides the hppa folks being lazy as usual) 1323115264 M * LuckyLuke Bertl: dunno. some people reported panics. I didn't test mine for much longer than an hour, no panics at all and linux-vserver working, but I always got some nasty "FATAL: memory allocation failure" when trying to load modules 1323115353 M * LuckyLuke both my problem and the panics where reported on 64bit kernels, maybe 32bit does better, but it would cut my ram in half (my system has 8gb and 32bit kernels on hppa will use up to 3.5gb) 1323115375 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1323115417 M * LuckyLuke I'm already working with half cpu since SMP isn't working on my system from a long time ago - but then SMP was flaky on hppa so it's much more stable now with just one cpu :) 1323115448 M * LuckyLuke actually hppa smp should be stable now but on some systems it just get CPUx is stuck on everything but the first cpu 1323115488 M * LuckyLuke oh well, when I'll have time to get up the new vSphere5 node I'll just move from hppa hardware to vmware guest and be done with it... 1323115593 M * LuckyLuke I'll go and make some filetto al pepe verde while the hppa compiles a kernel :) 1323115602 M * LuckyLuke many thanks for the support. bye bye. 1323115629 M * Bertl you're welcome! 1323116292 J * aj__ ~aj@tmo-061-27.customers.d1-online.com 1323117219 Q * BenG Quit: I Leave 1323117531 M * Bertl off for a nap .. bbl 1323117540 N * Bertl Bertl_zZ 1323120113 Q * hparker Quit: Quit 1323120570 Q * LuckyLuke Quit: new kernel 1323120885 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it 1323121165 M * LuckyLuke Bertl_zZ: FYI, managed to run 3.0.9-vs2.3.2.1 (in 32bit, better than nothing), and everything works, including my 'old' network setup with the vserver guests "lan" over dummy0 and remote traffic through the vpn. it's definitely the 2.6.39ish kernel that screws up routing source address 1323122022 J * bj_penn hello234@75-147-136-225-SFBA.hfc.comcastbusiness.net 1323122028 M * bj_penn how do i tell which vservers are running? 1323122134 M * dkg vserver-stat 1323122151 M * bj_penn cool thanks 1323122156 M * dkg np 1323122157 Q * qwerty1 Remote host closed the connection 1323122989 Q * bonbons Quit: Leaving 1323124858 Q * LuckyLuke Quit: new kernel 1323125131 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it 1323125662 Q * ghislain Quit: Leaving. 1323126043 Q * bj_penn Read error: Connection reset by peer 1323126234 J * bj_penn hello234@75-147-136-225-SFBA.hfc.comcastbusiness.net 1323127588 J * bjpenn ~hello@c-67-160-201-8.hsd1.ca.comcast.net 1323127920 Q * bj_penn Ping timeout: 480 seconds