1216772865 J * doener_ ~doener@i577BBDAB.versanet.de
1216772968 Q * doener Ping timeout: 480 seconds
1216775237 Q * NaioN Server closed connection
1216775238 J * NaioN stefan@misc.mordor.unilogicnetworks.net
1216780848 J * Moser_____ ~chatzilla@Ya8f3.y.pppool.de
1216781187 Q * Moser Ping timeout: 480 seconds
1216781188 N * Moser_____ Moser
1216782363 Q * mrjack Ping timeout: 480 seconds
1216783396 N * infotron_ infotron
1216785574 J * hparker ~hparker@linux.homershut.net
1216793558 J * ntrs_ ~ntrs@77.29.76.176
1216793908 Q * infotron Ping timeout: 480 seconds
1216793954 J * infotron ~infotron@166.70.62.200
1216794264 J * dna ~dna@169-192-dsl.kielnet.net
1216794352 Q * infotron Remote host closed the connection
1216794960 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr
1216795526 J * loddafnir ~mike@193.170.138.233
1216796173 N * DoberMann[ZZZzzz] DoberMann
1216799412 Q * FireEgl Read error: Connection reset by peer
1216800154 J * yang yang@yang.netrep.oftc.net
1216801318 J * besonen_mobile ~besonen_m@71-220-224-216.eugn.qwest.net
1216802343 J * yarihm ~yarihm@guest-docking-nat-1-072.ethz.ch
1216802535 J * FireEgl FireEgl@adsl-147-78-95.bhm.bellsouth.net
1216804497 M * matti Morning :)
1216805132 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1216805743 Q * ag- Server closed connection
1216805755 J * ag- ~ag@fedaykin.roxor.cx
1216805755 Q * mrfree Quit: Leaving
1216806650 Q * padde Ping timeout: 480 seconds
1216807364 Q * Aiken Quit: Leaving
1216808117 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1216808589 Q * Wonka Server closed connection
1216808593 J * Wonka produziert@chaos.in-kiel.de
1216809700 J * friendly ~friendly@ppp59-167-145-230.lns4.mel6.internode.on.net
1216809740 J * ktwilight_ ~ktwilight@215.116-66-87.adsl-dyn.isp.belgacom.be
1216809912 Q * Genghis Server closed connection
1216809954 J * Genghis ~Genghis@got.debian-inside.com
1216809981 N * Genghis Guest914
1216809982 Q * ktwilight Ping timeout: 480 seconds
1216810278 J * ntrs__ ~ntrs@77.29.70.130
1216810308 A * arekm trying to run ubuntu hardy guest... somehow init scripts are not run
1216810320 M * arekm  /etc/inittab not there hm 
1216810322 J * kir ~kir@swsoft-msk-nat.sw.ru
1216810323 Q * kir Remote host closed the connection
1216810347 M * daniel_hozac upstart.
1216810429 M * arekm aha, then it doesn't work due to something. It didn't start sshd for example
1216810477 M * daniel_hozac probably because networking failed...
1216810587 M * arekm Jul 23 12:56:19 firmanew init: string.c:143: Assertion failed in nih_strdup: str != NULL
1216810590 M * arekm Jul 23 12:56:19 firmanew init: rc-default main process (13728) killed by ABRT signal
1216810593 M * arekm uhm
1216810636 M * daniel_hozac heh.
1216810683 Q * ntrs_ Ping timeout: 480 seconds
1216810697 M * arekm someone had the same problem in february here, unsolved, means problems
1216810840 M * daniel_hozac so, figure out why it's not working.
1216810847 M * arekm how to strace init? :>
1216810891 M * arekm strace vserver start won't work I guess, right?
1216810913 M * daniel_hozac nope.
1216810922 M * daniel_hozac but vserver --strace <guest> start should, IIRC.
1216811064 M * arekm it did but hangt at
1216811065 M * arekm 27534 chroot(".")                       = 0
1216811065 M * arekm 27534 vserver(0x34020000, 0x3ee, 0x7fffb68437e0, 0xffffffffffffffff, 0
1216811097 M * daniel_hozac that's weird, it should already be in the context.
1216811101 J * kir ~kir@swsoft-msk-nat.sw.ru
1216811102 Q * kir Remote host closed the connection
1216811214 M * arekm it runs various vserver utils via strace http://pld.pastebin.com/f17643b4e
1216811230 J * balbir ~balbir@204.50.130.82
1216811313 M * arekm vps aux shows strace as being inside of context
1216811557 M * arekm and I can't strace a process from inside of guest :/
1216811610 M * daniel_hozac any process, or init?
1216811639 M * arekm init
1216811697 M * arekm by doing "init 1" from guest I'm able to reproduce assertion
1216811922 M * arekm can stracing be allowed via flags or something like that?
1216811947 M * daniel_hozac no.
1216812355 Q * mrfree Quit: Leaving
1216812744 M * arekm  NIH_MUST (term = nih_strdup (NULL, getenv ("TERM")));
1216812748 M * arekm fails here
1216812771 M * arekm how to pass TERM to guest env so init will see it?
1216812776 M * daniel_hozac apps/init/environment
1216812912 M * arekm thanks! no longer fails
1216812939 M * arekm vi is quite good debugging tool heh
1216812947 M * daniel_hozac it's the best.
1216813357 M * arekm reported upstream, maybe they will fix it
1216813419 M * arekm I guess kernel always sets these (TERM and PATH) so it's non issue on non-guest
1216813635 N * Guest914 Genghis
1216813670 N * Genghis Guest920
1216814397 M * arekm # ls -l /proc/6332/oom_adj
1216814397 M * arekm -rw-r--r-- 1 root 17 0 Jul 23 11:51 /proc/6332/oom_adj
1216814405 M * arekm # echo -17 > /proc/6332/oom_adj
1216814405 M * arekm bash: /proc/6332/oom_adj: Operation not permitted
1216814424 M * arekm shouldn't these be registered with -w then in guest?
1216814442 M * daniel_hozac it's a bug. it's being worked on.
1216814640 M * arekm hm, in netstat -nlp in guest I see sockets from other guests
1216814649 M * arekm unix  2      [ ACC ]     STREAM     LISTENING     57785417 -                   /var/lib/mysql/mysqldb/mysql.sock
1216814669 M * daniel_hozac upgrade your kernel, that's already fixed.
1216816348 M * arekm has vs2.3.0.34.14.diff all the currently known fixes?
1216816400 M * daniel_hozac fixes, yes, but not features. and there are more fixes coming.
1216816596 J * kir ~kir@swsoft-msk-nat.sw.ru
1216817295 N * Guest920 Genghis
1216817330 N * Genghis Guest925
1216817339 Q * friendly Quit: Leaving.
1216817746 Q * kir Server closed connection
1216817803 J * kir ~kir@swsoft-msk-nat.sw.ru
1216818862 Q * dna Quit: Verlassend
1216819243 Q * Adrinael Server closed connection
1216819247 J * Adrinael adrinael@rid7.kyla.fi
1216819330 Q * kir Server closed connection
1216819369 J * kir ~kir@swsoft-msk-nat.sw.ru
1216819488 Q * balbir Ping timeout: 480 seconds
1216819595 N * Bertl_zZ Bertl_oO
1216820103 Q * kir Remote host closed the connection
1216820249 J * kir ~kir@swsoft-msk-nat.sw.ru
1216820254 Q * kir Remote host closed the connection
1216820259 J * kir ~kir@swsoft-msk-nat.sw.ru
1216820294 M * Bertl_oO kir: please fix your client
1216820294 Q * kir Remote host closed the connection
1216820303 J * kir ~kir@swsoft-msk-nat.sw.ru
1216820313 Q * kir 
1216820955 N * Guest925 Genghis
1216820990 N * Genghis Guest930
1216821278 J * padde ~padde@patrick-nagel.net
1216821281 Q * padde Remote host closed the connection
1216821286 J * padde ~padde@patrick-nagel.net
1216823594 J * docelic ~docelic@78.134.199.245
1216823917 Q * misc-- Ping timeout: 480 seconds
1216824277 J * balbir ~balbir@205.233.52.240
1216824589 Q * SpComb Server closed connection
1216824591 J * SpComb terom@zapotek.paivola.fi
1216824615 N * Guest930 Genghis
1216824651 N * Genghis Guest946
1216826199 J * xdr ~xdr@17-173-96-87.cust.blixtvik.se
1216826242 Q * docelic Server closed connection
1216826282 J * docelic ~docelic@78.134.199.245
1216827580 J * misc-- ~misc@122.2.122.190
1216828275 N * Guest946 Genghis
1216828310 N * Genghis Guest952
1216829531 J * ssd ~gernot@83-64-146-228.klosterneuburg.xdsl-line.inode.at
1216830014 Q * ssd Quit: Ex-Chat
1216830037 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1216830062 J * ssd ~gernot@83-64-146-228.klosterneuburg.xdsl-line.inode.at
1216830075 Q * ssd Read error: Connection reset by peer
1216830076 J * ssd ~gernot@83-64-146-228.klosterneuburg.xdsl-line.inode.at
1216830176 Q * docelic Quit: http://www.spinlocksolutions.com/
1216830313 Q * ssd 
1216830342 N * DoberMann DoberMann[PullA]
1216830476 Q * ktwilight_ resistance.oftc.net charon.oftc.net
1216830476 Q * fanto666 resistance.oftc.net charon.oftc.net
1216830476 Q * derjohn resistance.oftc.net charon.oftc.net
1216830476 Q * michal resistance.oftc.net charon.oftc.net
1216830476 Q * Guy- resistance.oftc.net charon.oftc.net
1216830476 Q * localghost resistance.oftc.net charon.oftc.net
1216830476 Q * arachnist resistance.oftc.net charon.oftc.net
1216830476 Q * franck34 resistance.oftc.net charon.oftc.net
1216830476 Q * cehteh resistance.oftc.net charon.oftc.net
1216830476 Q * eyck resistance.oftc.net charon.oftc.net
1216830476 Q * lownoize_ resistance.oftc.net charon.oftc.net
1216830476 Q * BobR_oO resistance.oftc.net charon.oftc.net
1216830476 Q * matti resistance.oftc.net charon.oftc.net
1216830476 Q * weasel resistance.oftc.net charon.oftc.net
1216830476 Q * C14r resistance.oftc.net charon.oftc.net
1216830476 Q * Bertl_oO resistance.oftc.net charon.oftc.net
1216830476 Q * blathijs resistance.oftc.net charon.oftc.net
1216830476 Q * padde resistance.oftc.net charon.oftc.net
1216830476 Q * ag- resistance.oftc.net charon.oftc.net
1216830476 Q * NaioN resistance.oftc.net charon.oftc.net
1216830476 Q * jsambrook resistance.oftc.net charon.oftc.net
1216830476 Q * disposable resistance.oftc.net charon.oftc.net
1216830476 Q * DoberMann[PullA] resistance.oftc.net charon.oftc.net
1216830476 Q * svenk resistance.oftc.net charon.oftc.net
1216830476 Q * cccp resistance.oftc.net charon.oftc.net
1216830476 Q * larsivi resistance.oftc.net charon.oftc.net
1216830476 Q * grobie resistance.oftc.net charon.oftc.net
1216830476 Q * maddoc resistance.oftc.net charon.oftc.net
1216830476 Q * vasko resistance.oftc.net charon.oftc.net
1216830476 Q * Radiance resistance.oftc.net charon.oftc.net
1216830476 Q * transaci1 resistance.oftc.net charon.oftc.net
1216830476 Q * arekm resistance.oftc.net charon.oftc.net
1216830476 Q * sannes resistance.oftc.net charon.oftc.net
1216830476 Q * PowerKe resistance.oftc.net charon.oftc.net
1216830476 Q * harry_ resistance.oftc.net charon.oftc.net
1216830476 Q * DLange resistance.oftc.net charon.oftc.net
1216830476 Q * ex resistance.oftc.net charon.oftc.net
1216830476 Q * [PUPPETS]Gonzo resistance.oftc.net charon.oftc.net
1216830476 Q * duckx resistance.oftc.net charon.oftc.net
1216830476 Q * snooze resistance.oftc.net charon.oftc.net
1216830476 Q * daniel_hozac resistance.oftc.net charon.oftc.net
1216830476 Q * trippeh resistance.oftc.net charon.oftc.net
1216830476 Q * fosco resistance.oftc.net charon.oftc.net
1216830476 Q * tokkee resistance.oftc.net charon.oftc.net
1216830476 Q * kiorky resistance.oftc.net charon.oftc.net
1216830476 Q * arthur resistance.oftc.net charon.oftc.net
1216830476 Q * m_o_d resistance.oftc.net charon.oftc.net
1216830476 Q * nenolod resistance.oftc.net osmotic.oftc.net
1216830476 Q * dddd resistance.oftc.net osmotic.oftc.net
1216830476 J * nenolod ~nenolod@ip70-189-74-62.ok.ok.cox.net
1216830476 J * ktwilight_ ~ktwilight@215.116-66-87.adsl-dyn.isp.belgacom.be
1216830476 J * franck34 franck34@sd-10138.dedibox.fr
1216830476 J * blathijs ~matthijs@drsnuggles.stderr.nl
1216830476 J * arachnist arachnist@atlnts.org
1216830476 J * matti matti@acrux.romke.net
1216830476 J * Bertl_oO herbert@IRC.13thfloor.at
1216830476 J * BobR_oO odie@IRC.13thfloor.at
1216830476 J * eyck Ta0oyL8p@nat05.nowanet.pl
1216830476 J * localghost anders@ies57-061.ies.luth.se
1216830476 J * weasel weasel@weasel.chair.oftc.net
1216830476 J * Guy- ~korn@elan.rulez.org
1216830476 J * C14r ~C14r@h58173.serverkompetenz.net
1216830476 J * lownoize_ ~lownoize@swt32.informatik.uni-mannheim.de
1216830476 J * michal ~michal@www.rsbac.org
1216830476 J * cehteh ~ct@pipapo.org
1216830476 J * derjohn ~derjohn@80.69.41.3
1216830476 J * fanto666 fantomas@fantomas.fantomas.sk
1216830476 J * padde ~padde@patrick-nagel.net
1216830476 J * ag- ~ag@fedaykin.roxor.cx
1216830476 J * NaioN stefan@misc.mordor.unilogicnetworks.net
1216830476 J * jsambrook ~jsambrook@aelfric.plus.com
1216830476 J * disposable ~disposabl@blackhole.sk
1216830476 J * DoberMann[PullA] ~james@cap31-6-88-180-72-76.fbx.proxad.net
1216830476 J * svenk ~sven@213.73.89.36
1216830476 J * cccp ~spamfail@lulzmeister.de
1216830476 J * larsivi ~larsivi@169.80-202-217.nextgentel.com
1216830476 J * daniel_hozac ~daniel@c-571472d5.08-230-73746f22.cust.bredbandsbolaget.se
1216830476 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se
1216830476 J * duckx ~Duck@81.57.39.234
1216830476 J * m_o_d ~m_o_d@host-80.54.30.252.ltv.pl
1216830476 J * tokkee tokkee@ssh.faui2k3.org
1216830476 J * [PUPPETS]Gonzo gonzo@fellatio.deswahnsinns.de
1216830476 J * kiorky ~kiorky@cryptelium.net
1216830476 J * ex ex@valis.net.pl
1216830476 J * DLange ~DLange@dlange.user.oftc.net
1216830476 J * harry_ ~harry@d51A461B4.access.telenet.be
1216830476 J * arthur ~arthur@pan.madism.org
1216830476 J * PowerKe ~tom@d5153A1EB.access.telenet.be
1216830476 J * sannes ace@har.sagt.no
1216830476 J * arekm arekm@carme.pld-linux.org
1216830476 J * trippeh atomt@uff.ugh.no
1216830476 J * transaci1 ~transacid@transacid.de
1216830476 J * grobie ~grobie@valgrind.schnuckelig.eu
1216830476 J * fosco fosco@konoha.devnullteam.org
1216830476 J * maddoc maddoc@social.ostruktur.com
1216830476 J * vasko ~vasko@unreal.rainside.sk
1216830476 J * Radiance ~Radiance@193.16.154.187
1216830477 J * dddd ~matthew@scorpion.sorbs.net
1216831922 J * ntrs_ ~ntrs@77.29.77.171
1216831940 N * Guest952 Genghis
1216831976 N * Genghis Guest967
1216832319 Q * ntrs__ Ping timeout: 480 seconds
1216832743 Q * yarihm Ping timeout: 480 seconds
1216832850 J * yarihm ~yarihm@guest-docking-nat-1-010.ethz.ch
1216833144 Q * balbir Ping timeout: 480 seconds
1216834737 Q * yarihm Quit: This computer has gone to sleep
1216835600 N * Guest967 Genghis
1216835636 N * Genghis Guest979
1216835895 Q * hparker Quit: reboot
1216836410 J * hparker ~hparker@linux.homershut.net
1216836412 N * DoberMann[PullA] DoberMann
1216836511 Q * dddd resistance.oftc.net scorpio.oftc.net
1216836582 Q * michal Ping timeout: 480 seconds
1216836640 J * dddd ~matthew@scorpion.sorbs.net
1216836662 Q * arekm Quit: leaving
1216837057 J * michal ~michal@www.rsbac.org
1216838615 J * giovanni_h ~giovanni@89-97-35-68.ip15.fastwebnet.it
1216838620 M * giovanni_h hello everybody
1216838651 M * giovanni_h does the packets generated inside a sliver pass the mangle PREROUTING table?
1216838665 M * giovanni_h inside a vserver, sorry
1216838671 M * giovanni_h ;)
1216838806 M * giovanni_h noone knows?
1216839198 M * Bertl_oO packet handling is not different from 'normal' linux
1216839217 M * Bertl_oO i.e. whatever is true for any linux machine is true for Linux-VServer too
1216839260 N * Guest979 Genghis
1216839262 J * arekm arekm@carme.pld-linux.org
1216839296 N * Genghis Guest990
1216839589 M * Mr_Smoke Bertl_oO: apart from the fact that packets never go thru the FORWARDING rule, right ?
1216839602 J * hparker_lappie ~hparker@linux.homershut.net
1216839617 M * Bertl_oO they don't pass the forwarding chain on Linux either
1216839636 M * Bertl_oO no forwarding ... no forwarding chain :)
1216839817 M * Mr_Smoke Well one might think that different IP address might mean routing/forwarding
1216839933 M * giovanni_h I seem to remember that vserver are treated, from netfilter point of view, like external hosts
1216839959 M * giovanni_h that would justify the trepassing of the PREROUTING table
1216840260 M * Bertl_oO giovanni_h: you remember wrong, iptables is not changed in Linux-VServer, so it behaves exactly like without the Linux-VServer patch
1216840291 M * Bertl_oO giovanni_h: it's your 'interpreting' some magic handling which causes 'unexpected' behaviour :)
1216840384 M * Bertl_oO maybe take a step back, and tell us what you are trying to do, and what fails for you ..
1216840430 M * Bertl_oO (also note that the planetlab version does indeed change the network behaviour to some degree)
1216840509 M * Bertl_oO Mr_Smoke: that's actually the problem, folks 'think there should be' and get beaten by 'nothing changed' :)
1216840913 M * Mr_Smoke Indeed ;)
1216842537 M * giovanni_h that wouldn't be a change made in iptables, but in the kernel. you are aware of that, aren't you?
1216842588 M * Bertl_oO 'iptables' are in the kernel, the iptables binary just communicates them between userspace and kernel space
1216842592 M * giovanni_h I'm just asking... I don't mean to me unrespectful
1216842605 M * giovanni_h yes, that's what I meant
1216842623 M * Bertl_oO yep, and nothing in the netfilter code is changed by Linux-VServer
1216842634 M * giovanni_h mmm
1216842642 M * Bertl_oO i.e. a Linux-VServer patched kernel behaves like a vanilla one
1216842655 M * giovanni_h and how is that "more than an Ip things" being handled?
1216842671 M * giovanni_h "more than an Ip thing"
1216842671 M * Bertl_oO hmm?
1216842695 M * giovanni_h the fact that there is an IP for every vserver
1216842722 M * giovanni_h (not always, but you can make that happen)
1216842723 M * Bertl_oO Linux-VServer does the following (in the network code):
1216842744 M * Bertl_oO - masking out 'unwanted' IP addresses (and related structures) to userspace
1216842757 M * Bertl_oO - blocking binding 'unassigned' IPs
1216842783 M * Bertl_oO - remapping some addresses (mainly loopback IPs) from/to userspace
1216842811 M * Bertl_oO there are absolutely no changes to netfilter, bridging or other related stuff
1216842835 M * Bertl_oO and there is minimal effect on source IP selection inside a guest (for routing)
1216842859 M * giovanni_h so, packets generated inside vserver come out from the OUTPUT hook?
1216842888 M * Bertl_oO yes, as for any packet generated 'on the host'
1216842901 M * giovanni_h what I'd like to do is marking packets from a sliver and have them routed depending on this mark
1216842920 N * Guest990 Genghis
1216842927 M * Bertl_oO sliver is a bad choice of name, as it is used on planetlab, IIRC
1216842930 M * giovanni_h I should be able to do that in the OUTPUT table, shouldn't I?
1216842950 M * giovanni_h yes, sorry... I'm used to it... vservers
1216842951 M * giovanni_h :)
1216842952 M * Bertl_oO you can do that simpler by using the 'from' routing rule
1216842956 N * Genghis Guest999
1216842969 M * giovanni_h but in my case the ip is the same
1216842981 M * Bertl_oO then no way to tell 
1216843038 M * giovanni_h maybe the marking of packets is a planetlab specific feature
1216843067 M * Bertl_oO yep, it is (although you can do that quite easily with 'normal' Linux-VServer too)
1216843084 M * giovanni_h using the owner module, I guess
1216843089 M * giovanni_h of iptables
1216843110 M * Bertl_oO actually we have the nid for each socket, so we can use that for the fw marking
1216843145 M * giovanni_h how would you do the marking?
1216843182 J * yarihm ~yarihm@84-74-147-84.dclient.hispeed.ch
1216843187 M * Bertl_oO simply transfer the nid to the fwmark for outgoing, for incoming, it's a lot trickier :)
1216843262 M * giovanni_h How do you do that?
1216843295 M * Bertl_oO what?
1216843349 M * giovanni_h how do you transfer the nid to the fwmark
1216843354 M * giovanni_h with iptables?
1216843403 M * Bertl_oO ah, no, you would do that with a simple change to the Linux-VServer patch on all outgoing packets, or you could do that with a specific iptables target (would require userspace changes too, but we did that some time ago :)
1216843788 M * giovanni_h ah, ok
1216843822 M * giovanni_h in fact, in planetlab, there is something similar, even though it isn't working properly yet
1216843861 M * giovanni_h at least for what I can tell... (it may be my fault) :
1216843862 M * giovanni_h :(
1216844151 M * Bertl_oO yes, I know :)
1216844702 Q * bonbons Quit: Leaving
1216846580 N * Guest999 Genghis
1216846616 N * Genghis Guest1007
1216847952 J * Aiken ~james@ppp121-45-243-126.lns2.bne4.internode.on.net
1216848151 Q * hparker_lappie Quit: Quit
1216848236 N * Guest1007 Genghis
1216848858 Q * ntrs_ Ping timeout: 480 seconds
1216849370 J * fluor- ~fluor@silentio.us
1216849378 M * fluor- hi there
1216849437 M * fluor- I'm in the following situation: my server buddy's all excited about OpenVZ, and thinks it's worth going that way for our new machine
1216849457 M * fluor- now, I've started reading articles comparing linux-vserver and openvz here and then,
1216849474 M * fluor- and I feel like sticking with vserver,
1216849484 M * tam Resist the peer pressure!
1216849493 J * h01ger ~holger@socket.layer-acht.org
1216849505 M * fluor- mostly 'cause I like it, and I always found the community incredibly helpful
1216849512 M * Bertl_oO fluor-: well, check out both and decide what suits your needs best
1216849555 M * fluor- on top of all, I prefer something that's being developped in a collaborative fashion, than a product that's made by a company to seel its proprietary upgrade
1216849562 M * fluor- but I'd appreciate your take on it
1216849578 M * fluor- s/seel/sell
1216849593 M * Bertl_oO what do you expect from us, of course we prefer Linux-VServer for various reasons :)
1216849599 M * fluor- hehe
1216849603 M * fluor- Bertl_oO: I want your reasons! :)
1216849627 M * h01ger hi. i'm running vservers on etch (with debians 2.6.18 kernel). how can i get loopback devices there? $etcdir/interfaces/0/lback with contents 127.0.0.1 didnt work as well as $etcdir/interfaces/1/dev with contents "lo" and .../ip with contents 127.0.0.1
1216849662 M * Bertl_oO fluor-: first, code quality .. second, performance and simplicity, third, independance from any company
1216849710 M * Bertl_oO h01ger: simply by upgrading the kernel to a more recent one :)
1216849717 M * h01ger not an option
1216849730 M * Bertl_oO well, 127.0.0.1 in interfaces is not an option either :)
1216849737 M * h01ger i just want to use postfix everywhere. an option would be to just use nullmailer
1216849746 M * h01ger 127.0.0.$contextid? :)
1216849747 M * fluor- h01ger: grab a kernel from lenny, it's being freezed real soon
1216849747 J * cryptronic ~oli@p54A3B27E.dip0.t-ipconnect.de
1216849750 M * Bertl_oO (unless you do not care sharing the IP with other guests and the host=
1216849761 J * serek ~ser@sergiusz.pawlowicz.name
1216849769 N * Bertl_oO Bertl
1216849773 M * Bertl welcome serek!
1216849788 M * Bertl h01ger: postfix does not need 127.0.0.1
1216849796 M * h01ger is 127.0.0.$contextid an option? i dont mind a different ip, i just want loopback
1216849804 M * h01ger Bertl, but an interface
1216849811 M * Bertl nope, will be shared (on that kernel) between all guests/host
1216849830 M * h01ger ok, then it will be nullmailer than
1216849831 M * h01ger thanks
1216849836 M * Bertl you're welcome!
1216849880 M * serek hi, i cannot understand the idea of vhashify - what exactly is the base of system, which is later hard-linked?
1216849884 M * h01ger will lenny also have vserver if lenny will get 2.6.25? (afaik its _not_ clear what lenny will get... the kernel team wants .26, yes.)
1216849892 M * Bertl fluor-: in your case, you probably can add the support on the IRC channel as argument (which isn't a good argument for me :)
1216849896 M * h01ger (/me wants 26 too)
1216849909 M * Bertl serek: you know what a hash is?
1216849947 M * serek not really
1216849951 M * Bertl h01ger: there will be patches for 2.6.26 shortly, (there are patches for 2.6.25.x already)
1216849982 M * Bertl serek: okay, the idea is to have a 'fingerprint' for an entire file, i.e. something short which 'represents' the entire file
1216849987 M * serek i know what md5 hash is :)
1216849998 M * h01ger Bertl, cheers!
1216849998 M * serek is it crypto hash of file?
1216850023 P * h01ger thanks for all the tasty fish and have fun! :)
1216850026 M * Bertl well, there you go .. now vhashify goes through all the files, and calculates such a hash
1216850037 M * serek and later what - what is comparing if this file is already stored on drive?
1216850044 M * fluor- Bertl: it certainly is a good argument for me :)
1216850046 M * serek all files - where?
1216850049 M * Bertl it then compares the hash with existing ones, and if there is no entry, a new one is created
1216850068 M * serek it is my question - where it looks for files
1216850074 M * Bertl the hash is used as a name, and the file data (contents) is hardlinked
1216850090 M * Bertl it looks inside the guests you specify to vhashify
1216850091 N * DoberMann DoberMann[ZZZzzz]
1216850140 M * serek ok, so it compares them using this hash file - and if it finds the same file, it re-uses it?
1216850176 M * Bertl precisely, except that there is no 'list of hashes' just the directory entries (hashed files) in the cache
1216850244 M * Bertl this is usually combined with CoW (copy on write) link breaking (used in Linux-VServer)
1216850254 M * serek ok, so first i need to create one host server, then how to build another using the same files?
1216850296 M * Bertl you don't need to _create_ a guest first (not for this purpose :), you can vhashify any guest anytime ...
1216850316 M * Bertl and you can create a 'clone' with the 'clone' build method
1216850325 M * serek ah, ok - now i can slowly understand
1216850328 M * Bertl (which speeds up guest creation dramatically)
1216850513 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1216850526 M * serek ok, so after cloning, i need to dist-upgrade each vserver separately but finally they will use the same files, right?
1216850579 M * Bertl you can upgrade all at once or separately, whenever you run vhashify on them, identical data will be linked together
1216850670 M * serek ok, definitly your words should be in faq, very thanks!
1216850708 M * Bertl then please go ahead an add them (after checking that they are not already there :)
1216850733 M * serek last question: so i may vhashify two existing hosts as well, right?
1216850743 M * Bertl yep, anytime
1216850744 M * serek guests
1216850748 M * serek OK
1216850757 M * serek so i am adding it to faq :)
1216850760 M * Bertl http://linux-vserver.org/Vhashify
1216850763 M * serek thanks again
1216850942 M * fluor- < Bertl> you can upgrade all at once or separately <- what would the "all at once" method be?
1216850948 Q * cryptronic Quit: Leaving.
1216851050 M * Bertl fluor-: depends on the package management, for most common management mechanisms, there is vapt, vyum, and vrpm 
1216851220 M * serek ok, http://linux-vserver.org/Vhashify updated :)
1216851289 Q * maddoc Ping timeout: 480 seconds
1216851352 J * maddoc maddoc@social.ostruktur.com
1216851521 J * Mojo1978 ~Mojo1978@ip-78-94-125-184.hsi.ish.de
1216851560 M * fluor- Bertl: vapt? oh my!
1216851599 M * serek if one file exists in two actual guests, after hashify it would be removed from both of them and moved to /vserver/.hash? or left in one server?
1216851612 M * fluor- I can't believe I didn't know about vapt-get
1216851681 Q * loddafnir Quit: Leaving.
1216851730 M * Bertl serek: it will be linked together and to the .hash, after that, all three 'files' are identical
1216851754 M * Bertl (actually they are _the_same_ :)
1216851825 M * serek but phisically where they will stay?
1216851861 M * Bertl physically there is only one entry (the inode) and three identical references in the three directory nodes
1216851952 M * serek ok, but it requires both guests to be on one filesystem?
1216851979 M * Bertl yes, that is how unification (via hard links) works
1216852129 M * serek OK, now i can fully understand, thanks a lot
1216852129 M * Bertl you're welcome!
1216852248 M * fluor- serek: thanks for asking the right questions, I wanted to know more about that too :)
1216852267 M * Bertl but didn't dare to ask :)
1216852298 M * serek i used to use vserver until three years, but i have guests on separate LVs
1216852321 M * Bertl so you won't benefit from unification (right now :)
1216852349 M * serek yes, indeed - i have to think which solution is better :)
1216852374 M * Bertl depends on the usage pattern and the problems (if any) you are facing
1216852375 M * serek (for me)
1216852427 M * serek i think i'll stay with pvmove :)
1216852481 M * serek it is strange but i administrate linuxes several years, and i did not use hard links at all
1216852509 Q * giovanni_h Remote host closed the connection
1216852597 M * Bertl it's a unix thing ... not used in non-unix environments (because not available :)
1216852611 M * Bertl (thus it isn't that popular)
1216852692 M * fluor- weird, I get "Failed to initialize unification for vserver" when trying to hashify
1216852705 M * serek fluor-: is your guest running?
1216852835 M * fluor- yes, it is
1216852861 M * serek so i have no idea :)
1216852952 M * Bertl fluor-: what util-vserver version?
1216854145 M * fluor- Bertl: 0.30.215-4
1216854167 M * fluor- kernel is 2.6.22-3-vserver-amd64 (Debian, as you must have guessed by now)
1216854170 M * Bertl try with --debug, and upload the output
1216854361 M * fluor- Bertl: http://paste2.org/p/51469
1216854479 M * Bertl do you have a .hash dir?
1216854576 M * fluor- bummer, no
1216854588 M * fluor- should it sit with the config files, or the vserver themselves?
1216854604 M * Bertl http://oldwiki.linux-vserver.org/alpha+util-vserver
1216854669 M * Bertl (in addition to the link above)
1216854738 M * fluor- thanks, reading and doing ATM
1216854778 M * Bertl k, if you have detailed questions, just ask again (daniel_hozac will know)
1216854836 M * fluor- it seems to work now.
1216854975 M * Bertl great!
1216855030 M * fluor- I guess it will take a while, won't it?
1216855042 M * Bertl shouldn't be too long
1216855050 M * fluor- stupid me, I didn't run it within a screen
1216855051 M * Bertl (of course, depending on the guest :)
1216855055 M * fluor- :)
1216855085 J * groente ~groente@shell.puscii.nl
1216855095 M * Bertl welcome groente!
1216855184 A * sid3windr eats groente
1216855216 M * groente hey Bertl 
1216855266 M * groente sid3windr: i'm afraid i don't taste very well :-/
1216855454 M * fluor- this is likely to mean dropped vserver support in Debian kernels from Lenny onwards :(( -> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489387#10
1216855835 M * Bertl well, looks like misinformation
1216855858 M * Bertl just enabling ipv6 with recent kernels works perfectly
1216855875 M * Bertl (and all patches for 2.6.25+ have that support)
1216855927 M * Bertl but if OVZ is debian's choice, I'm fine with that too
1216855996 M * fluor- modular IPv6 support is what's required, AFAIK
1216856023 M * Bertl there is no point in modular ipv6
1216856079 M * Bertl (besides that this was done too, so would just need a small modification if somebody actually wanted to add it)
1216856152 M * fluor- it would be _really_ sad for vserver to be dropped in Debian kernels
1216856176 M * Bertl I'm not sure about that, the debian users probably would benefit from it
1216856203 M * Bertl (not always having an outdated kernel/patch and such)
1216856421 M * sid3windr groente: what, you're appelmoes or something?! :p
1216856449 M * groente sid3windr: neh, just a bit rotten, really
1216856489 M * sid3windr :/
1216857288 Q * yarihm Quit: Leaving