[00:05] <_shuri> http://vserver.13thfloor.at/Experimental/patch-2.6.0-vs0.04.diff [00:06] <_shuri> is the patch? [00:06] yup? [00:06] <_shuri> ok [00:14] is pptpd possible from within a vserver? [00:15] <_shuri> need extrat CAPS [00:16] Doener: it should be, especialy if you give it CAP_SYS_RAQ [00:16] RAW [00:16] hmm, pptpd, doesn't that use a ppp device? [00:17] to be honest, i don't know ;) a client asked if it is supported [00:18] <_shuri> pptpd need ppp yes [00:18] <_shuri> and BSD compresion [00:18] well I guess it is possible, but I would not do it in a vserver ... [00:19] probably the 'customer' 'thinks' that he can 'use' the vserver in his 'local' network ... [00:37] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [01:08] now combine the quoted words [01:08] customer thinks use local [01:08] without use its better [01:31] hmm ... it's so quiet ... [01:42] Action: MrBawb chirp chirp [01:42] says dan! ho dan! [01:42] hello :) [01:42] are you in testing mood? [01:43] hmm, I might be :) [01:44] http://vserver.13thfloor.at/Experimental/patch-2.6.0-vs0.04.diff [01:44] aah :) [01:44] cool [01:44] network seems to be working ;) [01:44] I managed to get 2 vserver with apache & ssh up and running in my emulation ;) [01:55] cool [01:58] tanjix1 (ViRu_@pD904A907.dip.t-dialin.net) joined #vserver. [02:01] _shuri (~shushushu@vserver.electronicbox.net) left irc: Quit: changing servers [02:03] shuri (~shushushu@vserver.electronicbox.net) joined #vserver. [02:03] wicj util i use with 2.6? [02:05] tanjix (ViRu_@cmn9-d9b84ce3.pool.mediaWays.net) left irc: Ping timeout: 480 seconds [02:11] Bertl [02:12] yup? [02:12] i get 2.6 working [02:12] i apply http://vserver.13thfloor.at/Experimental/patch-2.6.0-vs0.04.diff [02:12] vpn:/vservers# ./debian-newvserver.sh --hostname test1 --domain electronicbox.net --ip 0.0.0.0 [02:12] debian-newvserver.sh error: [02:12] Must be run from the host server (security context 0) [02:12] on a "vserver/ctx-patch" enabled kernel [02:12] See: http://www.solucorp.qc.ca/miscprj/s_context.hc [02:13] hmm, okay ... probably does some stuff with the (old) procfs ... [02:13] I don't know ./debian-newvserver.sh at all ... [02:14] will try without the debian-newserver [02:14] try to fix it first .. maybe just a simple check ... [02:14] k [02:17] if ! cat /proc/self/status | grep '^s_context:[^0-9]0$'; then [02:18] yo, replace it by something checking for /proc/self/vinfo [02:18] nha juste put # [02:18] and it work [02:19] how agressive ... [02:19] I: Retrieving http://ftp.uk.debian.org/debian/dists/woody/Release [02:19] I: Validating /vservers/test1/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release [02:19] I: Retrieving http://ftp.uk.debian.org/debian/dists/woody/main/binary-i386/Packages.gz [02:19] I: Validating /vservers/test1/var/lib/apt/lists/debootstrap.invalid_dists_woody_main_binary-i386_Packages.g [02:19] lol [02:19] very agressive [02:27] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) left irc: Read error: Connection reset by peer [02:30] Jaga (Jaga@user-0c8hc2i.cable.mindspring.com) joined #vserver. [02:31] hi Jaga! [02:31] hello... [02:31] I hope I am in the right place [02:31] depends what you are looking for ;) [02:31] I was looking for [02:31] open source web designer's channel [02:32] hmm, probably not quite right ... [02:32] Kinda was going thru their site and I need to understand some things [02:32] not important for now... I will learn some linux [02:33] Whta do u specialize in? [02:33] linux vserver, mainly ... [02:35] athat has to do with RedHat and apache, php and mysql? [02:35] hmm, not primarily, it has to do with virtualizin servers on linux ... [02:36] pls exlpain.. [02:38] well, linux servers at least use 1U in a rack, so we tried hard, and finally succeded to squeeze more than one in a single 1U rack chassis ... actually we are now able to get up to 60 servers in one 1U box .... [02:38] Nick change: tanjix1 -> tanjix [02:39] this saves a lot of space and simplifies administrative actions (you do not need to search 20+ boxes) ... [02:40] ok... as in many websites in a single machine... [02:40] that's cool [02:41] hmm, well actually it's many servers in a box, apache can do many websites, but we do many apaches .... [02:41] this is interesting... [02:42] where can I learn more of such stuff? [02:42] linux-vserver.org [02:44] thanks man.. let me go there and take a look [02:44] make it so ... [02:46] Jaga (Jaga@user-0c8hc2i.cable.mindspring.com) left #vserver. [02:52] rotfl [02:53] i've just tried to imagine how you're explanation of vserver would look like :) 60 real servers in one 1u box [02:53] s/you're/your/ [02:55] Doener-> that'd be pretty close to the truth [02:58] hm? is it my english that i don't get the meaning of that? i guess it's not possible to put 60 physical servers into 1u, is it? [02:59] best density I've heard is ~12 per 3u [03:00] Doener-> what's your native language? [03:00] german [03:00] Starting the virtual server test2 [03:00] Server test2 is not running [03:00] ipv4root is now 0.0.0.0 [03:00] Host name is now test2 [03:00] New security context is 49156 [03:00] expr: syntax error [03:01] well, let me transalte 1u then: Eine Höheneinheit [03:01] Starting internet superserver: inetd. [03:01] Starting OpenBSD Secure Shell server: sshd. [03:01] Starting deferred execution scheduler: atd. [03:01] Starting periodic command scheduler: cron. [03:01] i now 'that' ;) [03:01] vserver-stat [03:01] CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME DESCRIPTION [03:01] 0 0 0B 0B m00.00 m00.00 20m19.26 root server [03:01] bert not vserver-stat in 2.6 [03:01] i was more focused on what kungfuftr said [03:02] shuri: hmm, probably a similar issue with /proc somebody was mentioning save_s_context script ... [03:02] Doener-> it's an english expression that means 'you are very near to being correct' [03:05] ok, then i got yours right, but i guess you misunderstood mine :) i was referring to the explanation bertl gave to jaga, trying to say that i imagined what it would look like if it wasn't virtualization, but really 60 servers in 1u [03:05] save_s_context ? [03:06] teh server start [03:06] but do not run [03:06] well, they run, but the script doesn't check this ... [03:06] shuri: in /usr/lib/vserver/ should be a script called save_s_context [03:07] tanjix (ViRu_@pD904A907.dip.t-dialin.net) left irc: [03:07] there's also something with /proc/self/status you'll need to replace that one, too [03:07] ah, got ye [03:08] . /usr/local/lib/util-vserver/save_s_context [03:09] how i start a vserver in 2.6 this is my question.. [03:09] [01:02] expr: syntax error [03:09] shuri: don't you use static context ids, or do you just use vserver 0.29 without the fix? [03:10] that is caused by the error in save_s_context [03:10] i use utils-vserver027 [03:11] so the file in /var/run/vservers isn't written and the scripts can't determine if a vserver is running [03:11] hmm server config contain S_CONTEXT=? [03:11] no [03:11] (is unrelated to your issues, was just a question) [03:12] ls /var/run/vservers/ [03:12] test1.ctx test2.ctx [03:13] cat /var/run/vservers/test1.ctx [03:13] add some 'correctly' in my last sentence :) [03:13] at /var/run/vservers/test2.ctx [03:13] S_CONTEXT= [03:13] S_PROFILE= [03:13] that's what i meant :) [03:14] yeah, that looks like I expected ... [03:14] fix the save_s_context script ... it should write the context id into that file ... [03:14] you can add it per hand, for a quick test ... [03:15] (the context id you got on startup ;) [03:15] f [ $# -lt 1 ] ;then [03:15] echo save_s_context file command [03:15] echo Save the security context in file and execute a command [03:15] else [03:15] CTX=`grep ^s_context: /proc/self/status | sed s/s_context:// | (read a b; echo $a)` [03:15] CTX=`eval expr $CTX + 0` [03:15] echo S_CONTEXT=$CTX >$1 [03:15] echo S_PROFILE=$PROFILE >>$1 [03:15] shift [03:15] exec "$@" [03:15] fi [03:15] stop [03:15] oups [03:15] sorru [03:15] CTX=`grep ^s_context: /proc/self/status | sed [03:15] sorry [03:15] s/s_context:// | (read a b; echo $a)` [03:16] that's the one you want to edit ... [03:16] k [03:16] with /proc/self/status [03:16] check it on the command line, but something like sed '/VxID/ s/.*://' should do ... [03:19] well [03:19] do not work for me.. [03:19] need utils for 2.6 [03:20] CTX=`sed '/VxID/ s/.*:\w*//' instead of the CTX=`grep .... echo $0)` [03:21] shuri, did you start the vserver again, or did you add die ctx id to the .ctx file, before trying to determine the status of the vserver? [03:21] s/die/the/ [03:21] You don't actually do redirect to sed, it's last argument is filename anyway. [03:21] s/do /need to do / [03:21] okay ;) [03:22] CTX=`sed '/VxID/ s/.*:\w*//' /proc/self/vinfo` [03:22] :)) [03:22] I expect you to make the vserver 2.6 tools patches ;) [03:22] Action: virtuoso will handle this after all the exams, be sure. :) [03:23] not an acceptable excuse!!! [03:23] *cough* [03:23] Khe-he. [03:23] Action: virtuoso has a truly exceptional situation in the university. :) [03:25] hmm, they all know what underwear you prefer? or what? ;) [03:25] can't imagine a truly exceptional situation, per se ... [03:26] No. They don't know almost anything about me. :) [03:26] ok [03:26] vserver-stats do not work [03:26] but the server is runing [03:27] all process is there when enter [03:27] so i cantest now [03:27] network [03:27] perfect, use static ids that will ease the script stuff ... [03:27] 12387 ? S 0:00 /usr/sbin/inetd [03:27] 12396 ? S 0:00 /usr/sbin/atd [03:27] 12399 ? S 0:00 /usr/sbin/cron [03:27] 12454 pts/0 S 0:00 /bin/bash -login [03:27] 12460 pts/0 R 0:00 ps ax [03:27] statis ids? [03:27] static [03:27] S_CONTEXT=1001 is always the same, no S_CONTEXT means throwing dice each time ... [03:27] what is that [03:28] ok [03:32] New security context is 1001 [03:37] 553 ? S 0:00 /usr/sbin/apache [03:37] 554 ? S 0:00 /usr/sbin/apache [03:37] nice [03:37] will test muliple ips laterz [03:41] hmm, vserver-stat seems to use the procfs too ... [04:31] Nick change: Doener -> doener_zz [05:28] Topic changed on #vserver by Bertl!~herbert@MAIL.13thfloor.at: http://linux-vserver.org/ || latest stable 1.22, devel 1.3.3, exp 0.04 [05:30] moo [05:31] mooo ... [05:31] bah... debian dependencies-- [05:32] Bertl-> you a debian user at all? [05:40] Nick change: riel -> surriel [05:47] kungfuftr: nope, but I'm not against it ... [05:47] =0) [05:48] please tell me at least that you're not a red hat user [05:49] okay, I'm not a redhat user, I use Mandrake (8.2) ... [05:50] and i'm a FreeBSD 4.9 user (hehe) [05:50] so what are you doing here, hush, go away ;) [05:51] cos i unfortunately have to use Debian due to a virtual block device issue within FreeBSD [05:51] hmm, what could that be? virtual block device issue? [05:51] it realtes to the differences between lvm and vinum [05:52] why not fix that issue in FreeBSD then? [05:53] it runs very very deeply [05:53] and it would then require both kernel changes and changes to vinum... both of which are pretty huge tasks [05:54] hmm, and linux doesn't have those issues? [05:54] apparently not [05:55] hmm, never thought that FreeBSD would lack such features ... [05:56] it limits the number of virtual block devices that can be created to 16 iirc [05:57] Vinum is part of the base distribution of the FreeBSD operating system. Versions exist for NetBSD and OpenBSD. I'm actively seeking people who can help me port it to Linux. If you're interested in working on it, consider joining the mailing list. [05:58] why would someone seek to port it, if it isn't useful? [05:59] it's very very useful... it does all that mdtools does and a lot more (it's hell of a lot more stable too) [05:59] the only place it's limited in is in that virtual block device area [05:59] hmm, never had issues with md .. well for the last 4-5 years IIRC [06:00] somebody wrote a raid6 driver for linux ... [06:00] recently? [06:00] yup ... [06:02] is this for network RAID etc (enquires /me, having found 'net access again) [06:03] the raid6? [06:04] the vinum [06:04] hey paul, by the way, do you have a minute for the reboothelper? [06:04] but yeah, *proper* error-recovery RAID is good [06:05] possibly; I'm just doing that machine that was having issues(tm) at the moment [06:05] that with the ancient software, right? [06:07] well, it has now up-to-date but buggy code [06:07] right, what needs doing with the reboothelper? [06:07] have you fixed the calling interface? [06:07] hmm, buggy you say? [06:08] should [06:08] remember the discussion from the other night? [06:08] sorry, yeah... raid6 [06:08] hmm, not really, help my poor mind, please ... [06:08] bertl: all the IP address rewriting not working, and it possibly being the Debian patches [06:09] bertl: if you can't remember, it doesn' matter [06:09] ah okay, so you stick with the debian stuff? [06:09] or got it replace by a solid vanilla kernel + patches ;) [06:09] bertl: yes, when on production machines I use the stuff out of the Debian archive as it's generally more easily reproducable [06:10] bertl: except in the odd case [06:10] bertl: back to the reboot helper [06:10] ad reboothelper: I didn't change anything, but as I wrote in my last mail, I have no problem to add the sys_reboot info back ... [06:10] bertl: on completely rewrote my patch, what needs doing? [06:11] *nod* [06:11] sladen-> don't suppose you know of any "dependency spiders" for the debian Packages file? [06:11] so lets take vs1.3.3 and add a 'small' modification ... [06:11] yeah, there's some script that generates node-graphs of the dependancies [06:13] any idea on the name of it at all? [06:14] sladen: hmm would an environment variable be sufficient? [06:15] bertl: no [06:15] hmm, why not? [06:16] I was thinking about VS_SYS=reboot [06:16] because it's a basic requirement of the interface; not superfurous meta-data [06:16] hmm, hmm basic requirement ... [06:17] you called the script `vshelper' yeah. not `vsreboothelper' right? [06:17] kungfufu: apt-cache dotty | neato - [06:18] kungfufu: apt-cache show dep.pl may or may not be helpful? [06:18] s/yeah//;s/right// [06:18] hmm, okay then vshelper reboot right? [06:19] sladen-> ta!!! [06:19] in which case you might as well add the `sys_' back on so that it is concise [06:20] well, we don't have sys_ in userspace, right? [06:21] hence the reason why the existing `rebootmgr' is not called `sys_rebootmgr' [06:21] that is a userspace solution. This isn't. This is a kernel solution that happens to call userspcae [06:22] yeah but adding the in kernel sys_ prefix for userspace calls is confusing ... [06:22] secondly, if you switch it *back* to vshelper sys_reboot then you can just use the existing script, which is consistent with the naming of the other vserver utilities [06:24] well, your argument was, that the 'reboot' info is 'a basic requirement' and that there could be 'other' uses of this helper ... so putting the 'before' the 'type' isn't a good idea either ... [06:25] vshelper ... in this case vshelper reboot ... [06:25] My thinking was along the lines of context[42].sys_reboot("-t now now"); [06:26] and I guess you have to test the script anyway, so shuffling the arguments around shouldn't be too hard, right? [06:27] What I'm objecting to is the alteration of a (IMHO, although I accept your PoV) well-thought out interface [06:27] after 12+ months of no-comment [06:28] well, actually I don't want the userspace helper, I prefer an even based interface ... but that isn't near future ... [06:28] could you describe that? [06:29] some 'pipe' or something similar, which spits out 'even' messages into userspace, where some 'handler' processes those, and reacts on those events he understands ... [06:29] s/even/event/ [06:29] the other think I'm uncomfortable is the idea the changeing of the definition of a Capability--something that vserver has carefully not done until this point [06:29] that has the advantage, that it would work for nested vserver solutions too ... [06:30] ah, a sort of syslog/klog interface? [06:30] where the userspace helper will fail terribly ... [06:31] you are complaining about 12months of no reaction, I'm in charge for 2-3months, and I already added the userspace helper into the devel branch ... so I guess you have to complain elsewhere ... [06:31] hehe [06:32] anyway, nobody actually uses this stuff, at least not atm. [06:33] this 'might' be related to the fact, that almost no distribution calls reboot -f, instead doing reboot, which talks to init, which isn't present ... [06:33] init talks to sys_reboot [06:33] yeah, but init isn't used in most vservers ;) [06:34] that needs to change... [06:34] since then the distro-specific quirks disappear [06:34] well, you change it, and I add sys_reboot to the arguments, deal? [06:35] regarding explicit arguments vs. environment variables--I'd intended the environment to be ``extra'' (almost debugging) information. and nothing required to actually execute the call [06:36] well, actually my concept was a little simpler, basically action/event based ... [06:37] so IMHO a 'reboot' is always 'caused' by sys_reboot ... [06:37] and a 'halt' too ... [06:37] physical reboot, or a reboot of context? [06:38] so for me, it doesn't make sense to mention to the userspace, hey you got a reboot, and guess what, from sys_reboot ... [06:38] (context specific) [06:38] argv[3] = "restart"; [06:38] break; [06:38] case LINUX_REBOOT_CMD_HALT: [06:38] argv[3] = "halt"; [06:38] break; [06:38] case LINUX_REBOOT_CMD_POWER_OFF: [06:38] argv[3] = "poweroff"; [06:38] those 'are' the commands. period. [06:39] all of them are generated by vs_reboot() which acts in place of sys_reboot() [06:40] if we needed to 'catch' another syscall, lets say sys_setrlimit(), it would use 'setrlimit' as command [06:40] they are context specific to the sys_reboot system call, yes [06:41] but not to system calls in general [06:41] I don see the advantage of 'sys_reboot reboot' over 'reboot' [06:41] or 'sys_reboot halt' over 'halt' [06:42] so for me, the ``extra'' (almost debugging) information would be the redundant fact that it was sys_reboot() who would have guessed? [06:43] read the nested for loop in the script [06:43] haven't had a look at the script yet, where is it? [06:44] same place it's always been. http://www.paul.sladen.org/vserver/sys_reboot/schelper [06:45] hmm where is the 'for loop?' [06:46] s/for loop/nested switch statement/ [06:46] could actually be simpler with my interface .. right [06:47] and it convinces me that vshelper would be the best solution ... [06:48] this way, eliminating all your extra checks, etc ... [06:49] what do you think? [06:49] ``some people delete all their error handling code when they've debugged it. Others have the sense to leave it in'' [06:50] VSERVER="/usr/sbin/vserver" [06:51] this needs some changes ... [06:52] of course it does. It was written in 2002, and it is now 2004. [06:53] gee, time passed by ... [06:55] http://vserver.13thfloor.at/Experimental/patch-vshelper-fix01.diff [06:55] I would consider this the best solution for the userspace interface .... [06:55] (ontop of vs1.3.3) [06:56] actually a NULL can be removed in *argv[] = ... [06:59] can you live with that? [07:00] I've bounced you an email, probably worth a read (rather than a skim) since it seems to be similar to most of the questions you bought up tonight [07:00] Action: sladen looks [07:02] do you have the full patch handy? [07:02] sec [07:04] http://vserver.13thfloor.at/Stuff/sladen01.txt [07:05] groovy [07:07] it causes reboot behaviour is the MAGIC is wrong [07:08] holdy on, it's caught by the original sys_reboot commands checking (rather than vs_reboot's) [07:08] no, if the magic is wrong, nothing is done ... [07:08] return -EINVAL; [07:09] http://vserver.13thfloor.at/Stuff/sladen02.txt [07:09] (for reading the code ;) [07:10] I just saw, comments are wrong ... [07:10] let me fix that ... [07:11] if you do it with diff contexts that are very large, you get the best of worth worlds [07:12] diff -lines 9999 -u {old,new}/sys.c [07:12] updated the files http://vserver.13thfloor.at/Stuff/sladen0*.txt [07:14] thank you [07:14] okay, so this works for you? [07:15] (I remain unhappy that you've changed the interface). There doesn't seem to be much I can do about it though [07:15] if yes, then I put it into 1.3.4 and announce the change of the interface ... [07:16] well, you can do your own patches ... but if so, let me know, because in this case I remove the entire helper stuff ... we don't need diverging interfaces/helpers ... [07:27] I see the point for VX_TICK_HARD_REBOOT [07:27] I don't like the way it inverts such a narrowly-defined CAP [07:27] it doesn't invert anything [07:28] it prevents it doing what it says on the tin [07:28] nope, not at all ... you got it wrong ... [07:28] okay, let me explain once again ... [07:28] your vserver needs to have CAP_SYS_BOOT to call sys_reboot() [07:28] I don't actually have an answer for the {CAP,TICK}_REBOOT issue [07:29] if (!capable(CAP_SYS_BOOT)) [07:29] return -EPERM; [07:29] okay, you've sold me [07:30] then, if that is okay, (so your context has that CAP), the VX_HARD_REBOOT is checked ... [07:30] if (!(flags & VX_HARD_REBOOT)) [07:31] vx_reboot(...) [07:31] else [07:31] real reboot ... [07:32] actually VX_INFO_REAL_REBOOT would be a good name in the current setup ... [07:33] "INFO"? [07:33] yeah, that's what the flags are currently called ... [07:34] VX_INFO_NPROC for example ... [07:34] will go away, as soon as the interface for that changes ... [07:35] okay, I'll add the changes to 1.3.4 ... if you would like to have the syscall name in an environment variable for debugging purposes, please let me know, before the next release ... [07:38] okay, thanks for your time, looking forward to see a vshelper release on the mailing list/wiki page soon ;) [07:38] sladen (paul@starsky.19inch.net) left #vserver (what's the fucking point). [07:38] I'm off to bed now ... cu all 2morrow ... [07:39] Nick change: Bertl -> Bertl_zZ [07:40] sladen (paul@starsky.19inch.net) joined #vserver. [07:41] bertl: there's no fucking point putting the syscall in the ENVIRONMENT, since those are designed for humans. Passing the fucking syscall as a parameter is designed for computers to parse [07:41] s/f.cking//g [07:42] people normally ignore the sarcasam and bang their head against a wall at this point don't they [07:44] oh how I wish I was better at explaining steps 2, 3, 4 and 5 rather than giving step 6. This happens semi-in-frequently enough that I just get really, really annoyed when I see it happening /again/ [07:44] it's like OpenGL vs. DirectX [07:45] just because it wasn't needed at this moment, they removed it. Rather than leaveing it in [07:46] So, you've had 8 major revisions of a badly-designed interface to get the point where you can do everyhting that you could do with OpenGL 1.0 and extensions [07:46] *bang* *bang* *bang* [07:49] AAAAAAAAAArrrrrrrrrrrrgggggggggggggggghhhhhhhhhhhhhhhhh [07:49] never try to hold a rational conversation at 5am in the morning when still sober [07:56] why is something so *obvious* to me, so hard to explain? [08:25] and why does NOTHING work?! [08:36] shuri (~shushushu@vserver.electronicbox.net) left irc: Ping timeout: 483 seconds [08:43] shuri (~shushushu@vserver.electronicbox.net) joined #vserver. [09:01] shuri (~shushushu@vserver.electronicbox.net) left irc: Ping timeout: 483 seconds [10:33] noel- (~noel@pD9FFA51C.dip.t-dialin.net) joined #vserver. [10:41] noel (~noel@pD9FFAD99.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [11:13] pflanze (~chris@ethlife-a.ethz.ch) left irc: Ping timeout: 512 seconds [11:16] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [11:24] Simon (~sgarner@apollo.quattro.net.nz) left irc: Read error: Connection reset by peer [11:27] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [12:04] pflanze (~chris@cc-linux4.ethz.ch) joined #vserver. [12:45] stubbsd (~stubbsd@217.206.216.194) joined #vserver. [12:49] pflanze (~chris@cc-linux4.ethz.ch) left irc: Ping timeout: 480 seconds [13:56] stubbsd (~stubbsd@217.206.216.194) left irc: Ping timeout: 480 seconds [14:04] stubbsd (~stubbsd@217.206.216.194) joined #vserver. [14:17] Simon (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [15:43] virtuoso (~shisha@ip114-115.adsl.wplus.ru) left irc: Remote host closed the connection [15:48] virtuoso (~shisha@ip114-115.adsl.wplus.ru) joined #vserver. [16:25] Doener_zZz (~doener@pD9E12F73.dip.t-dialin.net) joined #vserver. [16:33] doener_zz (~doener@pD9588D71.dip.t-dialin.net) left irc: Ping timeout: 512 seconds [16:57] shuri (~shushushu@vserver.electronicbox.net) joined #vserver. [17:14] serving (~serving@213.186.191.28) left irc: Ping timeout: 480 seconds [19:03] does anyone have a patch/fix/workaround for the latest 2.4.23 vulnerability? mremap? [19:04] netrose (john877@CC3-24.171.21.47.charter-stl.com) left #vserver. [19:04] netrose (john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [19:06] serving (~serving@213.186.191.79) joined #vserver. [19:10] bargh yet another one [19:10] is there any further info about the vulnerability? [19:12] http://isec.pl/vulnerabilities/isec-0013-mremap.txt [19:13] thx [19:14] any exploits in the wild yet? [19:31] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [19:31] Bertl_zZ :( you're sleepin? [19:32] anybody know where i could find a 2.4.23 patchset for xfs that will apply cleanly? [20:00] Nick change: Bertl_zZ -> Bertl [20:00] Bertl, do you know where i could find a 2.4.23 patchset that will apply cleanly in conjunction with vs1.22? [20:01] hmm, patchset? [20:01] http://www.13thfloor.at/vserver/patchset/overview/ [20:02] hmm, but you are looking for xfs, right? [20:02] yah [20:03] but i need a vs 1.2x series.... [20:03] hmm, why? [20:03] production linux-vserver [20:03] James Noble is having me set some stuff up for him [20:05] guess you have some xfs patches lying around then? [20:05] there's one at silug [20:05] netrose: hmm, sounds bad, any fixes around? or shall we 'just' fix it? ;) [20:07] infowolfe: url? [20:08] but you know, quota doesn't work with xfs ... [20:08] http://ftp.silug.org/pub/xfs/patches/2.4.23/ [20:08] hrm... [20:09] I mean context quota, normal quota seems to work ... [20:09] ok [20:10] you tried to apply to 2.4.23-vs1.22 yet? [20:10] yup [20:10] what is rejected? [20:10] sysctl.c had some rejects [20:10] i can apply it again if you'd like [20:10] and the other way round? [20:11] Bertl, umm [20:11] http://isec.pl/vulnerabilities/isec-0013-mremap.txt [20:11] *ahem* [20:11] just got that in my email [20:16] i have to go to work [20:16] hmm, okay cu later ... [20:18] okay, guess well update to 2.4.24 then ... regarding mremap [20:34] sladen: hmm paul? [20:36] stubbsd (~stubbsd@217.206.216.194) left irc: Quit: Leaving [20:37] http://vserver.13thfloor.at/Stuff/delta-mremap-2.4.23-2.4.24.diff [20:37] lkml claims that 2.4.24 fixes the mremap issues, here is the difference between 2.4.23 and 2.4.24 regarding mremap ... [20:39] JonB (~JonB@129.142.112.33) joined #vserver. [20:40] JonB (~JonB@129.142.112.33) left irc: Client Quit [21:05] tanjix (ViRu_@pD9049D9F.dip.t-dialin.net) joined #vserver. [21:05] hi [21:07] hi! [21:40] _shuri (~shushushu@vserver.electronicbox.net) joined #vserver. [21:40] shuri (~shushushu@vserver.electronicbox.net) left irc: Ping timeout: 483 seconds [22:09] irmin (~irmin@lake.ptc.spbu.ru) joined #vserver. [22:10] does anyone use vserver on debian's 2.4.23 kernel? [22:15] JonB (~jon@129.142.112.33) joined #vserver. [22:20] irmin: IIRC paul found some issues with the debian patch ... [22:22] Bertl: yes, debian's kernel have pieces of tcp/ip stack backported from 2.6 [22:23] yeah I know, I did the debian port ;) [22:23] but I thought I got it right, but it seems I failed ... [22:24] are you interested in fixing the debian patches? [22:25] Bertl: well, I remember someone did that already for 2.4.22 and it worked perfectly several months on my server [22:25] unfortunately I've lost that sources :( [22:25] hmm .. what do you remember? andy patch names? [22:26] it was a standard ctx17a modified for working with debian tcp stack [22:27] Action: irmin . o O ( or was it 2.4.21? ) [22:28] hmm, well it would help to see a working patch ... or if somebody would do some testing ... [22:30] hmm, you are a debian guy, right? [22:30] right :) [22:30] do you know about the mremap issue? [22:30] is debian affected by that one too? [22:31] it is affected, though 2.4.24 patch is 2.5kb so applies to .23 sources cleanly [22:31] hmm, well the fix is actually 6 lines ... [22:32] http://vserver.13thfloor.at/Stuff/delta-mremap-2.4.23-2.4.24.diff [22:32] but you are probably right 2.4.24 fixes another issue too ... [22:32] yes, 2.4.24 contains also information leak fix as well as two oopses fixes [22:33] I've already tried to apply 2.4.24 - no problems [22:33] was this the bug that was discovered ages ago ? [22:33] JonB: http://lists.netsys.com/pipermail/full-disclosure/2004-January/015198.html [22:35] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) joined #vserver. [22:36] irmin: i hate such things [22:36] hey bert [22:36] hi nathan! [22:37] how goes the new proc stuff? [22:39] slowly ... but yesterday I hacked the network stuff into 2.6 vserver [22:39] ah [22:40] how do you think 1.3.3 with O(1)/preempt would be on uni? [22:40] advantageous ;) [22:41] is it the preempt that makes it that? [22:41] well, guess both .. the preempt gives responsiveness, the O(1) fairness ... [22:41] but would you say its risky? [22:41] did you try it? [22:42] i want to, but this is going to be a production box [22:42] well try it on the test box, those with/for the crashes ... [22:42] hmm guess i could just disable smp [22:42] yup [22:45] should i test with 1.3.3 on th site or do you have some up coming version? [22:46] well, there is a 1.3.3 for 2.4.24 in a few minutes ... [22:46] but it's the same as the 1.3.3 ... just for the new kernel ... [22:46] next gen. procfs will need some time/testing ... [22:48] let me know when the 2.4.24 is good to go [22:48] sure ... stable is now updated for 2.4.24 ... devel will take a few minutes longer ... [22:51] hmm will stable patch against ck1? [22:51] nope ... [22:53] ensc (~ircensc@ultra.csn.tu-chemnitz.de) joined #vserver. [22:53] hi enrico! [22:53] hello [22:53] good to see you! [22:53] just visiting, or back to life? [22:53] back to life... [22:54] but I will have to compile some kernels first... [22:54] yeah ... [22:54] vserver is 2.4.24 ready ... ;) [22:54] was probably much work... ;) [22:55] yeah, I had one bad diff issue to resolve .... ;) [22:55] a really bad one, didn't even apply with -l [22:56] VERSION=2.4.23 ? [22:56] yup! [23:00] Bertl, did 1.3.3 patch cleanly with ck1 and 2.4.23? [23:01] the ck1 version, yes, the other no ... [23:01] oh did you give me a ck1 specific version? [23:01] yup, it's on the release page too ... [23:01] ah [23:01] duh [23:01] http://www.13thfloor.at/vserver/d_release/v1.3.3/ [23:01] totally overlooked that [23:02] ignore my stupidity [23:02] it has quite some different code, the O(1) scheduler for one ... [23:02] yea i was going to start hacking it and trying to sort it out but then i remembered that i tested it briefly with ck1 for you and it was a clean patch, so i was confused [23:03] would be nice to give the ck1 a thorough spin ... testing the scheduler and of course vserver ... [23:05] im tossing grsec into the mix as well [23:06] well, no problem with that ... [23:16] Bertl: can you update the (signed) md5sum file please? [23:17] argh! I knew that ;) [23:17] well, enrico is back .... [23:18] I'll update them, when I uploaded the devel releases ... [23:20] Bertl: I found vserver patch for 2.4.22 which looks like working one [23:20] hmm, looks like? the others did look like working too ;) [23:20] Bertl: debian's kernel-patch-ctx package contains correct patch for .22 though invalid one for .23 :) [23:21] kestrel (~athomas@dialup51.optus.net.au) left irc: Ping timeout: 512 seconds [23:21] irmin: okay, could you look for the difference? [23:23] Bertl: yes, wait a bit [23:28] ok got 2.4.23+netconsole+1.3.3+grsec+ck1 all patched in [23:28] here we go [23:28] Bertl: http://tranq.dorms.spbu.ru/data/diff-patch-2.4.23--patch-2.4.22.diff [23:29] Bertl: the important difference is actually in parts for udp.c and route.h actually [23:29] Bertl: so it is about 10 lines only [23:30] hmm, okay, please verify them against the changes in the debian kernels ... [23:30] we do not want to 'change back' any useful additions ... [23:30] Bertl: that is a diff between patches from Ola's package [23:31] yeah, what I mean is, maybe the change in udp, is between deb-22 and deb-23 (no vserver) [23:31] and in this case, we do not simply want to revert it, right? [23:49] nathan_: http://www.13thfloor.at/vserver/d_release/v1.3.3/ [23:52] Bertl: do you have a test set which can be run against server running patched kernel, to verify that all vserver features works properly? [23:52] http://vserver.13thfloor.at/Stuff/testme.sh [23:52] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) got netsplit. [23:52] JonB (~jon@129.142.112.33) got netsplit. [23:52] Doener_zZz (~doener@pD9E12F73.dip.t-dialin.net) got netsplit. [23:52] mcp (~hightower@wolk-project.de) got netsplit. [23:52] MedivhWrk (ck@netops.multimedia-centrum.de) got netsplit. [23:52] surriel (~riel@riel.netop.oftc.net) got netsplit. [23:52] lp (~lpressl@interner.SerNet.DE) got netsplit. [23:52] Bertl (~herbert@MAIL.13thfloor.at) got netsplit. [23:52] Zoiah (Zoiah@matryoshka.zoiah.net) got netsplit. [23:52] lp (~lpressl@interner.SerNet.DE) returned to #vserver. [23:52] Bertl (~herbert@MAIL.13thfloor.at) returned to #vserver. [23:52] but only does basic tests, no network test for example ... [23:53] Zoiah (Zoiah@matryoshka.zoiah.net) returned to #vserver. [23:53] heh, we need network tests now actually :) [23:53] well, extend it! [23:54] hi Zoiah! [23:55] mcp (~hightower@www.c-tera.de) joined #vserver. [23:55] MedivhWrk (ck@netops.multimedia-centrum.de) returned to #vserver. [23:56] surriel (~riel@imladris.surriel.com) joined #vserver. [23:56] hey mcp! what a rare visitor! [23:56] Doener (~doener@pD9E12F73.dip.t-dialin.net) joined #vserver. [23:57] hmm, is now joining time? did I miss a netsplit? [00:00] --- Tue Jan 6 2004