1381882451 N * l0kit Guest2504 1381882457 J * l0kit ~1oxT@0001b54e.user.oftc.net 1381882853 Q * Guest2504 Ping timeout: 480 seconds 1381883223 M * paradigm-X When a Debian guest has been configured to use a DNS proxy at localhost 127.0.0.1 for its resolver, I would need to set that in the host config file at "/etc/resolv.conf", would I not? 1381883284 M * Bertl assuming that you have configured lo isolation, then 127.0.0.1 will be guest specific 1381883302 M * Bertl so the request will go to a service running (or not running :) in the guest 1381884099 M * paradigm-X Bertl: is there documentation of this topic on the vserver.org website? 1381884110 M * Bertl probably 1381884227 J * bzed_ ~bzed@bzed.netrep.oftc.net 1381884538 Q * bzed Ping timeout: 480 seconds 1381884545 N * bzed_ bzed 1381885699 Q * Ghislain Quit: Leaving. 1381885700 J * Ghislain ~aqueos@adsl1.aqueos.com 1381886186 Q * Ghislain Ping timeout: 480 seconds 1381887133 Q * ser Ping timeout: 480 seconds 1381887178 M * paradigm-X which of the program manuals discusses implementing loopback isolation? 1381887297 M * Bertl http://linux-vserver.org/Installation_on_Linux_2.6 here is some info about the configs 1381887724 M * paradigm-X Bertl, by enabling loopback isolation, you meant enabling this option in the kernel when it was compiled:" Automatically Assign Loopback IP". Is that right? 1381887778 M * Bertl no, this config option causes the kernel to automatically assign a loopback IP 1381887821 M * Bertl the isolation itself is independant from that and can be enabled via the network context flags (NXF_LBACK_REMAP) 1381887848 M * Bertl and it gets hidden (the real IP) by the NXF_HIDE_LBACK flag 1381887878 M * Bertl which together make that per guest loopback IP appear as 127.0.0.1 1381888740 M * paradigm-X The link you just gave provides an illustration of vserver kernel configuration options about halfway through. In those options nothing is mentioned about "network context flags". Should those two settings (NXF_LBACK_REMAP & NXF_HIDE_LBACK) be in my "/usr/src/linux-vserver-vxx/.config"? I do not find them there. I do see one in VSERVER section called .._AUTO_LBACK=Y, which sounds similar. Does that indicate whether loopbac 1381888819 M * paradigm-X This is new territory for me so I am trying to follow it carefully the best I can. 1381888915 M * paradigm-X I found no mention whatsoever in the online docs about loopback isolation, aside from a couple of insubstantial points of minutae, but nothing explanatory. That is why I hoped to find something in a manual with the programs themselves too. 1381889608 M * paradigm-X Okay, I did just find a document about it here: http://linux-vserver.org/index.php?title=Installation_on_Linux_2.6&action=edit 1381889769 M * paradigm-X It looks to me, based on the link you gave and on the doc from the link I just showed, if I understand correctlym, that I may have enabled lookback isolation. Is it not so that this indicates it is set correctly: CONFIG_VSERVER_AUTO_LBACK=y 1381889997 M * paradigm-X or is that merely in reference to having the regular loopback interface loading automatically? 1381892078 Q * jrklein Remote host closed the connection 1381892080 J * jrklein ~osx@proxy.dnihost.net 1381892301 M * paradigm-X Bertl: you said above that "automatically assign loopback IP" would not be sufficient for the purpose of using loopback isolation, is that correct? Did I understand you correctly in that regard? 1381892551 M * paradigm-X I am looking at the set of kernel options available in the vserver section of "make menuconfig", but I do not see any options identifiable as either of those two you mentioned: NXF_LBACK_REMAP or NXF_HIDE_LBACK. Therefore, I cannot determine whether I enabled it or not without additional information. Can you provide anything more explanatory for me to take a look at? 1381892754 M * Bertl http://www.linux-vserver.org/Capabilities_and_Flags 1381892782 M * Bertl NXF means that it is a network context flag (aka nflag) 1381893116 Q * jrklein Read error: Connection reset by peer 1381893160 J * jrklein ~osx@proxy.dnihost.net 1381893369 M * paradigm-X so it looks like I could set those two flags with util-vserver, does it not? I mean, since I did in fact compile in the option I mentioned above, re: " Automatically Assign Loopback IP". By having compiled that in, I can now use the util-vserver to set those flags, and then "This creates a per-guest, isolated 127.0.0.1 address." 1381893405 M * paradigm-X Is that not so? 1381893530 Q * jrklein Remote host closed the connection 1381893531 J * jrklein ~osx@proxy.dnihost.net 1381893660 M * paradigm-X specifically, it looks like using this is what would work: nattribute: to change network capabilities and flags of a live guest (ncaps and flags). 1381893768 M * paradigm-X or possibly this one: vattribute. And which one should be determinable from its help file, if it was included with such. 1381894407 M * Bertl regardless if you have 'Automatically Assign Loopback IP' enabled or not, you can always give or remove those two network context flags 1381894420 M * Bertl (and in a moderately recent kernel they will work as expected) 1381894569 M * paradigm-X what about kernel 2.6.35-vs2.3.0.36.32 1381894600 M * paradigm-X that is a gentoo source 1381894608 M * Bertl quite old but should work 1381894630 M * paradigm-X that is the one provided by gentoo-sources for vserver 1381894737 M * Bertl doesn't make it newer does it? :) 1381894747 M * paradigm-X are these two flags called nflags? 1381894766 M * Bertl those two and a bunch of others are so called nflags 1381894776 M * paradigm-X No, it does not make it any newer. It is just what my distro provided is all I meant. 1381895037 M * paradigm-X so, would I need to use this command: echo "NXF_LBACK_REMAP" > /etc/vservers//nflags 1381895071 M * Bertl if it isn't already set, yes 1381895140 M * paradigm-X also this command: echo "NXF_HIDE_LBACK" > /etc/vservers//nflags 1381895164 M * Bertl well, that will overwrite the previous one :) 1381895217 M * paradigm-X yes, my bad! I spoke to quickly because I was just delighted to have found the answer. 1381895260 M * paradigm-X I should comma separate them, or put on separate lines with "echo >> .." 1381895279 M * paradigm-X * too quickly 1381895330 M * paradigm-X yes, I see now, on separate lines is the way 1381895448 M * paradigm-X Still, although I understand the commands, I still need to understand a bit more technically about what is happening when I do the commands. 1381895462 M * Bertl nothing 1381895478 M * paradigm-X great, that was easy. 1381895479 M * Bertl you are writing some characters into a file 1381895492 M * Bertl nothing will change right away 1381895518 M * Bertl if you start your guest, util-vserver will pick up the selected flags and set them for the context 1381895568 M * paradigm-X what determines the context of the guest? 1381895572 Q * jrklein Ping timeout: 480 seconds 1381895584 M * Bertl you mean the context id? 1381895677 M * paradigm-X no, I set that up already.. 1381895767 M * Bertl so please rephrase your question as I do not understand it 1381895850 M * paradigm-X I mean, after I have restarted the guest and util-vserver (automatically?) picks up the context, it will then inform the kernel that each context has unique loopback setting... 1381895884 M * Bertl no, it will simply reconfigure the guest with those two flags set 1381895924 M * paradigm-X does that mean whenever each guest's programs make a reference to using 127.0.0.1, that it will be handled now? 1381895962 M * Bertl yes, it will get remapped to the loopback IP and everytime the loopback IP would show up, it will get replaced by 127.0.0.1 1381896041 M * paradigm-X So all I need to do is those two commands, nothing more? 1381896069 M * Bertl to get loopback isolation if it isn't already on, yes :) 1381896141 M * paradigm-X i have no nflags folder in my guests' directories, none, zero. So, I cannot have loopback isolation in place without it, is that not so? 1381896255 M * Bertl depends on the kernel configuration and the tool defaults 1381896258 M * paradigm-X now, I just configure the guests normally for using the setting 127.0.0.1, and the kernel (or util-vserver) will handle the mapping based on the context of that guest. 1381896450 M * paradigm-X When I read this statement in the docs, I was under the impression that I would now need to use something else besides 127.0.0.1, something like 127.256.0.1, just depending on what context I had created fo rthe guests: "Enable this to get a unique 127.x.y.1(x.y matches the context id)" 1381896529 M * Bertl as I explained, there is a (usually unique) loopback IP assigned to each network context (either by the kernel via 'Auto LBACK' or via the config) which is mapped to 127.0.0.1 1381896539 M * paradigm-X Based on what I read, if I understand it correctly, after doing this, I can no longer use a service in the host at 127.0.0.1 from one of the guests. Is that correct? 1381896550 M * Bertl correct 1381896632 M * paradigm-X Is there a test to see whether this is working by using a little tool of some sort? Or should I just see if it works with my programs? 1381896786 M * Bertl you can simply start a 'ping 127.0.0.1' inside the guest and dump the packets with 'tcpdump -vvnei lo icmp' 1381896806 M * Bertl you will see that the ping goes to 127.x.y.1 instead of 127.0.0.1 1381897251 M * paradigm-X Bertl, I very much appreciate your help with this matter. It was not easy for me to understand from the docs alone. Your pointers provided the clues I needed to figure it out. I hope I can help you with something at some point. :) 1381897265 M * Bertl you're welcome! 1381900159 M * paradigm-X Hmm? when I run 'tcpdump -vvnei lo icmp' as root, I get an response saying I do not have permission to capture on that device 'lo' (socket: operation not permitted) 1381900475 M * Bertl inside the guest, yes; but you want to do that on the host 1381900528 M * paradigm-X ping in the guest, but tcpdump in the host? 1381900535 M * Bertl correct 1381900578 M * paradigm-X got it. 1381901539 M * paradigm-X it appears to be working, Bertl. I ping 127.0.0.1 in guest, and the output from the tcpdump command shows 127.0.x.1 (where x is the context) > 127.0.x.1: ICMP echo reply, id ... 1381901667 M * paradigm-X so now I can use the program normally in the guest and have it sending output to 127.0.0.1 as usual, while the kernel maps it uniquely. This will work for any of the guests with so-called isolated loopback configurations. 1381901711 M * paradigm-X Awesome! 1381901775 M * paradigm-X While in the host, I can still use 127.0.0.1 for programs only in it. 1381901799 M * paradigm-X Bertl: did you write the code that makes this happen? 1381901835 M * Bertl yup 1381901866 M * paradigm-X Good work, Bertl! Truly outstanding. 1381901886 M * Bertl thanks! 1381901966 M * paradigm-X I am quite impressed. I even understand it a bit, and that makes it more fun too. I need to learn much more about the capabilities of this vserver. 1381902092 M * paradigm-X While search around earlier, I came across this topic: http://linux-vserver.org/Frequently_Asked_Questions#Is_it_possible_to_provide_a_different_MAC_address_per_vServer.3F 1381902194 M * paradigm-X Does that work currently? "Is it possible to provide a different MAC address per vServer?" 1381902309 M * Bertl it works with a network namespace 1381902331 M * Bertl anyway, off to bed now ... have a good one 1381902337 N * Bertl Bertl_zZ 1381906882 Q * ncopa_ Quit: Leaving 1381906988 J * ncopa ~test@3.203.202.84.customer.cdi.no 1381907208 Q * BlackPanx Ping timeout: 480 seconds 1381907222 Q * paradigm-X Quit: leaving 1381908420 J * ser ~ser@host1.tldp.ibiblio.org 1381908489 J * Ghislain ~aqueos@adsl1.aqueos.com 1381908963 Q * ser Ping timeout: 480 seconds 1381914586 Q * hijacker Remote host closed the connection 1381915051 J * hijacker ~hijacker@bgva.sonic.taxback.ess.ie 1381918110 Q * guerby Read error: Connection reset by peer 1381918221 J * guerby ~guerby@ip165-ipv6.tetaneutral.net 1381918710 Q * guerby Ping timeout: 480 seconds 1381920145 J * guerby ~guerby@ip165-ipv6.tetaneutral.net 1381921118 J * ivanhoe ~ivanhoe@ip-36-106.sn2.eutelia.it 1381921148 Q * ircuser-1 Ping timeout: 480 seconds 1381921628 M * ivanhoe Bertl_zZ: o/ 1381921722 M * ivanhoe Bertl_zZ: I just wanted to say that patch-3.10.9-vs2.3.6.6.diff works with kernels 3.10.10-3.10.16 too, so the wiki page can be updated accordingly. 1381922744 Q * ivanhoe Quit: WeeChat 0.4.1 1381923276 J * druschka ~druschka@91.135.172.82 1381923456 J * BlackPanx ~kvirc@31.15.133.178 1381923694 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net 1381924297 Q * druschka Ping timeout: 480 seconds 1381924657 J * druschka ~druschka@91.135.172.82 1381924953 N * Bertl_zZ Bertl 1381924957 M * Bertl morning folks! 1381926243 J * thierryp ~thierry@90.84.146.199 1381926487 Q * druschka Quit: druschka 1381926874 Q * thierryp Remote host closed the connection 1381927616 Q * Aiken Remote host closed the connection 1381930623 J * ivanhoe ~ivanhoe@ip-36-106.sn2.eutelia.it 1381931539 J * thierryp ~thierry@home.parmentelat.net 1381931989 M * Bertl hey ivanhoe! thanks for the heads-up! 1381934551 Q * Romster Read error: Connection reset by peer 1381934905 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1381937138 M * ivanhoe Bertl: happy to be useful, even if at a microscopical scale. 1381939501 J * bonbons ~bonbons@2001:a18:224:e01:cd50:3693:5409:eb77 1381941000 Q * thierryp Remote host closed the connection 1381941022 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:d18a:2ba:7977:3263 1381941505 Q * thierryp Ping timeout: 480 seconds 1381942275 J * thierryp ~thierry@82.226.190.44 1381946279 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg 1381947627 Q * ivanhoe Quit: WeeChat 0.4.1 1381948916 Q * thierryp Remote host closed the connection 1381948937 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:411a:e08:a8d5:3125 1381949420 Q * thierryp Ping timeout: 480 seconds 1381952784 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1381956174 J * thierryp ~thierry@home.parmentelat.net 1381956511 Q * bonbons Quit: Leaving 1381957305 J * cuba33ci_ ~cuba33ci@1-164-208-166.dynamic.hinet.net 1381957656 Q * cuba33ci Ping timeout: 480 seconds 1381957661 N * cuba33ci_ cuba33ci 1381960125 Q * thierryp Remote host closed the connection 1381960148 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:3c67:77dd:e7ec:60b6 1381960630 Q * thierryp Ping timeout: 480 seconds 1381961620 Q * Ghislain Quit: Leaving. 1381961762 N * l0kit Guest2588 1381961768 J * l0kit ~1oxT@0001b54e.user.oftc.net 1381962076 Q * Guest2588 Ping timeout: 480 seconds 1381962361 Q * [Guy] Ping timeout: 480 seconds 1381965415 J * Guy- ~korn@elan.rulez.org 1381966091 Q * Guy- Ping timeout: 480 seconds 1381966699 J * Guy- ~korn@elan.rulez.org 1381967788 J * [Guy] ~korn@elan.rulez.org 1381967823 Q * Guy- Ping timeout: 480 seconds