[00:00] next step, remove the CAPS you added to the vserver config [00:00] did [00:00] okay, now let's have a look at the mounttab with 'cat /proc/mounts' [00:02] rootfs / rootfs rw 0 0 [00:02] /dev/root / ext3 rw 0 0 [00:02] /proc /proc proc rw 0 0 [00:02] /dev/sda1 /boot ext3 rw 0 0 [00:02] none /dev/pts devpts rw 0 0 [00:02] none /dev/shm tmpfs rw 0 0 [00:02] /dev/sda2 /usr ext3 rw 0 0 [00:02] /dev/sda3 /var ext3 rw 0 0 [00:02] /dev/sda7 /home ext3 rw 0 0 [00:02] none /home/vservers/ray/dev/pts devpts rw 0 0 [00:02] /dev/loop0 /tmp ext3 rw,nosuid,noexec 0 0 [00:02] /dev/loop1 /var/tmp ext3 rw,nosuid,noexec 0 0 [00:02] [root@sopher dev]# umount /home/vservers/ray/dev/pts [00:02] umount: /home/vservers/ray/dev/pts: device is busy [00:02] probably something is using it ... somehow ... terminal/ssh/etc [00:03] ok tahts ray we'll do taht after [00:03] ok so now what? [00:03] start pinny? [00:03] now we check the runlevel scripts ... [00:03] cd /home/vservers/pinny [00:03] cd etc/ [00:04] rc.d/rc.local is emtpy for pinny [00:04] okay what about rc3.d? [00:04] ist all normal [00:04] please show me the entries ... [00:05] ok [00:05] K05kudzu K45arpwatch K65identd S08iptables S17keytable S34named S80sendmail S94admserv S99local [00:05] K13portmap K46radvd K74nscd S09isdn S20random S39poprelayd S85gpm S95anacron [00:05] K20nfs K50snmpd K74ypserv S10network S25netfs S55sshd S90crond S95atd [00:05] K28autofs K50snmptrapd K74ypxfrd S12syslog S26apmd S56rawdevices S90mysql S97rhnsd [00:05] K34yppasswdd K60lpd S08ipchains S14nfslock S26ntpd S56xinetd S90xfs S98httpd [00:05] okay, this is inside the vserver? [00:05] ya [00:06] (just to make sure you are not messing with the host runlevels ;) [00:06] okay everything hw related isn't useful inside a vserver ... [00:06] ok [00:06] kudzu [00:06] K05kudzu S20random S26apmd S85gpm S09isdn [00:07] ok [00:07] will remove those [00:07] this can go without any questions ... [00:07] same is K45arpwatch K28autofs S56rawdevices S08ipchains S08iptables [00:07] ok [00:08] Last message repeated 1 time(s). [00:08] ah and S17keytable [00:08] what is K46radvd ? [00:08] is there a way to use iptables in vservers? [00:08] i dont know [00:08] not from inside a vserver [00:08] but you can define iptable rules for vservers [00:08] okay, show me the remaining services once again ... [00:10] K45arpwatch K65identd S34named S80sendmail S94admserv S99local [00:10] K13portmap K74nscdn S39poprelayd S95anacron [00:10] K20nfs K50snmpd K74ypserv S10network S25netfs S55sshd S90crond S95atd [00:10] K28autofs K50snmptrapd K74ypxfrd S12syslog S56rawdevices S90mysql S97rhnsd [00:10] K34yppasswdd K60lpd S14nfslock S26ntpd S56xinetd S90xfs S98httpd [00:11] okay, following services are dubious for me, so they should be removed for now: [00:11] K28autofs [00:11] K45arpwatch [00:11] K50snmpd [00:11] K50snmptrapd [00:11] K60lpd [00:11] S56rawdevices [00:12] don't know what the S25netfs is [00:12] now have a look at the vservers init.d/syslog script [00:12] this probably starts syslog and the klogd shortly one after the other ... [00:13] ok [00:13] im tryignto build /dev on ray, but it says [00:13] [root@sopher dev]# umount /vservers/ray/dev/pts [00:13] umount: /vservers/ray/dev/pts: device is busy [00:14] what do i do about syslog - it looks normal? [00:15] is there a line for syslogd and a second for klogd? [00:15] hm i have to run [00:15] ill be back later [00:15] thanks! [00:15] ok cu [00:19] paul (~irssi@pD9FF14FA.dip.t-dialin.net) joined #vserver. [00:19] hi [00:19] hi paul! [00:21] Mister_A_ (~mab@nat01-clo-ext.Rutgers.EDU) left irc: [00:26] Bertl: GDB does not have an x86 sim target [00:27] Bertl: but thats a minor detail [00:29] Bertl: is this what you were looking for ? [00:29] Bertl: http://bitrange.com/temporary/a-place-to-test-gcc-webpages--do-not-bookmark/simtest-howto2.html [00:30] hmm, basically the right direction, but a long way to the regression tests ... [00:30] Bertl: okay [00:30] well, not too long ... [00:31] but yes,this is a good start [00:33] has been some time since, so maybe new targets, but might be also that some stuff is already broken :( [00:33] Bertl: that wouldnt be good [00:34] are the regression tests code specific? like some tests are not useable on the kernel ? [00:34] basically the regression tests are simple C programs ... [00:34] some apply to the kernel, others not (for example those using float) [00:35] but this doesn't matter, basically gcc should be able to compile all those tests correctly [00:35] (for every arch it supports) [00:35] so, how does this benefit your work ? [00:36] heh, I'm currently trying to get a cross compiling kernel environment up and running ... [00:36] http://vserver.13thfloor.at/Stuff/Cross/ [00:36] and I take a shortcut for the toolchain 8-) [00:36] http://vserver.13thfloor.at/Stuff/Cross/howto.info [00:38] hmm' [00:40] and the response from the gcc and cross compiling folks was intense ... [00:40] this cat't work, because we always did it with (g)libc ... [00:41] how often would the regression test run ? [00:41] hmm, which one, kernel, gcc, 'your simulation'? [00:42] maybe it's because i miss some knowledge [00:42] i think you mentioned it at some point, but i can not find it when i scroll back [00:42] just ask again ... ;) [00:43] i seem to remember you said something about you would use the regression tests to test if your new code changed the way fakeinit worked ? [00:43] nope [00:43] the chain of thought - usefullness is this: [00:44] linux kernel -> cross compile [00:44] linux kernel + vserver patches + cross compile -> platform check [00:44] vserver + crosscompile + time/releases -> regression checks [00:45] and to do that, we need MANY, MANY cross compiling toolchains, which just WORK [00:45] ?? you cross compile the kernel, or the kernel can cross compile [00:45] now I think I have found a way to get them easily ... [00:46] what I do is compiling a MIPS kernel on an i386 for example ... [00:46] to see if vserver would compile on MIPS ;) [00:47] and the time/releases ? [00:47] well, if I test for example vs0.08 on alpha, sparc, mips ... [00:47] and a little later vs0.09 on alpha, sparc, mips, and suddenly mips has an error, which wasn't there before, then this is a regression [00:48] now the question is, what causes the error ... [00:48] ofc [00:48] it could be a change in the kernel (which can be tested by comparing it to the vanilla kernel build) [00:48] or it could be a 'regression' in vserver [00:49] or it could be an error in the cross compiling toolchain ;) [00:49] ben (ben@bengrimm-host229.dsl.visi.com) left irc: Read error: Connection reset by peer [00:49] and that is, where the gcc 'regression' tests come into play [00:49] ahhh [00:49] to verify that the toolchain for mips is working ... we have to do the gcc regression tests ... [00:49] and because it is cross platform, it could be tested using the GDB sim target [00:50] as the regression tests fall in two categories, a) compile only, b) compile and execute ... the b) part needs either a mips or a sim [00:51] but how can you be sure the GDB sim is good enough ? [00:51] how often do the toolchain change ? [00:52] well, I can't, but this could be used to do several things: [00:52] a) compare the fast patch I have chosen to the slow (g)libc toolchain [00:52] b) verify general gcc regression stuff and compare it from time to time to real hardware [00:53] c) if the regression + sim works, everything is okay, if not, the tests/gcc must be investigated ... [00:54] why are your patch faster? what makes glibc slow, does that have to be rebuilt with every kernel ? [00:55] okay, one question at a time: [00:56] my path (did I write patch again?) is faster because it doesn't require the glibc and headers to be built for the cross compiling arch [00:56] what is required to build ? [00:57] ls [00:57] sorry, wrong window... [00:58] building glibc takes about 4-5 times as long as binutils+gcc [00:58] but that is not the only problem, for many archs, it's not even possible to build a sane glibc ... [00:59] Dan Kegel is working on cross compiling toolchains for a long time now ... [00:59] http://gcc.gnu.org/simtest-howto.html [01:00] using his crosstool build system, I managed to get the following toolchains working [01:01] alpha, i686, ia64, m68k, mipsel, powerpc, sh4, sparc [01:01] compiling did take about a day ... [01:02] total ? [01:02] using my approach, I built the following in about 4 hours [01:02] alpha, arm, cris, hppa, hppa64, i386, ia64, m68k, [01:02] mips, mips64, ppc, ppc64, s390, sh, sh4, sparc, [01:02] sparc64, v850, x86_64 [01:03] and while we are talking, I'm probably adding s390x ... [01:03] kay i can see the advantage [01:04] but, I can not proove that thos toolchains will compile the kernel as expected ... [01:04] well, actually nobody can proove this for any toolchain ;) [01:05] but I would like to know if, when and maybe in what aspect, my toolchain deviates from the 'default' toolchain ... [01:05] ofc. [01:06] and as a side effect, the gcc people can be blamed for errors in the compiler ;) [01:07] if there are any [01:08] well, I'm sure there are, and there always will be ... [01:09] yep, s390x toolchain finished ... [01:09] with Dan's crosstool, s390 doesn't even build ;) [01:10] (not his fault, probably broken glibc ...) [01:10] TheCount (~count@pD9E7C7FA.dip0.t-ipconnect.de) joined #vserver. [01:10] hi! [01:10] uh - help! :O) [01:10] hi Count! [01:10] http://www.securityfocus.com/bid/9596/exploit/www.securityfocus.com/vulns works on 1.26, and I'm unable to help myself :( [01:11] (the chroot exploit) [01:11] unfortunate ... (you are #22 if my counting is correct) [01:11] I've been googling etc. quite a while now, but didn't have any success? [01:11] hi Bertl [01:11] Bertl: so, what do I do? [01:11] probably something wrong ;) [01:12] lets just check the obvious ... [01:12] http://vserver.13thfloor.at/Stuff/testme.sh [01:12] what does this give on the host? [01:12] one moment :) [01:13] [201]# failed. [01:13] I shouldn [01:13] I shouldn't paste that here, should I? no fails [01:14] paste it in private ... [01:14] done [01:15] okay .. looks good ... [01:15] JonB: this is normal for stable and older utils ... [01:16] what filesystem do you use for the vserver part, and where/how is it mounted? [01:16] me? [01:17] no, the counte [01:17] -e [01:18] Bertl: uhm, ext3 [01:18] mounted on / [01:19] okay ... now where are the vservers? [01:19] Bertl: debian, thus /var/lib/vservers [01:19] Bertl: in /vservers, a ext2 mounted on /vservers [01:19] ext3 [01:19] okay so let us have a look at the folowing output ... [01:20] ls -lad /var/lib/vservers /var/lib [01:20] ( ls -lad /vservers / for you Jon) [01:20] Bertl: got it, pasting in private [01:20] d--------x 16 root root 4096 Nov 21 22:21 /var/lib [01:20] d--------x 14 root root 4096 Dec 12 18:45 /var/lib/vservers [01:21] and the same with lsattr -d /var/lib/vservers /var/lib [01:21] only - [01:21] ( lsattr -d /vservers / for you jon) [01:22] none as well [01:22] congrat, both setups are insecure ;) [01:22] now we are going to secure them ... [01:22] cool [01:22] chmod 000 /var/lib/vservers (TheCount) [01:23] chattr +t /var/lib/vservers (TheCount) [01:23] done ;) [01:23] chattr +t /vservers (JonB) [01:24] as you are going to test this setup (I suppose ;) please make sure that you leave the vserver first (maybe even restart it) [01:24] ? [01:25] i did this in the root server [01:25] Bertl: umm .. ok. [01:25] yeah, but for testing any exploits ;) [01:25] well, i'm still confused [01:25] I assume TheCount did check with the exploit and still has a terminal open ;) [01:25] Bertl: works! :O) thanks [01:26] if you want to add yourself to the list of happy vserver users, feel free to do so ... [01:27] http://www.linux-vserver.org/index.php?page=VServer+Users [01:28] will think about it ;) [01:29] yeah, no need to hurry ... [01:31] hmmm... i can't get vserver build to do anything useful... [01:31] what do you want it to do? [01:31] build a vserver ;) [01:31] and what does vserver test build do for you? [01:32] No build-method specified :) [01:32] ah newer, even alpha utils? [01:32] http://www.linux-vserver.org/index.php?page=alpha+util-vserver [01:33] read that... results in a vserver root like this: [01:33] dev etc proc [01:33] Creates the vserver foo with the Fedora Core 1 distribution and apt-rpm method. [01:33] (for example) [01:33] vserver build -m skeleton [01:33] or this to build from a skeleton ... [01:34] vserver build -m debootstrap * -- -d sarge [01:34] or this to build via debootstrap on debian ... [01:37] all of them give me the above result... [01:37] which tools version? [01:38] "vserver creation within a Fedora Core 1 host" ... hmm, i didn't read that one... [01:38] i'm on debian... [01:39] then the debootstrap method is the simplest ... [01:39] 0.29.196 [01:39] vserver test2 build -m debootstrap -- -d woody [01:39] or sarge for example ... [01:40] make sure that debootstrap is installed ... [01:41] i just recalled the line i used before and now it works?! [01:42] vserver magic, no vserver tool would fail in my presence ... [01:42] ;) [01:42] hehe [01:44] ok, whenever a vserver tools fails for me again, i'll create a Bertl user and try to trick it ;) [01:44] ever tried to trick Murphy, by washing your car, just to make it rain? [01:46] but i dont want to make it rain [01:46] hehe [01:47] Bertl: *grin* [01:47] no, but i'll try to make it rain to have Murphy wash my car :) [01:47] *sigh* why can't that fucking hostmaster decide... [01:47] click: too little fucking lately? [01:48] finished up the mailserver-thingie, and now he wants me to move it BACK again, as his scripts didn't work. (no wonder, as all the scripts are on another box) [01:48] TheCount: me or him? me, yeah, dunno' about him. [01:53] JonB (~NoSuchUse@129.142.112.33.ip.tele2adsl.dk) left irc: Quit: Leaving [01:54] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [01:54] hi Simon! [01:54] hi Bertl :) [01:54] good to see u again! [01:55] Just trying to upgrade kernels and stuff... has 2.4.25-vs1.26 been tested under x86_64? [01:55] guess not, same for 1.3.7 [01:55] Ok, I get this when making: [01:55] gcc -D__KERNEL__ -I/usr/src/linux-2.4.25/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -finline-limit=2000 -fno-strength-reduce -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-unit-at-a-time -nostdinc -iwithprefix include -DKBUILD_BASENAME=vswitch -c -o vswitch.o vswitch.c [01:55] In file included from /usr/src/linux-2.4.25/include/linux/vcontext.h:83, [01:55] from /usr/src/linux-2.4.25/include/linux/vswitch.h:5, [01:55] from vswitch.c:17: [01:55] /usr/src/linux-2.4.25/include/asm/current.h: In function `stack_current': [01:56] /usr/src/linux-2.4.25/include/asm/current.h:20: error: `THREAD_SIZE' undeclared (first use in this function) [01:56] hmm, let me see ... [01:57] try to add #include to include/linux/vcontext.h [01:58] cool, that did the trick :) [01:59] I'm working on a cross compile farm, to avoid such errors in the future ... [02:04] nice [02:12] anything I should watch out for, upgrading from 2.4.22-c17h to 2.4.25-vs1.26? [02:13] phew ... reality might catch up soon ... ;) [02:13] beware there are a zillion new features and at least 3-4 exploits fixed ;) [02:13] yeah yeah ;) [02:15] have any of the old extra patches (quota etc) been rolled in? [02:15] vroot [02:15] and the quota was updated to 0.13 ... will soon be upped to 0.14 [02:16] what about file context ids, ili, is that all still the same? [02:17] ili is basically the same, contexts are similar [02:17] cool [02:17] you should use the vproc security stuff, and the chroot barrier ... [02:17] hey, before you upgrade, could you give my testscript a run? [02:17] what is the vproc stuff? [02:17] sure thing [02:18] http://vserver.13thfloor.at/Stuff/testme.sh [02:18] never got around testing it on ancient setups ;) [02:18] although it could have been ctx-13, right? [02:25] Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl [02:25] chcontext is working. [02:25] chbind is working. [02:25] Linux 2.4.22-c17h x86_64/0.23.93/0.23.93 [E] [02:25] --- [02:25] [001]# succeeded. [02:25] [011]# succeeded. [02:25] [031]# succeeded. [02:25] [101]# succeeded. [02:25] [102]# succeeded. [02:25] [201]# failed. [02:25] [202]# succeeded. [02:25] hmm, not so bad ... [02:26] what is vproc, what do I do with it? :) [02:26] sec [02:28] http://archives.linux-vserver.org/200401/0125.html [02:28] paul (~irssi@pD9FF14FA.dip.t-dialin.net) left irc: Quit: leaving [02:37] hmmm.... setattr crashed and i guess /proc is 'damaged' now, as for example ps just hangs... [02:37] hmm, you mean you hit the oops with setattr? [02:37] yepp [02:37] hmm, not too shabby .. thought nobody would find it ;) [02:39] http://doener.homeip.net/Oops [02:39] Not Found [02:39] The requested URL /Oops was not found on this server. [02:40] http://doener.homeip.net/doener/Oops [02:40] yeah, that's it ... [02:42] ok, can i safely restart my box or will /proc be messed up? [02:43] nope, you can restart, no problem there ... [02:43] what tools are you currently using? [02:43] 0.29.196 [02:43] current alpha tools [02:43] on 0.08 or later? [02:44] 0.08.4 as you suggested [02:44] hmm, sec [02:44] anything i should do before restarting? [02:44] pray? [02:45] owkie... reboot in progress... [02:45] *brb* [02:45] hmm, what API version does vserver-info report? [02:45] erhm... none? [02:46] [*] Select task to kill on out of memory condition (NEW) [02:46] bertl? [02:46] a good thing ? [02:46] kernel upgrade [02:46] for some ... [02:47] well, we're a shellprovider [02:47] at least vserver-info --help doesn't... should this be done in an other way? [02:47] (shell, web, etc) [02:48] Doener: vserver-info - SYSINFO [02:48] VS-API: 0x00010011 [02:48] click: well, do you want to select the task which is killed in a oom condition? [02:49] Doener: thanks ... [02:49] Doener: if you wait a few minutes, you could try the 0.09 prerelease, which should fix this ... [02:50] no, all running processes are maintained and I've checked that they won't cause trouble. the only thing I want killed is for instance forkoffs, that allocates mem and forks like f.... [02:50] i'm not quite sure if it just kills on random, or the latest spawning task [02:50] thinking of fork-bombs [02:50] basically the oom killer kills what he thinks is the best candidate for killing ... [02:51] (for example huge apache servers ;) [02:51] ups... [02:51] hm [02:51] what about forkbombs? [02:51] the oom just takes out the largest procs? [02:51] well, they are tiny in regard to the memory footprint [02:51] hm, darned. [02:51] got to set up some protection for forkbombs in grsec then [02:52] OOOH! grsec does that, I've forgot [02:53] too tired I guess [02:53] still haven't slept [02:54] 48+ hours [02:54] are you sure you aren't dead already? [02:54] Bertl: ok, i'll wait, i've got plenty of time today... too late to go to bed, i'd miss my test at university tomorrow if i'd go to bed... [02:54] Bertl: just checked, I've got pulse, but it's weak :) [02:55] thanks for caring :) [02:56] Doener: http://vserver.13thfloor.at/Experimental/patch-2.6.3-vs0.09-rc1.diff [02:59] Bertl, what's the chroot barrier? [03:00] a security feature to block chroot escape exploits ... [03:01] on ctx-17h for example, a simple 10 line C proggy, manages to leave the vserver if you are root on that vserver [03:01] d'oh [03:01] you then have 'root' access to the host ... [03:01] is it a kernel patch? [03:01] which one? the exploit? or the barrier? [03:02] the barrier :) [03:02] Action: Medivh wonders if the recent kernel exploit can used to break out of context? [03:02] the barrier is included in vs1.25/1.26/1.3.7 and vs0.08 and later [03:02] s/used/be used/ [03:02] but it requires userspace support ... [03:03] Medivh: you mean the mmap part 2 exploit? [03:03] oh ok, how do I get that? [03:03] Bertl, exactly [03:03] mremap() or what is was [03:03] bah, s/is/it/ ... can't type today ;) [03:03] it's not trivial to use this exploit ... but yes, it might be used for many things ... [03:04] ok, then i better go upgrade my vserver machine [03:04] not of my machines, but customers' ... sucks enough tho [03:04] Simon: with vs1.26 the only thing you have to make sure is to set the vservers dir permissions correctly ... [03:04] 000? [03:04] chmod 000 /vservers [03:04] and [03:04]