[00:00] @zyong have you found the .config? [00:00] yes i have [00:00] i'm menuconfiging now [00:01] okay, because I have to leave again ;) [00:01] haha ok [00:01] cya! [00:01] Nick change: Bertl -> Bertl_oO [00:03] Hi [00:03] Currently running the old freevsd.org pacakages [00:03] Looking for a replacement [00:04] Our current implementation has been hacked and patched to death [00:04] number of things broken [00:40] Nick change: riel_ -> unriel [00:53] Anyone aliver here today? [00:53] *alive [00:54] yea [00:54] but i do not know the answer to your question that's why i'm keeping quiet [01:20] hehe [01:20] Have you used these VServer patches and util much? [01:22] I want to get started trying this out [01:22] what is the simplest way to patch against a 2.4.22 vanilla kernel? [11:15] loger joined #vserver. [11:54] say (~say@212.86.243.154) left irc: Ping timeout: 493 seconds [12:01] cool site layout. hey herbert thanks for all your help. if there is anything i can do for the vserver community i wouldn't mind putting in my time and effort ;) [13:46] say (~say@212.86.243.154) joined #vserver. [13:58] serving (~serving@213.186.191.55) left irc: Ping timeout: 493 seconds [15:16] say_ (~say@212.86.243.154) joined #vserver. [15:16] Nick change: Bertl_zZ -> Bertl [15:17] hi all! [15:24] Hello Herbert [15:24] hi alex! [15:24] you dream is good ? [15:24] excellent ;) [15:24] very nice :) [15:25] i be absent - but return to 17 EEST.. [15:25] ok ? [15:26] this is 16 CET, right? [15:26] 13:26 CET now ... [15:27] yes. i go to shop for buy eat :) [15:27] get some fine food for the weekend ... [15:27] do you know is say around? [15:28] yes. [15:29] okay, thanks then ... cu l8er ... [15:29] i send icq for him [15:29] perfect ... [15:32] Hi, Bertl! [15:32] hi say ... [15:32] I heard you solve your trouble by netfilter? [15:33] yes, it seems to work, and I guess it could become a really cool approach ... [15:33] I would like to discuss it with you a little ... do you have time? [15:34] yes, but I can out in any moment [15:34] should be no problem ... [15:35] http://vserver.13thfloor.at/Experimental/patch-2.4.23-rc1-vn0.03a.diff [15:35] this is my latest version, and it is full of useless/wrong stuff commented out ... ;) [15:35] but it is pretty simple, if you remove all that crap ... [15:36] yes, got it [15:37] basically it registers a virtual device, which as we know cannot receive packets 'per se' [15:37] then it adds some netfilter hooks (only one is used actually) [15:38] a cruel 'match test' checking for .10 and 'eth0' decides that this is a packet for vnet0 ... [15:39] and changes the interface (dev) ... [15:40] ifconfig eth0 10.0.0.10 [15:40] ifconfig vnet0 192.168.0.10 [15:40] ok. it seems correct way [15:40] and after one small detail, I have to set the arp entry by hand :( ... [15:41] I'm able to ping or reach 192.168.0.10 from the 'wire' of eth0 [15:41] but all traffic is redirected through vnet0 ... [15:45] ok. i understand. it's all seems as right way for redirecting vnet traffic [15:45] one problem I would like to solve is the arp entry ... it is done for eth0, but not for vnet0 (which was expected), but I don't know (yet) how to add an arp entry for vnet0 when the eth0 (master) arp entry is created .. [15:47] hm. i see 2 way: [15:48] 1. copy all arp packets that coming to eth0 to vnet0 too. [15:49] not only with vnet0-ip-address [15:50] 2. generate arp-requests directly by vnet0 when it is no needed entry in it's internal arp-table [15:50] 1) hmm, tried that, but maybe the reroute was the failure, copy sounds better [15:50] serving (~serving@213.186.191.89) joined #vserver. [15:50] what way you choise? [15:50] 2) how would I do that? [15:51] hi serving! [15:52] wait a minute, i go to see sources :) [16:03] hm. it seems arp_solicit which calls arp_send request must be called automatically from core/neighbour.c [16:04] good point, can you explain the neigh/neighbour scheme to me? [16:09] just a moment. i'll find a root of this chain [16:10] take your time ... [16:37] heh. so, when we add neighour there is assinging timer function neigh_timer_handler which calls by timer expire [16:38] okay ... [16:38] and if hw-addr for this neighbour in "incomplete" we automatically send arp-request to this neighbour [16:41] okay let me clean up the mess, so we can try to add what might help ... [16:42] i'll find a way that you can use. wait a moment please [16:53] http://vserver.13thfloor.at/Experimental/patch-2.4.23-rc1-vn0.04.diff [16:55] hmm, it seems that the arp reply cannot be matched ... [16:57] http://vserver.13thfloor.at/Experimental/VNET_01.log [16:57] (this is the output of a single ping, which _is_ successful ;) [17:02] this works for some time (about 2-5 seconds) until the system decides that it doesn't want to respond to this address :( [17:05] wait, i see your latest patch [17:08] by the way, the arp entries look good now ... [17:09] 192.168.0.1 ether 00:FF:D0:60:91:5D C eth0 [17:09] 192.168.0.1 ether 00:FF:D0:60:91:5D C vnet0 [17:09] but maybe it's not good to have two of them ;) [17:15] say (~say@212.86.243.154) left irc: Read error: Connection reset by peer [17:15] say_ (~say@212.86.243.154) left irc: Write error: connection closed [17:15] say__ (~say@212.86.243.154) joined #vserver. [17:18] there is 2 way: 1. add replacing vnet0 to eth0 in arp-answer procedure [17:18] 2. virtualizing arp-table. it's most difficult :) [17:19] way 2 need more arp trafic... [17:19] but it need ? [17:20] hmm, you mean for the arp out ... yes, this would be easy ... there is a hook too ... [17:20] @shadow: for full virtualization - it needed [17:21] say (~say@212.86.243.154) joined #vserver. [17:21] i.e. for defence separate vdev-s from arp-attack etc. [17:22] hmm, what I don't understand, the arp request is sent via vnet_xmit, and this 'does' the vnet0 -> eth0 mapping ... [17:24] heh. afaiu this maping in _packet_, not in arp-tabel [17:24] actually it seems that the arp reply is dropped ... for whatever reason before I can rewrite it ... [17:24] virtuoso (~shisha@195.131.114.115) joined #vserver. [17:24] so, people, sorry, but i leave you alone. [17:25] Hi [17:25] bye. see you tomorrow. [17:25] @say okay .. enjoy the rest of the day ... [17:25] thnx :) [17:25] hi virtuoso! [17:26] Hi Bert [17:27] Nick change: say__ -> say-out [17:29] Hi virtuoso [17:29] Hi Alex [17:30] hehe probably filtering out the arp reply is not a good idea ;) [17:31] :) [17:31] :) [17:34] Are there any debian packages with 1.0? [17:34] hrm, there is the patch ... [17:35] don't know if anybody made a package yet ... [17:35] No, I mean vserver tools. [17:35] The latest what I see in debian is 0.24 [17:36] seems like vserver-0.26 is somewhere as deb ... [17:36] util-vserver not that I know of ... [17:36] Brrr. [17:36] I missed something. [17:37] "1.0" means a patch, not tools, right? [17:37] actually it's 1.00 but yes ... [17:38] And I guess it's totally different from ctx thing? [17:38] completely ... almost everything changed ;) [17:40] That's what I'll try on my home workstation this evening. :) [17:41] And yet nothing for 2.6? [17:41] well .. not my fault, Rik has stopped working on it ... [17:42] This-is-a-damn-heresy mode? :) [17:43] you want to test 2.6 stuff? [17:44] Most likely yes, I do. [17:45] well I still got zero/null/no response regarding the qh0.12 on 2.6.0-test9 ... [17:45] As I understood from the webpage, it should apply cleanly and the best effect is no effect, right? [17:46] exactly ... [17:47] wgot it :) [17:48] Well, I check it asap. [17:48] any slightes deviation from normal behaviour (regarding quota) is a bug ... [17:49] Ok. [20:04] anyone is getting such shrinkage ? Non configuration files may be linked together saving a huge amount of disk space: A 2 GIG rh7.2 installation shrinks to 38megs [20:04] yup! [20:04] HI Bertl :) [20:05] then I am doing someting wrong. I still get 400 MB on a the new unified server. [20:06] how do you measure? [20:06] a 600 MB original gives me about 250 MB on the unified [20:06] what are the 350MB ununified? [20:06] 600 MB [20:06] probably not configuration files, right? [20:07] I think it is copying binaries [20:07] well binaries _can_ be unified, right? [20:07] the docs on solucorp is advertising " A 2 GIG rh7.2 installation shrinks to 38megs. [20:08] I am using the newvserver script and I am chosing option unified [20:08] well it probably does ... [20:09] is there another way to unify a server at install time ? :) [20:10] I'm not maintaining the userspace tools, in the newvserver case it's jack who is doing this ... but let's see what still isn't unified on your system ... [20:10] ok [20:11] try find with -links 1 option ... and put the result somewhere on the web ... or send it via DCC/email ... [20:11] you know how to use find? [20:11] not that way . [20:13] is find /vservers/rht2/ -links 1 correct ? [20:13] give me a second ... [20:14] find /vservers/rht2/ -links 1 -printf "%k\t%p\n" [20:14] this is what we are looking for ... [20:15] k. [20:20] i did [20:20] find /vservers/rht3/ -links 1 -printf "%k\t%p\n" > rht3-find-output [20:20] http://213.186.191.89/vserver/rht3-find-output [20:20] good ... [20:21] rht3 should share files with rhtest vserver. Both dirs are showing 595 MB size [20:22] hehe, how do you measure? [20:22] in root server I am doing du /vserver/rhtest -m [20:23] since there is linking I am not sure if the results is correct on rht3 [20:23] well, and how should this know about the 'unified' files? [20:24] du /vserver/rht3 -m ( not sure this is correct) [20:24] okay .. let us make a simple test example, yes? [20:24] sure [20:24] go to the /tmp directory and do the following: [20:25] mdkir A B [20:25] dd if=/dev/zero bs=1k count=2048 of=/tmp/A/file1 [20:25] dd if=/dev/zero bs=1k count=2048 of=/tmp/B/file2 [20:26] dd if=/dev/zero bs=1k count=4096 of=/tmp/file3 [20:26] okay? [20:26] ok. 1 sec [20:27] done [20:27] now let us check the sizes du -sk /tmp/A /tmp/B /tmp/file3 [20:27] 2058/tmp/A [20:27] 2058/tmp/B [20:27] 4113/tmp/file3 [20:27] this means about 2M in A and 2M in B and 4M size of file3, right? [20:27] 2056 /tmp/A [20:27] 2056 /tmp/B [20:27] 4100 /tmp/file3 [20:28] okay, now have a look at your df -k /tmp [20:28] how much space is available? [20:28] 425312 [20:28] good, remember that value ... [20:29] ok [20:29] now we do ln /tmp/file3 /tmp/A/file3 [20:29] and ln /tmp/file3 /tmp/B/file3 [20:29] ok done [20:29] du -sk /tmp/A /tmp/B /tmp/file3 now showsy [20:30] 6171/tmp/A [20:30] 6171/tmp/B [20:30] 4113/tmp/file3 [20:30] and the free space of df -k /tmp ? [20:30] 6156 /tmp/A [20:30] 6156 /tmp/B [20:30] 4100 /tmp/file3 [20:30] 425312 available [20:31] same as b4 [20:31] well, how did this happen? [20:31] :) [20:31] the file3 is _shared_ amoung /tmp and /tmp/A and /tmp/B [20:32] The ln counted caused the sapce to be counted [20:32] if you want to know the amount which isn't shared between vservers, you are probably on the right side if you only count files with a link count of 1 [20:33] in your case, the html file, it's about 64M [20:33] I c . then rht3 is using only 64MB _acrtual_ disk space ? [20:34] so each 'new, cloned and/or unified' vserver, will probably add 64M to your current usage ... [20:34] the rest, your 200-600MB are shared between all unified servers ... [20:34] I get it. [20:35] actually the average size of a vserver becomes smaller when you add new servers ;) [20:35] now If I moce rht3 to another server, I have to move with it the server it was unified with rhtest ? [20:35] moce/move [20:36] no, as there is no difference between the three 'links' we had in our /tmp/file3 example ... [20:37] it doesn't matter which one you copy over, but it will use the full amount of diskspace, unless unified with a similar server over there ... [20:37] oh. I C now. a rht3 copy to another server will move 595 MB [20:39] let say I moved rhtest first (595 MB moved) how can I move rht3 and unify it with it on the new server ? [20:39] well, with special tools, one could actually avoid to move files already there on the other server ... (to be unified ones and to be copied ones) [20:39] the unifications is done with an existing tool called vunify ... [20:41] I dont have it on my root server. Is it a seprate tool that I ned to install ? [20:41] you probably have, but do not find it ... /usr/lib/util-vserver/vunify [20:42] or with jack's tools in /usr/lib/vserver/vunify ... [20:42] right . I found it in /usr/lib/vserver [20:43] thanx Bertl for the lesson. I realy apprciate your time :) [20:44] well, you can write a little about this unification stuff ... right? [20:44] Once . I do the move I will if you want me to [20:44] s/./, [20:45] when you feel like giving back, do so ... [20:45] I taking notes about what you have just explained to me and it is wirth publishing [20:45] Bertl: sure thing [21:12] morrigan (~morrigan@WWW.13thfloor.at) joined #vserver. [21:58] Action: morrigan is hungry [22:08] Action: Bertl offers a toasted bread with molten cheese ... [23:03] morrigan (~morrigan@WWW.13thfloor.at) left #vserver. [00:00] --- Sun Nov 16 2003