[01:54] loger joined #vserver. [01:55] bye all [01:55] shadow (~umka@212.86.233.226) left irc: Quit: bye [02:07] Nick change: riel -> unriel [02:15] Nick change: Bertl_oO -> Bertl [02:15] hi all! [02:15] hi simon! [02:17] hi Bertl [02:17] goodnight Bertl [02:17] goodnight! [02:17] JonB (~jon@kg184.kollegiegaarden.dk) left irc: Quit: zzzzzzzzzzz [02:38] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [02:39] testing c17f [02:39] hi shuri, great! [02:40] got a lot of warning [02:40] hmm, from what? [02:41] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [02:41] make bzImage > ../Build.log [02:41] hi bobi! [02:41] In file included from /usr/src/linux-2.4.22/include/linux/ext3_fs_sb.h:20, [02:41] from /usr/src/linux-2.4.22/include/linux/fs.h:717, [02:41] from /usr/src/linux-2.4.22/include/linux/capability.h:17, [02:41] from /usr/src/linux-2.4.22/include/linux/binfmts.h:5, [02:41] from /usr/src/linux-2.4.22/include/linux/sched.h:9, [02:41] from keyboard.c:28: [02:41] etc etc [02:42] hmm, can you put them somewhere on the web? [02:42] yes [02:42] all my compiles where without any 'new' warnings ... [02:43] (new means, other than the original kernel warnings ...) [02:44] give me a few minutes [02:44] no problem ... [02:51] Hi Bertl :) [02:51] hi simon! [02:52] did you get my mail? [02:52] yes ... [02:53] the problem is that this kernel probably uses the O(1) scheduler ... and the current vserver stuff doesn't work with that ... [02:54] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [02:54] oh :( [02:54] but maybe we can add what you need to the vanilla kernel ... [02:54] what's the O(1) scheduler? [02:55] an advanced task scheduler present in 2.6 (beside other schedulers) and some 2.4 distros ... [02:56] what are the issues with NTP library you encounter? [02:57] the lack of it in vanilla :) [02:57] hmm, this is a glibc library extension, so how is the kernel involved? [02:59] this is what they told me :( [02:59] Taroon glibc relies on all NPTL functionality being there. [02:59] So vanilla 2.4.22 has no chance of working properly (unless you [02:59] mv /lib/tls /lib/tls.disabled), 2.6.0-testX has some chance, but as Arjan [02:59] wrote, only taroon kernels are supported on taroon. [02:59] [02:59] Jakub [03:01] hmm well, sounds like a Micro$oft answer to me ... [03:03] :( [03:03] on the nptl page, they state 2.5.32 kernel minimum ... [03:05] hmm, any good reasons for using taroon anyway? [03:06] I need x86_64... afaik the choices are Suse (didnt like it), RH gingin64 (didnt work) and RHEL taroon [03:07] hmm, mandrake? [03:08] did I mention that I use mandrake for my vservers? [03:08] or at least some derived homebrewn distro ;) [03:09] do they have a 64bit version? [03:09] at least they have x86_64 packages since 9.0 ... [03:10] they are now at 9.2 (release in progress ;) [03:11] I dunno [03:11] I'd prefer not to do that [03:11] I'll just use freevsd if we can't get this working [03:11] hmm, what is freevsd? [03:12] old ;) [03:12] SG1: do you have tried vanilla 2.4.22? On ia32, only the db4 package has NPTL related problems [03:13] SG1: else, it is working fine [03:13] yes... [03:13] anything threaded will have problems I think? [03:13] hmm db4 could be compiled without ... [03:13] hi enrico! [03:13] I will try linux-2.6.0-test7 and see if that works [03:13] does that have NPTL? [03:14] NPTL is userspace/glibc AFAIK ... [03:14] well what are RH talking about then :/ [03:14] but it said NPTL needs kernel > 2.5.36? [03:14] about some 'requirements' they have for their nptl version ... [03:15] SG1: RH backported the NPTL stuff [03:15] yes [03:15] SG1: Ulrich Drepper invented it and RH9 gave him enough beta-testers ;) [03:16] "requires a kernel with the threading capabilities of Linux 2.5.36." [03:17] hmm, but you didn't explain why RHEL, if Mandrake would probably do nicely ... [03:21] I'm not changing distros, I've already spent too long setting it up as it is... [03:21] I don't suppose vserver works with 2.6 does it? :( [03:22] hmm, not yet, unless rik did some miracle yesterday ;) [03:24] hmm, simon, could you give the c17f a try, just to see if the syscall stuff works? [03:24] with 2.4.23? [03:24] no actually 2.4.21 and/or 2.4.22 ... [03:25] Ok [03:26] hey, that's great, thanks ... [03:26] so there's no chance of making vserver work with the O(1) sched? [03:27] there is always a chance ... it is working with alexeys patches (the O(1) scheduler) we just don't support it right now ... [03:28] Bertl: for what do you want ->child members in the hierarchical vserver-modell? IMO, ->parent will be enough [03:29] :( [03:29] I could take a deeper look at it in the next two weeks, but I would need heavy testing support [03:29] if I start to port it to a RH kernel, and I'm not sure if this is a GoodThing(tm) ... [03:30] maybe it would be easier to find the thread requirements, but I guess they are scheduler related too ... [03:31] well it's not so much the RH kernel as the stuff in it that they have backported... if vserver supported 2.6.0 it wouldn't be a problem? [03:32] if RH would split/provide their backports, it might be no problem either ;) [03:32] you mean their patches? [03:33] basically the patches required to get this working ... yes ... [03:33] say vanilla 2.4.22 + nptl-patches ... [03:33] Bertl: they are all the src.rpm ;) [03:34] Bertl: (among the other 100 ones) [03:34] yeah, I know, 200+ patches ... [03:34] each requiring the previous ;) [03:36] alekibango (~john@b59.brno.mistral.cz) left irc: Remote host closed the connection [03:36] but if you really want vserver, give Mandrake a second thought, is is very similar to RH and in some aspects easier to handle ... [03:51] Bertl: where is the wishlist for the kernel-interface? [03:52] hmm, good question ... you want to add something? [03:52] wish1: s!short int!ctx_t! [03:53] wish2: a getctx(ctx_t) syscall (or function of the multiplexer) [03:53] instead of the proc interface, I presume? [03:53] I mean 'getctx(pid_t)' [03:53] yep; /proc is bad [03:54] hey, something we can agree on after all ;) [03:54] okay, just make a 'hidden' page on the wiki ... [03:55] what is with the chrootsafe() syscall? It sounds that it would be independent from security-contexts. Does it have an official syscall-number? [03:55] nope, I'm not even sure it _is_ chsaferoot() after all ;) [03:55] will need some tests, are you interested in doing this? [03:56] no; I do not have time for tests [03:56] okay, if you find someone, let me know ... [03:56] why do you think that it is not safe? IMO, when you can break it, you can break the current 'chmod 000' also [03:57] I haven't had a deeper look at it yet, so I can't say anything, and I'm not speculating .... [04:04] ad additional syscalls/functions: we'll do that when the syscall switch is in place ... [04:45] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [05:57] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [06:26] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [07:23] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Quit: ipv6 [07:25] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [07:58] mdaur__ (mdaur@p50917040.dip.t-dialin.net) joined #vserver. [08:05] mdaur_ (mdaur@p50917C2C.dip.t-dialin.net) left irc: Ping timeout: 492 seconds [08:47] Nick change: Bertl -> Bertl_zZ [09:03] Nick change: mdaur__ -> mdaur_fudd [09:16] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [09:36] [HvD] (~guess@62.99.252.14) left irc: Ping timeout: 492 seconds [10:26] mdaur (~mdaur@zepto.informatik.fh-ulm.de) joined #vserver. [10:27] mcp (~hightower@wolk-project.de) left irc: Ping timeout: 483 seconds [10:31] gaertner (~gaertnerl@212.68.83.160) joined #vserver. [10:31] moin [10:36] mcp (~hightower@81.17.110.148) joined #vserver. [11:30] rus_ (rghf@212.13.198.100) joined #vserver. [12:02] loger joined #vserver. [12:47] SG1 (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [12:52] alekibango (~john@62.245.97.59) joined #vserver. [13:10] say-out (~cryostar@212.86.243.154) joined #vserver. [13:16] Nick change: say-out -> say [14:10] alekibango (~john@62.245.97.59) left irc: Remote host closed the connection [14:48] alekibango (~john@b59.brno.mistral.cz) joined #vserver. [14:56] shadow (~umka@212.86.233.226) joined #vserver. [14:56] Hi all [15:24] serving (~serving@213.186.190.124) left irc: [15:34] mdaur (~mdaur@zepto.informatik.fh-ulm.de) left irc: Quit: Client exiting [15:42] say (~cryostar@212.86.243.154) left irc: [15:55] say (~cryostar@212.86.243.154) joined #vserver. [15:55] Nick change: say -> say-out [17:32] Nick change: unriel -> riel [17:49] say-out (~cryostar@212.86.243.154) left irc: Read error: Connection reset by peer [18:00] say-out (~cryostar@212.86.243.154) joined #vserver. [18:18] serving (~serving@213.186.190.113) joined #vserver. [18:22] Nick change: Bertl_zZ -> Bertl [18:22] Hi Herbert [18:22] hi alex! [18:23] you wanted to talk about something yesterday, but I still don't know what ;) [18:24] :) [18:26] [root@rh73-alex root]# mount -o remount,usrquota,grpquota / [18:26] [root@rh73-alex root]# [18:26] [root@rh73-alex root]# quotaon -a [18:27] hmm, yes? [18:27] hi matt, by the way! [18:28] Sorrty, Herbert - it`s for me.. [18:28] ahh crash tests again? [18:29] again and again :) [18:29] and new points :) [18:30] @matt had you time to try the latest mq/cq patches since I released them a few weeks ago? [18:30] yes [18:30] running in production [18:30] stable [18:30] but doesn't work [18:30] :) [18:30] hmm, stable sounds good, doesn't work not .. please elaborate ;) [18:30] [root@vps3 root]# /root/cq-tools-0.06/cqhadd -v /dev/hda3 [18:30] adding quota hash for /dev/hda3 ... failed: Function not implemented [18:31] hmm, and /dev/hda3 is what partition? [18:32] root [18:32] okay, that explains it ... [18:32] oh shit [18:32] n/m [18:32] ctxquota mount flag [18:33] exactly ;) [18:33] or is it just 'ctx' now ? [18:33] tagctx ... [18:34] that's a killer [18:34] LOL [18:35] maybe I should add a verbose error message which explains the different reasons for this return code ;) [18:35] yes [18:35] should be sufficient just for cqhadd [18:35] i completely forgot about that change [18:35] ok, then yes your code works good so far [18:35] no complaints [18:36] I hope that this tool will be integrated in the util-vserver package so this issue should be resolved soon ... [18:36] almost 4 days uptime [18:36] the c17f (or the final stable release should be even better ;) [18:36] c17e [18:37] c17f is the release candidate for vserver-1.0.0 8^) [18:38] I don't know how your distro mounts root, but it might be necessary to specify the rootflags=tagctx on the kernel command line, if no initial ramdisk is used ... [18:38] no, it's fine [18:38] c17f will have vserver within vserver ? [18:39] no, this will probably have to wait for some testing ... [18:39] [root@vps3 cli]# mount | grep hda3 [18:39] /dev/hda3 on / type ext3 (rw,tagctx) [18:39] [root@vps3 cli]# /root/cq-tools-0.06/cqhadd -v /dev/hda3 [18:39] adding quota hash for /dev/hda3 ... failed: Function not implemented [18:39] hmmm.... [18:39] hmm, you did not try a remount, did you? [18:40] yes i did [18:40] that doesn't work? [18:40] nope ... [18:40] that sucks. [18:40] :) [18:40] it is technically possible but gives a lot of troubles if you use it .. [18:41] all inodes opened so far would suddenly contain context information and therefore be written with wrong context info at sync ... [18:44] it seems you do quite some tests on the vserver kernels, (network/memory/etc) would it be possible to make some notes, so others could make their own tests, or extend them? [18:46] Attention: vserver.error@solucorp.qc.ca [18:46] A problem was found in an Email message you sent. [18:46] This Email scanner intercepted it and stopped the entire message [18:46] reaching its destination. [18:46] The problem was reported to be: [18:46] Disallowed file (huafijdd.exe) assosiated with unrelated MIME type (audio/x-wav) - [18:46] potential virus [18:46] Hmmmm [18:47] Bertl: i will see what I can do, right now I have MUCH bigger problems :) [18:47] @nesh on which list, the old or the new? [18:47] MAIL FROM: vserver.error@solucorp.qc.ca [18:47] like the server with my largest customers going down every day [18:47] @matt can we help? [18:47] Bertl: it's alex's code on that server... need it because many people want to use iptables [18:48] well that code is debugable too ;) [18:48] yes [18:48] it's come to the point [18:48] that I ordered another server [18:48] to use as a terminal for serial console :) [18:48] i figured $99 for the server is not bad consider I can put a few vps's on it and use it for data backup along with debugging [18:48] good idea ... you know where to find the wiring schematics ... [18:49] lol well it's up to my ISP to do that :) [18:51] what exeactly brings him down? [18:51] just a hang, or some panic ... or ooM? [18:53] no clue [18:53] most of the time it's in a "hung" state [18:53] tcp connections answer, but no answer back [18:53] no serial yet, I presume? [18:53] nope [18:53] they say they see a panic on the screen [18:53] but no way to copy that [18:54] gee, that would be helpful ... [18:54] i asked about borrowing a port on their terminal server but they said they don't have enough ports for themselves :) [18:54] having 19 real vps's on a server brings out so many problems that are impossible to replicate in a lab [18:55] you could let control/monitor your servers each other ... [18:55] huh? [18:55] with some cable between them ... [18:55] yes [18:55] that is the plan [18:55] I assume you have more than one server ... [18:55] serial and private network [18:56] and something to reset them ... [18:56] oh, all different datacenters [18:56] hmm, so no two servers in the same datacenter? [18:57] yaya i got a panic [18:57] Bertl: no, not until this new server is setup [18:58] Oct 10 09:20:03 vps4 kernel: EIP is at clear_inode [kernel] 0x94 (2.4.18-27.7.x) [18:58] kswapd error [18:59] matta it bug in base vserver ? [18:59] shadow: nope [19:00] shadow i'm e-mailing to you now [19:00] Bertl: want a copy? [19:00] why not ... [19:00] addy? [19:00] yeah why not [19:00] i'll do 13thfloor.at [19:01] perfect ... [19:01] sent [19:02] oh, no reverse dns [19:02] guess Bertl doesn't get it :) [19:03] put it on the web ... thats easier ;) [19:04] shadow: that is definitely where it is crashing, i have that same error twice in my logs [19:05] both right before my reporting software says server is down [19:11] http://66.103.140.20/10-10-oops.txt [19:11] see if you make any sense from that :) [19:12] you ran out of memory, and the system tried to shrink the inode_cache (my first guess) [19:12] both oops are different codepaths [19:12] destroy inode then does something (on the ctx info) which should not be done ... [19:12] but both in kswapd [19:13] @alex have a deep look at the destroy_inode() ... [19:13] but what about the first [19:13] that doesn't touch destroy_inode [19:14] not? did I look at the wrong oopses? [19:14] oh wait [19:14] yes it does [19:14] lol [19:14] my bad [19:17] in current i can`t work with this oops... at workplaces started test for smp and time wait sockets. [19:17] hmm, what looks strange to me is that in both decoded oops a call 4(%eax) is the cause ... do you call function pointers? [19:20] Bertl> i have opinion - swaps inodes not have pointer to context :-\ [19:20] in this part i not have changes.. [19:23] @alex,matt can you show me the clear_inode code of this kernel? [19:23] yes [19:23] what file is it in? [19:24] inode.c [19:24] i not patch this function. [19:24] serving (~serving@213.186.190.113) left irc: [19:24] so it's stock 2.4.18-27.7.x [19:26] errors not in destroy_inode.. [19:26] where? [19:26] or in clear_inode or prune_icache [19:27] okay what was the patch, I have the 2.4.18-27.7.x on my server ;) [19:27] Bertl: www.freevps.com/snapshots [19:27] the latest rh-vserver.. [19:27] serving (~serving@213.186.190.113) joined #vserver. [19:27] @matt please a number or url ;) [19:27] the error is hard to reproduce, no one specific thing will do it [19:27] Medivh (ck@server1.shell-express.de) left irc: Read error: Connection reset by peer [19:28] http://www.freevps.com/download/snapshots/rh-vserver-1065436704.diff.gz [19:28] i think it's just something that ocurrs under heavy load [19:28] @matt thanks ... [19:28] matta - yes. all errors be show in heavy load... [19:29] @matt do you compile ther kernel with debug symbols? [19:29] Bertl: no [19:29] Bertl - all rh kernels have option kallsyms enabled by default. [19:30] alex... [19:30] yeah, but with debug (-g) you'll get a line number too ;) [19:30] i see i sent you a kswapd error before [19:31] @matt could you scan your logs backwards ... maybe some error is thrown before? [19:31] your response was: [19:31] Hm.. it`s oops in "clear_inode". hm.. i see similar oops where porting my path [19:31] to vanila kernel. Panic in DQUOT_DROP in start kernel, because some inode not [19:31] have pointer to context. [19:31] Bertl: no, that is where I got the oops from... [19:31] Bertl: no other messages around them [19:31] must not be directly around them ... [19:31] s/must/may/ [19:32] nothing [19:32] just normal [19:32] okay, just wanted to know ... [19:33] @alex okay it's in DQUOT_DROP ... [19:34] reload 10-10-oops.txt [19:34] same message from july is there [19:34] sb->dq_op->drop(inode); /* Ops must be set when there's any quota... */ [19:34] this causes the panic ... [19:34] sb is there ... sb->dq_op is not ... [19:34] drop is at location 4 of dq_op ... [19:35] hm.. [19:35] this results in call *0x4(%eax) going to void ... [19:35] include/linux/quotaops.h (line 62) [19:35] should read: [19:35] if (sb->dq_op) [19:36] sb->dq_op->drop(inode); [19:36] and if you had merged my quota code, this would not had happened *G* [19:36] LOL [19:36] yay Bertl ! [19:36] you are my hero [19:38] Bertl> one problem - alls sb`s have inited sb_op. [19:38] nope ext3 don't ... [19:38] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [19:39] at least not all the time ... [19:40] hmm.. i check.. can be add BUG_ON(sb->dq_op == NULL) for check it.. [19:40] make it a warning only ... [19:41] printk("dear matt, we have some problem here\n"); should be enough ...# [19:41] LOL [19:41] do that :) [19:41] not warning. [19:42] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [19:42] soryy - i must go to check my SMP test. i returned after 10-15 mins. [19:42] returned [19:42] Bertl: you may get some testing docs for this [19:42] i must go to lunch too [19:42] be back in 30 mins [19:43] @alex look at quota_on/off the dq_op is changed there ... [19:44] how old is everone? [19:44] 22 [19:44] everyone is too old, I'm 33 ;) [19:44] i'm 27 [19:44] :) [19:45] serving (~serving@213.186.190.113) left irc: Ping timeout: 480 seconds [19:48] @alex but I guess that the real reason for this panic is not in your code [19:49] go figure [19:49] I'm searching since a while for some inodes with S_QUOTA set but without a dquot ... they seem to exist ... otherwise this codepath would not be triggered ... [19:50] server locked up while compiling with fix [19:51] hmm, server locked up - while compiling - with fix or server locked up - while compiling with fix ? [19:51] compiling kernel who has the fix [19:52] serving (~serving@213.186.189.167) joined #vserver. [20:01] fungu! [20:01] DDOS on nameservers [20:17] huh? [20:17] hmm, huh what? [20:18] ddos on nameservers? [20:19] shadow: do you have a patch with the umount fix? [20:21] Bertl: so why would that codepath panic under alex's code but not default kernel? [20:21] no the default kernel will walk it too, but quota is not per server ... [20:23] so... i don't understand why it would panic [20:23] alex uses the same path for his vserver disk limits? [20:24] it is the quota drop, when an inode is released from the cache ... [20:25] this doesn't happen unless memory is low and the swapper decides to free up caches ... [20:25] weird [20:25] it isn't hit by the disklimit stuff ... because this doesn't use the quota operations ;) [20:25] at least I hope it doesn't *G* [20:25] hrm [20:26] okay I'll get something to eat now, brb (ca 20min) [20:28] your if statement has been added, let's see how it runs now... [20:50] okay, I'm back ... [20:58] well, 30 mins and good so far :) [20:58] 1:00pm up 31 min, 2 users, load average: 26.68, 22.27, 12.44 [21:05] you can try to trigger it if you do some grep -r (which caches inodes) and then putting some pressure on memory ... [21:05] if you want to verify, add ... [21:05] else [21:05] printk("bad dq_op\n") [21:06] printk("bad dq_op\n"); (of course) [21:33] shadow still here? [21:33] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [21:41] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [21:50] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Read error: Connection reset by peer [22:04] did anybody think about using jfs instead of ext3? [22:04] hmm why? [22:05] hmm, just a question, because ext3 fs corruption seems to strike again ... :( [22:05] hrm [22:05] i saw that benchmark on slashdot [22:05] that said jfs beats the shit out of ext3 [22:05] and ext3 journaled is the slowest fs of all [22:06] I'm not very comfortable with xfs ... and reiser seems still experimental to me ;) [22:06] xfs seems cool [22:06] dedicated bandwidth [22:06] so jfs would be a considerable alternative [22:06] i'd like to move to jfs/xfs [22:08] hmm, the ILI stuff is working on jfs ... [22:08] ILI ? [22:08] Immutable Linkage Invert ... (the unification flag) [22:09] hmm, tagctx supports jfs too ... [22:10] say-out (~cryostar@212.86.243.154) left irc: Read error: Connection reset by peer [22:10] could work out of the box ... [22:12] I don't trust xfs/jfs yet. they're too new to linux [22:13] hmm jfs is tested what? mor than five years? ... [22:15] and at least 2 years on linux ... [22:15] is it.. [22:17] hrm [22:17] your oom idea may be correct [22:17] Max Swap mem in use : [22:17] 1426.9 MB (69.7%) [22:17] Average Swap mem in use : [22:17] 112.8 MB (5.5%) [22:17] Current Swap mem in use : [22:17] 200.8 MB (9.8%) [22:18] spiked up for a few mins [22:18] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [22:18] usually inodes are only freed when the filesystem is unmounted or memory gets low ... [22:20] this problem is most likely the one from the old patch of alex's too, the one I had to stop using [22:20] since I had the same panic back in july [22:20] hmm, so it hadn't been reported yet? [22:20] i reported it [22:20] but he said he couldn't reproduce [22:20] so it never got fixed [22:21] jack (~jack@206.162.172.138) joined #vserver. [22:21] hi jack! [22:21] Hi [22:21] hi [22:21] I received a solution for ping written in perl [22:22] huh? [22:22] Basically, this is a small perl daemon running in the root server and crearing a /dev/ping in all vservers [22:22] Then a small faked ping client in a vserver allows one to ping with no need for CAP_NET_RAW [22:22] Is there anyone who came with another solution [22:23] hmm, sounds interesting ... but wouldn't be some kernel solution more apropriate? [22:23] The problem with ping is that beside ping (and traceroute), no other apps need to implement this IP protocol [22:23] hey [22:24] so what they did is set ping as a setuid program and let it do RAW socket. This is a neat solution (keep the fluf out of the kernel) [22:24] what about a way for the kernel to trap the reboot so normal reboot/shutdown commands can work? [22:24] that should be easy ... [22:24] Someone implemented that a while ago [22:24] paul did [22:24] but never even tested it himself [22:24] hmm, url? sources? [22:25] Anyway, this ping stuff. Should it be included ? [22:25] alekibango (~john@b59.brno.mistral.cz) left irc: Quit: Client killed by consultant [22:25] you mean in newer tools, or what? [22:26] I mean this ping daemon and fake ping client. I can post it to the mailing list if you want [22:26] yes, go ahead ... you don't have to ask me for posting something to the list ;) [22:26] i would like to test it [22:27] last time I proposed some modified tools inside a vserver, the response was, no we can't do that ... but if somebody wants to do it this way, why not ... [22:27] if the ping/traceroute is such a required feature, we can address it from the kernel too ... [22:28] the only thing I use ping for is checking if network conenctivity is there or not ;) [22:28] This means we are moving this part of the ICMP protocol inside the kernel [22:28] Yes and this is the reason people would like to ping from a vserver [22:29] well, on a vserver you already _know_ that the server _has_ connectivity ... [22:29] and if you want to test for the vserver ip, you can always do it on the host ... [22:29] Yes but in general, you also want to test some other server in case they are down or whatever [22:30] well hearbeat should be udp ... by the way, why not use udp pings? [22:30] Quite often you wonder check with ping for whatever reasons [22:30] No you really need to ping, the real ping. This is in line with the idea that a vserver must behave like a normal server. [22:31] People are used to use ping to check if this or that host is alive and so on. [22:31] okay, maybe be should focus on the virtual network then ... [22:31] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [22:32] Maybe. (virtual network). How does it work [22:32] 01:40:03 PM 118052.82 [22:32] context switches per second... [22:32] maybe alex could explain the internal, and matt the user perspective ... [22:33] it's a lot of code, i can tell you that [22:33] touches a lot [22:33] I haven't had a deeper look at the network stack, but I'm thinking of something like the tun/tap devices for vserver ... [22:34] maybe with some inherent limitation/verification this could be used ... [22:34] you may want to look at freebsd's implementation [22:34] i believe I sent you the doc [22:36] @matt what I meant was, maybe you could explain _what_ the vserver user _requires_ such a virtual network to do/provide ... [22:36] oh [22:36] sure :) [22:36] primarily: iptables within vserver [22:37] secondary: integration with other systems [22:37] uptime.. [22:37] function more like a real server [22:37] it allows vservers to have own loopback and own network devices [22:38] the network devices work like a bridge, and allow you to attach an interface in a vserver to one on the physical host [22:38] ie. vifconfig --ctx 1 --device eth0 --attach eth0 [22:38] make that ctx 2 [22:38] creates an eth0 in ctx 2 that is attached to the physical hosts eth0 [22:39] @jack we could for example tag all packets on the stack as coming from/targeted at a special vserver, and just indirect the tables for that ... [22:39] you then do [22:39] vifconfig --ctx 2 --device eth0 --addipv4 192.168.1.2 --ipv4netmask 255.255.255.0 [22:39] for each IP... can be done in realtime, no need to restart vserver to add an ip [22:40] the vserver can then ifconfig the designated ip's on the designated interface with the designated netmask [22:40] what happens if you config the wrong ip in the vserver? [22:40] it uses the normal network startup scripts [22:40] Bertl: permission denied [22:41] the checks are very strict, so strict I removed the netmask check for my personal servers [22:41] only "ip" will work default because ifconfig brings all ip's up with a default netmask of 255.255.255.0 then changes it [22:41] then the vserver can modify interfaces, iptables, and routing table [22:41] but not sysctl's [22:43] [root@www /]# ifconfig eth0 inet 192.168.1.1 netmask 255.255.255.0 [22:43] SIOCSIFADDR: Invalid argument [22:43] SIOCSIFNETMASK: Cannot assign requested address [22:43] that's the error [22:43] sounds good ;) [22:48] jack? what do you think, can we do that? [22:48] just use alex's code [22:48] :) [22:48] hrm, no thanks, enough debuging for today ;) [22:48] hahaha [22:49] but yes, we'll probably have a look at it anyway ... [22:49] http://www.tel.fer.hr/zec/papers/zec-03.pdf [22:59] @matt what if you assign/allow one address for two vservers? [23:00] and then configure it from each vserver? [23:01] Bertl: i never tried that, actually. [23:02] hmm, could you then? *smile* [23:04] hmm seems like honza confirmed some ext2/(ext3?) quota lock ... [23:07] -` [23:09] - [23:09] [23:09] Medivh (ck@server1.shell-express.de) joined #vserver. [23:10] hmm, kind of ASCII art? [23:11] haha [23:12] maybe that guy is trying to communicate? -` - -` [23:27] hi dude++ [23:28] - [23:28] hi ASCII artist-- [23:33] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [23:34] serving- (serving@213.186.190.72) joined #vserver. [23:39] serving (~serving@213.186.189.167) left irc: Ping timeout: 492 seconds [23:40] JonB (~jbendtsen@217.157.144.114) joined #vserver. [23:40] evening [23:40] hi jon! [23:41] hey Bertl [23:41] Bertl: any news? [23:42] regarding what? [23:43] serving- (serving@213.186.190.72) left irc: Ping timeout: 492 seconds [23:45] Bertl: _ANYTHING_ ;-P [23:45] Bertl: i'm sitting at work copying data from one HD to another :/ [23:46] (has to make the LVM support more than 256G [23:48] well there is c17f as prerelease ... [23:48] and we where discussing virtual network stack requirements ... [23:48] okay [23:49] we fixed/found some bug? in alexeys vserver implementation [23:50] any news on your work? [23:52] 147G left [23:52] to move [23:52] they might just hire a friend of mine [23:52] which means i score 15.000 dkr (about 2? [23:52] 2k? [23:53] alexys? made his/theirs own implemention [23:54] well he made some improvements, based on the RH kernels ... [23:55] what improvements was that? [23:55] network virtualization, and basically the limits (disk, memory, ...) [23:56] requirements ... [23:56] okay [23:56] we fixed/found some bug? in alexeys vserver implementation [23:56] any news on your work? [23:56] 147G left [23:56] to move [23:56] they might just hire a friend of mine [23:56] which means i score 15.000 dkr (about 2? [23:56] 2k? [23:56] alexys? made his/theirs own implemention [23:56] NICE [23:56] hmm .. [23:56] i like the memory stuff [23:58] weell [23:59] myscrenn was close and something fall on tha keyboard [23:59] hmm interesting explanation ;) [23:59] Bertl: heh [00:00] --- Sat Oct 11 2003