1186360434 Q * arcil Remote host closed the connection 1186361554 J * DoberMann_ ~james@AToulouse-156-1-53-51.w90-16.abo.wanadoo.fr 1186361628 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds 1186361660 Q * meandtheshell Quit: Leaving. 1186365166 J * jmp_ ~jmp@Montreal.safe.ca 1186365229 M * jmp_ Bert are you here? 1186365238 M * daniel_hozac _oO says no ;) 1186365318 Q * jmp_ 1186365591 Q * DoberMann_ cation.oftc.net charon.oftc.net 1186365591 Q * pyquila cation.oftc.net charon.oftc.net 1186365591 Q * Loki|muh cation.oftc.net charon.oftc.net 1186365591 Q * zLinux cation.oftc.net charon.oftc.net 1186365591 Q * Guy- cation.oftc.net charon.oftc.net 1186365591 Q * eyck_ cation.oftc.net charon.oftc.net 1186365591 Q * Vudu cation.oftc.net charon.oftc.net 1186365591 Q * Greek0 cation.oftc.net charon.oftc.net 1186365591 Q * Baby cation.oftc.net charon.oftc.net 1186365591 Q * FireEgl cation.oftc.net charon.oftc.net 1186365591 Q * FloodServ cation.oftc.net charon.oftc.net 1186365591 Q * brcc_ cation.oftc.net charon.oftc.net 1186365591 Q * coderanger cation.oftc.net charon.oftc.net 1186365591 Q * balbir_ cation.oftc.net charon.oftc.net 1186365591 Q * tam cation.oftc.net charon.oftc.net 1186365591 Q * mugwump cation.oftc.net charon.oftc.net 1186365591 Q * hallyn_ cation.oftc.net charon.oftc.net 1186365591 Q * ntrs_ cation.oftc.net charon.oftc.net 1186365591 Q * Hollow cation.oftc.net charon.oftc.net 1186365591 Q * emtty cation.oftc.net charon.oftc.net 1186365591 Q * gdm cation.oftc.net charon.oftc.net 1186365591 Q * dilinger cation.oftc.net charon.oftc.net 1186365591 Q * neuralis cation.oftc.net charon.oftc.net 1186365591 Q * mattzerah cation.oftc.net charon.oftc.net 1186365591 Q * Aiken cation.oftc.net charon.oftc.net 1186365591 Q * hardwire cation.oftc.net charon.oftc.net 1186365591 Q * bored2sleep cation.oftc.net charon.oftc.net 1186365591 Q * er cation.oftc.net charon.oftc.net 1186365591 Q * Johnnie cation.oftc.net charon.oftc.net 1186365591 Q * quasisane cation.oftc.net charon.oftc.net 1186365591 Q * yoh cation.oftc.net charon.oftc.net 1186365591 Q * micah cation.oftc.net charon.oftc.net 1186365648 J * DoberMann_ ~james@AToulouse-156-1-53-51.w90-16.abo.wanadoo.fr 1186365648 J * FireEgl FireEgl@Sebastian.Atlantica.US.TO 1186365648 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net 1186365648 J * FloodServ services@services.oftc.net 1186365648 J * emtty ~eric@dynamic-acs-24-154-34-241.zoominternet.net 1186365648 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net 1186365648 J * balbir_ ~balbir@122.167.74.154 1186365648 J * Vudu ~vudumen@perverz.hu 1186365648 J * Baby ~miry@195.37.62.208 1186365648 J * eyck_ ~eyck@nat.nowanet.pl 1186365648 J * coderanger ~coderange@c-65-96-210-168.hsd1.ma.comcast.net 1186365648 J * er ~yakker@aegis.CS.Princeton.EDU 1186365648 J * Guy- VpFTQTAnHs@chardonnay.math.bme.hu 1186365648 J * Hollow ~hollow@proteus.croup.de 1186365648 J * Greek0 ~greek0@85.255.145.201 1186365648 J * zLinux ~zLinux@88.213.32.248 1186365648 J * brcc_ bruce@72.20.27.65 1186365648 J * bored2sleep ~bored2sle@66.111.53.150 1186365648 J * yoh ~yoh@ravana.rutgers.edu 1186365648 J * Loki|muh loki@satanix.de 1186365648 J * pyquila gerbens@82.94.222.35 1186365648 J * hardwire ~bip@216.152.176.9 1186365648 J * mattzerah ~matt@121.50.222.55 1186365648 J * ntrs_ ntrs@68-188-55-120.dhcp.stls.mo.charter.com 1186365648 J * gdm ~gdm@www.iteration.org 1186365648 J * quasisane ~user@c-75-67-252-184.hsd1.nh.comcast.net 1186365648 J * hallyn_ ~xa@adsl-75-0-152-82.dsl.chcgil.sbcglobal.net 1186365648 J * micah ~micah@micah.riseup.net 1186365648 J * dilinger ~dilinger@mail.queued.net 1186365648 J * neuralis ~krstic@solarsail.hcs.harvard.edu 1186365648 J * mugwump ~samv@watts.utsl.gen.nz 1186365648 J * tam ~tam@gw.nettam.com 1186367444 Q * fs Ping timeout: 480 seconds 1186367834 Q * Baby Remote host closed the connection 1186373006 J * jmp_ ~jmp@Montreal.safe.ca 1186373151 Q * pyquila cation.oftc.net charon.oftc.net 1186373151 Q * Loki|muh cation.oftc.net charon.oftc.net 1186373151 Q * zLinux cation.oftc.net charon.oftc.net 1186373151 Q * Guy- cation.oftc.net charon.oftc.net 1186373151 Q * eyck_ cation.oftc.net charon.oftc.net 1186373151 Q * Vudu cation.oftc.net charon.oftc.net 1186373151 Q * DoberMann_ cation.oftc.net charon.oftc.net 1186373151 Q * Greek0 cation.oftc.net charon.oftc.net 1186373151 Q * FireEgl cation.oftc.net charon.oftc.net 1186373151 Q * FloodServ cation.oftc.net charon.oftc.net 1186373151 Q * jmp_ cation.oftc.net charon.oftc.net 1186373151 Q * brcc_ cation.oftc.net charon.oftc.net 1186373151 Q * coderanger cation.oftc.net charon.oftc.net 1186373151 Q * balbir_ cation.oftc.net charon.oftc.net 1186373151 Q * tam cation.oftc.net charon.oftc.net 1186373151 Q * mugwump cation.oftc.net charon.oftc.net 1186373151 Q * hallyn_ cation.oftc.net charon.oftc.net 1186373151 Q * ntrs_ cation.oftc.net charon.oftc.net 1186373151 Q * Hollow cation.oftc.net charon.oftc.net 1186373151 Q * emtty cation.oftc.net charon.oftc.net 1186373151 Q * gdm cation.oftc.net charon.oftc.net 1186373151 Q * dilinger cation.oftc.net charon.oftc.net 1186373151 Q * neuralis cation.oftc.net charon.oftc.net 1186373151 Q * mattzerah cation.oftc.net charon.oftc.net 1186373151 Q * Aiken cation.oftc.net charon.oftc.net 1186373151 Q * hardwire cation.oftc.net charon.oftc.net 1186373151 Q * bored2sleep cation.oftc.net charon.oftc.net 1186373151 Q * er cation.oftc.net charon.oftc.net 1186373151 Q * Johnnie cation.oftc.net charon.oftc.net 1186373151 Q * quasisane cation.oftc.net charon.oftc.net 1186373151 Q * yoh cation.oftc.net charon.oftc.net 1186373151 Q * micah cation.oftc.net charon.oftc.net 1186373225 J * jmp_ ~jmp@Montreal.safe.ca 1186373225 J * DoberMann_ ~james@AToulouse-156-1-53-51.w90-16.abo.wanadoo.fr 1186373225 J * FireEgl FireEgl@Sebastian.Atlantica.US.TO 1186373225 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net 1186373225 J * FloodServ services@services.oftc.net 1186373225 J * emtty ~eric@dynamic-acs-24-154-34-241.zoominternet.net 1186373225 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net 1186373225 J * balbir_ ~balbir@122.167.74.154 1186373225 J * Vudu ~vudumen@perverz.hu 1186373225 J * eyck_ ~eyck@nat.nowanet.pl 1186373225 J * coderanger ~coderange@c-65-96-210-168.hsd1.ma.comcast.net 1186373225 J * er ~yakker@aegis.CS.Princeton.EDU 1186373225 J * Guy- VpFTQTAnHs@chardonnay.math.bme.hu 1186373225 J * Hollow ~hollow@proteus.croup.de 1186373225 J * Greek0 ~greek0@85.255.145.201 1186373225 J * zLinux ~zLinux@88.213.32.248 1186373225 J * brcc_ bruce@72.20.27.65 1186373225 J * bored2sleep ~bored2sle@66.111.53.150 1186373225 J * yoh ~yoh@ravana.rutgers.edu 1186373225 J * Loki|muh loki@satanix.de 1186373225 J * pyquila gerbens@82.94.222.35 1186373225 J * hardwire ~bip@216.152.176.9 1186373225 J * mattzerah ~matt@121.50.222.55 1186373225 J * ntrs_ ntrs@68-188-55-120.dhcp.stls.mo.charter.com 1186373225 J * gdm ~gdm@www.iteration.org 1186373225 J * quasisane ~user@c-75-67-252-184.hsd1.nh.comcast.net 1186373225 J * hallyn_ ~xa@adsl-75-0-152-82.dsl.chcgil.sbcglobal.net 1186373225 J * micah ~micah@micah.riseup.net 1186373225 J * dilinger ~dilinger@mail.queued.net 1186373225 J * neuralis ~krstic@solarsail.hcs.harvard.edu 1186373225 J * mugwump ~samv@watts.utsl.gen.nz 1186373225 J * tam ~tam@gw.nettam.com 1186373276 Q * jmp_ Quit: Leaving 1186373285 J * jmp_ ~jmp@Montreal.safe.ca 1186373752 Q * jmp_ Quit: Leaving 1186374716 J * jmp_ ~jmp@Montreal.safe.ca 1186376991 J * al ~al@72.24.65.244 1186377043 Q * al Quit: Leaving 1186377676 Q * jmp_ Quit: Leaving 1186378475 J * jmp_ ~jmp@Montreal.safe.ca 1186378475 Q * jmp_ 1186378924 J * jmp_ ~jmp@Montreal.safe.ca 1186378934 M * jmp_ \help 1186378940 Q * jmp_ 1186379225 N * DoberMann_ DoberMann 1186381396 J * DavidS ~david@p57A4A46B.dip0.t-ipconnect.de 1186381424 J * sharkjaw ~gab@158.36.44.106 1186382169 N * DoberMann DoberMann[PullA] 1186382777 J * dna ~dna@190-238-dsl.kielnet.net 1186383581 N * Bertl_oO Bertl 1186383589 M * Bertl morning folks! 1186383860 Q * emtty Ping timeout: 480 seconds 1186383890 M * DavidS morning! 1186383936 M * Bertl hey! how's going? 1186384670 M * DavidS i'm going to Vechta today and to vienna in 3 days :) 1186384670 M * DavidS now i have to pack up everything (once again) :) 1186384741 M * Bertl how much is 'everything'? 1186384797 M * Bertl bXi: if you are around, the first 'prototype' is already available, although I'm sure it will have some issues 1186384989 J * yarihm ~yarihm@whitehead2.nine.ch 1186385165 M * Bertl wb yarihm! 1186385360 M * DavidS Bertl: one suitcase and one backpack (with all the electronics) 1186385421 M * DavidS and it seems like my server just did on me :-( 1186385421 M * bXi Bertl: cool i'll try it out later today 1186385447 M * DavidS Bertl: how was your weekend? 1186385688 M * Bertl well, a lot of fun (work) ... 1186385782 M * DavidS ah, i know that feeling :) I worked a bit on shorewall puppetization 1186385797 M * Borg- moin 1186386145 J * friendly12345 ~friendly@ppp121-44-229-67.lns2.mel4.internode.on.net 1186386337 M * Bertl wb friendly12345! 1186386895 M * yarihm hi everyone 1186387241 J * ktwilight_ ~ktwilight@159.109-66-87.adsl-dyn.isp.belgacom.be 1186387584 Q * ktwilight Ping timeout: 480 seconds 1186388632 J * Baby ~miry@195.37.62.208 1186388641 Q * Baby 1186388651 J * Baby ~miry@195.37.62.208 1186388705 J * ktwilight ~ktwilight@159.101-66-87.adsl-dyn.isp.belgacom.be 1186389089 Q * ktwilight_ Ping timeout: 480 seconds 1186389169 Q * Johnnie Ping timeout: 480 seconds 1186389401 M * Bertl wb Baby! 1186389693 Q * balbir_ Read error: Connection reset by peer 1186389767 J * fs fs@213.178.77.98 1186389772 M * Bertl wb fs! 1186390400 A * bXi hates these easy to build websites 1186390410 M * bXi especially the fact that i need to use joomla 1186390438 M * Bertl sounds like java and tastes slow, what is it? 1186390459 M * bXi its a php based cms 1186390503 M * Bertl hmm, shouldn't be too slow then ... 1186390508 N * ensc Guest98 1186390518 J * ensc_ ~irc-ensc@p54B4E733.dip.t-dialin.net 1186390536 M * bXi their doing a rewrite of it because the 1.0.x series is to slow 1186390542 M * bXi but the new version isnt stable yet 1186390548 N * ensc_ Guest99 1186390555 M * bXi i'm writing my own cms system 1186390599 Q * FloodServ synthon.oftc.net services.oftc.net 1186390626 Q * Guest98 Ping timeout: 480 seconds 1186390641 M * bXi oh and joomla is very inconveniant for the enduser 1186390783 J * balbir ~balbir@122.167.72.133 1186390801 M * Bertl that probably helps with the distribution (see M$ products) 1186390995 M * bXi oh btw 1186391018 M * bXi the vmware modules compile correctly with 2.6.21.6-vs2.2.0.3.ipv6 1186391170 J * FloodServ services@services.oftc.net 1186391625 J * Piet ~piet@tor.noreply.org 1186392050 Q * wenchien Ping timeout: 480 seconds 1186392301 Q * zLinux Remote host closed the connection 1186392428 J * Supaplex supaplex@166-70-62-199.ip.xmission.com 1186392439 M * Supaplex hiya Bertl 1186392450 M * Bertl hey Supaplex! 1186392461 A * Supaplex checks the wiki for host stdout | guest stdin tricks 1186392530 J * meandtheshell ~markus@85.127.109.10 1186392552 M * Supaplex I think I'll just netcat out. duh! :) 1186392567 M * Bertl good approach 1186393094 M * Supaplex so far so good. 1186393119 M * Supaplex manage-restore:/restore# netcat riddle 38901 | restore rf - 1186393167 M * Bertl hmm, which one is inside the guest? 1186393205 M * Bertl (the data or the restore?) 1186393214 M * Supaplex restore 1186393285 M * Bertl probably not the best idea, any reason for not doing that on the host? 1186393355 M * Supaplex I'm trying to recover some system scripts that were known to work 24hours before this backup was captured, and fail sometime 12 days later. (it's the oldest I have) 1186393469 M * Supaplex this guest is minutes old. the restore man page makes me a little awry 1186393490 M * Bertl I would not expect restore to work properly inside a guest 1186393511 M * Bertl it does low level filesystem access so it should be blocked 1186393526 M * Supaplex it's working so far. it yells about some device nodes, but I'm not worried about those. 1186393881 M * harry is centos a good "base system" for vserver guests? 1186393938 M * bXi Bertl: how much were those speed increases with 64bit again? 1186394011 M * Bertl really depends on what you are doing, but you can expect 2-3 on most arithmetics 1186394041 M * Bertl of course, doesn't help much with cache or page faults :) 1186394338 M * bXi its mostly apache/mysql 1186394366 M * Bertl well, should benefit from the adress space, I think 1186394383 M * bXi i'm going to try and get 2 60gb disks or so 1186394392 M * bXi fix software raid 1186394402 M * bXi and reinstall gentoo but with 64bit this time 1186394464 Q * virtuoso Remote host closed the connection 1186394496 J * virtuoso ~s0t0na@80.253.205.251 1186395043 J * arcil ~arcil@p5B076EB7.dip.t-dialin.net 1186395076 M * bXi or 2 40gb disks as the case may be 1186395080 Q * yarihm Quit: Leaving 1186395227 J * lilalinux ~plasma@dslb-084-058-213-207.pools.arcor-ip.net 1186396117 J * bzed ~bzed@10-205-116-85.dsl.manitu.net 1186396541 Q * lilalinux Remote host closed the connection 1186396636 J * rgl ~rgl@84.90.10.107 1186396642 M * rgl morning guys! 1186396750 M * Bertl morning rgl! 1186396953 M * Borg- yo Bertl 1186396959 M * Borg- any news w/ that UDP loopback? :) 1186396964 M * rgl Bertl, I finally got KVM working with NATed network :) 1186397065 M * Bertl great! 1186397086 M * Bertl Borg-: there is a 'new' network stack version in 2.3.x 1186397104 M * Bertl Borg-: if you are bold, you could test that 1186397160 M * rgl Bertl, where can I read about the new stack of 2.3? 1186397161 Q * Piet Ping timeout: 480 seconds 1186397198 M * Bertl basically in the source code :) 1186397218 J * Piet ~piet@tor.noreply.org 1186397218 M * Bertl but stack is the wrong term here, actually, it should be caqlled isolation mechanism 1186397247 M * rgl caqlled? :D 1186397254 M * Bertl *called 1186397259 M * rgl ah sorry. 1186397309 M * Bertl typing on three keyboards here atm, and all of them are not aligned :) 1186397356 A * rgl .oO{ Bertl is an octopus! } 1186397396 M * Bertl now you know what _oO means :) 1186397440 M * rgl thinking? 1186397455 M * Bertl nah, Operation Octopus :) 1186397465 M * rgl ahaha 1186397541 M * Loki|muh lol :) 1186397612 M * Bertl btw, that one didn't come from me, it was somebody (I don't remember) who suggested that as explanation for Bertl_oO :) 1186398128 M * rgl *G* 1186398842 Q * virtuoso Ping timeout: 480 seconds 1186399541 J * virtuoso ~s0t0na@80.253.205.251 1186400043 Q * virtuoso Quit: leaving 1186401026 Q * sharkjaw Quit: Leaving 1186401031 J * gerrit ~gerrit@dslb-084-060-210-155.pools.arcor-ip.net 1186401381 Q * DavidS Quit: Leaving. 1186401640 Q * pyquila Remote host closed the connection 1186402383 Q * Aiken Remote host closed the connection 1186402556 J * jmp_ ~jmp@Montreal.safe.ca 1186402586 M * jmp_ Herbert, are you on line? 1186402594 M * Bertl yup 1186402623 M * jmp_ Jack on me are working on the loop back and we come up 1186402628 M * jmp_ we 2 solutions, 1186402633 M * jmp_ (with) 1186402651 M * Bertl well, there already is a solution, as I told you yesterday 1186402661 M * jmp_ I am implementing mine and I would like to check with you what think about it 1186402675 M * jmp_ (coding so fare seems not that extended) 1186402680 M * jmp_ NO! 1186402687 M * jmp_ this is Brikolage 1186402699 M * Bertl Brikolage? 1186402724 M * jmp_ a solution which is working by "duct tape" 1186402730 M * Bertl not really 1186402761 M * jmp_ Solution currently implemented is too much restrictive 1186402767 M * Bertl how so? 1186402813 M * jmp_ Let say IN want to simulate a network within the host (to check ifdifferent component are 1186402818 M * jmp_ working together) 1186402820 Q * mugwump Quit: Reconnecting 1186402823 J * mugwump ~samv@watts.utsl.gen.nz 1186402848 M * Bertl I mean, feel free to implement your approach (whatever it may be) and show that it is superior to what we have right now ... 1186402852 M * jmp_ lets say I am working with 100 "terminal server" and I want to check if 1186402879 M * jmp_ packet are properly recoginsed (revers address) 1186402949 M * jmp_ I just need to say (on a standard host) term01 bind to 127.X.X.1 up to term100 bind to 127.X.X.100 1186402976 M * jmp_ I do NOT need define the localloop 1186402983 M * Bertl but why would you do that? 1186402997 M * jmp_ and reverse address are working this IS by design on the LOOPBACK 1186403025 M * jmp_ (you asked me why current solution is too restrictive) 1186403063 M * Bertl look, if you like to that, you can simply assign the 127.X.X.1-100 to the guest, and it will work just fine 1186403065 M * jmp_ because I want to check if a specific software ia able to handle a big network without 1186403071 M * jmp_ have external network 1186403086 M * jmp_ NO! 1186403090 M * Bertl yes! 1186403093 M * jmp_ reverse address IS NOT WORKING 1186403128 M * jmp_ so I can't see from where the packet is working 1186403143 M * jmp_ (coming) 1186403145 M * Bertl look, get netcat and make an example of what you consider essential and doesn't work 1186403224 M * jmp_ It won't show up at the netcat level because of specific loopback behaviour 1186403233 M * jmp_ not implemented in vserver 1186403253 M * Bertl hmm? so netcat cannot show what you describe as problem? 1186403268 M * Bertl but we agree that netcat covers _all_ of IP, yes? 1186403278 M * jmp_ (told you 18 month++ ago) 1186403279 M * jmp_ NO! 1186403284 M * jmp_ not for the loopback 1186403308 M * jmp_ try this (NOT on a vserver) 1186403312 M * Bertl so netcat specifically treats the loopback device badly :) 1186403321 M * jmp_ NO 1186403330 M * jmp_ (problem is NOT at netcat level) 1186403343 M * jmp_ try this on a standard host 1186403356 M * jmp_ nc -l 127.12.13.14 1234 1186403374 M * jmp_ you CAN do it whitout defining the interface 1186403379 M * Bertl sure 1186403389 M * Bertl try the same in a guest with 127.12.13.14 assigned 1186403418 M * jmp_ not only that, but packet sent from that connection will be seen as comming 1186403424 M * jmp_ from 127.12.13.14 1186403438 M * Bertl so it will be on the guest with 127.12.13.14 assigned 1186403468 M * jmp_ I am (may be) may be missing a point 1186403471 M * sid3windr :) 1186403483 M * jmp_ but you can't do it without specifying the interface 1186403491 M * Bertl what? 1186403500 M * jmp_ in vserver 1186403505 M * Bertl huh? 1186403524 M * jmp_ do you have a standard host in front of you? yes sure 1186403535 M * Bertl you are completely wrong there, the Linux-VServer kernel does not even allow you to set an interface for the assigned ips 1186403542 M * jmp_ try nc -l 127.X.Y.Z aaaa 1186403559 M * Bertl jmp_: I know that this works 1186403574 M * jmp_ it this working on vserver? 1186403579 M * Bertl jmp_: nothing new in the last few years there 1186403595 M * Bertl yes it works if, and only if you assign that ip to the guest 1186403607 M * Bertl that is what IP isolation is about 1186403609 M * jmp_ You are missing my point 1186403624 M * Bertl you are not making any 1186403643 M * jmp_ 1) you need to specify the interface in the vserver 1186403645 M * jmp_ right? 1186403647 M * Bertl nope 1186403661 M * jmp_ 2) is the reverse address seen? 1186403663 M * Bertl it is IP isolation, not interface virtualization 1186403677 M * Bertl what is the 'reverse address' you are talking about? 1186403683 M * jmp_ Ha!!! 1186403683 M * Bertl the peer address? 1186403685 M * daniel_hozac getsockaddr, i guess. 1186403694 M * Bertl yes, that is seen correctl 1186403695 M * Bertl +y 1186403705 M * jmp_ no 1186403713 M * Bertl morning daniel_hozac! 1186403717 M * daniel_hozac morning Bertl 1186403755 M * jmp_ what I am saying 127.0.0.0/8 is INTERNAL to the host and application 1186403767 M * Bertl correct, so is any 'local' ip 1186403775 M * jmp_ YES 1186403777 M * harry ?????????? 1186403780 M * harry i don't get it 1186403783 M * harry panic panic!! 1186403791 M * jmp_ but you do NOT need to define the interface! 1186403791 M * harry rpm -qa shows some packages double! 1186403799 M * harry why's that? rpm --rebuilddb doesn't help 1186403807 M * Bertl jmp_: yes, I agree 1186403818 M * daniel_hozac harry: rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' 1186403834 M * daniel_hozac harry: uh, rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n', of course. 1186403836 M * jmp_ I started to implement it (I do not know if this the best methode0 1186403854 M * Bertl jmp_: it looks like we are going in circles 1186403863 M * harry libselinux-1.33.4-2.el5 1186403863 M * harry libselinux-1.33.4-2.el5 1186403863 M * jmp_ problem if we do not agree about the problem valueof the solution is difficult to share 1186403881 M * Bertl jmp_: you are telling me that a) doesn't work, I tell you it works, you tell me that you are working on a solution :) 1186403897 M * harry daniel_hozac: i seem to have 32 and 64 bit versions 1186403906 M * harry is there a reason i should keep both ? 1186403918 M * daniel_hozac if you want to run 32-bit binaries, you'll need 32-bit libs. 1186403924 M * jmp_ Ok, may be I am missing a point 1186403935 M * jmp_ let me ask you a simple question 1186403941 M * Bertl go ahead 1186403943 M * jmp_ on the the guest 1186403947 M * jmp_ I can do 1186403951 M * harry aha 1186403952 M * harry tnx 1186403960 M * jmp_ nc -l 127.X.Y.Z aaaa 1186403967 M * Bertl yes 1186403971 M * jmp_ without ever defining the interface 1186403975 M * Bertl yes 1186403999 M * jmp_ on the vserver I need to define it 1186404000 M * jmp_ ? 1186404004 M * Bertl yes 1186404024 M * jmp_ yes? I need to define it?? 1186404037 M * Bertl correct, otherwise it will not be available for binding 1186404044 M * daniel_hozac not the interface. 1186404047 M * daniel_hozac just the address. 1186404064 M * jmp_ Ok, agree lets use the proper word 1186404080 M * jmp_ on the guest I do not need to specify the address 1186404095 M * jmp_ I need to do it on the vserver 1186404110 M * Bertl vserver is slang for guest 1186404117 M * Bertl the machine is called host 1186404155 M * jmp_ (OK no address on host, address needed on vserver) 1186404158 M * jmp_ do we agree? 1186404158 M * Bertl if you want your guest xy to use 127.x.y.z 1186404181 M * Bertl then you have to tell the kernel, via syscall, that 127.x.y.z is part of that network context. period 1186404184 M * Bertl . 1186404193 M * jmp_ not only 127.x.y.z 1186404206 M * Bertl you do neither have to assign it to an interface or whatever 1186404236 M * jmp_ let me explain with a real application 1186404239 M * jmp_ sendmail 1186404253 M * jmp_ sendmail use 127.0.0.1 1186404267 M * Bertl typically 1186404271 M * jmp_ which is set relayable inside. 1186404299 M * jmp_ but I can have sendmail to listen on 127.x.y.z 1186404309 M * jmp_ and taht won't be relayable 1186404324 M * jmp_ so If ask a question about an Email to sendmail 1186404336 M * jmp_ answer will quite differenet if I ask the question 1186404349 M * jmp_ on 0.0.1 or x.y.z 1186404351 M * harry Bertl: is there an easy way to share data over different virtual servers? 1186404359 M * daniel_hozac harry: bind mounts 1186404365 M * harry tnx 1186404372 M * harry that works cross context too then? ;) 1186404374 M * harry nice :) 1186404379 M * harry rw i hope? 1186404384 M * Bertl jmp_: correct, works in a Linux-VServer guest the same as on the host 1186404416 M * jmp_ correct me if wrong 1186404426 M * jmp_ suppose now I have 1186404446 M * jmp_ 2 vservers same sendmail config (which is the vserver purpose) 1186404472 M * jmp_ I can't use the same 127.x.y.z 1186404473 M * jmp_ ? 1186404502 M * Bertl no, you cannot (atm) but you will be able to do so (within certain limits) in the near future 1186404533 M * Bertl but, if you hardcode your sendmail to an ip address (the public one) the same is true 1186404539 M * jmp_ ok, so we start to understand each other 1186404575 M * jmp_ no suppose I have a application which user 127.X.Y.[1-30] 1186404613 M * jmp_ (or more), I will be very limited to the number of vserver I have because of the 1186404618 M * Bertl daniel_hozac: please let me know when there is a tool version utilizing the new ipv6 ABI 1186404629 M * jmp_ interface "alias" limitation. 1186404641 M * Bertl jmp_: we do not use interface aliases anymore 1186404650 M * jmp_ 2 sec 1186404659 M * jmp_ we are out of power her 1186404661 M * jmp_ storm 1186404665 M * jmp_ I need take care 1186404901 M * Bertl daniel_hozac: ah, did you get a look at the 2.3 code yet? 1186404971 M * Bertl daniel_hozac: it is still missing some minor virtualizations and checks, but IMHO it is a great improvement over the old code 1186405284 Q * jmp_ Ping timeout: 480 seconds 1186405534 M * daniel_hozac Bertl: i've started reading through the diff, looks good thus far. 1186405558 M * Bertl please ask when something looks fishy or missing 1186405580 M * Bertl the code is not really perfect yet, so there will be some issues 1186405678 M * daniel_hozac if you want, we could move to the add_match interface right away. 1186405706 M * daniel_hozac i haven't gotten too far yet, but i assume IPv6 is made a boolean? 1186405747 M * Bertl well, I think we can get almost the same effect without adding a lot of (new) code right now (like the match interface) 1186405777 M * Bertl but I would appreciate support for the address range and mask settings with the normal add interface (v1) 1186405790 M * Bertl (which can be considered a very simple form of the match tree) 1186405791 M * daniel_hozac okay. 1186405822 M * Bertl thus we can test and stabilize that first, then we can improve on the matching performance 1186405844 M * Bertl I guess that will also give a few ideas how to make the match trees more intuitive 1186405979 M * Bertl ad ipv6, you mean the checks are address only for ipv6? if so, yes 1186405995 M * daniel_hozac well, i meant CONFIG_IPV6. 1186406005 M * Bertl ah, yeah, right, that too 1186406019 M * Bertl didn't want to bother with ipv6 a module 1186406021 M * Bertl *as 1186406043 M * Bertl personally I do not see a point in that anyway, except for distros 1186406064 M * Bertl (but we will probably add that lateron) 1186406082 J * arachnist arachnist@088156185052.who.vectranet.pl 1186406097 M * Bertl wb arachnist! 1186406769 M * Bertl daniel_hozac: if I want to make a few test guests, the fastest way would be: build, unify, hashify, clone, clone, clone ... yes? 1186406888 M * daniel_hozac s/unify//, i'd say so. 1186406906 M * Bertl ah, vhashify doesn't need the vunify anymore? 1186406929 M * bXi yoyo 1186406957 M * daniel_hozac vhashify just reuses the configuration. 1186406974 M * Bertl yes, but how to get that? 1186406988 M * daniel_hozac if you install using the util-vserver specfile, everything should be set up for you. 1186407013 M * daniel_hozac just mkdir -p /etc/vservers//apps/vunify 1186407017 M * Bertl excellent, is that true for the rpms you built in priceton? 1186407036 M * bXi does this experimental patch include ipv6? 1186407049 M * Bertl yep 1186407053 M * daniel_hozac yeah, it's just a -tb. 1186407128 M * Bertl bXi: but you probably need to update the tools or configure it manually 1186407183 M * bXi hmmm 1186407896 M * harry daniel_hozac: what dietlibc should i use? 1186407901 M * harry i have a centos 5 host 1186407971 M * daniel_hozac rebuilding the FC6 RPM should be fine. 1186407980 M * harry fc6? 1186407995 M * harry why not 7 ? 1186408008 M * daniel_hozac because RHEL5 is based on FC6. 1186408035 M * daniel_hozac though the FC6 and F7 source RPMs should be identical, AFAIK. 1186408043 M * harry http://linux-vserver.org/Installation_on_CentOS 1186408046 M * harry then that should be changed 1186408050 Q * FireEgl Ping timeout: 480 seconds 1186408151 M * daniel_hozac i plan on changing that as soon as i've got a build of "our" tree, i give up on building that, or dietlibc shows up in EPEL. 1186408163 J * jmp_ ~jmp@Montreal.safe.ca 1186408172 M * Bertl wb jmp_! 1186408196 M * jmp_ Bonjour, sorry some system were shutdown (none critcal one) 1186408205 M * jmp_ and I made sure everything was fine. 1186408218 M * jmp_ ok... 1186408241 M * jmp_ I started to implement something to resolve the 127.0.0.0/8 issue 1186408250 M * jmp_ hoppefully it is not too dummy 1186408250 M * Bertl great! :) 1186408257 M * jmp_ basically is to say 1186408290 M * jmp_ for 127.0.0.0/8 (IN_LOOPBACK(a)) lets say the port number 1186408312 M * jmp_ is "port number" + nx_id<<16 1186408347 M * daniel_hozac what happens if i bind to port 32000? 1186408360 M * sid3windr the dungeon collapses. you die. 1186408365 M * jmp_ this way all vservers will have the full loopback range and vserver 1186408369 M * jmp_ reade me again 1186408381 M * jmp_ I now port number is short 1186408386 M * jmp_ (kown) 1186408414 M * sid3windr (know) 1186408419 M * jmp_ :-}} 1186408430 M * Bertl that's canadian for know :) 1186408434 M * jmp_ :-}}}}} 1186408441 M * jmp_ (french canadian) 1186408450 M * jmp_ Anyway 1186408468 M * jmp_ I gamble with the idea to move port from short to int 1186408503 M * jmp_ but better to add the nx_id near the port number in the structure 1186408516 M * Bertl in what structure? 1186408521 M * jmp_ 2 sec 1186408531 M * jmp_ give you the info 1186408554 A * Bertl .oO( hmm, those french canadians always take longer ... 2sec instead of 1 :) 1186408580 M * arachnist .oO( those french canadians are more realistic ) 1186408608 A * daniel_hozac .oO( i can think too! ) 1186408620 M * jmp_ include/net/inet_hashtables.h 1186408626 M * jmp_ struct inet_bind_bucket { 1186408626 M * jmp_ unsigned short port; 1186408626 M * jmp_ nid_t lpb_nx_id; /*loop back NX_ID*/ 1186408626 M * jmp_ signed short fastreuse; 1186408626 M * jmp_ struct hlist_node node; 1186408626 M * jmp_ struct hlist_head owners; 1186408628 M * jmp_ }; 1186408693 J * ema ~ema@rtfm.galliera.it 1186408709 M * jmp_ this means (my guess) we could have 2 127.0.0.2 among 2 vservers but not the same for 1186408711 M * jmp_ the host 1186408712 M * Bertl so you are planning on virtualizing the hash table 1186408736 M * Bertl feel free to do that, I've been there, done that, didn't work as expected :) 1186408757 M * jmp_ good, that is the purpose of my contact 1186408764 M * jmp_ what kind of trouble you got 1186408787 M * Bertl it basically works, but it adds a lot of code and makes everything quite slow, still you have to map in many places (to and from) 1186408793 P * friendly12345 1186408802 M * Bertl finally you lose the ability to track connections from the host 1186408833 M * jmp_ tracking 127.0.0.0/8 from the host is not (IMHO) a concern 1186408969 M * jmp_ beside code implementation(which could be slow) trouble, you seen no pitfall.. right? 1186408999 M * Bertl no, we _know_ that completely virtualized network stacks work too :) 1186409037 M * jmp_ I do not want to reinvent the wheel 1186409091 M * jmp_ if you tell me I can use (lets say) 1600 IP among loopback within a vserver with reverse address than 1186409101 M * jmp_ (then) I'll wait... 1186409137 M * Bertl reverse address is a dubios term in this context 1186409154 M * Bertl we do not have forward addresses as there is no lookup 1186409181 M * Bertl but, as I said, the following is true: 1186409183 M * jmp_ I want to be able to recognise the packet is coming from 127.x.y.z (as within a host actually) while 1186409187 M * jmp_ lo is ONLY 127.0.0.1 1186409195 M * Bertl - the guest/context behaves exactly like the host 1186409206 M * jmp_ on 2.2.0.3???? 1186409209 M * Bertl - the guest/context is limited to a certain subset of IP addresses 1186409254 M * Bertl yes, even 2.0 allows you to assign 127.x.x.x addresses to a guest 1186409289 M * Bertl you will run out of address slots on 2.0/2.2 very soon though, as the limit there is still 16 ips 1186409290 M * jmp_ this is were It seems you are missing the point 1186409327 M * Bertl - no, there is no address or interface virtualization in Linux-VServer :) 1186409336 M * jmp_ on host to bind to 127.3.4.5 I do NOT need to define an interface 1186409351 M * Bertl jmp_: and you do not need to do so in a guest either 1186409365 M * jmp_ ok. 1186409395 M * jmp_ (So I missed the documentation) 1186409409 M * bXi Bertl: after this disc juggeling i'm doing now i'll start installing a 64bit vserver host 1186409417 M * jmp_ let say my vserver has IP number 1186409418 M * Bertl jmp_: you have a 2.2.x system at hand? 1186409426 M * jmp_ 192.219.254.140 1186409437 M * jmp_ 127.0.0.1 is "linked" to it 1186409443 M * jmp_ (yes) 1186409451 M * jmp_ (Yes I have a vserver at hand) 1186409460 M * jmp_ (2.2.0.3) 1186409493 J * Freax ~Linus@bl7-128-2.dsl.telepac.pt 1186409494 M * Bertl chbind --nid 42 --ip 127.1.2.3 -- nc -l 127.1.2.3 1234 1186409510 M * Bertl (make the nc -vvl) 1186409527 M * jmp_ 3 sec 1186409820 M * jmp_ seems I can do 1186409822 M * jmp_ chbind --nid 40045 --ip 127.1.2.3 -- nc -lvvv 127.1.2.3 1234 1186409829 M * jmp_ chbind --nid 40044 --ip 127.1.2.3 -- nc -lvvv 127.1.2.3 1234 1186409860 M * jmp_ (vserver context) 1186409861 M * jmp_ CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1186409862 M * jmp_ 40001 25 359.5M 156.1M 0m04s68 0m00s95 45m45s92 fc7.alardun 1186409862 M * jmp_ 40044 27 358.4M 75M 0m02s68 0m02s25 45m45s81 fc7.demo1 1186409862 M * jmp_ 40045 24 336.9M 69.7M 0m02s23 0m02s18 45m45s89 fc7.demo2 1186409893 M * Bertl sure, just one will time out, IIRC 1186409910 M * Bertl but the idea was not to overlap the IPs 1186409924 Q * Linus Ping timeout: 480 seconds 1186409933 M * daniel_hozac you shouldn't use existing contexts either. 1186409941 M * jmp_ (sure) 1186409949 M * daniel_hozac chbind will just migrate into them, not add the IPs. 1186409949 M * jmp_ (both context was existing) 1186410014 M * jmp_ how many 127.X.Y.Z can I add? 1186410020 M * jmp_ on the same vserver 1186410038 M * jmp_ is the limitation not to have the same number of 2 vservers? 1186410038 M * daniel_hozac 16 IPs per context in 2.2. 1186410059 M * jmp_ out then 1186410073 M * jmp_ sure? 1186410126 M * Bertl with 2.3, you can assign a whole subnet of 127.x.y IPs with a single entry 1186410151 M * jmp_ without collision between vserver or do we 1186410162 M * jmp_ still need to make different range for IP?? 1186410171 M * Bertl if you assigne the same IP they will overlap/collide 1186410182 M * jmp_ Sh..t 1186410191 M * Bertl that is the way how IP _isolation_ works 1186410209 M * jmp_ loopback is a very peticalr set of IP 1186410227 M * Bertl nope, sorry, nothing special there from the ip pov 1186410235 Q * Baby Quit: so sad :( 1186410248 M * Bertl but, we are testing/using a special loopback remap feature 1186410276 M * Bertl and this could easily be used to not only remap 127.0.0.1 (which is what it is doing right now) but also entire ranged 1186410279 M * Bertl *ranges 1186410916 M * Borg- Bertl: so I should download and try vs2.3.0.12 ? 1186410932 M * daniel_hozac 2.3.0.15 1186411181 M * Bertl correct 1186411320 M * Borg- daniel_hozac: I dont see 2.3.0.15 in downloads 1186411323 M * Borg- any SVN repository ? 1186411341 M * Bertl http://vserver.13thfloor.at/Experimental/ 1186411449 M * Borg- thx 1186411646 M * Bertl Borg-: please report any anomalies immediately 1186411704 M * Borg- ok :) I will instal it tomorrow.. 1186411728 M * Borg- so I assume that my little test script now works? 1186411742 M * Bertl actually I haven't tested it yet :) 1186414566 M * jmp_ OK, I recompiled the kernel working around the proposed idea and it seem to be working (at least for the proposed demo test) 1186414598 M * jmp_ telnet 127.0.10.1 1234 1186414598 M * jmp_ Trying 127.0.10.1... 1186414598 M * jmp_ Connected to 127.0.10.1. 1186414598 M * jmp_ Escape character is '^]'. 1186414598 M * jmp_ tsts 1186414600 M * jmp_ this is demo1 1186414601 M * jmp_ wrong this is demo2 1186414606 M * jmp_ nc -l 127.0.10.1 1234 1186414607 M * jmp_ tsts 1186414609 M * jmp_ this is demo1 1186414611 M * jmp_ wrong this is demo2 1186414634 M * jmp_ if I do the same on demo1 (same 127 IP number) 1186414643 M * jmp_ there is no cross leakage 1186414660 M * jmp_ telnet 127.0.10.1 1234 1186414660 M * jmp_ Trying 127.0.10.1... 1186414660 M * jmp_ Connected to 127.0.10.1. 1186414660 M * jmp_ Escape character is '^]'. 1186414660 M * jmp_ abcd 1186414662 M * jmp_ efg 1186414663 M * jmp_ this is demo1 1186414665 M * jmp_ nc -l 127.0.10.1 1234 1186414669 M * jmp_ abcd 1186414671 M * jmp_ efg 1186414673 M * jmp_ this is demo1 1186414714 M * jmp_ this is working on two guest (named demo1 and demo2) on the same host 1186414841 M * Bertl which means? 1186414848 M * jmp_ which means 1186414864 M * jmp_ 1) I can use the FULL class A range without using chbind 1186414894 M * daniel_hozac without using chbind? :) 1186414895 M * jmp_ 2) from the vserver stand point 127.0.0.0/8 is accessible 1186414902 M * jmp_ with right reverse address 1186414920 M * Bertl there is nothing like a 'reverse address' :) 1186414926 M * jmp_ (without chbind --nid 42 --ip 127.1.2.3 -- nc -l 127.1.2.3 1234) 1186414942 M * daniel_hozac so... it works fine on the host, is that what you're saying? 1186414948 M * jmp_ when I am bind on 127.0.10.3 all packet sent are seen as 27.0.10.3 1186414952 M * jmp_ niet 1186414961 M * jmp_ 2 vserver demo1 and demo2 1186414964 M * daniel_hozac so you'd have to call chbind at some point, no? 1186414974 M * jmp_ CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1186414974 M * jmp_ 40001 25 359.4M 156.1M 0m04s58 0m00s73 12m21s13 fc7.alardun 1186414974 M * jmp_ 40044 32 384.5M 81.3M 0m02s30 0m02s10 12m21s14 fc7.demo1 1186414974 M * jmp_ 40045 22 260.3M 52.3M 0m04s44 0m01s80 12m21s14 fc7.demo2 1186414976 M * jmp_ niet 1186414980 M * jmp_ no chbind 1186414988 M * daniel_hozac so then you're not in a network context? 1186414994 M * daniel_hozac thus, on th ehost? 1186415003 M * Bertl probably ... no idea what he is talking about :) 1186415014 M * jmp_ not sure I understand your question 1186415043 M * Bertl jmp_: a normal guest is built of process and network context (and a few other spaces) 1186415063 M * jmp_ I am doing the test within vsrevre 1186415067 M * jmp_ 4 screen open 1186415069 M * Bertl jmp_: thus, by default, you are _inside_ a network context when you use a guest 1186415075 M * jmp_ yes 1186415079 M * jmp_ what I am saying 1186415085 M * daniel_hozac to get there, you have to use chbind :) 1186415086 M * Bertl so that is equivalent to a chbind ... 1186415114 M * jmp_ within the vserver I can use 127.0.0.0/8 on ALL vserver regardless 1186415130 M * jmp_ did you understand my demo 1186415135 M * Bertl nope 1186415146 M * jmp_ 2 screen on demo1 1186415153 M * jmp_ on is with nc 1186415158 M * jmp_ (one with nc) 1186415166 M * jmp_ the other on telnet 1186415172 M * jmp_ message are exchanges 1186415179 M * jmp_ now in same time 1186415188 M * jmp_ 2 others screen on demo2 1186415198 M * jmp_ same ip number 1186415208 M * jmp_ (127.0.10.1) 1186415214 M * jmp_ message are exchange 1186415224 M * jmp_ demo1 messages stay within demo1, 1186415229 M * jmp_ demo2 message stay in demo2 1186415236 M * jmp_ is my explaination better> 1186415237 M * jmp_ ? 1186415253 M * daniel_hozac and you have proven that this doesn't work without your patch? 1186415264 M * jmp_ Yes 1186415278 M * jmp_ I was not able to it before 1186415363 M * Bertl well, that it _doesn_t work with the same ip is intentional, so? 1186415380 M * jmp_ nid_t inet_get_lpb_nx_id(struct sock *sk,__u32 s_addr,char *cmt) 1186415380 M * jmp_ { 1186415380 M * jmp_ nid_t lpb_nx_id; 1186415380 M * jmp_ lpb_nx_id=(nid_t)0; 1186415380 M * jmp_ if ((sk->sk_nx_info!=(struct nx_info *)0)) { 1186415380 M * jmp_ if (IN_LOOPBACK(ntohl(s_addr))==1) 1186415382 M * jmp_ lpb_nx_id=sk->sk_nx_info->nx_id; 1186415384 M * jmp_ printk("JMPDBG inet_get_lpb_nx_id from %s s_addr='%08x' lpb_nx_id='%d'\n", 1186415388 M * jmp_ cmt,s_addr,lpb_nx_id); 1186415390 M * jmp_ } 1186415390 M * Bertl please stop flooding 1186415397 M * jmp_ sorru 1186415400 M * jmp_ sorry 1186415400 M * Bertl use paste.linux-vserver.org 1186415413 M * jmp_ I was just giving you the key subroutine 1186415427 M * jmp_ (not reaaly fluent in chating) 1186415453 M * Bertl now show me how you do the following, with your patch: 1186415468 M * Bertl - inside guest1, bind netcat to 127.1.1.1 1186415480 M * Bertl - on the host, send a message to this guest via 127.1.1.1 1186415492 M * jmp_ it won't work 1186415508 M * jmp_ (tried the same test with nc) 1186415525 M * jmp_ and this is the result I want 1186415538 M * Bertl so, you change the semantics to work as you imagine how it should work 1186415552 M * jmp_ Hummm Hummmm...... 1186415556 M * Bertl well, that is fine with me, but how is that related to mainline Linux-VServer? 1186415568 M * jmp_ I didnt' change the semantic 1186415586 M * jmp_ 127.0.0.0/8 pertain to a server 1186415614 M * Bertl the current semantic is _not_ that 127. is guest private :) 1186415622 J * fatgoose ~samuel@76-10-147-136.dsl.teksavvy.com 1186415649 M * jmp_ on a unix system 1186415669 M * Bertl like bsd or solaris zones? 1186415671 M * jmp_ 127.0.0.0/8 is private to the whole set of application running 1186415683 M * jmp_ this is by design 1186415711 M * Bertl so that must then be noted somewhere in the LSB or the UNIX specification, right? 1186415725 M * jmp_ considere 127.0.0.0/8 as a "possibility" to have many many "host" 1186415760 M * jmp_ such I can say 2 application can share information with the "host" whatever the host is 1186415770 M * jmp_ but not OUTSIDE the box 1186415775 M * jmp_ and a vserver is a BOX 1186415804 M * Bertl well, same is true for any link local IP 1186415825 M * jmp_ no 1186415838 M * jmp_ 127.0.0.0/8 is 1186415841 M * jmp_ loopback 1186415845 M * daniel_hozac s/link local/host local/ 1186415853 M * Bertl tx 1186415880 M * jmp_ there is kernel macro saying to test loopback 1186415882 M * jmp_ IN_LOOPBACK 1186415905 M * Bertl yeah, it's a hack, should have gone away some time ago :) 1186415945 M * jmp_ ok 1186415959 M * jmp_ forget for now vserver , take a plain 1186415961 M * jmp_ host 1186415983 M * jmp_ and do telnet 127.0.12.3 1186415997 M * jmp_ system won't complain about interface missing 1186416040 M * daniel_hozac IN_LOOPBACK isn't even used anywhere, AFAICS. 1186416126 M * jmp_ seems I am not able to explain myself properly 1186416138 M * jmp_ lets take a crude example "sendmail" 1186416153 M * jmp_ if I ask to sendmail to bind on 127.1.2.3 1186416169 M * jmp_ do I need to define an interface 1186416172 M * jmp_ answer no 1186416188 M * Bertl you do not need to define an interface for 10.0.0.1 either :) 1186416189 M * daniel_hozac what does "interface" mean here? 1186416210 M * Bertl I guess I can translate part of this 1186416229 M * jmp_ /sbin/ifconfig lo: 127.1.2.3 up 1186416231 M * Bertl 'define an interface' means, add a host local ip to the lo device 1186416260 M * Bertl and no, you do not need to do that 1186416397 J * Ashsong ~chatzilla@orchard.laptop.org 1186416409 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33 1186416415 M * Ashsong Bertl: greetings. 1186416416 M * jmp_ Bert 1186416422 M * jmp_ I do not confirm 10.0.0.1 1186416430 M * jmp_ I need to specify interface 1186416474 M * jmp_ Aug 6 12:07:39 oka sendmail[5125]: daemon MTA: problem creating SMTP socket 1186416533 Q * rgl Remote host closed the connection 1186416583 M * jmp_ but changing 10.0.0.1 by 127.1.2.3 make sendmail very happy and 1186416599 M * jmp_ it bind on BOTH interface 127.0.0.1 AND 127.1.2.3 1186416635 J * rgl ~rgl@84.90.10.107 1186416700 M * jmp_ but (and we can disagree on this) I beleive vserver should like exactly the same way 1186416737 M * jmp_ as admin of demo1 I should be able to configure sendmail the same way on all vserver 1186416849 M * daniel_hozac but _why_ would you bind sendmail to some random 127.x.y.z address instead of 127.0.0.1? 1186416870 M * jmp_ Ok, this is the good question 1186416881 M * jmp_ it is NOT instead of 127.0.0.1 1186416889 M * jmp_ it is beside 127.0.0.1 1186416897 M * jmp_ but the the application stand point 1186416912 M * jmp_ packet received on 127.1.2.3 are handle 1186416921 M * jmp_ the same way as 127.0.0.1 1186416945 M * jmp_ ie Email submited on 127.0.0.1 are relayble (by config) 1186416960 M * jmp_ the one on 127.1.2.3 are not 1186416994 M * jmp_ (typing too quickly) 1186417008 M * jmp_ packet received on 127.1.2.3 are NOT handle 1186417324 J * gerrit_ ~gerrit@208.78.239.161 1186417987 M * daniel_hozac so what's the point? 1186418008 M * daniel_hozac anything that can send to 127.1.2.3 can send to 127.0.0.1. 1186418048 M * jmp_ no, I'll try to explain again typing more slowly 1186418064 M * jmp_ from the application stand point (sendmail as an example) 1186418104 M * jmp_ 127.0.0.1 and 127.1.2.3 are not alike at all 1186418123 M * jmp_ 127.0.0.1 will imply (relay A-mail received from Here) 1186418143 M * jmp_ 127.1.2.3 will say (do not relay E-mail) 1186418149 M * jmp_ this is an example 1186418150 M * daniel_hozac but what i'm saying is, this is not interesting use-case. 1186418168 M * daniel_hozac if something wants to relay email, it'll send to 127.0.0.1. 1186418181 M * jmp_ :-}}}}} please read me again 1186418222 M * daniel_hozac i did. 1186418230 Q * arcil Quit: Leaving 1186418246 M * jmp_ lets continue with sendmail (it is just an example) 1186418263 M * daniel_hozac if you can come up with an interesting use-case, sure. 1186418298 M * jmp_ I could ask to sendmail is this E-mail for you or is this an external E-mail 1186418306 M * jmp_ from the sendmail stand point 1186418332 M * jmp_ if I ask on 127.0.0.1 it will tell ok (Ready to relay anyway) 1186418348 M * jmp_ on 127.1.2.3 it will say no (I cant' take care of it) 1186418350 M * Bertl and if you ask on the public, ip it will work as normal 1186418370 M * Bertl s/public, ip/public ip/ 1186418373 M * daniel_hozac but _what_ would use 127.1.2.3? 1186418402 M * daniel_hozac to me it seems like the argument you're making is "i want this 'cuz it's pretty". 1186418413 M * jmp_ NO 1186418437 M * jmp_ I want this because I it a standard feature on unix host 1186418451 M * Bertl so it has to be part of a 'standard' no? 1186418455 M * jmp_ and a vserver is a virtual unix host 1186418468 M * Bertl so the first thing would be to _show_ us that standard 1186418491 M * jmp_ Once again 1186418510 M * jmp_ is the sendmail example about 127.1.2.3 versus 10.0.0.1 1186418513 M * daniel_hozac and then show us why it's an interesting/useful feature, which would enable things that weren't possible before. 1186418516 M * jmp_ meaningful for you 1186418558 M * Bertl yes, of course, we can always talk about stuff which obviously is _useful_ for a larger community 1186418592 M * jmp_ Let be straight here 1186418601 M * Bertl because you are using 127.1.2.3 instead of to communicate with your sendmail, doesn't make it an useful feature, does it? 1186418682 M * jmp_ I want 127.0.0.0/8 virtualised , 1186418688 M * jmp_ I Impleted it 1186418715 M * jmp_ (need to be double check) but first it does what is requested 1186418719 M * Bertl okay, I want a million dollars :) 1186418723 M * jmp_ No 1186418727 M * jmp_ I do not care 1186418735 M * Bertl you are better off than me, you can virtualize your 127. :) 1186418782 M * jmp_ you are still a young man bert :-}}} 1186419257 M * Bertl thanks for the flowers :) 1186419308 M * jmp_ sorry about this :-} but 1186419327 M * jmp_ seems to me 127.0.0.0/8 is an issue for a long time now 1186419353 M * jmp_ I propose you a solution (may be not the best) 1186419368 M * daniel_hozac to be honest, i don't see the issue. 1186419411 M * Bertl jmp_: feel free to provide patches for your solution 1186419411 M * jmp_ the mix-up (in your minds) between 1270.0.1 and public ip 1186419433 M * jmp_ what is the procedure? 1186419463 M * daniel_hozac upload it or send it to the mailing list... 1186419478 M * Bertl we can link it on the wiki too 1186419479 M * jmp_ and do agree if we fully "virtualize" 127.0.0.0/8 this will be a good idea? 1186419490 M * Bertl nope, not a good idea :) 1186419519 M * daniel_hozac you have yet to show _why_ 127.x.y.z is better than 127.0.0.1. 1186419541 M * jmp_ 127.x.y.z is NOT better 1186419541 M * Bertl (or ) 1186419584 M * Bertl jmp_: look, by now, I think I know exactly what you mean 1186419585 M * daniel_hozac even works. 1186419613 M * jmp_ ok, then ok I can give more information 1186419613 M * Bertl jmp_: but, AAMOF, I do not see any real world case which would actually 'require' it 1186419629 M * jmp_ I have here an example in front of me 1186419635 M * Bertl jmp_: more than that, I see that it adds unnecessary overhead and confusion 1186419648 M * jmp_ lets say I want to simulate a huge network from the application stand point 1186419703 M * jmp_ I define 2000 terminal server with number within 127.0.0.0/8 1186419721 M * jmp_ and I have a 200 small application generatic traffic 1186419742 M * Bertl terminal server is what? a telnetd? 1186419756 M * jmp_ I can see if each terminal is properly recognize (from the traffic stand point) and if everythin 1186419812 M * jmp_ a terminal server is a where Internet connection are handle (cisco, etc..) 1186419836 M * Bertl so a serial console reachable via telnet or so 1186419840 M * jmp_ those a generating accounting traffic (Radius protocol) 1186419878 M * jmp_ within the radius protocol identification is done (partly) via the orignating 1186419879 M * jmp_ IP 1186419942 M * jmp_ lets say a terminal server is reporting who connect/disconnect (but not the user traffic) 1186419966 M * jmp_ and you could have many treminal server handling many connection 1186419997 M * jmp_ using a 127.0.0.0/8 is a way to "simulate" traffic 1186420030 M * Bertl well, using 10.0.0.0/16 too :) 1186420065 M * Bertl shouldn't we then virtualize 10.0.0.0/16 too? 1186420073 M * jmp_ no 1186420094 M * jmp_ 127.0.0.0/8 do NOT have the same defintion neither purpose 1186420124 M * jmp_ than 192.168.0.0/16 10.0.0.0/8 172.16.0.0/16 1186420135 M * Bertl per _your_ definition in _your_ case :) 1186420170 M * jmp_ 127.0.0.0/8 is to exchange data among a server program 1186420174 M * jmp_ using IP instead socket 1186420198 M * jmp_ 127.0.0.0/8 is not intended to go outside 1186420276 M * jmp_ is my explaination better? 1186420301 M * Bertl still doesn't provide a reason to virtualize it 1186420345 M * Bertl besides the fact that you didn't show the standard stating that 'every unix system has to handle that this way' 1186420351 M * jmp_ lets see this another way 1186420393 M * jmp_ can application on two vserver exchange data via sockets??? 1186420398 M * daniel_hozac yes. 1186420419 M * daniel_hozac both IP and UNIX :) 1186420472 M * jmp_ Not very familiar with socket, but how the socket information is exchanged 1186420475 M * jmp_ ? 1186420516 M * jmp_ how vserver1:application1 know about the socket open on vserver2:application2? 1186420549 J * Baby ~miry@195.37.62.208 1186420943 M * jmp_ did I say a bad word? 1186420993 M * Bertl hmm, I'm having troubles to make bind9 behave ... does anybody have a good contact/irc channel for special bind questions? 1186422241 Q * balbir Ping timeout: 480 seconds 1186422747 Q * ema Read error: Connection reset by peer 1186423274 Q * coderanger Remote host closed the connection 1186423343 J * balbir ~balbir@122.167.81.121 1186423524 J * coderanger ~coderange@c-65-96-210-168.hsd1.ma.comcast.net 1186423884 N * DoberMann[PullA] DoberMann 1186423924 M * daniel_hozac jmp_: how does it know it for IP? 1186423941 M * daniel_hozac jmp_: there really aren't any significant differences. 1186424007 M * daniel_hozac Bertl: i don't think the ISC people use IRC... 1186424319 M * Bertl yeah, unfortunately it seems that I'm unable to get a secure and working setup with bind :/ 1186424449 M * daniel_hozac how so? 1186424493 M * Bertl well, we know that recursion is bad (worldwide) 1186424514 M * Bertl so I'd like to restrict recursion to some specific IPs 1186424631 M * Bertl the problem is, this cannot be done on a per host basis, unless you use 'views' (AFAIK) 1186424654 M * Bertl but with two views, bind9 becomes completely schizophrenic with dynamic updates 1186424682 J * cruser ~chatzilla@72.242.194.162 1186424760 M * jmp_ As I said I am that fluent in sockets but as far I know socket connection is done via a file (which can be in /tmp) 1186424778 M * Bertl daniel_hozac: well, maybe time to abandon bind, and try something else ... 1186424814 M * Bertl okay, off for now ... back later ... 1186424817 M * daniel_hozac jmp_: you can have both named and anonymous sockets, but yes, the named ones are the interesting ones... 1186424820 N * Bertl Bertl_oO 1186424823 M * daniel_hozac Bertl: hehe, may be. 1186425039 M * cruser Hi Does anyone know if/how multiple vguests can share a directory on the virtual host? 1186425061 M * daniel_hozac cruser: bind mounts are your friend. 1186425131 M * cruser daniel_hozac: google "bind mounts" and that should get me going? Thanks. 1186425211 J * onox ~onox@kalfjeslab.demon.nl 1186425213 M * daniel_hozac guess so. 1186425272 M * cruser Thanks 1186425609 Q * quasisane Ping timeout: 480 seconds 1186426942 M * cruser daniel_hozac: mount bind did the trick. Thanks again. 1186427060 M * daniel_hozac you're welcome! 1186427541 M * cruser daniel_hozac: When a vguest is started (init style) on the vhost is it possible to have a script run on the vhost before it boots the guest? 1186427617 M * daniel_hozac like /etc/vservers//scripts/pre-start? 1186427624 M * cruser yes 1186427693 Q * gerrit_ Ping timeout: 480 seconds 1186427796 M * cruser daniel_hozac: Is that it? I put a scripts directory with scripts in the guests root directory? Thanks. 1186427813 M * daniel_hozac in the configuration directory, yes. 1186427863 M * daniel_hozac that is what the flower page says. 1186427877 M * cruser thanks again. 1186428736 M * bXi hmmm 1186428754 M * bXi i wont get much difficulties copying vservers over from a 32bit host to a 64bit host right? 1186428762 M * bXi just have to enable that 32bit personality? 1186428782 M * daniel_hozac yep. 1186428825 M * bXi if this second HD is ok i'll build a 64bit system on a software raid1 array 1186428872 Q * gerrit Ping timeout: 480 seconds 1186429014 M * bXi awww 1186429044 M * bXi hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } 1186429416 Q * Piet Remote host closed the connection 1186429570 J * Piet ~piet@tor.noreply.org 1186429992 Q * jmp_ Quit: Leaving 1186430296 Q * bonbons Ping timeout: 480 seconds 1186430307 J * bonbons ~bonbons@2001:960:7ab:0:20b:5dff:fec7:6b33 1186430460 Q * rgl Quit: Zzzzz 1186432178 P * cruser 1186432526 J * gerrit_ ~gerrit@208.78.239.161 1186433508 Q * bonbons Quit: Leaving 1186433955 M * Supaplex bXi: time for a replacement? :) 1186434212 Q * yoh Quit: Leaving 1186434362 J * Aiken ~james@ppp121-45-255-55.lns2.bne4.internode.on.net 1186434464 Q * dna Quit: Verlassend 1186434892 M * bXi Supaplex: i got a few broken maxtor 40gb's 1186434895 M * bXi trying them 1186434938 M * arachnist i wonder if one could reattach pata drives on the fly when using libata 1186435012 M * arachnist and there's a tool for rescanning scsi stuff under linux... wonder if it would work 1186435042 M * daniel_hozac probably wouldn't be a problem for Linux, not sure about the controllers though... 1186435051 M * Supaplex I don't suggest it either way 1186435089 M * Supaplex granted, I might try the same thing if I knew all the hardware was for expermintation :) 1186435261 Q * Piet Ping timeout: 480 seconds 1186435261 Q * fs Read error: Connection reset by peer 1186435266 J * fs fs@213.178.77.98 1186438389 Q * onox Quit: leaving 1186438638 Q * gerrit_ Ping timeout: 480 seconds 1186438963 J * mountie ~mountie@trb229.travel-net.com 1186438991 Q * opuk Quit: leaving 1186439103 J * opuk ~kupo@213-64-112-143-no19.tbcn.telia.com 1186439819 M * Bertl_oO off to bed ... have a good one everyone! 1186439824 Q * meandtheshell Quit: Leaving. 1186439825 N * Bertl_oO Bertl_zZ 1186440218 M * Supaplex night. :) 1month uptime milestone with my primary vserver. 1186440264 M * Supaplex oddly, only a resize2fs issue on a non vps related filesystem. (might need a reboot *sniffle*) 1186440515 Q * bzed Remote host closed the connection 1186441250 Q * mountie Ping timeout: 480 seconds 1186441366 J * mountie ~mountie@trb229.travel-net.com 1186441533 J * coderanger_ ~coderange@1cc-dhcp-120.media.mit.edu 1186441578 M * coderanger_ Are there F7 kernel RPMs floating around somewhere? 1186441613 M * daniel_hozac with vserver? no. 1186441622 M * daniel_hozac not that i am aware of, at least. 1186441629 A * coderanger_ straps on his kernel boots 1186441641 M * daniel_hozac current F7 kernels have ingo's scheduler, and i really didn't feel comfortable doing that port 1186441732 M * coderanger_ Is there a major reason to use the fedora source over the vanilla? 1186441746 M * coderanger_ This is just running under emulation, so I don't need anything fancy 1186441763 M * daniel_hozac then vanilla should be fine, i guess. 1186441920 M * coderanger_ Are there generic RPMs of some kind I can just use? 1186442040 M * daniel_hozac this is terribly untested at this point, http://rpm.hozac.com/dhozac/centos/5/vserver/SRPMS/kernel-2.6.20.15-vs2.2.0.3.1.src.rpm 1186442054 J * Piet hiddenserv@tor.noreply.org 1186442109 N * DoberMann DoberMann[ZZZzzz] 1186442619 M * coderanger_ daniel_hozac: Thanky