1478654317 J * fstd_ ~fstd@x4db5566b.dyn.telefonica.de 1478654772 Q * fstd Ping timeout: 480 seconds 1478654772 N * fstd_ fstd 1478655696 Q * Ghislain Quit: Leaving. 1478657707 J * derjohn_mobi ~aj@x590dfdaf.dyn.telefonica.de 1478658150 Q * derjohn_mob Ping timeout: 480 seconds 1478661334 J * kolorafa ~quassel@root03.itdesk.eu 1478661392 M * kolorafa Hi, problem after upgrading from Debian 7.2 to 8, after starting vserver all my mount points (/dev /proc/) are missing, vserver not running correctly 1478661421 M * kolorafa even on host /proc gets unmounted 1478661549 M * Bertl_oO sounds like incomplete isolation if the guest affects the host 1478661573 M * Bertl_oO but it could as well be the tools on the host 1478661589 M * Bertl_oO what kernel (version/patch) and what util-vserver (version) are you using? 1478661591 M * kolorafa it's the seond box with the same problem after upgrading from 7 to 8 1478661605 M * kolorafa Linux itdesk-host 4.1.35-vs2.3.8.5.2-beng 1478661627 M * kolorafa vserver 0.30.216-pre3126-jessie0.1 -- manages the state of vservers 1478661716 M * kolorafa using: deb http://repo.psand.net/ jessie main 1478661777 M * Bertl_oO well, doesn't look bad per se ... do you run systemd on the host? 1478661809 M * kolorafa yes, i think it's default 1478661825 M * Bertl_oO well, that is probably the main reason 1478661825 M * kolorafa see cgroup also mounted 1478661844 M * Bertl_oO IIRC, you want to switch to sysv on the host 1478661893 M * kolorafa do you have some hints how to do that? 1478661924 M * Bertl_oO sorry, no idea, not using debian anywhere :/ 1478661941 M * Bertl_oO but I'm sure there will be somebody around who knows 1478662468 M * kolorafa ok, simple apt-get install sysvinit-core sysvinit-utils cp /usr/share/sysvinit/inittab /etc/inittab did drop systemd, i hope it will work 1478662847 M * kolorafa yes, it's working ! thanks for the big hint, i would never think that the systemd might conflict somehow 1478662863 M * Bertl_oO you're welcome! 1478666829 M * Bertl_oO off to bed now ... have a good one everyone! 1478666831 N * Bertl_oO Bertl_zZ 1478677195 Q * fback Ping timeout: 480 seconds 1478677707 J * fback fback@red.fback.net 1478677993 J * Ghislain ~ghislain@adsl1.aqueos.com 1478678531 J * Ghislain1 ~ghislain@81.56.195.31 1478678835 Q * Ghislain Ping timeout: 480 seconds 1478680821 J * fback_ fback@red.fback.net 1478680940 Q * fback Ping timeout: 480 seconds 1478684174 M * Guy- hm, I'm once more confused about routing vs. vserver 1478684193 M * Guy- supposedly using ip rules to cause vserver traffic to choose a different routing table should work, right? 1478684209 M * Guy- "ip rule add from lookup " 1478684266 M * Guy- however, it doesn't quite work, and I suspect the reason is that the kernel consults the routing table to determine the IP of outgoing packets, so that the routing decision has to be made before a "from" condition in an ip rule can be evaluated 1478684292 M * Guy- ("from" rules obviously work for forwarded packets) 1478685638 Q * derjohn_mobi Ping timeout: 480 seconds 1478687245 J * derjohn_mobi ~aj@b2b-94-79-172-98.unitymedia.biz 1478689231 N * Bertl_zZ Bertl 1478689252 M * Bertl morning folks! 1478689300 M * kolorafa morning 1478689540 J * kimegede ~kimegede@0x55537b63.adsl.cybercity.dk 1478690848 M * CcxWrk Guy-: IIRC if there is no bind() prior to connect() the routing table is used to assign outgoing ip/port automatically. You can try ping -I SRC_IP or something else that bind()s before it connects. 1478691007 M * CcxWrk I don't think there's any per-connection routing information though so it shouldn't affect subsequent routing decisions. 1478694231 M * Bertl Guy-: should work fine, what does your look like and does the packet actually use the ? 1478694373 Q * BlackPanx Ping timeout: 480 seconds 1478694464 J * BlackPanx ~black@93-103-10-34.static.t-2.net 1478694556 M * Guy- CcxWrk: well, the problem was I was trying to get nagios pings to use the correct routing table, and the nagios plugin doesn't bind() 1478694598 M * Guy- Bertl: well, since it doesn't hit the correct routing table entry, it doesn't use the correct source IP 1478694671 M * Guy- the table in question looked like this: 1478694671 M * Guy- default via 192.168.0.1 dev bypass src 192.168.146.128 1478694723 M * Guy- but the pings just used the default route of the main table if I tried matching via 'ip ru add from ...'; if I just used a destination match, the ip rule worked 1478694781 M * Bertl so that brings us to the question: what IP(s) are configured for the guest? what network/ip isolation is used? 1478694853 M * Bertl does ping -I work on the host? on the guest? 1478694988 M * Guy- Bertl: the guest has 192.168.147.68/32 on dummy0 1478695016 M * Guy- what do you mean, "what network/ip isolation is used"? 1478695141 M * Guy- now that's weird... meanwhile I workarounded this problem using nfmark, and if I now add a high-priority ip rule with only 'from' matching, 'lookup main', _that_ matches (i.e. ping stops working) 1478695265 M * Bertl /32 is not on a network 1478695292 M * Bertl so the first step is probably to fix that and assign the proper netmask 1478695313 M * Guy- well, "fix" is such a loaded word here :) 1478695325 M * Guy- it's perfectly valid to have a /32 IP 1478695334 M * Bertl regarding isolation: do you use ip isolation or network namespaces? 1478695377 M * Guy- network namespaces 1478695408 M * Guy- ping -I doesn't work, it complains it can't find an interface named 192.168.147.68 1478695412 M * Bertl so the ping actually comes from a virtual network device and is routed on the host, yes? 1478695494 M * Guy- yes 1478695513 M * Bertl does your ping (debian maybe?) allow for using an address for the -I option (check man) 1478695545 M * Bertl because the ping I know supports interface and address and knows which is which 1478695690 M * Guy- yes, it supposedly supports both 1478695697 M * Guy- and I specified the IP, not the interface name 1478695709 M * Guy- that's why I was surprised to see the error message complain about the name 1478695721 M * Bertl also, what do you get with tcpdump -vvnei icmp 1478695734 M * Bertl (on the host) when you ping from the guest? 1478695740 M * Guy- what's "guest-venet"? 1478695757 M * Guy- I see the pings leaving on the interface the default route of the main table points out through 1478695759 M * Bertl the virtual network device you use to connect the network namespaces 1478695769 M * Guy- the source IP is the IP of the guest 1478695783 M * Guy- OK, I may have misunderstood you -- there is no such virtual network device 1478695786 M * Guy- I only have the dummy0 1478695803 M * Bertl so you are not using network namespaces but IP isolation instead? 1478695833 M * Guy- as far as I understood so far, I was using network namespaces -- util-vserver sets one up for every guest, no? 1478695867 M * Guy- and network namespaces are the tools that achieve IP isolation 1478695869 M * Bertl util-vserver can do both, network contexts (aka. IP isolation) and network namespaces 1478695919 M * Bertl network namespaces give you a separate network stack for each guest, with a virtual network device 1478695933 M * Guy- oh, OK, then no, I'm using network contexts 1478695952 M * Guy- but this namespace thing sounds promising, I'll look into it :) 1478695981 M * Bertl well, it doesn't really matter for the problem at hand 1478695988 M * Guy- but meanwhile I still don't understand why the ip rule doesn't match 1478696000 M * Bertl it matters which you use, because the setup/approach is different 1478696033 M * Bertl how do you verify that the rule doesn't match? 1478696047 M * Guy- a) the ping says destination unreachable; 1478696055 M * Guy- b) I see the ping packets leaving on the wrong interface 1478696072 M * Guy- (using tcpdump) 1478696135 M * Bertl well, doesn't mean that the rule didn't match, does it? 1478696192 M * Guy- I don't see how it doesn't 1478696209 M * Bertl I know nothing about your table (yet) 1478696209 M * Guy- if I omit the from condition in the rule, leaving only the destination condition, it matches 1478696223 M * Guy- i.e. the ping works, the packet leaves on the correct interface 1478696243 M * Guy- should I pastebin something? 1478696254 M * Bertl yes, please pastebin everything related :) 1478696292 M * Guy- meanwhile, is the util-vserver vs. namespace thing documented somewhere? 1478696366 J * Gremble ~Gremble@cpc87179-aztw31-2-0-cust6.18-1.cable.virginm.net 1478696390 Q * Gremble 1478696403 J * Gremble ~Gremble@cpc87179-aztw31-2-0-cust6.18-1.cable.virginm.net 1478696703 M * Guy- Bertl: http://sprunge.us/XdWb 1478697254 M * Guy- I found /etc/vservers/vserver-name/netns on the great flower page 1478697265 M * Bertl your routing table is missing the network declaration for 192.168.0.1 1478697301 M * Guy- ah, sorry 1478697302 M * Guy- 192.168.0.0/24 dev bypass scope link src 192.168.146.128 1478697305 M * Guy- this is that line 1478697327 M * Guy- I know all of this is very strange (why isn't the source address in 192.168.0.0/24? and so on) 1478697349 M * Guy- this "bypass" interface is connected directly to another linux box 1478697360 M * Bertl the problem here is more missing/partial information 1478697361 M * Guy- and it has similarly weird routing, so it works 1478697390 M * Guy- yes, I was trying to include what was needed without creating confusion by including irrelevant details too, but I failed 1478697405 M * Guy- however, I think the last bits are interesting 1478697408 J * Ghislain ~ghislain@adsl1.aqueos.com 1478697417 M * Guy- the ip ro get commands in the guest 1478697422 M * Bertl can you update the routing tables to match reality please? 1478697463 M * Guy- OK 1478697505 M * Bertl an what is the addr info for 'bypass'? 1478697519 M * Guy- I'll include that too, hang on 1478697704 Q * Ghislain1 Ping timeout: 480 seconds 1478697823 M * Guy- Bertl: http://sprunge.us/aaUj 1478697953 M * Bertl any SNAT or masquerading? 1478698236 M * Guy- lots 1478698276 M * Guy- Bertl: but it shouldn't matter, because the packets that get sent out use the real IP of the guest 1478698296 M * Guy- (in both cases -- i.e. both when the ip rule matches and when it doesn't) 1478698302 M * Bertl well, the problem is, your routing table doesn't cover the guest source IP at all 1478698321 M * Bertl the routes suggest an IP which is not part of the guest 1478698340 M * Bertl and if there is no nat happening, then the routing decision will fail (in some cases) 1478698356 M * Bertl it will work fine if the route is cached from the host 1478698380 M * Bertl if your goal is to route any traffic from that guest via bypass 1478698396 M * Bertl then I would suggest to add that IP to the device (instead of dummy) 1478698445 M * Guy- yes, I thought that might work around it 1478698446 M * Bertl I would also suggest to get a ping which can handle -I at least on the host 1478698457 M * Guy- ping -I ip on the host works 1478698472 M * Guy- hm, no 1478698478 M * Guy- it used to a few months ago 1478698534 M * Guy- it's iputils-ping 3:20150815-2, the latest available in Debian unstable 1478698684 Q * Gremble Quit: I Leave 1478698702 M * Guy- I'd install inetutils-ping, but nagios plugins depend on iputils-ping 1478698717 M * CcxWrk I generally prefer fping. 1478698736 M * Guy- I now use oping 1478698743 M * Guy- oping -I works on the host 1478698794 M * Guy- so with oping -I in the guest, the ip rule works 1478698934 M * Guy- oh well, I'll just go back to nfmark 1478699279 M * Bertl so the ping is routed correctly from inside the guest? 1478699301 M * Bertl but your service ping (nagios) doesn't work? 1478699332 M * Guy- exactly 1478699344 M * Guy- well, oping -I is routed correctly 1478699346 M * Guy- plain ping is not 1478699366 M * Bertl what about oping without -I ? 1478699396 M * Bertl (inside the guest) 1478699411 M * Guy- Bertl: also doesn't work 1478699425 M * Guy- goes out the default interface 1478699444 M * Bertl so that means that the 'default' route inside the guest is still wron if no IP is specified 1478699511 M * Guy- well, the default route is correct; the problem is that the guest uses the default route instead of the ip rule matching and causing the default route from the bypass table to be used 1478699544 M * Guy- to me it looks like the decision that assigns the source IP is taken after the routing decision 1478699554 M * Guy- so that no 'ip rule ... from ...' would ever match 1478699591 M * Bertl yes, that is how the Linux network stack works 1478699630 M * Bertl if you do not specify a source IP, the destination is routed and according to your rules the appropriate source IP is chosen 1478699652 M * Guy- but this isn't universally true, because if it were, trying to use ip rules to segregate vserver traffic would be ineffective 1478699654 M * Bertl inside a guest, you are then limited to guest IPs, so if that default source IP is not available, it is overwritten 1478699670 M * Bertl there are two ways to address this 1478699707 M * Bertl first, you can force the guest IP at bind time (with the single IP special casing) 1478699726 M * Bertl (not sure this works with ICMP though, which is in general a hack) 1478699756 M * Bertl and secondly, you can make the routing source IP available to the guest 1478699781 M * Bertl either by putting the guest IP on the routing table or by applying proper nat rules 1478699835 M * Bertl but of course, tagging the packets with marks and routing based on that will do the job as well 1478699860 M * CcxWrk What about implementing vserver-id routing selector? :] 1478699861 M * Guy- I don't normally enable CONFIG_VSERVER_AUTO_SINGLE because I don't fully understand what it does 1478700153 M * Bertl you can still enable it on a per guest basis with the appropriate flags 1478700556 M * Guy- I know 1478700569 M * Guy- I'll try to see if it helps when I have more time 1478700571 M * Guy- thanks so far :) 1478700709 M * Bertl np 1478701063 M * Guy- Bertl: regarding /etc/vservers/vserver-name/netns, how does one use this? for example, how do you configure the host end of the virtual interface? (I suppose the guest can pretend it's a physical interface and use whatever it would if it were a physical box) 1478702126 M * Bertl best check with daniel_hozac how util-vserver uses the network namespaces 1478702167 M * Guy- haven't seem him speak up in a while 1478702250 M * AlexanderS I am using network namespaces, but I have a couple of patches on top of util-vserver. 1478702407 M * Guy- AlexanderS: what patches? 1478702530 M * Bertl off for now .. bbl 1478702531 N * Bertl Bertl_oO 1478702756 J * maxigas ~mxs@162.247.75.173 1478702789 M * maxigas hello -- i would like to know if dirtycow and CVE-2016-7117 has been fixed in the latest Beng line of kernels. 1478702852 M * Guy- what's Beng? 1478703585 M * AlexanderS maxigas: dirtycow is fixed. I think CVE-2016-7117 is fixed, too. But I do not know for sure. 1478703933 M * AlexanderS Guy-: I have some patches, to move the network namespace outside of the vserver-spaces (so I can use network namespaces _and_ network contexts), I automatically create macvlan devices and mac addresses and I have a loop to wait until ipv6-dad is ready on the new interfaces before continuing starting of the vserver. 1478704154 M * Guy- AlexanderS: did you show these to daniel_hozac? 1478705932 Q * kimegede Quit: Linkinus - http://linkinus.com 1478706145 M * AlexanderS No. 1478706178 M * Guy- AlexanderS: perhaps you should :) 1478706233 M * Guy- AlexanderS: anyway, how do you cause the host end of the veth interface to be configured on vserver startup? 1478706476 M * AlexanderS I do not use veth, but I use macvlan devices. I think plain util-vserver supports it, too. With macvlan "virtual" devices you can just create a new device with a physical "master" device and assign the new device to the network namespace. 1478706614 M * Guy- AlexanderS: is this documented anywhere? I'd like to know more but I don't want to take up your time with questions 1478706908 M * AlexanderS Guy-: I do not now any special docs for linux-vserver, but macvlan is pretty general and you could find docs with google ;-) 1478706965 M * AlexanderS macvlan creation is simple. "ip link add link eth0 mac0 address 56:61:4f:7c:77:db type macvlan" or something like that should work. 1478707713 M * Guy- AlexanderS: and in /etc/vservers/vserver-name/netns/interfaces/iface/type you then write macvlan? 1478709433 M * AlexanderS Guy-: Like I said, I have a special setup. But yes, I think that should work. 1478716453 Q * derjohn_mobi Ping timeout: 480 seconds 1478716998 M * daniel_hozac Guy-: you basically have to write a script to configure the interfaces. 1478720747 M * Guy- daniel_hozac: that's OK, but what's going to call my script? does 'vserver foo start' have some hook? 1478721377 M * AlexanderS Guy-: There is "/etc/vservers/vserver-name/scripts" 1478721560 M * Guy- ah, right 1478725331 J * FireEgl Fire_OFTC@2604:2d80:8410:8126:64be:99cb:291f:b1ba