1115943092 M * mep_ is it possible to use fuse with vserver? 1115943359 M * Bertl probably ... 1115943443 M * mep_ failed to create device node 1115943456 M * mep_ hmm but i think grsecurity blocks there again anrf 1115943543 M * Bertl hmm, well, inside vservers you are not allowed to create device nodes 1115943549 M * Bertl (for security reasons) 1115943560 M * mep_ so how i solve this? 1115943564 M * DaCa mep_: if you want to allow creation of device node _inside_ the vserver, you are actually giving root in the vserver access to all your devices 1115943580 M * mep_ thats bad :/ 1115943620 M * DaCa so the solution is to do this stuff from the host 1115943622 M * mep_ but waht should i do now 1115943656 M * Bertl doesn't fuse require a kernel patch? 1115943661 M * mep_ nope 1115943667 M * mep_ its a modul 1115943863 M * DaCa Bertl: any idea how long an allyesconfig compile takes on a 900MHz C3 ? 1115943881 M * Bertl I'd say a few hours ... 1115944020 M * DaCa oh dear, I had better started it on the server :p 1115944450 M * Doener` hmm... s/hours/days/ ? 1115944475 M * Doener` i was already about an hour on my xp2600+... 1115944490 M * Bertl it's mainly I/O bound ... 1115944620 M * DaCa the server is a xp3000+, next time I'll do it there ... 1115946042 J * explasm__ ~explasm@p549FF6A6.dip.t-dialin.net 1115946059 M * Bertl hmm, wb explasm__? 1115946087 M * Bertl DaCa: don't worry, I'm compiling binutils and gcc for almost a week now ... 1115946482 Q * eXplasm2 Ping timeout: 480 seconds 1115947642 M * Bertl Doener`: hmm, where is the patch which 'caused' the xfs issues you fixed? 1115947670 M * Doener` http://www.13thfloor.at/~doener/vserver/patches/diff-2.6.11.7-vs2.0pre3-proc_doutsstring-3.diff 1115947712 M * Doener` we expanded struct ctl_table there and the xfs code uses the old initialization style (csv) 1115947736 M * Doener` thus we had to add NULLs there in the xfs fix 1115947739 M * Bertl ah, yes, thanks, that got into pre4, but didn't make it into FOR-2.0, no? 1115947787 M * Doener` right 1115947805 M * Bertl that's what confused me, thanks for the clarification 1115947840 M * Doener` you're welcome 1115947965 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-2.0 should now contain the 'missing' patches ... 1115947975 M * Bertl including http://vserver.13thfloor.at/Experimental/FOR-2.0/delta-schedacc-feat01.diff 1115947989 M * Bertl (which brings back the scheduler tick accounting) 1115948208 M * Doener` yep :) 1115948264 M * Doener` we actually did quite a lot FOR-2.0 considering that we initially said that 1.9.5.xsomething would just need some cleanup ;) 1115948296 M * Bertl yeah, but I have a strong feeling that 2.0 will be _really_ stable (from the kernel side) 1115948633 M * Bertl I expect more to come ... I'm going to release the rc1, hopefully folks will test it ... 1115951928 M * Bertl Patch Linux-VServer-2.6.11.9-vs2.0-rc1 accepted as Patch ID#4461 1115951946 T * Bertl http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, 2.0-rc1, ng9.4 -- He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1115951952 M * micah woo! 1115951965 M * Doener` micah: well, now you got to test it ;) 1115951978 M * micah hehe 1115951991 M * micah I'm trying to figure out why this vserver seems slow to respond 1115952018 M * Bertl seems or is? ;) 1115952034 M * micah thats wht i am trying to determine 1115952047 M * micah I showed someone how to setup vservers, and he really likes them 1115952052 M * micah but now he is asking me why they are "slow" 1115952064 M * micah so I am trying to figure out if it actually *is* slow or if it is something else 1115952278 M * Bertl well, how does he experience this 'slowness'? 1115952421 M * Bertl Doener`: do you know how to tell (on debian) to which .deb a file belongs to? 1115952451 M * micah it is experienced when using the website, which was much faster than before (so he makes a relative comparision) 1115952459 M * micah it could be there is a database connectivity problem or something 1115952466 M * micah Bertl: dpkg -S 1115952486 M * Bertl ah, great, thanks! 1115952516 M * Doener` micah: that works only for installed packages :/ there's another tool that searches in all packages, but it is terribly slow... 1115952529 M * Doener` i usually use the search at the bottom of http://www.debian.org/distrib/packages 1115952536 M * Bertl yeah, but that was sufficient for my purpose 1115952538 M * micah Doener`: ah yes, apt-file.... it takes forever to update 1115952550 M * micah yes, I will typically use packages.debian.org 1115952637 M * micah can someone explain to me why there is no lo interface in vservers? 1115952669 M * Bertl micah: well, it is there, you just don't see it? 1115952673 M * micah I'm having trouble answering my friend who thinks that a system without 127.0.0.1 on localhost is a foobar unix system 1115952692 M * Bertl has your friend an irc client? 1115952715 M * micah I think he is bothered that he cannot ping 127.0.0.1 1115952726 M * micah which I am guessing can be enabled 1115952727 M * Bertl (or is he reading your irc clients output?) 1115952736 M * micah well, he is on the phone :) 1115952798 M * Doener` ping 127.0.0.1 -I 192.168.100.100 1115952798 M * Doener` PING 127.0.0.1 (127.0.0.1) from 192.168.100.100 : 56(84) bytes of data. 1115952798 M * Doener` 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.061 ms 1115952801 M * Doener` works fine ;) 1115952831 M * micah hmm, doesn't in his vserver 1115952835 M * micah oh 1115952837 M * Doener` (you have to specify the source address though... evil raw sockets) 1115952842 M * micah weird 1115952843 M * micah howcome? 1115952858 M * Bertl it's a tradeoff 1115952879 M * Bertl to avoid virtualization overhead, the vservers are restricted to 'certain' ips 1115952892 M * Bertl and the 127.0.0.1 ip is usually not one of them 1115952903 M * Doener` if a proces in the vserver tries to access 127.0.0.1 is automatically rewritten to use the first ip address of the vserver instead 1115952981 M * micah Doener`: but if the first IP is the IP of the vserver, and it doesn't respond then that is different than doing ping 127.0.0.1 -I 1115953035 M * micah i need to get him on here :) 1115953073 M * Doener` ping tries to use 127.0.0.1 as source address and uses raw sockets (which we don't rewrite) 1115953097 M * Doener` i.e. dst becomes 192.168.100.100 in my case, but source stays at 127.0.0.1 1115953109 M * micah Doener`: raw sockets aren't re-written for security reasons? 1115953152 M * Doener` hm, well, in a raw socket, there could be anything in the header 1115953193 M * micah ahhhh 1115953195 M * micah that makes sense 1115953284 M * micah i must admit I was surprised to read on the mailing list that one should be doing setattr --barrier /vservers/vcrux02/.. on each vserver created! 1115953294 M * micah I thought it was only necessary to do on /vservers 1115953354 M * Doener` note the ".." ;) if all your vservers are really directly below /vservers (that one being a directory, not a symlink for example), it's enough to do it on /vservers 1115953379 M * micah ah! ok 1115953380 M * micah great 1115953381 M * Doener` /vservers/vcrux02/.. becomes /vservers then anyway 1115953396 M * micah then, it is the same (in my case) 1115953417 M * Doener` but there are cases where just omitting the vserver's directory name may _not_ give you the _real_ parent 1115953424 M * micah and setattr --barrier is the same as chmod 000 /vservers ; chattr +t /vservers right? 1115953438 M * Doener` the former on 2.6 is equal to the latter on 2.4 1115953460 M * Doener` the barrier flag doesn't exist on 2.4, the 000+t check doesn't exist in the 2.6 kernels 1115953511 M * micah Doener`: so on a 2.6 system, if you do the 000+t it means nothing, you should be doing setattr --barrier? 1115953520 M * Doener` right 1115953525 M * micah yikes 1115953525 M * micah ok 1115953568 M * Bertl and basically the tools 'know' how to do it on both ... 1115953581 M * Bertl so using setattr --barrier is always fine 1115953582 M * micah there is a method via the tools as well? 1115953586 M * micah ahhh, gotcha 1115953666 M * micah after you do the setattr --barrier should you be able to see something with lsattr? 1115953684 M * Doener` on 2.4: yes, 2.6: no, use showattr 1115953752 M * micah ah, gotcha 1115953758 M * micah jeez, stuff moves too fast for me :) 1115953798 M * micah just to make sure, this is correct flags? 1115953798 M * micah sudo showattr /var/lib/vservers 1115953798 M * micah ---Bui- /var/lib/vservers 1115953799 M * micah ---bui- /var/lib/vservers/colorado 1115953824 M * Bertl looks good ... but best test would be 1115953836 M * Bertl sudo showattr /var/lib/vservers/colorado/.. ;) 1115953861 M * micah sudo showattr /var/lib/vservers/colorado/.. 1115953861 M * micah ---Bui- /var/lib/vservers/colorado/.. 1115953861 M * micah ---bui- /var/lib/vservers/colorado/../colorado 1115956113 M * Doener` hmm... a security flaw in hyper threading... interesting... 1115956116 M * Doener` http://www.daemonology.net/hyperthreading-considered-harmful/ 1115956306 M * Bertl is there a simple way to search for debian packages of _all_ supported archs? 1115956344 M * Doener` httphttp://www.debian.org/distrib/packages#search_packages 1115956355 M * Doener` oops... http://www.debian.org/distrib/packages#search_packages 1115956411 M * Bertl ah, great, thanks! 1115956417 M * Doener` you're welcome 1115956633 M * Bertl hmm, the HT stuff sounds interesting ... 1115956723 M * Doener` yep... in a few hours we'll know more... 1115956758 M * Bertl I could imagine that it is related to way HT uses the cache 1115957642 M * Doener` i don't know how ht works at all... maybe that's a good time to look that up 1115958198 M * Bertl definitely SMP and SMT are the future ;) 1115959219 Q * rs Quit: rs 1115959685 M * Bertl Doener`: PLM test compile finished .. looks good ;) 1115959697 M * Doener` great! 1115959763 M * Bertl I'm not even sure if the 'differences' I get reported really exist ... seems they had some compile issues (clock skew) 1115960685 M * DaPhreak morning ;) 1115960691 M * Bertl morning! 1115960716 M * DaPhreak what a fine day :D sun is shining :P it's nearly weekend ... 1115960745 M * Bertl indeed! 1115960939 M * DaPhreak Bertl: about that ELF BufferOverflow ;) It's fixed in 2.6.11.9 1115960962 M * DaPhreak as you may have read :D 1115960983 M * Bertl yup yup ... thanks! 1115961221 M * Bertl could anybody explain 'emerge' to me? short and to the point if possible? 1115961246 M * DaPhreak well it's simply something like rpm .. a package managment system 1115961264 M * Bertl yeah, what does emerge foo/bar do? 1115961267 M * DaPhreak emerge vnet installs vnet to your running system 1115961295 M * Bertl okay, so there are existing packages? 1115961296 M * DaPhreak emerge -p vnet would show you what dependencies he would install if there are any .. 1115961313 M * DaPhreak yeah, which are in the offical tree or in your overlay 1115961337 M * Bertl hmm, I got the impression that gentoo builds all the stuff ... no? 1115961347 M * DaPhreak yeah ... 1115961363 M * Bertl so it's like source rpms basically 1115961371 M * DaPhreak yeah .. basically :) 1115961389 M * Bertl okay, if I know an emerge sequence, where can I find the 'sources'? 1115961415 M * DaPhreak what do you mean with "where to find the sources" ? 1115961428 M * Bertl for example: emerge cross-hppa2.0-unknown-linux-gnu/linux-headers 1115961451 M * Bertl I'd like to know where I could find a tar or something like that ... 1115961466 M * DaPhreak well do a emerge -f cross-hppa2.0-unknown-linux-gnu/linux-headers and they should be in /usr/portage/distfiles 1115961485 M * Bertl okay, for that I would need gentoo, right? 1115961491 M * DaPhreak alternativly you could have a look at the corresponding ebuild and take a look at SRC_URI 1115961499 M * DaPhreak yeah, or even portage 1115961519 M * DaPhreak but not for the second one 1115961537 M * Bertl okay, how would I do that? 1115961593 M * DaPhreak which one ? look at the SRC_URI ? 1115961635 M * Bertl yup, basically I'm searching for the sources of some 'packages' used for the emerge mentioned above 1115961648 M * Bertl (without having a gentoo/portage system at hand) 1115961656 M * DaPhreak second 1115961692 M * DaPhreak do you know the name ? 1115961743 M * Bertl well, I have this for example: http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO 1115961761 M * Bertl and I'm interested in the cross-hppa2.0-unknown-linux-gnu/linux-headers 1115961775 M * Bertl which are 'emerged' in (6) 1115961855 M * DaPhreak well simply they are the normal linux headers shipped with gentoo 1115961872 M * DaPhreak cd /usr/local/portage/cross-hppa2.0-unknown-linux-gnu && ln -s /usr/portage/sys-kernel/linux-headers linux-headers 1115961909 M * DaPhreak http://www.gentoo-portage.com/sys-kernel/linux-headers 1115961927 M * Bertl aha, so those are not somehow cleaned up kernel headers, right? 1115961935 M * DaPhreak yeah, they are 1115961985 M * Bertl okay, and those ebuild files there are? 1115962006 M * DaPhreak which ?! :) 1115962033 M * Bertl linux-headers-2.6.11.ebuild <- picked this one as an example ;) 1115962079 M * Bertl mirror://gentoo/linux-2.6.11-m68k-headers.patch.bz2" 1115962084 M * Bertl this is the source? 1115962087 M * DaPhreak yeah, you'll see something like SRC_URI="${KERNEL_URI} mirror://gentoo/linux-2.6.11-m68k-headers.patch.bz2" 1115962102 M * Bertl and the ${PN}-2.6.0-sysctl_h-compat.patch * are patches? 1115962107 M * DaPhreak yeah 1115962136 M * DaPhreak and this ${KERNEL_URI} stands for http://www.de.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2 1115962165 M * Bertl okay, why is the m68k patch mentioned/listed in the same line? 1115962195 M * Bertl while the 'other' patches are listed below (UNIPATCH_LIST)? 1115962269 M * DaPhreak well its mainly a matter of size .. gentoo dev-policy says something about the size of patches which should be in the tree 1115962335 M * DaPhreak so if they are greater than 2 or 3k (i forgot the size, go and ask Hollow, he should know) the patches have to go to the mirrors and thats why this m68k stuff is in SRC_URI 1115962526 M * Bertl i.e. it _is_ larger than 2 or 3k, yes? 1115962698 M * DaPhreak 12K to be exactly :) 1115962710 M * Bertl ah, okay, thanks a lot for the explanations! 1115962778 M * DaPhreak you're welcome ~ ... for that i'll gonna bug you in the evening if i've some problems with the ngnet stuff ;) 1115962800 M * Bertl feel free to do so .. as always ... 1115962822 M * DaPhreak yeah :) 1115963031 M * DaPhreak Bertl: what would be the right place for vnet ? /usr/sbin or /usr/bin ? 1115963146 M * Bertl I would not consider it 'that' important to put it into sbin 1115963180 M * Bertl and according to the history sbin vs bin is related to static vs. dynamic 1115963203 M * DaPhreak so i'll go for /usr/bin 1115963215 M * Bertl that would be my choice too ... 1115963220 M * DaPhreak oh, I see it's already -rc1 :) 1115963228 M * Bertl ;) 1115963662 M * DaPhreak am i right with assumption that -rc1 includes the xfs fix ? :) 1115963749 M * DaPhreak patching file Makefile 1115963749 M * DaPhreak patching file Makefile.orig 1115963749 M * DaPhreak patching file Makefile.rejpatching file Makefile 1115963749 M * DaPhreak patching file Makefile.orig 1115963779 M * DaPhreak heh ;) 1115963829 M * Bertl hmm ... did they slip through again? 1115963874 M * DaPhreak seems so :) 1115963886 M * Bertl sec 1115964036 M * Bertl okay, thanks for spotting, removed those, and replaced the patch 1115964530 M * DaPhreak the xfs-fix included i saw :) 1115965740 M * ciphernaut there was some sort of bug with xfs? It hardlocked on my system shortly after starting a vserver on an xfs volume/mount 1115965780 M * DaPhreak oO sounds weird :) no in pre4 was only some warning about xfs-stuff 1115965853 M * Bertl ciphernaut: could be without the 'proper' fix some structures were badly initialzed 1115965876 J * sukria ~sukria@213.223.184.197 1115965884 M * Bertl welcome sukria! 1115965939 M * ciphernaut I couldnt get a full syslog/klog output but it did look like something out of the xfs module 1115965980 M * sukria Bertl: hi :) 1115966008 M * sukria Are there known problems under sparc64 architecture with chbind? 1115966025 M * sukria testme.sh fails the chbind test 1115966335 M * Bertl no, worked fine when I tested it ... 1115966363 M * Bertl but you should make sure to compile the tools with a proper dietlibc 1115966387 M * sukria I'm building it by hand... 1115966400 M * Bertl details? 1115966417 M * sukria I started playing with the debian packages 1115966454 M * Bertl which isn't the worst thing to do ;) 1115966464 M * sukria and there is a problem with chbind, I'm buildind bu hand the latest util-vserver tools in order to see if that comes from the debian package or not 1115966481 M * sukria Bertl: yes, indeed, the vserver Debian packages are really great 1115966484 M * Bertl which dietlibc ? 1115966506 M * sukria dietlibc-dev 0.28-3 1115966518 M * Bertl okay, won't do .. you need a few patches 1115966536 M * sukria ? 1115966550 M * sukria what have I to patch? 1115966563 M * Bertl unfortunately it's broken on almost all archs except x86 1115966598 M * Bertl http://vserver.13thfloor.at/Stuff/DIETLIBC/ 1115966628 M * Bertl for sparc the two patches should be enough 1115966757 M * sukria Bertl: thanks a lot, I'm applying those patches and will say you if that's better :) 1115966768 M * Bertl k 1115966781 M * Bertl don't forget to rebuild the util-vserver afterwards 1115966841 M * sukria ok 1115967084 M * DaPhreak Bertl: is dietlibc that kind of broken ? 1115967416 M * sukria Bertl: it doesn't build: 1115967430 M * sukria syscall.S: Assembler messages: 1115967430 M * sukria syscall.S:131: Error: .err encountered 1115967724 M * Bertl try the http://vserver.13thfloor.at/Stuff/DIETLIBC/syscall.S 1115967744 M * Bertl (put it into the libcompat dir) 1115967775 M * Bertl DaPhreak: well, it is only supported on x86 it seems ;) 1115967788 M * sukria Bertl: :) ok, thanks 1115967832 M * Bertl DaPhreak: i.e. IIRC all but two implementations of the syscall() in dietlibc are mine ;) 1115967949 M * DaPhreak heh, yeah i saw your syscall stuff in the svn-repo 1115968019 M * sukria :( 1115968034 M * sukria even with your syscall.S it does not build correctly: 1115968036 M * sukria libcompat/syscall.S: Assembler messages: 1115968036 M * sukria libcompat/syscall.S:131: Error: .err encountered 1115968058 M * Bertl sec 1115968080 M * sukria should I put put syscall.S in both ./ and ./libcomapt dirs? 1115968092 M * Bertl no, only in libcompat 1115968132 M * Bertl hmm, seems debian defines the WANT_THREAD_SAFE 1115968143 M * sukria ah 1115968161 M * Bertl just change the WANT_THREAD_SAFE to WANT_THREAD_SAFE_disabled 1115968177 M * Bertl (line 130) 1115968250 M * sukria ok, done, building 1115968276 M * sukria if that works, I'll ship the .deb on my repo ;) 1115968289 M * Bertl be careful, it's just a hack ;) 1115968303 M * sukria he he "if it just works" (tm) ... 1115968338 M * sukria another question 1115968386 M * sukria I'm also testing vserver under an i386 box 1115968397 M * sukria I created a vserver and it seems to work correctly 1115968423 M * Bertl seems? 1115968462 M * sukria the only thing I find strange, is that the apache web server I installed answers to both IP adresses (the master host one and the VPS one)... 1115968484 M * Bertl where is it installed? on the host or on the guest? 1115968503 M * sukria on the guest 1115968538 M * Bertl that's usually a sign of a missing network config ;) 1115968586 M * sukria :) 1115968603 M * sukria I created the VPS with the debiantool "newvserver" 1115968616 M * sukria maybe I missed something in my /etc/vservers/vs00.conf 1115968645 M * Bertl well ... you should try with 'vserver build ...' and make sure to specify some --interface 1115968672 M * sukria ok 1115969030 M * PazZzzzooo morning Bertl! 1115969036 N * PazZzzzooo Pazzo 1115969043 M * Pazzo hi @ll 1115969071 M * Bertl morning Pazzo! 1115969130 J * erwan_ho ~erwan@konilope.dyndns.org 1115969159 M * DaPhreak morning Pazzo & erwan_taff 1115969173 M * DaPhreak or was it tuff ? *g* 1115969187 M * Pazzo hey, 2.0-rc1? 1115969230 M * Pazzo I did 2.6.11.9-vs2.0-pre4 yesterday, works as expected like a charm... 1115969339 M * DaPhreak yeah :) same here ;) gonna try -rc1 in the evening 1115969345 M * Pazzo ok, compilation running 1115969352 M * Pazzo :) 1115969386 M * Pazzo does anyone know if the new ELF bug could cause harm also from inside a vserver? 1115969638 M * DaPhreak Pazzo: try it 1115969640 M * DaPhreak http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt 1115969650 M * Pazzo thnx 1115969654 M * DaPhreak see the PoC Exploit at the bottom 1115969660 M * DaPhreak but be careful ;) 1115969678 M * Pazzo hmmm... have to reboot, test server is already running 2.6.11.9-vs2.0-pre4 :-) 1115969700 Q * erwan_ho Remote host closed the connection 1115969963 M * Pazzo ??? doesn't even work on the host side ??? 1115969970 M * Pazzo (running 2.6.11.8-vs2.0-pre4) 1115969979 M * Pazzo system is sarge 1115969986 M * Pazzo but kernel sources are vanilla 1115970021 M * Pazzo any idea? 1115970045 M * Bertl probably the slightly different kernel internals make it fail 1115970061 M * Bertl or really vanilla kernel? 1115970078 M * Pazzo really vanilla 2.6.11.8 1115970088 M * Pazzo (with vserver patch) 1115970131 M * Pazzo exploit from http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt compiles, running ./elfcd1 or ./elfcd2 write out their messages and that's it, nothing happens 1115970144 M * Pazzo [+] ./elfcd1 argv_start=0x7ffffc1a argv_end=0x7ffffc22 ESP: 0x7ffffa70 1115970149 M * Pazzo [+] phase 1 1115970154 M * Pazzo [+] AAAA argv_start=0x7fff6fee argv_end=0x7fff6ff2 ESP: 0x7fff6e60 1115970159 M * Pazzo [+] phase 2, to crash Killed 1115970176 M * Pazzo <= that's the whole ./elfcd1 output 1115970192 M * Bertl do you have coredumps enabled? 1115970198 M * Bertl do you test as a user? 1115970213 M * Pazzo shit, sorry - testing as root :-) 1115970213 M * Bertl ah, with vserver patch, that's what I meant ... 1115970328 M * Pazzo [+] phase 2, to crash exploit.sh: line 183: 2994 Killed ./elfcd1 1115970346 M * Pazzo nothing happens (as a normal user now) 1115970360 M * Pazzo coredumps enabled? how/where? 1115970369 M * Bertl ulimit -c 1115970379 M * Pazzo 0 1115970391 M * Bertl ulimit -Hc 1115970391 M * Bertl unlimited 1115970396 M * Bertl ulimit -Sc 1115970396 M * Bertl 1000000 1115970419 M * Pazzo -Hc -> unlimited, -Sc -> 0 1115970430 M * Pazzo (and -c -> 0) 1115970450 M * Bertl use ulimit -Sc unlimited 1115970465 A * Pazzo would like to crash the host :-) 1115970498 M * Pazzo ulimit -Sc -> unlimited: still nothing 1115970534 M * Bertl well, I'd try with an unpatched kernel from kernel.org 1115970543 M * Bertl just to see that it works there ;) 1115970551 Q * sukria Remote host closed the connection 1115970567 J * prae ~prae@ezoffice.mandriva.com 1115970622 M * Pazzo kernel-image-2.6.11.9-vs2.0-rc1+xyz.deb is now ready and I cannot try it out but have to compile a plain vanilla kernel :'-( 1115970821 A * Pazzo needs coffee... 1115970830 M * Pazzo cu later guys! 1115970863 M * DaPhreak cul Pazzo 1115970875 M * Bertl cya! 1115970985 N * Pazzo PazZzzzooo 1115971053 J * SEAwolfx ~mike@203-59-111-6.dyn.iinet.net.au 1115971062 M * SEAwolfx hello. 1115971064 M * Bertl welcome SEAwolfx! 1115971170 M * matti Hi Bertl, sup? 1115971176 M * SEAwolfx btw .. is it a good idea to use unionfs instead of vunify? 1115971210 M * Bertl probably not ... 1115971229 M * Bertl matti: almost off to bed, except for vs2.0-rc1 nothing new ;) 1115971290 M * SEAwolfx Bertl: are there some disadvantages by using unionfs? 1115971290 M * matti Bertl: :) 1115971355 M * Bertl SEAwolfx: I'd say the higher overhead will be one ... 1115971379 M * Bertl (same goes for the caches) 1115971430 M * PazZzzzooo needed to test rc1 before going for my coffee ;-) 1115971443 M * PazZzzzooo system is running fine, vservers are starting / stopping 1115971453 M * matti PazZzzzooo: Mmm... Coffee ;] 1115971477 M * PazZzzzooo matti: yeah, good italian one ;-) 1115971515 M * matti Oh ;-P 1115971519 M * matti :) 1115971527 M * matti That's a good one, indeed. 1115971527 M * matti :) 1115971531 M * PazZzzzooo Bertl: vshelper-delegate/shutdown <= is this still needed, is this a workaround for misbehaviour of the tools, will this be fixed in the next utils version, do I need to add this everywhere?? 1115971647 M * SEAwolfx Bertl: so ur opinion is that unification should happen on the vserver-layer and not on the filesystem-layer. could be please say more about the disadvantages?! ;) 1115971766 M * PazZzzzooo I'm gonna go now - Bertl: if you could leave me a short statement about the vshelper-delegate/shutdown before you go to bed that yould be great, thank you! 1115971770 A * PazZzzzooo is off for coffee 1115972383 M * Bertl PazZzzzooo: yup, hope it will be fixed soon ;) 1115972417 M * Bertl SEAwolfx: well, the unification linux-vserver uses is based on hard links 1115972433 M * SEAwolfx yes, indeed. 1115972436 M * Bertl this means, the 'contents' is directly available in a single inode 1115972458 M * Bertl it will be cached only once, and there is no compliated lookup 1115972485 M * Bertl I don't know how exactly the unionfs you use does work .. but I assume it adds overhead to both ... 1115972514 J * sukria ~sukria@213.223.184.197 1115972526 M * SEAwolfx ok ... i will gather more information about unionfs. 1115972534 M * SEAwolfx thank you, Bertl. 1115972555 M * Bertl you're welcome! 1115972564 M * SEAwolfx ;) 1115972782 Q * Hollow Ping timeout: 480 seconds 1115973653 Q * SEAwolfx Quit: leaving 1115974275 N * PazZzzzooo Pazzo 1115974290 M * Pazzo thnx Bertl! 1115974436 J * rs ~rs@staff.lycos.fr 1115974446 M * rs hi 1115974604 M * Bertl morning rs! 1115974605 M * DaPhreak morning rs :) 1115974926 M * rs bertl: wow still there ? 1115974948 M * Pazzo hi rs! 1115975060 M * DaPhreak seems so ;) 1115975262 Q * sukria Remote host closed the connection 1115975424 J * jsambrook ~jsambrook@aelfric.plus.com 1115975460 M * bro morning all ;> 1115975474 M * DaPhreak morning bro ;) 1115975521 M * Bertl morning bro! 1115975917 M * bro im running into some weird problems, been running fine all this time, but 2 days ago it started showing "no space left on device" on one of vservers i have there, it happens when user tries to work with mysql database trough web 1115975991 M * bro sill have the same old "2.6.9-vs1.9.3" with the new tools(util-vserver: 0.30.204) 1115975996 M * Bertl check system wide shmem and semaphores ... 1115976013 M * Bertl (you most likely ran out of those ..) 1115976159 P * jsambrook 1115976173 M * bro hmm, kinda lame question, but where to check `em? 1115976265 M * bro mkay, will use google before asking dumb questions ;> 1115976404 M * Bertl /proc/sys/kernel/{msg,shm}* 1115976421 M * Bertl and /proc/sys/kernel/sem 1115976494 M * Bertl okay, off to bed now .. have a nice day ... 1115976502 N * Bertl Bertl_zZ 1115976554 M * bro gnight ;> 1115976602 M * DaPhreak heh, have a good night Bertl_zZ 1115976633 M * bro mkaay, and how do i see if im running out of em or not? 1115976652 Q * rs Quit: rs 1115976662 M * bro who can tell me this, or maybe point where to look 1115977187 M * bro anyone? 1115977626 M * bro mkay, found some irclogs ;> 1115977643 J * sukria ~sukria@213.223.184.197 1115977685 M * sukria is there somthing special to do for the /dev entry of the vservers if I want to use XFree inside a VPS? 1115977708 J * rs ~rs@staff.lycos.fr 1115977729 M * rs re 1115977764 M * rs someone know something about the BLK_DEV_VROOT new option ? 1115978527 M * sukria y/quit 1115978529 Q * sukria Quit: leaving 1115980049 M * bro hmm, any1 here? 1115980071 M * bro bout those shmem's and semaphores 1115980420 M * Pazzo root exploits? why make things so complicated *gg* => http://www.heise.de/newsticker/meldung/59523 (german) 1115980437 N * Pazzo PazZzzzooo 1115980439 M * PazZzzzooo lunch time 1115980809 M * rs PazZzzzooo could you translate/summaries ? 1115980813 M * rs lunch time too 1115980869 Q * rs Quit: rs 1115981053 M * bro damn, i seriously need some help with those nasty "no space left on device" errors 1115981163 J * sukria ~sukria@213.223.184.197 1115981330 M * sukria ok, where can I change CAP_SYS_RAWIO for a given vserver? 1115981345 M * sukria I don't find any file under /etc/vservers/VS/ for such a purpose 1115985667 J * SEAwolfx ~mike@trip.cc.gt.atl.ga.us 1115985688 M * SEAwolfx hallo @all. 1115985758 J * rs ~rs@staff.lycos.fr 1115986141 Q * sukria Quit: Going back to real life 1115988789 M * wurd can anyone please help? this morning is my last chance to make this work 1115988816 M * wurd i get "cannot connect to x server test:10.0" and i dont understand why... 1115989929 J * sebd ~sebd@lesdeveloppementsdurables.org 1115992297 Q * SEAwolfx Ping timeout: 480 seconds 1115993263 N * PazZzzzooo Pazzo 1115993771 J * sukria ~sukria@213.223.184.193 1115993783 M * sukria vserver rocks 1115994158 M * eyck good for him 1115994265 M * SiD3WiNDR :) 1115994679 Q * logger Remote host closed the connection 1115994696 J * logger ~rs@vds.pas-mal.com 1115996945 M * DaPhreak Doener`, Bertl_zZ: might you two have a look at http://studip.uni-greifswald.de/~heim/vspatches/ngnet9.5-vs2.0-rc1.patch and tell me, if those two fixes for net/ipv6/af_inet6.c are good or wrong :) 1115997083 M * DaPhreak the diff between ngnet9.5-vs2.0-pre4 and ngnet9.5-vs2.0-rc1 is at http://studip.uni-greifswald.de/~heim/vspatches/fix-af_inet6.c.diff 1115998904 Q * rs Quit: rs 1116000312 M * prae DaPhreak: do you remember where we can download the latest patch vs+gr ? 1116001041 Q * prae Quit: Client exiting 1116003201 J * mep__ mep@p5091CE83.dip.t-dialin.net 1116003388 Q * mep_ Read error: Operation timed out 1116005071 M * Doener` DaPhreak: you mean the inet_addr_type() change and the includes? 1116005108 M * Doener` i'd say those look good, but i don't remember much of the ngnet code 1116005438 M * DaPhreak yeah Doener` :) 1116005520 M * DaPhreak since it didn't even compiled here (without the fix) 1116006001 Q * wurd Quit: BitchX-1.0c20cvs -- just do it. 1116006946 J * erwan_ho ~erwan@konilope.dyndns.org 1116009641 M * micah Bertl_zZ: the "slow" vserver was missing a swap partition. :) 1116010462 M * eyck no swap no pain 1116010465 M * eyck hmm, or maybe 1116010471 M * eyck no swap no gain? 1116010530 M * eyck no eyck no pain? 1116012822 M * Doener` micah: hm, that sounds more like a randomly dying vserver ;) 1116012841 M * micah well, it was the host server 1116013137 Q * erwan_ho Remote host closed the connection 1116013157 J * erwan_ho ~erwan@konilope.dyndns.org 1116013431 J * Doener_ ~doener@p5487781E.dip.t-dialin.net 1116013499 N * Doener_ Doener 1116013770 Q * Doener` Read error: Operation timed out 1116014773 J * sarnold ~sarnold@sarnold.noc.oftc.net 1116014873 M * sarnold has anyone ever seen 'gart' say anything? 1116014963 M * eyck no, he's a spambot 1116015206 M * micah heh 1116015343 M * sarnold thanks 1116015345 M * DaCa prae: for the latest you will have to wait a bit as Bertl releases faster as my cpu can compile kernels 1116016035 M * eyck we need Bertl-On-A-Chip 1116016056 M * eyck imagine Beowulf cluster of those! 1116018787 N * Bertl_zZ Bertl 1116018800 M * Bertl evening folks! 1116018848 M * Doener morning Bertl! 1116018857 M * Doener hmm... wrong channel (the other one ;) 1116018880 M * Bertl hehe, morning Doener! 1116018905 M * Doener you were right about the cache (the hyper threading stuff) 1116018954 M * Bertl good to hear ... 1116021155 Q * gart autokilled: Suspected email-address-harvesting bot. Please contact support@oftc.net if you feel this is in error. Thank 1116021213 P * sarnold 1116023266 M * Bertl Doener: yeah, interesting approach the htt ;) 1116023296 M * ntrs What about ht? Is it ok to use with vservers? 1116023317 M * Doener http://www.daemonology.net/hyperthreading-considered-harmful/ 1116023326 M * Bertl yeah, we are just taking about this .. 1116023375 M * ntrs how serious is this really? 1116023382 M * Bertl and before it becomes a 'security' issue, I can say that a loaded linux-vserver is probably the best defense ;) 1116023414 M * Bertl (as you would not be able to time cache misses properly) 1116023446 J * kjo ~krischan@p5484C431.dip.t-dialin.net 1116023449 M * Bertl ntrs: it's a funny idea, but IMHO no real issue 1116023474 M * ntrs :) 1116023559 M * Bertl evening kjo! 1116023612 M * kjo hi all 1116025147 N * BobR_zZ BobR 1116025322 Q * erwan_ho Ping timeout: 480 seconds 1116025392 N * BobR BobR_zZ 1116027720 Q * kjo Quit: Verlassend 1116028236 M * Bertl okay, folks, off for now .. maybe back later ... 1116028241 N * Bertl Bertl_oO 1116028418 Q * mep__ Ping timeout: 480 seconds