1103592821 J * ntrs_ ntrs@Dardeene-68.188.50.87.charter-stl.com 1103593011 Q * ntrs Ping timeout: 480 seconds 1103594391 J * DuckKing ~Duck@dyn-83-154-79-38.ppp.tiscali.fr 1103594820 Q * DuckMaster Ping timeout: 480 seconds 1103595256 Q * Thorsten Ping timeout: 480 seconds 1103597304 M * Snow-Man hey 1103597327 M * Snow-Man How's vserver on amd64 these days? 1103598089 N * Bertl_zZ Bertl 1103598098 M * Bertl Snow-Man: fine I guess ... 1103598334 M * Snow-Man hrm, ok. 1103598376 M * Bertl there are various issues ... like you need to use the fixed dietlibc and most x86_64 distros provide broken kernel headers 1103598392 M * Bertl you should use recent kernels and a working compiler ... 1103598413 M * Bertl but once you got everything together ... it seems to work just fine 1103601634 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3, ng8.7 1103603491 J * mboman ~michael@cm48.sigma230.maxonline.com.sg 1103604116 Q * mugwump Ping timeout: 480 seconds 1103604327 N * Bertl Bertl_zZ 1103604428 J * nox- ~vps@c135208.adsl.hansenet.de 1103604647 Q * nox Ping timeout: 480 seconds 1103604669 N * nox- nox 1103610469 Q * are|afk Quit: Disconnecting 1103610984 M * eyck 1103617425 Q * mboman Quit: One day I'll get that peer and reset HIS connection! 1103618426 Q * grecea Remote host closed the connection 1103618567 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103619358 Q * grecea Remote host closed the connection 1103619416 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103619578 Q * grecea Remote host closed the connection 1103619634 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103621628 J * are|afk ~are@mail.foehl.de 1103621634 M * are|afk hi 1103621638 N * are|afk _are_ 1103623574 M * _are_ Snow-Man: I run vserver on amd64 1103623592 A * Loki|muh too ;) 1103624157 J * Thorsten ~Thorsten@dsl-084-057-029-063.arcor-ip.net 1103624159 M * _are_ wq 1103624163 M * _are_ umpf 1103625940 Q * Thorsten Quit: Leaving 1103626346 M * _are_ btw, what are these ng8.7 patches(?), the next version? enhancements? 1103627085 Q * sebd Read error: Connection reset by peer 1103627618 J * mboman ~michael@cm48.sigma230.maxonline.com.sg 1103628888 J * jsambrook ~jsambrook@aelfric.plus.com 1103632576 M * _are_ I currently migrate from old /etc/vserver/*.cfg to /etc/vserver/*/, what is this 'run' directory? Obviously not the bservers root directory as this is an extra parameter. 1103632814 M * Doener $ ls -l /etc/vservers/debian/run 1103632814 M * Doener lrwxr-xr-x 1 root root 25 Nov 25 19:21 /etc/vservers/debian/run -> //var/run/vservers/debian 1103632814 M * Doener doener@doener ~ $ cat /etc/vservers/debian/run 1103632814 M * Doener 10 1103632837 M * Doener and 10 is the vserver's context id 1103632881 M * Doener ng used to be ngn and is 'next generation networking' 1103632938 M * Doener the target for the 'run' symlink only exists when the vserver is running 1103636027 M * Snow-Man _are_: Cool. :) 1103637014 J * mikmu hadge@h64-5-199-35.gtcust.grouptelecom.net 1103638195 M * _are_ Doener: found the ngn info while looking for the 'run', a 'skeleton' vserver helped me there a bit. 1103638246 M * _are_ Snow-Man: however, I kep having serious rouble with networking/proc, it 'randomly' dissapears. vprocunhide won't help and vproc -e /proc/net seems only to help #now and then' 1103638249 J * Webmazter ExUser@S010600e0299633f1.cg.shawcable.net 1103638442 M * Snow-Man _are_: erm, that's not good... 1103638470 J * sebd ~sebd@lesdeveloppementsdurables.org 1103638508 M * _are_ well, i try and fix it by doing a 'correct' configuration. but this is somewhat hard in between beta releases, it seems to me 1103638829 J * Hollow ~bene@home.xnull.de 1103639106 M * _are_ another bit corrected, network works somewhat like expected again :-) 1103639368 M * _are_ hmpf, managed to loose /proc/net on master and all vservers again :-/ 1103639507 Q * mboman Quit: One day I'll get that peer and reset HIS connection! 1103640695 Q * serving Ping timeout: 480 seconds 1103642481 P * ccooke 1103643147 N * Bertl_zZ Bertl_oO 1103646119 M * _are_ Bertl_oO: master and vservers lost /proc/net again :-/ 1103647344 N * Bertl_oO Bertl 1103647349 M * Bertl evening folks! 1103647360 M * _are_ :-) 1103647374 M * Bertl _are_: sorry about that, but be can investigate it ... if you have some time ... 1103647384 M * _are_ sure 1103647419 J * serving ~serving@213.186.189.138 1103647461 M * Bertl wb serving! 1103647480 M * Bertl _are_: okay, let's check if Doener is around, I'd like a second opinion 1103647491 M * Bertl Doener: ru here? 1103647494 M * _are_ Bertl: in context 1 /proc/net is visible, not in context 0 or any vserver 1103647498 M * Doener SYN 1103647505 M * Doener s/SYN/ACK/ 1103647517 M * Bertl excellent ... I updated the vxid yesterday 1103647533 M * _are_ oh, newer than 0.2? 1103647542 M * Bertl no, the 0.2 is the updated version 1103647562 M * Bertl Doener: it now uses the set/get_iattr syscall by default ... 1103647572 M * _are_ hmm, that one won't work (as far as I can see that) 1103647586 M * Bertl which has the advantage that it doesn't need to 'open' the file first 1103647600 M * Bertl _are_: please re-download the sources and recompile them 1103647608 M * Bertl (I did a small modification) 1103647609 M * _are_ ok 1103647618 M * Bertl Doener: http://vserver.13thfloor.at/Experimental/TOOLS/vxid-0.02.tar.bz2 1103647643 M * Doener just got it ;) 1103647686 M * Bertl okay, so this basically invokes the get_iattr .. which in turn does the user_path_walk ... 1103647732 M * _are_ ./vxid /proc/net 1103647733 M * _are_ get_iattr:: Function not implemented 1103647733 M * _are_ xid= 0, flags=0x00000000, mask=0x00000000, /proc/net 1103647752 M * Bertl you have to adjust the syscall number ... 1103647791 M * _are_ #define __NR_vserver 273 <-- that one? 1103647798 M * Bertl yep, it's 236 for x86_64 1103647842 M * _are_ # ./vxid /proc/net 1103647842 M * _are_ get_iattr:: No such file or directory 1103647842 M * _are_ xid= 0, flags=0x00000000, mask=0x00000000, /proc/net 1103647864 M * _are_ still same 1103647882 M * Bertl yep, I expected that ... 1103647905 M * Doener hm, why do i get xid 2? 1103647907 M * albeiro hello Bertl :) 1103647936 M * Bertl Doener: no idea ... 1103647942 M * albeiro i have finished (lets call it that ;p) vserver gentoo instalation 1103647949 M * albeiro but it behaves... strange 1103647952 M * Doener i'm with 2.6.10-rc2-vs1.9.3 btw... 1103647974 M * _are_ 2.6.10-rc3-vs1.9.3.11 1103648095 M * Bertl albeiro: with or without ngnet? 1103648104 M * _are_ btw, error only occurs with /proc/net: # ./vxid /proc/scsi/scsi 1103648104 M * _are_ xid=-1073743816, flags=0x01000005, mask=0x00060007, /proc/scsi/scsi 1103648133 M * albeiro Bertl: with 1103648136 M * albeiro i mean - vservered gentoo is starting looooooong 1103648137 M * Bertl Doener: okay, maybe we should ignore the xid on that ... 1103648154 M * albeiro will get back to it in about 20 minutes 1103648167 M * albeiro busy now 1103648169 M * Bertl okay, will be away in about an hour, for about 3 hours ... 1103648282 M * Bertl so we get ESRCH 1103648312 M * Bertl vc_get_iattr() itself does not return that 1103648331 M * Doener _are_: do you know a way to reproduce that bug? 1103648351 M * Bertl __vx_get_iattr() returns it if in or in->i_sb isn't there after the pathwalk 1103648354 M * _are_ Doener: nope, occurs after some random time 1103648378 M * _are_ but random time < 2h 1103648398 M * Bertl so I'd say either user_path_walk_link() already returns ESRCH 1103648418 M * Bertl or the returned dentry has no inode or superblock 1103648426 M * Bertl (which I consider unlikely) 1103648437 M * _are_ well, it is not marked as directory, e.g. bash-completion finds /proc/net, but ls then states it is not there 1103648471 M * Bertl that's because the former reads the directory _above_ but the latter accesses the dentry 1103648532 M * Bertl _are_: could you upload your kernel config somewhere? 1103648541 M * _are_ sure 1103648714 M * _are_ http://vgn.lihas.de/config 1103648760 M * Bertl CONFIG_SECURITY_CAPABILITIES=m 1103648761 M * Bertl CONFIG_SECURITY_ROOTPLUG=m 1103648771 M * Bertl is the security module loaded? 1103648784 M * Doener good one ;-) 1103648804 M * _are_ uhm, erm, hum, I'd say no 1103648819 M * Bertl okay, let's do the following: 1103648824 M * _are_ unless it is named llc 1103648831 M * Bertl disable the security stuff in the kernel 1103648843 M * Bertl CONFIG_SECURITY=n 1103648855 M * Bertl this will automatically enable the capabilities 1103648872 M * Bertl and disable the other crap^Wstuff ... 1103648899 M * Bertl let's see if you encounter the network issues with that config again ... 1103648908 M * _are_ k 1103648924 M * Bertl (the disappearing network and such can be the result of those missing cap module) 1103648942 M * _are_ would loading the module help? 1103648987 M * Bertl yes, but I don't know what the other 'modules' might change or influence ... 1103649001 M * Bertl so disabling it completely is probably the best check for now ... 1103649045 M * _are_ uhm, which one is this to disable? 'Enable different security models' as such? 1103649122 M * Bertl get vi, edit the .config 1103649135 M * Bertl delete CONFIG_SECURITY=y 1103649153 M * Bertl do make oldconfig, then answer the question for security with no 1103649178 M * _are_ done 1103649858 M * _are_ rebooting... 1103650053 M * _are_ ok, box up again 1103650110 M * _are_ uhm, erm, hmm, # ls /proc/net 1103650110 M * _are_ ls: /proc/net: No such file or directory 1103650152 M * Bertl well, didn't say that it was the only explanation ... but it was worth a try ... 1103650174 M * Bertl what does the vxid report on that now? 1103650188 M * _are_ # /usr/local/src/vxid-0.02/vxid /proc/net 1103650188 M * _are_ get_iattr:: No such file or directory 1103650188 M * _are_ xid= 0, flags=0x00000000, mask=0x00000000, /proc/net 1103650203 M * Bertl and xid=1 still sees it? 1103650216 M * _are_ yes 1103650234 M * Bertl maybe it is configured like that? or do you see it on the host sometimes? 1103650253 M * _are_ how can I co nfigure it like that? 1103650267 M * _are_ i have seen it on the host most of the time 1103650296 M * _are_ and as soon as I don't see it anymore, most software stops works for not being able to e.g. check netmasks (samba) or similar 1103650359 M * Bertl hmm, yeah ... okay, let me check other options ehre ... 1103650430 M * Bertl do you get any output from the kernel log when you try to acces it? 1103650503 M * _are_ dmesg shows nothing 1103650517 M * Bertl anything in the normal syslog? 1103650518 M * Snow-Man bah 1103650519 M * _are_ neithe rsyslog 1103650530 M * Snow-Man What's all the bitching about Debian? 1103650572 M * Bertl nobody is bitching about debian, we are unhappy with the linux-vserver maintainance ... 1103650580 M * eyck debian is big, thus bitching about it is both en-vogue and inevitable 1103650589 M * eyck yeah, I should take over 1103650595 M * eyck as soon as I get some spare time 1103650596 M * Snow-Man He just has the stable shit. 1103650616 M * Snow-Man If you want the other stuff, release a stable version. 1103650636 M * Snow-Man eyck: *smirk 1103650647 M * Bertl well, I'm not going to adjust linux-vserver development to debian oddities ;) 1103650658 A * Snow-Man shrugs 1103650667 M * Snow-Man Then don't bother to bitch. :) 1103650681 M * eyck they say there are drugs that free you from sleep... 1103650687 M * Bertl Snow-Man: the issue is more complex ... 1103650696 M * eyck I've got strong suspictions that Bertl has access to those... 1103650717 M * Snow-Man Bertl: I'm actually a DD, feel free to lay it on me. 1103650737 M * Bertl we had someone who was willing to do sane debian packaging but he was shot down, from the debian side ... because there already is a debian maintainer ... (which just happens not to care about) 1103650754 M * eyck Snow-Man: oh, then sponsor poink, CAP_NET_RAW-free ping replacement upload 1103650770 M * Snow-Man eyck: heh. 1103650782 M * Snow-Man Bertl: Who was he 'shot down' by? 1103650809 M * eyck this damn public-relations-happy new head honcho probably 1103650818 M * Snow-Man head honcho? 1103650825 M * Snow-Man Somehow I doubt tbm was involved.. 1103650847 A * Snow-Man notes he's already packaged up the more recent vserver tools into a .deb :) 1103650882 M * Snow-Man -rw-r--r-- 1 sfrost users 330910 Oct 18 23:58 util-vserver_0.30.195-1_i386.deb 1103650886 M * Snow-Man Or at least, that version. 1103650946 M * _are_ Bertl: what now? just reboot and check if I have /proc/net until it is somewhat evident it misses all the time or kill '/proc security' or something like that? 1103651009 M * Bertl Snow-Man: don't know and really don't care ... anyway fact is, most issues are currently debian related and we are doing the support for them. period. 1103651025 M * Snow-Man 'most issues'? 1103651033 M * _are_ alternates in my view: kick 'Persistent Inode Context tagging' or enable 'Compile debuging Code' 1103651035 M * Bertl _are_: nope, we have to add some debug statements to the kerneö 1103651051 M * Bertl but this will take a little and I have to leave in about 15 minutes ... 1103651057 M * Snow-Man Bertl: What, e-mail's to the mailing list or something? 1103651089 M * _are_ ok, running in trouble there, have to fix that box before xmas :-> 1103651104 M * Bertl Snow-Man: folks coming here, with issues like: my vserver kills the host ... 1103651128 M * Bertl _are_: let's schedule some 'debug' sessions then ... for example today at 23:30 CET ... 1103651139 M * _are_ fine with me 1103651153 M * Snow-Man my vserver killed my host once. :) 1103651162 M * Snow-Man Which was rather annoying, and that was with my own deb. 1103651164 M * Bertl Snow-Man: where the answer then is, please enable/load the capabilities module ... 1103651168 M * Snow-Man As I recall anyway. 1103651171 M * _are_ will compile a kernel with same options like this one and 'Compile debuging Code' enabled 1103651193 M * Bertl _are_: yep, that is a good thing to do, also enable the vserver debugging 1103651198 M * Snow-Man Bertl: Uhm, and who's going to load the module? 1103651208 M * _are_ Bertl: this is the debugging i spoke about 1103651208 M * Snow-Man Bertl: What if it's not built? 1103651234 M * Bertl Snow-Man: on vanilla kernels it's built into the kernel by default 1103651241 M * Snow-Man Bertl: Uhm, yeah, irrelevent. 1103651268 M * Bertl exactly ... 1103651309 M * Snow-Man Bertl: I don't like the idea of util-vserver loading modules up for me during boot, sorry. 1103651314 M * Snow-Man Bertl: It's a bad idea(tm) 1103651354 M * _are_ Snow-Man: so does hotplug, usbutils, pcmcia-tools, alsa 1103651410 M * Bertl Snow-Man: it's not util-vserver loading it, it's compiled into the kernel by default (unless you say otherwise) 1103651438 M * Bertl for debian kernels/configs, it's a module, and it is not loaded at all ... 1103651444 M * Snow-Man _are_: hotplug and pcmcia-tools are more reasonable things to expect to be trying to load modules. Personally, I don't like them doing it either. 1103651486 M * Snow-Man Bertl: That's an issue to discuss with the Debian kernel folks. 1103651498 M * Bertl anyway, I don't want to waste time on 'bitching' on debian, where it doesn't improve the situation ... 1103651535 M * Snow-Man Bertl: It's not useful to have a discussion if no one's going to move, no. 1103651601 M * Snow-Man Bertl: Why do you refuse to make a stable release when you say it's stable? 1103651712 M * Snow-Man That's annoyed me since I started looking at vservers, and isn't a Debian or whatever issue. 1103651734 M * Bertl I don't say it's stable, I just say, it's _as_ stable as the kernel 1103651756 M * Snow-Man When are you going to say it's stable then? 1103651770 M * Bertl when I've finished the cleanup and testing ... 1103651795 M * Bertl and when we have 'stable' tools for it too ... 1103651805 M * Snow-Man Bertl: I remember coming in here and asking what I should be using and was told to use the development version. 1103651824 M * Snow-Man Bertl: And that's worked out pretty decently for me, really. 1103651843 M * Snow-Man Bertl: I'm a little worried that the goal for when you're going to release a stable version is years off. 1103651888 M * Snow-Man And that really sucks as I'm likely to get flak about it being a development version from others when I install it here at work for some things, even though I know it works decently because I've been using it for quite a while elsewhere. 1103651914 M * Bertl I can assure you that the 'stable' 2.0 release will happen sooner than you think, but not until thinks are finished ;) 1103651941 M * Bertl and keep in mind, 2.6.x kernels are _not_ stable ... 1103651958 M * Snow-Man heh, they've been working quite decently for me for quite some time. 1103651998 M * Snow-Man And as much as you say they're not stable, kernel.org still says they are. 1103652000 M * Bertl sure, just check the changelogs and bug reports on lkml to get a feeling ... 1103652019 M * Snow-Man Oh, I follow lkml and read through the changelogs. 1103652039 M * Snow-Man I know where you're coming from and in general I agree, but you've got to release *sometime*. 1103652047 M * Bertl also Linus decided not to do a devel branch in 2.6 so he is just using 2.6.x for development ... 1103652091 M * Bertl so if you like to consider devel stuff 'stable', go ahead, in this case 1.9.x is a stable release for you ... 1103652095 M * Snow-Man I know, and I also know that he said that the way changes are being done supposedly 2.6 isn't expected to really destabalize all that badly even with the development going on. 1103652116 M * Snow-Man Bertl: I know they're stable enough for me, I'm using them. 1103652125 M * Bertl so where it the problem then? 1103652141 M * Snow-Man Bertl: The problem is that you won't admit it and just release a stable version. :) 1103652169 M * Bertl feel free to release your own stable version ;) 1103652186 M * Snow-Man Heh, essentially, that'd be what releasing a Debian version would be. 1103652218 M * Bertl okay, we have to delay that until later, as I have to leave now ... 1103652250 M * Bertl cya later folks! ... 1103652252 M * _are_ we are stable in 'no /proc/net in main server' now :-> 1103652260 Q * jsambrook Ping timeout: 480 seconds 1103652264 N * Bertl Bertl_oO 1103652313 M * Snow-Man Dealing with kernel-space crap in a distribution sucks. 1103652325 M * Snow-Man I've had to deal with alot of similar issues wrt OpenMosix, it's not fun. 1103652385 M * _are_ vxW: xid=0 did lookup hidden 000001000c296298[#104,4026531862] »/proc/net«. 1103652395 M * _are_ at leats the kernel admits it is hidden ;) 1103652468 M * _are_ hmmm, and the #104 is a contextid and in that context it *is* visible 1103652530 M * _are_ anyway, have to leave, cu later 1103652532 Q * _are_ Quit: Disconnecting 1103653234 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1103654583 J * Thorsten ~Thorsten@dsl-084-057-034-179.arcor-ip.net 1103655445 J * mirax ~Miranda@pcp02712319pcs.athens01.tn.comcast.net 1103655452 P * mirax 1103655523 Q * TheSeer Remote host closed the connection 1103655867 J * TheSeer ~theseer@border.office.salesemotion.net 1103656128 Q * Thorsten Remote host closed the connection 1103659271 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1103659932 J * _are_ ~are@dsl-213-023-050-156.arcor-ip.net 1103660095 M * _are_ hi 1103660871 J * Thorsten ~Thorsten@dsl-084-057-034-179.arcor-ip.net 1103660871 Q * sannes Read error: Connection reset by peer 1103661039 M * _are_ hmpf, seems the server crashed, now can't reboot it as it is 50km apart :-/ 1103661063 M * _are_ had been stable till now, so probably something with the debug statements :-( 1103661536 Q * mikmu Quit: 1103663097 Q * ndim Ping timeout: 480 seconds 1103663369 J * ndim U2FsdGVkX1@helena.bawue.de 1103667925 J * sannes ~ace@home.skarby.no 1103668821 Q * SiD3WiNDR Quit: Lost terminal 1103668848 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1103669748 N * Bertl_oO Bertl 1103669763 M * Bertl evening folks! 1103669782 M * Thorsten Hi Bertl 1103669787 M * Bertl _are_: took a little longer than expected, are you ready for debugging now? 1103669795 M * Bertl hey Thorsten, how are you? 1103669811 M * Thorsten Fine :-) and you? 1103669831 M * Bertl good, thanks ... 1103670434 M * SiD3WiNDR any way to check network traffic usage of a vserver? 1103670578 M * _are_ Bertl: for some unknown reason the server doesn't respond anymore and I am 50km away from it :-/ 1103670612 M * _are_ last think I changed had been enabling the vserver debug info in a new kernel and running that 1103670627 M * Bertl hmm, okay so we delay this till tomorrow? 1103670635 M * _are_ I now know who may read my /proc/net, but have no idea how to fix it. 1103670658 M * _are_ logfile showed /proc/net belonged to xid 104 (one of the servers) 1103670685 M * Bertl interesting! 1103670686 M * _are_ hoewever, I had not been able to e.g. use chcontext --xid 104 vproc -e /proc/net 1103670746 M * Bertl okay, we'll investigate when we can reach the machine again ... 1103670797 M * Bertl SiD3WiNDR: depends on the patch version .. 2.6/1.9.x has accounting of socket traffic in /proc/virtual/* but in any way you can setup iptables accounting rules on the host 1103670804 M * _are_ for me this will e about 8am CET tomorrow 1103670836 M * Bertl yeah, okay, won't be up at 8 but I guess around 11 we can continue ... 1103670843 M * _are_ :-> 1103670872 M * _are_ that would have been my time if the server didn't crash. 1103670897 M * _are_ because then I would have started a data-sync now and just came back after it was done, so i have some real test data to load the servers 1103670920 M * SiD3WiNDR yea, but I dont like iptables for that, I like /proc/ ! :) 1103670943 M * Bertl well, it's different things which get accounted ... 1103670960 M * SiD3WiNDR what's accounted in the 1.9 tree? 1103670975 M * Bertl the socket I/O so incoming and outgoing messages 1103670992 M * SiD3WiNDR and what's the difference with iptables counting all traffic to a certain ip? 1103670995 M * Bertl a message might consist of several packets over the network 1103671017 M * Bertl a message might be retransmitted several times until confirmed 1103671021 M * SiD3WiNDR I see 1103671024 M * SiD3WiNDR so it's not as accurate 1103671038 M * Bertl incoming packets might not result in messages if dropped 1103671056 M * Bertl well, depends, from the 'vserver' perspective it's more accurate ;) 1103671062 M * SiD3WiNDR yea 1103671067 M * SiD3WiNDR but not accurate as on the wire ;) 1103671088 M * Bertl correct ... that will happen with ngnet in the future ... 1103671091 M * SiD3WiNDR which will cause discrepancy in cost vs income ;) 1103671093 M * SiD3WiNDR nice 1103671095 M * Bertl (where you will have both) 1103671117 M * SiD3WiNDR looks very promising 1103671132 M * SiD3WiNDR are there a lot of problems still with the 1.9 tree? 1103671141 M * Bertl okay, folks, off now, my SO demands here share ... 1103671157 M * Bertl SiD3WiNDR: not really ... but some issues remain, ask _are_ 1103671170 M * Bertl back tomorrow then ... cya 1103671171 M * SiD3WiNDR okay 1103671175 M * SiD3WiNDR have fun with the SO ;) 1103671182 N * Bertl Bertl_oO 1103671371 Q * Zoiah Ping timeout: 480 seconds