[00:01] how hard do you think it would be to write a xid aware quotacheck? or at least a patch? [00:01] it is not that far off if you start it 'within' the chrooted env, which should only contain files belonging to the host or the context ... [00:02] hmm, well I patched those tools for some time, but the consens was, a patched quota tool inside a vserver is not useable .. now we have modified reboot and halt commands, although there is a userspace helper which doesn't require this, so YMMV [00:03] yeah the rebootmgr. [00:04] if i can get quotacheck to at least set teh quotafiles to the porpper inital values id find that useful inside a vserver context. the otehr tools shouldnt really matter wether they are modified or not. [00:04] would be nice if quotacheck wasnt needed at all. [00:05] yeah, shouldn't be needed if the quota files are up to date ... [00:05] (means no modifications done while quota is off) [00:06] honza is working on journaled quota ... maybe that might bring a solution too ;) [00:06] hopefully. [00:06] but i am interested in making sure the quotacheck inital values are propper inside a context. since if im going to be doing quota system tests im goign to want to test inside of contexts as well as outside. [00:07] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [00:07] hmm, inside and outside values are orthogonal, so if you take the quotacheck as bias, or even use some fantasy values as bias, it should be okay .. [00:08] click (click@gonnamakeyou.com) left irc: Remote host closed the connection [00:08] click (click@gonnamakeyou.com) joined #vserver. [00:09] ls FIN [00:09] (wrong term ;) [00:09] also from a end user standpoint. it would be nice not to have to try and explain why the quota system reports a user ahs more files than they can find for a user. [00:10] when they are trying to admin their dedicated vserver instance and deadlign with quotas. [00:10] dealing with quotas i mean. [00:11] sure, as I see it, the next 'useful' tool would be a tools to scan a filesystem hierarchy for files belonging to one context, maybe separating them by uid/gid ... [00:12] this way you can get the total value for the disk limits, and if you separate by uid/gid, as a bonus the quota values correct ... [00:12] writing both the limits into kernel memory and the quota into the quota files would be the final tool for that purpose ;) [00:13] s/final/ultimate/ [00:13] thats meant to be run on the host right? [00:13] correct [00:13] and update the quota files for all vservers? [00:13] well either that, or one after the other ... [00:13] is there any way at all to make it work form inside a vserver? [00:14] id like to have quotas be up to whoever is assigned root on a particular vserver. [00:14] hmm, sure, why not, quotacheck does work, doesn't it? [00:14] from inside a vserver? [00:14] of course, that is what the quota system is designed for ... [00:15] it doesnt seem to give the correct values inside a vserver no. [00:15] it gives appropriate values from inside ... [00:15] means: all files visible to that vserver are categorized into quota files [00:16] if all the files belong to that context, the quotacheck results will be correct [00:16] right. but theres no way user talon has 3 files and 12 blocks allocated inside that context. [00:16] unless im misunderstanding somthing. [00:17] i should have 2 files and 8 blocks. [00:17] well, strace quotacheck and see what it does ... [00:19] Bertl, anything special needed when using vserver on an SMP box? [00:20] a recent kernel/vserver patch, nothing else ... [00:20] great [00:22] Bertl: do you want a copy of the strace output ? [00:22] if you could make it available somewhere, yes [00:24] surriel (~riel@imladris.surriel.com) joined #vserver. [00:26] talon.home.cosmic-cow.net/report [00:27] Nick change: surriel -> riel [00:27] hi rik! [00:29] Bertl: there is one interesting aspect althoguh i dont knwo if has anything to do with accounting for talon. [00:29] in the pre-start script. i do this. [00:29] mount -oro --bind /vservers/template/lib /vservers/$2/lib; [00:29] mount -oro --bind /vservers/template/bin /vservers/$2/bin; [00:29] mount -oro --bind /vservers/template/sbin /vservers/$2/sbin; [00:29] mount -oro --bind /vservers/template/usr /vservers/$2/usr; [00:29] files in /vservers/template belong ot context 0. [00:30] there are no files belonging to context 0 that are owned by uid 1000 (talon) [00:30] but there are ctx0 files visible to quotacheck. [00:31] well, you should take that log and (if you really want ;) check each lstat64 file for it's uid ;) [00:31] a simpler way would be to use an empty fs to do that, without all that 'junk' [00:32] or try something simpler, remove all files 'belonging' to talon and repeat the quotacheck ... [00:33] then add those files for some other uid 2000 for example, and verify the accounting again, all from inside the vserver [00:33] crap... [00:34] just removed my home dir on the host not the vserver.... [00:34] hmm, interesting approach ;) [00:34] dont think i had anythign important there. [00:34] but still. [00:35] Action: talon alises rm to rm -i on the host [00:35] a sane, but annoing default ;) [00:35] useful when your enterign and exiting vhosts a lot. [00:36] and forget where you are at teh moment half asleep. [00:36] a nice prompt might help there too [00:38] ok [00:38] remove all files belonging to talon inside context. [00:38] run quotacheck and then repquota. [00:38] nothign shown for user talon. [00:39] mkdir /home/talon and chown to talon. [00:39] do same andi get 2 files an 8 blocks. [00:39] root@taltest2:/# du -k /home/talon [00:39] 4 /home/talon [00:39] root@taltest2:/# ls -la /home/talon [00:39] total 8 [00:39] drwxr-xr-x 2 talon root 4096 Feb 7 07:24 ./ [00:39] drwxr-xr-x 4 root root 4096 Feb 7 07:24 ../ [00:40] chrism (~chris@82-32-130-79.cable.ubr05.hawk.blueyonder.co.uk) left irc: Quit: ..(cyp): [BX] Back wit anutha one of doz BitchX-rockin' beats! [00:43] if i remove the directory and just create a single file. [00:43] owned by talon. [00:43] thats accounted for correctly. [00:43] what quota tools do you use? [00:43] seems theres somthgin fishy goign on with directorys. [00:44] repquota and quotacheck. 3.09 [00:44] hmm, maybe fixed in 3.10 ;) [00:44] Bertl: will try that out. [00:44] definitely a bug in quotacheck if it is still there [00:44] ok now we are getting someplace. [00:45] I would also check that for ext2 and ext3 ... [00:45] cant do that from inside a context. [00:45] hmm, why not? [00:45] but will try outside with everythign set to cxid0. [00:46] Bertl: if it sees ext2 un an mtab it will try to read the raw device. [00:46] and vroot doesnt like that. [00:46] you should always use ufs in the mtab, regardless of the underlying fs [00:47] thats what i have been doing. [00:47] so where is the problem to do that with ext2 and ext3? [00:48] oh i thgouht you meant trying to make quotacheck try to check as if it was ext2 from inside the context. [00:48] if you want you could do that too, by using the real block device instead of the vroot ... [00:50] root -- 14 0 0 3 0 0 [00:50] root -- 1044 0 0 4 0 0 [00:51] tow partitions, one ext2 other ext3 both almost empty ... [00:51] # su test1 -c sh [00:51] $ mkdir /mnt/part1/X/test [00:51] $ mkdir /mnt/part2/X/test [00:51] $ exit [00:51] # repquota -vau [00:51] root -- 14 0 0 3 0 0 [00:51] test1 -- 1 0 0 1 0 0 [00:51] root -- 1044 0 0 4 0 0 [00:51] test1 -- 1 0 0 1 0 0 [00:52] # quotacheck -vaugm [00:52] root -- 44 0 0 6 0 0 [00:52] test1 -- 1 0 0 1 0 0 [00:52] root -- 1068 0 0 7 0 0 [00:52] test1 -- 1 0 0 1 0 0 [00:52] the difference for root are the quota files themselves ... [00:54] now the same with ufs type ... [00:54] root -- 25 0 0 3 0 0 [00:55] Last message repeated 1 time(s). [00:55] root -- 26 0 0 4 0 0 [00:56] Last message repeated 1 time(s). [00:56] (that is the correct start value, just forgot to add the test dir) [00:56] _force_ (force@brln-d9ba1f0f.pool.mediaWays.net) joined #vserver. [00:56] <_force_> hello! [00:56] root -- 26 0 0 4 0 0 [00:56] test1 -- 1 0 0 1 0 0 [00:56] root -- 26 0 0 4 0 0 [00:56] test1 -- 1 0 0 1 0 0 [00:57] <_force_> i have a strange problem currently, i just updated to 1.26 and now i cant start some vservers anymore [00:57] <_force_> i get following error: [00:57] root -- 62 0 0 8 0 0 [00:57] test1 -- 2 0 0 2 0 0 [00:57] <_force_> Can't set the ipv4 root (Unknown error 4294967274) [00:57] root -- 48 0 0 8 0 0 [00:57] test1 -- 2 0 0 2 0 0 [00:57] <_force_> what could this be?` [00:57] which obviously differs ... [00:57] _force_: upgrade your userspace tools. [00:57] _force_: from which tool/vserver version did you upgrade? [00:58] <_force_> im using this: util-vserver-0.28 [00:58] doesn't answer my question ;) [00:59] <_force_> oh.. im today a little dizzy i think [00:59] np [00:59] <_force_> i updated from vserver1.22 and usertools where 0.26 i think [00:59] what does the testme.sh script report on your system? [01:00] talon: so the quotacheck is wrong in this regard on ufs ;) [01:00] # quotacheck -V [01:00] Quota utilities version 3.09. [01:00] Compiled with RPC and EXT2_DIRECT [01:01] <_force_> http://nopaste.php.cd/7865 [01:01] <_force_> everything fine i think ;) [01:01] <_force_> this error happens on 2 vservers which bot have 16 ip's .. [01:01] hmm, interesting 201 is not supposed to succed on stable kernels ... [01:02] <_force_> 0_o [01:02] <_force_> well i also applied the quota patch [01:02] give me a minute, I have to compile the 0.28 tools ... [01:02] <_force_> which is for 1.24 but since it applied without errors i thought this would not be a problem :) [01:02] <_force_> ok [01:03] Bertl: i will try the lateist quotatools and if that doesnt work. i will see if i can figure out why it does teh accountign wrong. [01:04] im not sure where its getting the block count. but i know it counts directorys twice. [01:04] if a user just has two directorys and no files on a fs it iwll show up as 4 files. [01:04] okay, guess I'll update too, and check this with qemu, as this is simpler ... [01:05] i know this isnt quite as important as the quota patch working propperly. [01:05] so i hope im not beign too much of a pain. [01:06] if you where, I would tell you, so nothing to worry about ... [01:08] hmm, fascinating, enrico managed to get the 201 working ;) [01:08] I'm impressed ... [01:09] _force_: okay, stuff looks fine to me now ;) [01:09] <_force_> hehe [01:09] <_force_> well still have that error :] [01:09] so you get a strange message on vserver startup? [01:09] <_force_> yes [01:09] <_force_> when i do vserver name start [01:10] <_force_> it happens [01:10] okay, could you provide the config for that vserver, and the complete startup log? [01:10] <_force_> but only on 2 servers [01:10] 0.26er tools probably where Jack's tools right? [01:11] <_force_> http://nopaste.php.cd/7866 [01:11] <_force_> this is the config [01:12] <_force_> http://nopaste.php.cd/7867 [01:12] <_force_> this is the startup log (well doesnt show much though :) ) [01:12] okay, could you reduce the number of ips from 16 to 15 just for a test? [01:13] <_force_> hm well i can't remember if i used teh utilävserver tools oder the vserver tools from jacks [01:13] <_force_> k, one sec [01:14] <_force_> hm, well it works now! 0_o [01:14] okay, I suspected a bug there for some time, we'll have to investigate that ... [01:14] <_force_> (with 15 ip's) [01:14] so solution for now, max 15 ips ... for later .. we'll see ;) [01:15] ;) [01:15] hi [01:15] hi again! [01:16] i mnaged to build Owl with 2.4.25pre 8 and vs1-24 pre 6 :) and now security update :) [01:17] no joy with 3.10 so far. [01:17] <_force_> Bertl heh, ok, well my costumers wont be that happy i think, but what to do! ;) hope this will be fixed sometime :) [01:17] you could also raise the current maximum to 17 and recompile the tools too ... [01:17] <_force_> raise to 17? oh you mean in the sourcecode? [01:18] yeah, use the source _force_ [01:18] <_force_> well if you tell me which line that is, my programming skills are, ehm, well hehe ;) [01:18] the question should be, do you REALLY want to do that? [01:18] <_force_> :X [01:19] <_force_> would this create problems? then no ;) [01:19] even creating a file can create problems, so sure it can give you headache ... [01:20] <_force_> hm, well ill live with this 15 ip's solution for the time being, ive got enough headaches! ;) [01:20] but it seems to work for some folks which use more than 16 ips ... [01:21] serving (~serving@213.186.188.205) joined #vserver. [01:21] <_force_> :) well, thanks for the help, im off again [01:21] ok, cu [01:21] _force_ (force@brln-d9ba1f0f.pool.mediaWays.net) left irc: Quit: Der Mensch wird vom Geist geleitet. In der Wüste bin ich das wert, was meine Gottheiten wert sind. [01:21] Bertl: any luck on your end with 3.10 ? [01:22] working on the quota patch atm .. [01:29] hmm good. quotacheck has a debug flag. [01:30] gives me somthign a bit easier to go through than an strace log. [01:30] sounds useful .. [01:36] just add the d flag. [01:50] i think im going to pass out again. sorry ifi havent been too helpful today. [01:50] hey, any testing is helpful, have a good sleep ... [01:51] I'll finish the quota patch for now, and will go to bed too ... [01:51] sounds good. will certanly be here tomorrow. [02:48] Zoiah (Zoiah@matryoshka.zoiah.net) left irc: Quit: changing servers [02:53] Zoiah (Zoiah@matryoshka.zoiah.net) joined #vserver. [02:54] ensc (~ircensc@ultra.csn.tu-chemnitz.de) joined #vserver. [02:54] hi [02:54] hi enrico! [02:55] the fakeinit code creates unremovable zombies [02:55] how did you do it, that 0.28 seems to work with 0.28? [02:55] how did you do it, that 0.28 seems to work with fakeinit? [02:55] voodoo ;) [02:55] thought so .. and now the zombies are alive? [02:57] no; it happens when I do: new_s_context(); fork(); { child -> new_s_context(..., S_CTX_INFO_FAKEINIT); sleep(2); }; parent -> exit [02:57] then, the child becomes its own PPID [02:57] tested with 1.3.x? [02:57] because parent died -> old PPID disappeared -> the initpid becomes PPID -> child is the initpid [02:58] no, 1.24 [02:58] hmm, any quick test I could do on 1.3.x just to verify? [02:58] I just have a vs0.05 machine [02:59] hmm isn't 0.06 the current version? [02:59] but -rc kernels do not fit into my rpms [02:59] hmm, now I lost you ... [03:00] I am building all my kernels as rpm; and the '-rc' naming scheme makes things complicated [03:00] 1.3.5 is available for 2.4.24 too [03:00] (for example) [03:01] any test code I could check for you? [03:02] 0.28.197 should contain a chcontext triggering the bug [03:02] hmm 197 ... okay I'll download it ;) [03:04] hmm, would be nice to ahve a download link on your alpha-branch wiki page ;) [03:05] where was that download url again? [03:05] 'chcontext --disconnect --flag fakeinit true' should do it... [03:05] http://www-user.tu-chemnitz.de/~ensc/util-vserver/alpha/ [03:06] btw, it isn't very smart to have the savannah link and your homepage pointing to that ... [03:06] thanks [03:06] oops where is 196? [03:06] internal release [03:07] hehe, are there any changes to the spec file? [03:08] between 195 and 197 .. [03:08] mlawren (~mlawren@69-56-241-204.theplanet.com) joined #vserver. [03:08] hi mlawren! [03:08] good evening... [03:08] What are you still doing up? [03:09] he? [03:09] me? [03:09] probably not... [03:09] man, it's kinda late [03:10] hmm, I guess he is talking to me? [03:10] all of you, it should be about 01:10 in your (and my) part of the world :) [03:10] perhaps the chattr stuff [03:11] So, all is quiet, huh... I have some news... [03:12] I've written/rewritten the schelper kernel help tool and manpage. [03:12] sounds good ... but what do you do here at this time? 8-) [03:12] Writing code of course! [03:13] I said two weeks ago that I would write this tool, so I just had to sit down and do it :=) [03:13] So, I kind of need some testers :) [03:13] sounds virtuous too ;) [03:14] you mean your code is still untested? [03:14] Because... I don't have access to a host I can fiddle with at the moment [03:14] I'm working in Spain, and my personal server is in Switzerland, but of-net :* [03:15] t's t's ... [03:15] shocking, I know... [03:15] ensc: okay, vs1.26 + 0.28.197 what next? [03:16] chcontext --disconnect --flag fakeinit true [03:16] vps ax |grep Z [03:16] 18 root Z [busybox] [03:16] okay looks good ... let's see with devel ... [03:17] 'true' is from busybox? [03:17] yup, everything is from busybox atm. [03:18] 21 root Z [busybox] [03:18] seems to work on devel too ... [03:18] so the thing is the parent is killed, and there is nobody reaping this child, right? [03:19] look at the PPID entry of pid 21... [03:19] ... it is pid 21 [03:25] hmm, wait a minute? [03:25] you are killing the fakeinit, right? [03:26] ?? [03:26] ensc: you are starting a process, and declare it as fakeinit, then you spawn something and exit the fakeinit, right? [03:27] first new_s_context() is without the 'fakeinit' flag, then I fork() and in the child, I call a second new_s_context with ...(-2, ..., fakeinit) [03:29] ret = vx_set_initpid(current->vx_info, current->tgid); [03:29] who is taskgroup leader at this point? [03:31] hmm, and did you try ps aux ? [03:33] Bertl: quick question: when/what features move from unstable to stable? [03:33] you mean with 1.4? [03:33] The vshelper argument order is different between the two [03:34] between 1.25 and 1.3.x [03:34] that is correct, paul requested a modification ... [03:34] Will that order be back-ported to the stable patch? [03:35] Given that no-one is using it yet (I think) perhaps it doesn't break anything [03:35] 1.4 will have the new order [03:35] ensc; [03:35] ensc: [03:35] Great, I only have to write one tool :) [03:35] # chcontext --disconnect --flag fakeinit /bin/ls [03:35] # ps ax | grep Z [03:35] 21 root Z [busybox] [03:35] # cat /proc/virtual/49152/info [03:35] ID:49152 [03:35] Info:97f5f400 [03:35] Init:25 [03:36] so it is the parent which dies as zombie ... [03:36] which is somewhat expected I guess ... as the ls will not handle a sigchild correctly ;) [03:37] Could I also suggest changing /sbin/vshelper default to /usr/sbin/vshelper? [03:37] To my mind, it seems more FHS compliant there... [03:40] char hotplug_path[256] = "/sbin/hotplug"; [03:40] that is the kernel hotplug helper ... [03:40] # chcontext --disconnect --flag fakeinit cat /proc/self/status [03:40] New security context is 49166 [03:40] Name: cat [03:40] State: R (running) [03:40] Tgid: 935 [03:40] Pid: 935 [03:40] PPid: 934 [03:40] # chcontext --ctx 1 cat /proc/935/status [03:40] New security context is 1 [03:40] Name: cat [03:40] State: Z (zombie) [03:40] Tgid: 935 [03:40] Pid: 935 [03:40] PPid: 935 [03:40] in both cases: initpid: 935 [03:41] You also have: [03:41] patch-2.4.25-rc1-vs1.3.7.diff:+char vshelper_path[255] = "/sbin/vshelper"; [03:41] bertl: 1.26? damned, got a backport of the patches :D [03:41] oh yeah the chrootbuf [03:41] bug [03:42] huh? what are you talking about? [03:43] Bertl: talking to click, or me? [03:43] 2.4.24+1.24 was exploitable [03:43] mlawren: just make marcelo change the /sbin/hotplug and I adapt the /sbin/vshelper okay? [03:43] was/is. [03:43] yep, that is correct ... [03:43] Actually, I think /sbin/hotplug is in the right place. [03:44] The rational for /sbin is that it is potentially needed to get [03:44] the system booted. [03:44] ensc: yes, you are right I'll test that ... [03:44] bertl: major diffs from 1.24 to 1.26? [03:44] incremental patches? [03:44] bertl: mhm? [03:45] or can it be patched up manually? [03:45] mlawren: so your argumentation is that vshelper is not used to boot the system, right? [03:45] However vshelper is, from the host/root server point of view, purely a user-level tool [03:45] If you can consider vservers user-type aplications.. [03:46] same goes for the hotplug helper, which is also 'purely' userspace [03:46] However hotplug may be needed to load drivers, so that the rest of the system can boot [03:46] but I got your point and will think about it, btw, you can easily change that path on bootup, you know? [03:46] Yeah... just trying to reduce the number of changes from my default distribution scripts :-) [03:47] click: just use the incremental patches ... ;) [03:47] ok, on my way [03:47] :) [03:48] got to fix the kernel on four prodservers now :/ [03:48] well, ok [03:48] got to be done [03:48] hmm, isnt that a little late? ;) [03:49] I just enjoyed a weekend of, the exploit still works, no it doesn't, does to, does not ... [03:49] well, we have the boxes in full lockdown anyway, as that chroot-shit was wrapped using grsec :/ [03:50] thus they won't get more access as per a normal blocked grsec-patched kernel [03:50] sounds good .. [03:51] grsec should be mandatory :/ [03:52] ensc: okay, so if I got this right, what actually happens is: the fakeinit (initpid) process dies (limit the real init never does without panicing the kernel ;) and stays around as zombie ... right? [03:52] ExpiryJames (~james@h24-71-63-164.ok.shawcable.net) left irc: Remote host closed the connection [03:53] s /limit/what/ how did that happen? [03:53] huh, i think mylaptop is getting tired of me rebooting it [03:53] tried fedora. [03:53] never again. [03:53] back to debian [03:54] okay, anyway, I'll go to bed now ... will analyze this tomorrow ... [03:54] Bertl: yes; I guess that the system assigns the initpid as new PPID when the old PPID dies [03:54] what is correct, as the initpid is the 'new' per context reaper ... [03:55] I'll see if I can hack together a workaround for that corner case ... [03:55] the question is, what should be done with other tasks in the context, when the initpid context dies? [03:56] Action: click trods off to patch the kernel... [03:56] probably it should hang around as zombie until all children are dead ... or something like this ... [03:56] okay, more after some sleep, ... [03:56] see you guys tomorrow :) [03:57] night bertl [03:57] have a nice wossname everyone ... cu 2morrow ... [03:57] Nick change: Bertl -> Bertl_zZ [04:12] mlawren (~mlawren@69-56-241-204.theplanet.com) left irc: Ping timeout: 480 seconds [04:24] noel_ (~noel@pD9FFA50C.dip.t-dialin.net) joined #vserver. [04:30] Nesh (~dmistry@su-nat.datapipe.net) left irc: Ping timeout: 492 seconds [04:32] noel- (~noel@pD9FFA4B2.dip.t-dialin.net) left irc: Ping timeout: 504 seconds [05:00] mlawren (~mlawren@69-56-241-204.theplanet.com) joined #vserver. [05:00] mlawren (~mlawren@69-56-241-204.theplanet.com) left irc: Client Quit [05:44] youam (~youam@sc-gw.scientific.de) left irc: Ping timeout: 501 seconds [05:46] youam (~youam@sc-gw.scientific.de) joined #vserver. [06:24] Cmaj (~cmaj@3ffe:bc0:5f3:1:9999:911:c3d3:5431) left irc: Ping timeout: 483 seconds [06:59] Cmaj (~cmaj@3ffe:bc0:5f3:1:9999:911:c3d3:5431) joined #vserver. [07:11] Doener_aw (~doener@p5082D80D.dip.t-dialin.net) joined #vserver. [07:11] HI [07:17] Doener_zZz (~doener@pD9588773.dip.t-dialin.net) left irc: Ping timeout: 488 seconds [07:19] Nick change: riel -> surriel [07:56] _maharaja (maharaja@213.158.115.2) joined #vserver. [07:56] maharaja (maharaja@ipax.tk) left irc: Read error: Connection reset by peer [08:11] talon (talon@host-63-149-223-100.irwinresearch.com) left irc: Quit: Hey! Where'd my controlling terminal go? [08:18] <_shur1> hi [08:29] he _shur1 [08:30] <_shur1> gnite [09:07] youam (~youam@sc-gw.scientific.de) left irc: Remote host closed the connection [09:13] (hi Bert, sladen) [09:13] hmmm, replying 350K/sec late, a new world's record :) [10:11] Nick change: Bertl_zZ -> Bertl [10:12] hi lilo! [10:15] okay I'm away again .. cu later ... [10:15] Nick change: Bertl -> Bertl_oO [10:30] Winks (~paul@cpc1-stre1-6-0-cust47.bagu.cable.ntl.com) left irc: Read error: Connection reset by peer [10:31] Hm-hm. [10:31] Action: virtuoso looks for exp patch against -mm kernel. :) [10:37] morning.. [10:38] hi [10:44] Anyone interested in such patch? :) [10:44] I have it ready. :) [12:55] Nick change: Bertl_oO -> Bertl [12:55] hi virtuoso! [12:57] Nick change: Doener_aw -> Doener [12:57] morning... [13:02] morning! [13:08] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [13:08] hi mhepp! [13:09] WSU (~Josh@ny.webpipe.net) left irc: Quit: Leaving [13:11] Hi [13:21] Bertl: Hi [13:21] heard you did a mm patch? [13:21] (well actually read ;) [13:22] Bertl: Yeah, I had a question about it. [13:22] yeah? [13:24] Bertl: Have a look please: http://www.sot.com/~as/patch-2.6.2-mm1-vs0.06.diff [13:26] Bertl: Originally, S_IUNLINK conflicted with S_NOCMTIME in fs.h so I reassigned it. [13:26] Bertl: This is what bothers me. :) [13:26] hum? it did? [13:27] Oops, S_BARRIER actually. [13:27] +#define EXT2_BARRIER_FL0x04000000 /* chroot barrier */ [13:27] +#define EXT2_IUNLINK_FL0x08000000 /* Immutable unlink */ [13:27] looks like the flags I assigned ;) [13:27] #define S_BARRIER 512 /* chroot barrier */ [13:27] +#define S_IUNLINK 1024/* Immutable unlink */ [13:27] this is what you mean, right? [13:28] Yeah. [13:28] well, taht should be okay, it's the in memory inode representation [13:28] That's what I supposed. [13:28] Cool. [13:28] did you test it? [13:28] Not yet. [13:29] well, would suggest to do that, and then get working on 0.07 ;) [13:29] Is 0.07 ready? [13:29] almost ... [13:29] I will reboot today, I think. :) [13:34] btw, you should always test a patch at least with qemu or bochs (or vmware if you have to ;) [13:37] are there known issues with the ck patchset+vserver? we've got two boxes running approx. 1500 processes and i guess the O(1) scheduler should make some big improvements there, so ck would come in handy... [13:38] hmm, guess so, the ck is a little outdated ..let me see what needs to be done to get this up-to-date [13:52] Doener: are you interested in testing 1.3.7 for ckX? [13:55] not too much atm... the boxes concerned are production and i've got little to no spare time this week as i got to deal with some university stuff, stupid 8 bit cpu i got to design is trying to fool me [13:56] okay, np ... [14:13] Nick change: Bertl -> Bertl_oO [14:41] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [15:01] He-he. Intermezzo doesn't compile. [15:29] Nick change: Bertl_oO -> Bertl [15:29] hmm, < virtuoso> He-he. Intermezzo doesn't compile. how'd you know? [15:42] je (~je@hd5e25b7f.gavlegardarna.gavle.to) left irc: Remote host closed the connection [15:43] Bertl: It actually doesn't. [15:44] There is reference to some undefined structure member. [16:13] hmm, so you have the sources? [16:13] ah sorry was confused, you mean the fs ... [16:14] what is the problem there? [16:16] I'm not digging that. I don't really use intermezzo. [16:17] I may racall though. [16:18] No, I cannot. :( [16:18] hmm, well okay, guess it doesn't matter ;) [16:18] My scrollback history is too short to fit all kernel compilation messages. [16:19] you should compile with make ... >../Build.log [16:19] that will only display warnings and errors ... [16:19] and save the rest to the Build.log [16:19] I'll notice that. [16:20] But everything else compiled fine. [16:24] what kernel/patches was this? [16:38] mm1+vs0.06 [16:38] 2.6.2 [16:39] hmm, did you try if intermezzo compiles with the vanilla kernel [16:39] Nope. [17:54] miller7 (~none@adsl49-static-gw1.access.acn.gr) joined #vserver. [17:54] hello guys [17:54] hi miller7! [17:54] heya Bert [17:54] how's it going? [17:55] fine, thanks ... 1.3.7 and quota is out ;) [17:55] All right! :) [19:08] loger joined #vserver. [19:38] ExpiryJames (~james@h24-71-63-164.ok.shawcable.net) joined #vserver. [19:45] hi ExpiryJames! [19:46] <_shur1> :P [19:48] hi _shur1! [19:49] ydupont (~ydupont@lamier.cri.univ-nantes.fr) joined #vserver. [19:50] hello [19:51] hi yann! [19:51] so you made it ;) [19:51] this took time because I had tyo change our firewall rules [19:52] ahh, thre true reason for not using irc ;) [19:52] (you know irc is too much used by our students) [19:52] well, know the main reason (lots of disruptive taks) is still the good one [19:53] anyway. One good thin and 1 bad thing. wich one to start with ? [19:53] the bad of course ... [19:53] the xfs patch is not working... [19:53] in fact, the barrier is not checked [19:53] and I can escape [19:53] (even with the 1.26 delta applied) [19:54] good morning [19:54] the good one : switching on ext3 for the host and still using xfs on vservers volumes IS working [19:54] and can't escape anymore. [19:54] good morning too [19:55] hmm, interesting, well are you interested in getting the xfs support right? [19:55] of course yes [19:56] okay, so you are currently testing? with 1.26, is there any chance to test the devel kernel? [19:56] i changed almost all my servers in XFS some times ago - Re switch on ext3 for root is not such a big deal [19:56] I can on a machine that is not a prduction one [19:57] it would be interesting, as the devel version should support xfs, but you ahve to use the barrier flag there ... [19:58] with the chattr +t /vserver ? [19:58] nope, that requires Enrico's alpha tools ... [19:58] I think I have those [19:59] 0.28.197 is the latest version ... [19:59] util-vserver-0.28.91 [19:59] opps. [19:59] don't have the latets [19:59] I'll take thoses. [19:59] well, there is a tar.bz2 and an rpm (mdk) on my site .. [20:00] 0.28.200 has CLONE_NS & RBIND mounting so this does not need the barrier stuff anymore. But you can not do 'vserver ... enter' anymore [20:00] oh [20:00] hi enrico! [20:00] ydupont: I would not use the alpha branch on production servers... [20:00] of course not [20:00] it is just for testing! [20:01] I have a test machine where I validate all the modifications :-) [20:01] ydupont: see http://www.linux-vserver.org/index.php?page=alpha+util-vserver [20:02] Ionly see the .199 version... [20:03] yep... .200 is in CVS only ;) [20:03] ok. so I need the CVS repositery [20:03] momment please... [20:04] ok ... [20:05] yann, the chattr works on 1.26, but the barrier not, right? [20:06] yes that's right [20:06] could you unmount and remount the xfs filesystem and check with lsattr if the t flag is still set? [20:06] in fact I used yout 1.25 for 2.4.25rc1 + patches for XFS + delta 1.25 -> 1.26 [20:06] Mhhh my XFS fs is the /root [20:07] that is /vserver is on my root, [20:07] and all the entries are mounted (there are evms volumes) [20:07] the only way to remount is to reboot [20:07] mhh wait wait [20:08] Nick change: cgone -> cdub [20:08] I switched one of my machines to ext3 on a spare partition, I still have the old / one the old partition. [20:08] hi cw! [20:09] lsattr /mnt/Tempo [20:09] ---------------t- /mnt/Tempo/vservers [20:09] so, it's still there [20:09] okay, that is a step in the right direction ... [20:10] hmm, how did you verify that the barrier doesn't work [20:10] with the exploit posted on insecure.org [20:11] ensc: the lsxid and chxid don't work on . files? [20:11] with ext3/ext2 root, the program says the exploit works, but there are lots of .. : permission denied, and in the end, you're still on the vserver [20:11] with xfs you're on the host / [20:11] lsxid , chxid ?? what is that ? [20:12] okay, did you verify that the flag is set and the mods are 000 [20:12] miller7: what do you get there? [20:12] yes. [20:12] ydupont: experimental [20:12] ensc: I think that it does not see these files cause some dirs I had (.mc for example) I think that they didn't change context [20:12] not sure, just asking whether this is valid [20:13] miller7: there is a '-a' switch [20:13] ydupont: and the exploit reported what exactly? [20:13] ensc: oh, ok. I'll try that. Didn't see it (and I looked for it :-)) [20:14] well if i remeber correctly there is lots of ".. : permission denied", 5 or 10 message of this kind, the program exit and say that the exploit work, but you're NOT chrooted on the hosty. THAT is for ext3 [20:14] for XFS, it only says that the exploit work, and this is true ... [20:15] miller7: ah... chxid does not have it [20:19] ... just one thing (and sorry to bother you:): For the moment, the sanest thing to do is to swith to ext2/ext3 host, for my production servers ?? [20:20] miller7: http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/chxid.c.diff?r1=1.7&r2=1.8 [20:20] similarly for setattr.c [20:21] ensc: thanks, I'll try it later and see how it goes [20:22] ydupont: I'm not sure about that, but it might be an option, but I'm sure we can fix this for xfs in the next few hours ... [20:24] Well, I'll swith another "critical" server this afternoon, and I can wait for the others... [20:25] anyway, won't swith all my server today, my children are waiting for me [20:31] hmm, the exploit doesn't print any message except for the 'succeded'? [20:32] no [20:32] I can reboot if you want - maybe there is something i've missed [20:33] hmm, it would be interesting to verify that, because if this is true, it would mean that xfs bypasses any vfs checks ... [20:33] uhu [20:33] ok. I'll reboot [20:33] wait (3 min or so...) [20:33] np [20:34] reboot in progress [20:34] (the boot takes lot of times - because of raid...) [20:39] ok that's it [20:40] glenmorangie:/home/ydupont# cat /proc/mounts [20:40] rootfs / rootfs rw 0 0 [20:40] /dev/root / xfs rw 0 0 [20:40] proc /proc proc rw 0 0 [20:40] /dev/evms/Bastion /vservers/BASTION xfs rw 0 0 [20:40] /dev/evms/FTP /vservers/FTP xfs rw 0 0 [20:40] /dev/evms/Popeye /vservers/POPEYE xfs rw 0 0 [20:40] /dev/evms/DNS2 /vservers/DNS2 xfs rw 0 0 [20:40] devpts /dev/pts devpts rw 0 0 [20:40] none /vservers/BASTION/proc proc rw 0 0 [20:40] none /vservers/BASTION/dev/pts devpts rw 0 0 [20:40] none /vservers/DNS2/proc proc rw 0 0 [20:40] none /vservers/DNS2/dev/pts devpts rw 0 0 [20:40] none /vservers/FTP/proc proc rw 0 0 [20:40] none /vservers/FTP/dev/pts devpts rw 0 0 [20:40] none /vservers/POPEYE/proc proc rw 0 0 [20:40] none /vservers/POPEYE/dev/pts devpts rw 0 0 [20:40] so the / IS xfs here. [20:40] (as the vservers themselves) [20:40] glenmorangie:/home/ydupont# chmod 000 /vservers [20:40] glenmorangie:/home/ydupont# chattr +t /vservers [20:40] glenmorangie:/home/ydupont# [20:41] okay verify with lsattr and ls -lad [20:41] so, no problems here, chattr is happy [20:41] lenmorangie:/# lsattr [20:41] ---------------t- ./vservers [20:41] glenmorangie:/# ls -lad vservers [20:41] d--------- 6 root root 54 Feb 10 12:33 vservers [20:41] is ls -lmad shoud show something else ? [20:41] ls -lad sorry [20:42] it looks okay ... [20:42] usr/local/opt/VSERVER/sbin/vserver POPEYE enter [20:42] /usr/local/opt/VSERVER/sbin/vserver: ulimit: cannot modify max user processes limit: Invalid argument [20:42] ipv4root is now xxx [20:42] New security context is 49155 [20:42] root@Popeye:/# [20:42] BTW vserver is from util-vserver 0.28 [20:42] hmm, could you use ssh not enter? [20:42] Cmaj (~cmaj@3ffe:bc0:5f3:1:9999:911:c3d3:5431) left irc: Ping timeout: 483 seconds [20:42] ok no problems [20:43] ssh popeye [20:43] ydupont@popeye's password: [20:43] Linux popeye 2.4.19-pre10 #3 Mon Jun 24 15:22:34 CEST 2002 i586 unknown unknown GNU/Linux [20:43] [20:43] The programs included with the Debian GNU/Linux system are free software; [20:43] the exact distribution terms for each program are described in the [20:43] individual files in /usr/share/doc/*/copyright. [20:43] [20:43] Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent [20:43] permitted by applicable law. [20:43] You have mail. [20:43] ydupont@Popeye:~$ su [20:43] Password: [20:43] bash-2.05b# [20:43] bash-2.05b# ./a_tester [20:43] mkdir baz: File exists [20:43] Exploit seems to work. =) [20:43] sh-2.05a# ls [20:43] CACHENEWS bin dev ftp lib proc sys var [20:43] FREESPACE boot etc home lost+found root tmp vmlinuz [20:44] TRANSTEC cdrom floppy initrd mnt sbin usr vservers [20:44] this is my host root [20:44] and it probably would be beneficial to change -H to -HS in the config file to get rid of that ulimit message, or is that something else? [20:44] yup, looks worse that I thought ... [20:44] no, this is leftover from old config [20:44] let's check if this is a broken patch or something similar ... sec [20:44] the baz is because I already test the exploit... [20:47] _shur1 (~shushushu@vserver.electronicbox.net) left irc: Quit: changing servers [20:47] _shur1 (~shushushu@vserver.electronicbox.net) joined #vserver. [20:51] ydupont: okay, I have a patch for you to test against 2.4.25-rc1 ... http://vserver.13thfloor.at/Experimental/patch-2.4.25-rc1-vs1.26.diff [20:52] you're god :-) [20:52] hmm, do not worship me too early ;) [20:52] I'm not even sure that works ... [20:55] ok...I'll have to patch now [20:55] in 5 min the kernel will be ok [20:55] okay, we'll make some tests with that kernel when you are ready ... [20:56] ensc: about the fakeinit zombie ... [20:56] yep? [20:56] I spent some thoughts on that, and I guess that can be easily solved, but it has other implications too ... [20:56] not sure i'll have to test much today... [20:56] i can... sorry [20:57] np [20:57] ensc: per definition, the initpid (fakeinit process) is the (child) reaper of all other processes in that context ... [20:58] so there will be some trouble when that process exits before all of the other processes are done ... [20:58] uh. I have to apply the dm pacthes I forgotten (sorry) [20:59] you are using lvm2? [20:59] evms [20:59] or evms? [20:59] ah okay ... [20:59] verry happy with it BTW [20:59] hmm, thought about testing it, good to know that it actually works ... [21:00] very well :) [21:00] maybe you know,: how is the performance over software raid? [21:00] I switched all my setup (even my laptop) [21:00] goof [21:00] good, [21:00] very good [21:00] i user software raid 1 at home with evms [21:00] no degradation [21:00] okay, had some soft raid issues with lvm2, that's basically why I didn't switch yet ... [21:00] oh, there is still [21:01] basically i use evms on top of md device [21:01] but didn't put lvm volume on it [21:01] not sur i'm clear :-) [21:03] ok, compilation is starting [21:03] -> about evms: [21:03] I had a case of corruption [21:04] with software Raid. [21:05] when you uses plain partition /dev/sda3, /dev/sdb1, for example, this is working [21:05] hmm [21:05] (even if /dev/sda3 , /dev/sdb1 ARE driven by evms) [21:05] that is, your software raid is really /dev/evms/diskone , /dev/evms/disktwo [21:06] BUT. If one of your arry IS a lvm volume driven by evms, you have corruption [21:06] This was 3 months ago, with 2.6 kernel. Didn't tried since [21:07] Anyway, trid lvm2 before switching to evms... Didn't regret it [21:10] Bertl: hi! (sorry for the lag ;-) [21:16] np [21:17] ok reboot in progress [21:21] ahem... [21:21] not better i'm afraid [21:21] what happens? [21:21] the very same [21:21] I almost assumed that ... [21:22] okay, let's do one maybe two checks ... [21:22] ok, [21:22] first give the testme.sh script a run please ... [21:22] where it is ? [21:23] http://vserver.13thfloor.at/Stuff/testme.sh [21:25] it's not destructive ? [21:25] no, it should not be ... [21:25] is this the script that formats the HD Bert? :P [21:25] huhu [21:26] btw, why I get all "OK" to that script while some time ago there was a FAIL there? [21:26] something I did? [21:26] miller7: nope that was the previous version ... it's much smarter now ... [21:26] too bad... I need some boxes to be blindly killed [21:26] miller7: ad FAIL that was voodoo, said enrico ;) [21:26] :-) [21:26] mhh shoud I test inside a vserver ? [21:26] nope, on the host [21:27] ok [21:27] ydupont: I'm just kiddin [21:27] miller7: of course [21:27] :) [21:28] glenmorangie:~/TEST# ./testme.sh [21:28] Linux-VServer Test [V0.06] (C) 2003-2004 H.Poetzl [21:28] chcontext is working. [21:28] chbind is working. [21:28] Linux 2.4.25-rc1-vs1.26 i686/chcontext 0.28/chbind 0.28 [J] [21:28] --- [21:28] [001]# succeeded. [21:28] [011]# succeeded. [21:28] [031]# succeeded. [21:28] [101]# succeeded. [21:28] [102]# succeeded. [21:28] [201]# succeeded. [21:28] [202]# succeeded. [21:28] ... wich means ? [21:28] okay looks good [21:28] [301]# format succeed :P [21:28] now please do the following: [21:28] cd /tmp/ [21:28] mkdir X [21:28] chmod 000 X [21:29] done, [21:29] chcontext --ctx 100 rmdir /tmp/X [21:29] glenmorangie:/tmp# chcontext --ctx 100 rmdir /tmp/X [21:29] New security context is 100 [21:29] interesting ... [21:29] okay, let's try again with: [21:29] mkdir X [21:30] chmod 000 /tmp/X [21:30] chattr +i /tmp/X [21:30] chcontext --ctx 100 rmdir /tmp/X [21:30] glenmorangie:/tmp# chcontext --ctx 100 rmdir /tmp/X [21:30] New security context is 100 [21:30] rmdir: `/tmp/X': Operation not permitted [21:31] ah okay ... good next step [21:31] chattr -i +t /tmp/X [21:31] chcontext --ctx 100 rmdir /tmp/X [21:31] glenmorangie:/tmp# chcontext --ctx 100 rmdir /tmp/X [21:31] New security context is 100 [21:31] rmdir: `/tmp/X': Operation not permitted [21:33] hmm ... hmm ... [21:33] looks like the flags are working as expected ... [21:33] chcontext --ctx 100 chmod +x /tmp/X [21:33] glenmorangie:/tmp# chcontext --ctx 100 chmod +x /tmp/X [21:33] New security context is 100 [21:33] chmod: changing permissions of `/tmp/X': Operation not permitted [21:34] okay, maybe your issue isn't xfs related, but more mountpoint related ... [21:34] try to umount the vserver [21:34] not sure [21:34] you have them on /vservers ? [21:34] because the mount points remains the same if I swit to the (exact recplication) ext3 fs [21:35] do you ahve them on /vservers? [21:35] yes [21:35] okay, please unmount the /vservers [21:35] and try the following sequence: [21:35] stopping them [21:35] rmdir /vservers [21:36] mkdir /vservers [21:36] chmod 000 /vservers [21:36] chattr +t /vservers [21:36] mount /vservers [21:36] chmod 000 /vservers [21:36] chattr +t /vservers [21:36] then start the vserver and try the exploit once again ... [21:37] have to leave in a minute or so .. but if this doesn't help there is something really strange with xfs going on ... [21:38] well i have to recreat all 4 dirctory in /vservers [21:39] ok 4 vservers restared [21:40] bash-2.05b# ./a_tester [21:40] mkdir baz: File exists [21:40] Exploit seems to work. =) [21:40] sh-2.05a# ls [21:40] CACHENEWS bin dev ftp lib proc sys var [21:40] FREESPACE boot etc home lost+found root tmp vmlinuz [21:40] TRANSTEC cdrom floppy initrd mnt sbin usr vservers [21:40] uhuh... sorry [21:40] please tell me : I don't have to chattr +t on ALL my /vservers subdirectories [21:41] hmm, no, sorry, I'll check that later have to leave now :( [21:41] me too [21:41] thanks for your patience [21:41] bye ! [21:41] ydupont (~ydupont@lamier.cri.univ-nantes.fr) left irc: Quit: Leaving [21:41] cu [21:41] Nick change: Bertl -> Bertl_oO [22:26] miller7 (~none@adsl49-static-gw1.access.acn.gr) left irc: Read error: Connection reset by peer [22:31] mlawren (~mlawren@69-56-241-204.theplanet.com) joined #vserver. [22:31] Hello all [22:35] Cmaj (~cmaj@3ffe:bc0:5f3:1:9999:911:c3d3:5431) joined #vserver. [22:35] I have a question... if anyone is awake... [22:35] Aimed at Paul and Herbet, re: the reboot(2)/vshelper interface [22:36] mlawren (~mlawren@69-56-241-204.theplanet.com) left irc: Quit: ircII2.8.2-EPIC3.004 --- Bloatware at its finest. [22:37] mlawren (~mlawren@69-56-241-204.theplanet.com) joined #vserver. [22:38] mlawren (~mlawren@69-56-241-204.theplanet.com) left irc: Client Quit [22:51] <_shur1> hey it is possible to give acess to iptables in a vserver without to much security risk? [23:20] doubt it [23:23] serving (~serving@213.186.188.205) left irc: Read error: Connection reset by peer [00:00] --- Wed Feb 11 2004