[00:02] RH (~john877@24.171.21.47) joined #vserver. [00:02] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [00:04] MEEP [00:39] hrm... kswapd using lots of CPU again [00:56] JonB (~jon@194.239.210.46) joined #vserver. [01:36] Nick change: riel -> unriel [01:40] JonB (~jon@194.239.210.46) left irc: Quit: zzzzzzzzz [01:56] RH (~john877@24.171.21.47) left irc: Ping timeout: 485 seconds [02:24] kestrel_ (~athomas@192.65.90.92) left irc: Ping timeout: 492 seconds [02:33] kestrel (~athomas@202.139.83.4) joined #vserver. [02:33] morning [02:34] or good [03:10] matta (matta@69.10.150.254) left irc: Ping timeout: 492 seconds [03:43] matta (matta@69.10.150.254) joined #vserver. [03:48] RH (~john877@24.171.21.47) joined #vserver. [04:09] Nick change: Bertl_oO -> Bertl [04:10] hi all! [04:11] hi! [04:11] hi dan! [04:12] RH (~john877@24.171.21.47) left irc: Ping timeout: 485 seconds [04:26] @kestrel per vserver uptime isn't a big deal ... if you are willing to test, I can code up a patch ... [04:28] hi [04:28] hi matt! [04:28] TESTERS!!! [04:28] YAYAYA [04:28] so i tried to load c17h, o1, rmap, etc... [04:28] on SMP [04:29] server boots up, i can ping it [04:29] as soon as I try to ssh in, it hangs [04:29] and of course it's in a different country.... [04:29] MrBawb: if I gave you my patchset could you test it on smp ? [04:29] hmm, interesting .. so basically something is different to the stuff dan tested then? [04:29] Bertl: yes [04:30] what is it? [04:30] personally, i'm looking on ebay for old ppro SMP servers... but if he could test now that would be great [04:31] Bertl: well, if MrBawb can load up the kernel with the exact patches maybe we can see... [04:31] it's early in boot [04:31] lasted about 20 ping's [04:31] well, you didn't add the var Hz and your fake mem patches, right? [04:31] matta: how about you try the patches I did :) [04:31] MrBawb: this is everything, includes rmap, etc... [04:31] yeah, I did O(1)+rmap+c17h [04:32] ran it for 24 with 2 vservers [04:32] Bertl: no var hz, yes to fakemem but same without it... i knew you would ask that [04:32] 24 hours [04:32] this is... [04:32] [04:32] patch-2.4.23-pre8 [04:32] patch-2.4.23-pre8-O1.3.diff [04:32] patch-2.4.23-pre8-O1.2-rmap15k.diff [04:32] patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff [04:32] patch-2.4.23-pre8-O1.3-rmap15k-c17h-ml0.07.diff [04:32] patch-2.4.22-ctx17a-fakemem.diff [04:32] patch-2.4.23-pre8-O1.3-rmap15k-c17h-qh0.12.diff [04:32] patch-2.4.22-c17e-mq0.10-cx0.06.diff [04:32] patch-2.4.22-c17e-mq0.11-cx0.06-cq0.11.diff [04:32] patch-2.4.22-c17e-mq0.11-cx0.06-cq0.11-dl0.05.diff [04:32] patch-2.4.22-ctx17a-vr0.13.diff [04:32] patch-c17e-signal-ctx1.diff [04:32] no-proc-mounts.diff [04:32] no-hostname.diff [04:32] it may be ml, or qh/cx/cq/dl... [04:32] anything... [04:33] heh, what is all that? [04:33] MrBawb: qh = quota hash [04:33] then everything up to disk limits... [04:33] virtual root [04:33] okay, so it is quite reproducible for you then? [04:33] ability to send signals from context 1 [04:33] disable /proc/mounts in contexts [04:33] and remove the hostname from the build so /proc/versions shows something else [04:33] but you cannot test with this system, because it is out of hand, right? [04:34] Bertl: right... different country :) [04:34] i can tar up this directory, it's easy to apply it to a stock 2.4.22 tree [04:34] matta: send it to dan@drown.org, and I'll take a look [04:34] hmm, you don't have some remote control tool, as I suggested on the web page, right? [04:34] Bertl: no, that's impossible [04:35] nothing is impossible, you have to believe ;) [04:35] i don't how much you deal with hosting providers, but they like to not do anything too much out of normal range [04:35] oh, if i purchased a rack at someplace around my residence it would be possible [04:35] but most all hosting providers will say "no" [04:36] heh [04:36] well I had to deal with some of them, and it was never a problem to have 2 servers on site connected via some gray/black cable ;) [04:36] 2 servers is also a problem :) [04:36] almost ordered one so I could, they will do it [04:37] even give me the cable for free :) [04:37] I know a hosting provider you should put your servers in :) [04:37] i know of a hosting provider that charges 6x what I pay now [04:38] heh [04:38] latest server I got... dual athlon mp 2000+, 4GB RAM, 2x80GB HDD, 10mbit un-metered.. i'm paying like $550/mo [04:38] okay, but you agree that it is a logistical problem on your side, right? [04:38] Bertl: correct [04:38] MrBawb: i would love to put them at the hosting provider you mention :) [04:40] MrBawb: in your mail... [04:40] :) [04:41] okay, so what is the consequence when you lockup that machine? [04:41] what has to be done, to get it working again? [04:41] Bertl: I call them up and it's rebooted normally within 5 minutes [04:42] datacenter is on-site with support staff, no remote hands [04:42] and this costs you? [04:42] no [04:42] that's free, anything else such as having them type stuff and read me stuff costs me [04:43] okay, so we could basically do some (limited) tests, correct? [04:43] well, except for the 50 or so pissed off customers, yes [04:43] well, you could probably do it when they are asleep, right? [04:44] really, i'd rather spend $100 on ebay and buy an old dual ppro server to test everything on [04:44] Bertl: they don't sleep at the same time :) [04:44] that would be a good thing, but maybe you cannot reproduce on this machine .. only on the one in question ... [04:45] that's a valid point, but it's better to know than to blindly change things [04:46] okay, just discribe what exactly you did to this poor fella ... [04:46] if Bawb tests the exact patches and has no problems, then I would concede i must look for something wrong on that server [04:46] i rebooted, it came up and pinged [04:46] i tried to ssh in, it stopped pinging [04:46] rebooted again... [04:46] pinged it, let it go for 20 or so pings [04:46] as soon as I tried to ssh in it hung again [04:47] okay, did you try one of the vservers' services, like web or so? [04:48] everything was down [04:48] so basically the whole system didn't start/work, except for the network stack, right? [04:49] well, actually... [04:49] i'm looking through the boot logs [04:50] looks like it started sshd, named, httpd, etc... [04:51] that's odd, so it looks like it hung on the first tcp connection [04:53] motherfuck [04:53] bawb i guess i didn't attach it did i [04:58] matt, after some consideration, I would suggest to remove the O(1) scheduler and keep everything else in your mix for a test (of course, if possible) ... [05:08] serving- (~serving@213.186.190.157) left irc: Ping timeout: 488 seconds [05:13] bertl: i'd be more than happy to test a per-vserver uptime patch [05:13] don't go out of your way to do it though, it'd just be a cool thing to have :) [05:16] definitely cool [05:47] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-c17h-uptime.diff [05:47] okay, please test it ;) [05:54] awesome :) [05:54] that was swift :) [05:54] 8-) [05:58] very cool [05:58] i'll test it when i get home [05:59] okay, just send me a mail with the results ... [05:59] shall do [06:04] RH (~john877@24.171.21.47) joined #vserver. [06:29] Simon (~sgarner@210.54.177.190) joined #vserver. [06:30] hi simon! [07:00] serving (~serving@213.186.191.184) joined #vserver. [07:06] man i wish i wasn't at work [07:06] stupid work [07:16] ensc (~ensc@ultra.csn.tu-chemnitz.de) left irc: Quit: Terminated with extreme prejudice - dircproxy 1.0.5 [07:21] ensc (~ensc@ultra.csn.tu-chemnitz.de) joined #vserver. [07:57] mdaur__ (mdaur@80.145.122.17) joined #vserver. [08:04] mdaur_ (mdaur@80.145.103.67) left irc: Ping timeout: 485 seconds [08:21] shadow (~umka@212.86.233.226) joined #vserver. [08:21] morning... [08:21] morning alex! [08:23] herbert how are you ? [08:24] fine thanks, how are you? [08:25] :) five minutes after awake :) i don`t know :) [08:26] but see test work without deadlocks.... [08:26] it`s good :) [08:27] ;) [08:29] you see my private message ? [08:31] regarding linux bugs? [08:32] yes.. [08:32] i fix it triall [08:33] add DQUOT_DROP(file->f_dentry->d_inode); [08:33] file->f_dentry->d_inode->i_flags |= S_NOQUOTA; [08:33] s/triall/trivial/ [08:33] to [08:33] sock_map_file [08:34] after it on ext2 i can`t see it bug.. [08:34] hmm, where exactly? [08:34] net/socket.c [08:35] over 365 line [08:38] hmm, and why should the socket inode have/not have quota? [08:38] but if do cycle start/stop vps at one console and cycle with mount -o remount at second - on ext3 fs have dead lock on journal_stop :-\ [08:39] Bertl> because it network operations - but quota is disk operations. [08:40] and if minilogd not be killed at stop vps and quota be stoped we have deadlock on wait when this inode be freeed [08:41] okay, but either the inode is on a disk filesystem (with quota enabled) then it should get quota, or it is not, in which case it will not get any? [08:42] and it is perfectly okay for quotaoff to wait on used inodes .. just open some file (or even lock it) on a quota enabled partition, and you'll have to release it, to make quotaoff succeed ... [08:43] same as with umount ... [08:44] but you think - read/write from\to unix sockets must be controled with diskquota ? [08:45] i can send to you logs where it show. [08:46] how should something not on a quota enabled disk get a dquot? [08:47] it`s before fix. [08:51] well, if the socket it created _on_disk_ I expect it to be accounted by the quota system, right? [08:53] Simon (~sgarner@210.54.177.190) left irc: Read error: Connection reset by peer [08:53] not [08:54] but if you think, socket quota is wrong (I do not agree on that), then why do you add the dquot in the first place? [08:54] where i add ? [08:55] I would suggest to modify DQUOT_INIT in such way, that it doesn't add quota to socket inodes ... [08:55] but if we do this way [08:56] 1) create file on fs [08:56] 2) map socket to file [08:57] we be have socket who accounted with diskquota [08:57] but if add only my fix it not do. [08:59] at first point my have regular file passed as argument to sock_map_file [09:02] first, you are talking about sock_map_fd() right? [09:02] this returns a 'new' file descriptor for an existing socket, okay? [09:05] why should this change the dquot of the socket->inode? [09:07] the socket is located on sock_mnt/sock_fs_type if anonymous ... so it will not receive any quota ... [09:07] i don`t know but have other way for call :( [09:07] if, OTOH, the socket is on the disk/partition, it will and it should receive quota ... [09:08] okay, anyway, if you still think this is a quota bug, please contact Honza ... [09:09] okey. i make logs and write mail to Honza [09:10] okay, I'll go to bed now ;) [09:10] have a nice whatever ... cu l8er ... [09:10] Nick change: Bertl -> Bertl_zZ [09:11] good greams [09:40] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [09:43] Simon (~sgarner@apollo.quattro.net.nz) left irc: Client Quit [10:06] kestrel_ (~athomas@dialup28.optus.net.au) joined #vserver. [10:06] hey [10:08] kestrel_ (~athomas@dialup28.optus.net.au) left irc: Quit: ircII EPIC4-1.0.1 -- Are we there yet? [10:21] kestrel_ (~athomas@dialup28.optus.net.au) joined #vserver. [10:22] hello (again) [10:54] kestrel_ (~athomas@dialup28.optus.net.au) left irc: Quit: ircII EPIC4-1.0.1 -- Are we there yet? [11:05] kestrel_ (~athomas@dialup28.optus.net.au) joined #vserver. [11:05] bertl: the uptime patch works!!! :) [11:06] [root@dhcp:~]uptime [11:06] 19:07:16 up 0 min, 0 users, load average: 0.60, 0.75, 0.41 [11:06] [root@blink:~]uptime [11:06] 19:08:14 up 10 min, 2 users, load average: 0.63, 0.70, 0.41 [11:06] vserver and real server, respectively [11:16] re [11:18] hey [11:45] shadow (~umka@212.86.233.226) left irc: Quit: brb [12:04] shadow (~umka@212.86.233.226) joined #vserver. [12:27] kestrel_ (~athomas@dialup28.optus.net.au) left irc: Ping timeout: 483 seconds [12:33] kestrel_ (~athomas@192.65.90.92) joined #vserver. [12:44] hmm [13:47] kestrel_ (~athomas@192.65.90.92) left irc: Quit: vserver upgrade [13:52] say-out (~say@212.86.243.154) left irc: Ping timeout: 492 seconds [13:59] kestrel_ (~athomas@dialup28.optus.net.au) joined #vserver. [13:59] aah [15:07] say-out (~say@212.86.243.154) joined #vserver. [15:32] Nick change: RH -> netrose [16:39] Nick change: unriel -> riel [17:23] Nick change: Bertl_zZ -> Bertl [17:24] hi all ... [17:25] hey bertl [17:25] so it is working ... [17:26] hi alec! [17:27] Bertl: Good morning. :) [17:28] good moring alex! [17:28] bertl: it is indeed :) [17:28] the uptime patch is all good :) [17:30] any other 'simple' nice-to-have features? [17:31] hi [17:31] hi shuri! [17:33] vserver-1.0.0 release today? [17:33] per-vserver load average? :) [17:33] though i suspect that might be a bit more mojo [17:34] per-server uptime is cool! [17:34] sam had a point, as he said, why not release it as 0.9 (actually it would be 0.8 then), and the syscall switch version as 1.0 ... what do you think about it? [17:35] still we have the problem, that jack didn't release the updated tools (I requested from him) yet ... [17:36] btw herbert, i upgraded to c17h and haven't had any issues [17:36] and I did not receive _any_ feedback for non i386 platforms yet ;) [17:37] s/;)/:(/ [17:38] heheh :) [17:38] my my, why could that be i wonder? [17:39] I assume, because the attention span of the average vserver user is too small to give any feedback ... [17:42] well, that couldn't possibly be the case in my situation...it's actually because it's my work system :( [17:43] say-out (~say@212.86.243.154) left irc: Read error: Connection reset by peer [17:43] I guess that non-x86 hardware isn't that common. [17:43] Although I have an Alphastation 200 4/166 under my desk that isn't doing anything. :) [17:45] hehe [17:45] what people often don't realize is, that a small efford by oneself, could be (re-)used many times by others ... [17:46] for example, you all know that I try to explain things as often as possible ... [17:47] but if everybody who asks a lot of questions, would add those to a FAQ, including the answers, there would be no need to explain the same things over and over again ... [17:53] agree [17:57] say-out (~say@212.86.243.154) joined #vserver. [17:57] say-out (~say@212.86.243.154) left irc: Client Quit [18:02] oh yeah... i have stuff like that in my dmesg [18:02] DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh!DQUOT_DROP: inode without dqh! [18:02] i guess you're beyond that though :) [18:03] hi matt! [18:03] is this with the qh0.12/cq0.11 or with an earlier version? [18:11] Hi Herbert [18:11] hi alex! [18:12] hm.. it`s not be can so with my problem on diskquota.. where some inodes not have a correctly inited quotaops ? [18:13] huh?, please rephrase ;) [18:14] Bertl> remember half month ago... [18:14] yeah, I remeber the bug we fixed ... [18:14] Bertl: qh0.12 [18:15] my add only check - if dq_ops == NULL then skip and not do real drop. [18:16] yes, that fixed it ... [18:16] but i can`t way where inodes have not inited quota :-\ [18:17] i think it same problem.. [18:17] hmm, could be ... the DQUOT_DROP: inode without dqh messages seem to have a similar source/reason ... [18:18] :) [18:18] may be Matt addeed print debug info ? [18:19] printk("ERROR. inode without dq_ops. c:%d dev:%x ino:%ld [18:19] fl:%.8x", [18:19] inode->s_context == NULL? -1 : inode->s_context->id, [18:19] inode->i_dev, inode->i_ino, inode->i_flags ); [18:19] or simular for you. [18:20] cliu (~icechat5@pcd346179.netvigator.com) left irc: Quit: On the other hand, you have different fingers. [18:20] I was thinking about that, but I don't see any information gain in that, because what we really want to know is: where is/are the dqhash/ops removed, and we won't see that ... [18:21] i_dev / i_ino / flags can be identify inode.. [18:21] i got a problem on one of my box with vserver but dont know if its vserver related [18:22] hmm, let's hear ... [18:22] if i wget in a vserver i got 10 k /speed [18:22] but server run at 100 K + [18:22] like apache [18:22] ftp [18:23] wget lynx ncftp run at 10 k/s max [18:23] Bertl> me seems it "node" files. [18:25] iany idea? [18:25] @matt are you willing/interested in using some debug patches to find/fix the DQUOT_DROP issue, or should I just remove the debug message? 8-) [18:25] @shuri .. well I didn't do any performance tests, but what version is this ... kernel/patches? [18:25] ctx 17 [18:25] on 2.2 [18:25] 2.4.22 [18:26] ctx17 or c17f or c17h? [18:26] Bertl: not right now... [18:26] i connot reboot the server... [18:26] ctx17 [18:26] i would add them when I try to do the O(1) switch again [18:26] i guess Bawb never got to test that [18:27] all services are very fast apache , ftpd ... [18:27] but on shell wget lynx ftp are SLOW!!! [18:28] even on the root server [18:28] type "mii-tool" [18:28] might be a port speed/duplex mismatch [18:29] definitely vm problems in 2.4.22 [18:29] seems server won't use more than 1.6GB of physical memory (or it always wants to use 1.2GB of cache) [18:29] and after running for a week any sort of high i/o causes kswapd to use massive amounts of i/o [18:30] er, CPU for the last one [18:30] and then finally kswapd just decides it wants to use 99% of the CPU all the time [18:30] @shuri look with ifconfig and report the errors/dropped/overruns/frame and carrier ... [18:30] and drives loads up and makes the system unusable [18:30] @matt this is with or without rmap? [18:30] i looked and people saw this behavor in 2.4.2... [18:30] Bertl: without [18:31] okay and pre8 does show improved behaviour? [18:31] I casn't boot pre8 [18:31] :) [18:31] casn't == can't ?? [18:31] i'm almost of thinking of doing pre8 without O(1) if I have too... with almost 2000 process and SMP I think O(1) would be like a turbocharger on it though [18:31] Bertl: yes [18:32] this happens once a week guaranteed, other than that the server runs great [18:32] ahh okay so this 2.4.22 was with O(1)? [18:32] Bertl: no, 2.4.22 is stock [18:32] Bertl: just your patches == stock [18:32] okay, you should try one addition after the other ... [18:33] IIRC, pre7/8 fixed some of the 2.4.22 memory/swap issues ... [18:33] well, i'd like to just try rmap but your 2.4.23pre8 rmap patch depends on O(1).. [18:33] Bertl: yes, general vm plus highmem [18:33] then the rmap15k, if it works, should do some good ... [18:33] i guess it's a highmem problem, cache heavy ... [18:34] there are several (possible) issues at a 3G config ... [18:34] the different memory splits of 2.6 would help here too I guess ... [18:35] i must go now... i'll be back in a few hours.. [18:36] okay, cu l8er ... [18:41] @alex have a look at remove_inode_dquot_ref() [fs/dquot.c] [18:41] 1 sec. [18:42] ok. [18:42] do you see anything unusual there? [18:43] not :-\ [18:43] okay let us do some Q&A, right? [18:44] if type not be -1... [18:44] ok. [18:44] remove_inode_dquot_ref is called with an inode, a type (user/group) and the tofree head, right? [18:45] dquot is assigned the quota of this type (could be NODQUOT) [18:45] yes. [18:46] then the quota is removed from the inode, okay? [18:47] then we have the check if any other quota is still enabled ... [18:47] yes... [18:47] if not, the S_QUOTA is removed from the flags ... [18:48] yes. not quota on inode and not have flags.. [18:48] so this should be correct, right? [18:49] how i see - yes. [18:51] good, dquot_drop() does it the other way round ... [18:52] and dquot_initialize() is the only one adding the S_QUOTA, or am I missing something? [18:53] only one - dquot_initialize [18:55] hmm, did we observe those issues on any other fs than ext3? [18:55] static int __init init_ext3_fs(void) [18:55] init_dquot_operations(&ext3_qops); [18:56] old_sync_dquot = ext3_qops.sync_dquot; [18:56] ext3_qops.sync_dquot = ext3_sync_dquot; [19:00] Bertl> it stable problem ext3 and disk quota :) [19:00] for ext3 be replaced quotasync for block deadlock [19:01] see at end fs/ext3/inode.c [20:01] shadow (~umka@212.86.233.226) left irc: Ping timeout: 483 seconds [20:04] Bertl (~herbert@MAIL.13thfloor.at) left irc: Remote host closed the connection [20:08] shadow (~umka@212.86.233.226) joined #vserver. [20:13] grepmaster (~jeffrey@66-101-59-71.oplnk.net) joined #vserver. [20:21] Bertl (~herbert@212.16.62.51) joined #vserver. [20:22] Bertl (~herbert@212.16.62.51) left irc: Client Quit [20:24] will 1.0.0 release have per context quota and disk limits all in one patch? :) :) [20:28] Bertl (~duke@212.16.38.67) joined #vserver. [20:28] grepmaster ask Herbert (bertl) [20:29] @grepmaster what's up? [20:32] hir interested context quota and disklimits in vserver 1.0.0 [20:37] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [20:39] will 1.0.0 release have per context quota and disk limits all in one patch? [20:39] no [20:39] sorry, was away for a sec, a cat wandered in and i had to do something about it [20:39] ok [20:40] what is planned for 1.0? is there a page about it? [20:41] well if I don't change my mind in the last minutes, 1.0 will have the same features as c17f ... [20:41] allright [20:42] i plan on trying to run this on an SMP sparc64, so there will be bug/success reports whenever i get to that [20:43] sounds good to me ... [20:45] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Quit: leaving [20:53] crap [20:53] looks like vserver can't be integrated well with selinux ;( [20:53] hmm ... [20:53] how so? [20:53] the selinux security policy database is system central [20:54] can't be virtualised in any sane way [20:55] maybe I should help Jeff Dike implement kUML [20:55] :) [21:02] matta: yeah, I wasn't able to test it because the patches didn't compile without CONFIG_QUOTA defined :) [21:03] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [21:03] but for now, the hard work is in CKRM [21:03] which will be needed regardless of which virtualisation is used [21:04] if you say so ... [21:13] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Quit: Lost terminal [21:43] Bertl (~duke@212.16.38.67) left irc: Quit: Bertl has no reason [21:44] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [22:03] i just applied grsec 2.0rc3 after all of the vserver patches, only one reject in namei.c, one in fs/proc/base.c, three in kernel/signal.c [22:03] which were easy enough to manually merge [22:04] one of course must question the sanity of having alll of grsec's chroot restrictions on in conjunction with vserver [22:23] well test it and report your findings ... [22:27] will do [23:27] MrBawb: uhm... you just add linux/major.h to fs/quota.c [23:27] easy fix :) [23:29] what is kUML ? [23:29] kernel UserModeLinux KDE-UML, guesses [23:31] wouldn't it be KML then? :) [23:31] cdrwin [23:31] ? [23:31] KernelModeLinux ? [23:31] UserModeLinux [23:31] a user mode linux with way less overhead [23:32] the obvious difference from vserver is that kUML starts with separate data structures for all the virtual guests, and explicitly needs to decide where they can be shared with the host kernel [23:32] while vserver starts with everything shared, even in places where sharing is inappropriate, and needs to split things out for correctness [23:33] while kUML only needs to merge stuff for performance, correctness is there from the beginning [23:33] don't get me wrong, I like vserver a lot ... I just don't want the infinite pain of trying to virtualise the selinux security mechanism ;) [23:33] well, the difference has always been performance [23:34] it seems everyone with performance in mind has chosen the vserver method [23:34] so i would assume making UML fast is hard :) [23:34] *nod* [23:34] hmm, basically those are two different approaches ... [23:34] having not looked at the selinux security mechanism, is it basically akin to the grsecurity RBACs? [23:35] grepmaster: basically, yes [23:35] virtuozzo, vserver, and then h-sphere is based on vserver... [23:35] all use the same method [23:35] k [23:35] each of them has it's own advantages and disadvantages ... [23:36] the thing we were running into is basically: [23:36] there is the xen approach too [23:36] if you need a high degree of virtualization and separation, you'll go for UML/partitioning ... [23:36] which provides a full system and fast performance [23:36] but requires a custom kernel on the guest [23:36] "each RPM contains its selinux security policy, what happens when you upgrade an RPM that changes its security policy but you do not upgrade the RPM in another virtual host?" [23:36] but, guest's can re-compile that custom kernel even [23:37] Xen is very tempting, but a distro can't be limited by the device drivers the Xen hypervisor supports [23:37] you'd have to have Xen running on Linux, so you can use the Linux device drivers and management tools [23:37] xen would be the ultimate if it didn't need to modify the guest :) [23:37] best of both worlds [23:37] Xen is probably very fast (similar to real partitioning) but you have the same disadvantages as UML has ... [23:37] i like the shared aspect of vserver, makes management easy [23:38] namely the NON-shared resources and the inability to switch between partitions ... [23:38] in short, every existing virtualisation technology for Linux has showstopper issues ;(( [23:38] well, depends on what you want ... [23:39] riel: of course... [23:39] I could argue, linux has a show stopper issue, namely the kernel ;) [23:39] selinux is going to be an integral part of Fedora Core 2 [23:40] well, that is fine, but why should selinux be an issue for vserver? [23:40] they're incompatible [23:40] that is your opinion ... [23:41] unless you want to rewrite the selinux subsystem to be virtualised [23:41] why does vserver need selinux? [23:41] matta: it doesn't [23:41] it seems to do just fine by itself [23:41] @riel you'll have to virtualize it, or to disable/circumvent it ... [23:41] Bertl: that's a pretty good definition of incompatible ;) [23:42] so you would say that network and vservers are incompatible too, right? [23:42] do you even know what selinux does ? [23:42] yes, I had a deep look at their page ... a few weeks ago .-.. [23:43] to see the incompatibility, you'll need to take a deep look at their source code [23:43] in order to make selinux virtualisable, you basically need to rewrite half of it [23:44] not only is it a huge amount of work to do initially, but it'll be hell to maintain such a patch across multiple kernel versions [23:44] I'm sure that it can be done, but I'm not sure that we want it ;) [23:46] basically the installation of an RPM on the host could upset the security policy that's running in the guests [23:47] ask around who would need the security features added by se linux ... you will be surprised how few people actually working with linux systems would need/want it ... [23:47] true, can't be that many more than the people who need vserver ;) [23:47] Action: riel runs [23:48] but seriously, distributions are integrating selinux [23:48] I'm sure the number of ipv6 people (for vserver) is small, but the number of se-linux vserver people will be several orders lower ... [23:48] adding default policies to make sure security holes in bind and sendmail are self-contained and cannot do additional harm [23:48] etc... [23:48] hey rik, cute cat [23:48] grepmaster: hehe ;) [23:50] basically I don't understand your motivation ... [23:50] bertl, it seems what he's saying is that once distros add selinux by default, it will make it harder to use vserver without it colliding [23:50] it seems you would like to replace the vserver stuff by a dozen of other partially orthogonal projects ... [23:50] and distros are adding selinux already [23:51] within a year selinux will be in a number of distributions [23:51] expect the first ones in spring [23:52] probably only x86 distributions, as they do not support other platforms yet, right? [23:53] selinux is architecture independant [23:56] as is vserver *G* ... [23:57] that's exactly why I like vserver so much [23:57] do you really like it? I'm not sure anymore ... [23:58] I still like it [23:58] it's just not compatible with a committed feature to the distro I'm working on ;( [23:58] Fedora Core 2 _will_ have selinux [23:59] but not vserver then, right? [23:59] nope ;( [23:59] they can't be combined [00:00] --- Sat Nov 1 2003