1100996806 Q * redLED Read error: Connection reset by peer 1100997307 M * Bertl okay, I'm really tired now ... so I'm off to bed 1100997406 M * Bertl redLED: if you read the logs, please verify that the kernel works correctly with networking and such (as known and expected for 1.9.x) and ipv6 is blocked properly, tomorrow I'll upload a patch to disable the existing networking stuff which will require verification too ... 1100997433 M * Bertl night everyone! cya! 1100997439 N * Bertl Bertl_zZ 1101000322 Q * Shuri Quit: Leaving 1101003190 Q * cereal Quit: changing servers 1101003728 J * cereal cereal@ns1.starhosting.de 1101003801 Q * HackMan Ping timeout: 480 seconds 1101005287 Q * vx_info Ping timeout: 480 seconds 1101022682 J * vx_info s0t0na@spb.sot.com 1101023597 Q * vx_info Ping timeout: 480 seconds 1101029214 J * vx_info s0t0na@spb.sot.com 1101031484 J * vx_info_ s0t0na@mutator.sot.com 1101031601 Q * vx_info Ping timeout: 480 seconds 1101032871 J * redLED redled@d51A4EFA7.kabel.telenet.be 1101037277 N * Bertl_zZ Bertl 1101037282 M * Bertl morning folks! 1101037613 M * Bertl morning redLED! any news? 1101038267 M * albeiro morning Bertl :) 1101038295 M * Bertl hey albeiro! how are you? 1101038310 M * albeiro thx, nice, and you ? 1101038322 M * Bertl fine, a little sleepy, but fine ... 1101038333 M * albeiro btw - ibm technican has repaired my broken laptop 1101038348 M * albeiro ibm poland in official way told me that it will cost 1000 usd 1101038355 M * albeiro and he did for less than 60 ;p 1101038361 M * albeiro so i am really fine :) 1101038368 M * Bertl sounds great! 1101038467 M * Bertl what was broken? 1101038488 M * albeiro they said motherboard needs to be exchanged 1101038500 M * albeiro but this man managed to repair it :) 1101038641 M * albeiro in theory ibm authorized service is disalowed to repairing motheboards :) 1101038666 M * Bertl i.c. but he probably knew what was broken ... 1101038703 M * albeiro sure he did 1101038723 M * albeiro i am phonning him tommorow to ask what it was 1101038726 M * Bertl okay, because tracking down an issue on a notebook mb isn't really that easy ... 1101039622 Q * sebd Remote host closed the connection 1101040816 M * redLED Bertl, there will be some in a few short moments :) 1101040833 M * redLED Bertl, fell asleep on the keyboard last night, my ear killed my build proccess :p 1101040889 M * Bertl LOL 1101040906 M * Bertl well, it was bedtime for me too, yesterday ... 1101045728 J * monrad monrad@213083190130.sonofon.dk 1101045755 M * Bertl welcome monrad! 1101045760 M * monrad hi 1101046874 Q * eyck uranium.oftc.net keid.oftc.net 1101046874 Q * no_x uranium.oftc.net keid.oftc.net 1101046874 Q * albeiro uranium.oftc.net keid.oftc.net 1101046874 Q * matti uranium.oftc.net keid.oftc.net 1101046874 Q * Pinnen uranium.oftc.net keid.oftc.net 1101046874 Q * Doener|gone uranium.oftc.net keid.oftc.net 1101046874 J * Pinnen pinnen@h194n2fls35o917.telia.com 1101046874 J * albeiro albeiro@lexx.eu.org 1101046875 J * matti matti@linux.gentoo.pl 1101046876 J * eyck eyck@81.219.64.71 1101046884 J * no_x vps@c150033.adsl.hansenet.de 1101046896 J * Doener|gone doener@193.24.208.131 1101049628 Q * mugwump Ping timeout: 480 seconds 1101052166 M * eyck wow, 2.7 may be created this year... this is great news for 2.6 folks 1101052193 M * Bertl hmm, how's that? Linus changed his mind? 1101052753 M * Bertl okay, dinnertime, back later ... 1101052761 N * Bertl Bertl_oO 1101052834 M * redLED Bertl_oO, build is done, new logs + config uploaded to same URL 1101052839 M * redLED Bertl_oO, bonappetit :) 1101053758 M * eyck supposedly Andrew Morton said something during SDForum conference 1101053801 M * eyck it's not exactly clear what he said though, because jounralist reporting about that has no idea what she was talking about, 1101053853 M * eyck but 2.7 release means that I will be moving to 2.6 in ~3 months 1101054584 J * DuckKing Duck@dyn-83-154-92-223.ppp.tiscali.fr 1101054763 M * eyck nobody cares about that though 1101055022 Q * DuckMaster Ping timeout: 480 seconds 1101059666 N * Bertl_oO Bertl 1101059676 M * Bertl I'm back ... 1101059723 Q * monrad Ping timeout: 480 seconds 1101060691 M * Bertl redLED: and does it boot/work? 1101060707 M * redLED i can boot and see :) 1101060722 M * Bertl then let's do that, btw how do you compile the kernel? 1101060752 M * Bertl (because we definitely need to speedup that process for the next few test cycles) 1101060767 M * redLED unpack 2.6.9, patch to 2.6.10-rc2, patch to vserver, import redhat's 2.6.9 config, make modifications, make, make modules, make modules_install, make install, edit grub, reboot 1101060817 M * redLED in other words, 'slow and painful' 1101060840 M * redLED going for reboot now... 1101060845 M * Bertl okay, first I would suggest cutting down the .config to a minimum 1101060882 M * redLED tbh, i don't even know off head what that minimum would be; i have no idea about the hardware i work on :) 1101060883 M * Bertl then I would suggest reserving some space for the kernel trees, we will probably do some runs ... 1101060893 M * redLED there's racks and racks on it a few hundred km's away 1101060900 M * redLED s/on/of/ 1101060907 Q * meebey Ping timeout: 480 seconds 1101060987 M * redLED ok 1101060988 M * redLED box is back 1101060995 M * Bertl good ;) 1101061002 M * redLED 2.6.10-rc2-vs1.9.3 booted 1101061014 M * Bertl you have some kind of non-networking access to that box? 1101061053 M * redLED no, but i can send a monkey^H^H^H^H^H^Hengineer to attend it if it proper-dies 1101061081 M * Bertl okay, just because the next step might be a little more critical (when we change the networking behaviour) 1101061088 M * redLED or just start working on another one :) 1101061094 M * redLED plenty to kill before i'm all out 1101061120 M * Bertl okay, first let's make sure everything is working as expected (old network behaviour) 1101061181 M * Bertl you compiled most of the things as modules, check which modules are loaded when everything is running as expected (with lsmod) then check the .config and remove module entries which are not related at all 1101061208 M * Bertl (that will probably cut down your kernel to 1/5th of the current size) 1101061367 M * redLED one moment 1101061372 M * redLED building useful util-vserver 1101061461 M * redLED hmm 1101061761 M * redLED fc2 removed xalan-j 1101061765 M * redLED did it get renamed? 1101061770 M * redLED or totally removed? 1101061803 M * Bertl no idea ... 1101061868 M * redLED util-vserver alpha depends on it, or atleast claims to... 1101061872 M * redLED *goes looking* 1101062098 M * Bertl that is for the docu, just ignore it, or provide some option to disable it 1101062135 M * redLED it (together with the rest of the java packages, e.g. tomcat, etc) have been removed from fc3 :| 1101062138 A * redLED ponders why 1101062236 M * daniel_hozac there weren't enough time to get it into a usable state. 1101062439 M * redLED ok 1101062443 M * redLED got my util-vserver together 1101062457 M * redLED Bertl, i presume i should roll out atleast one vserver to be of any use from here forth? 1101062464 M * Bertl yep 1101062493 M * Bertl for ngn tests we'll need at least two ... to check for 'identical' services 1101062502 M * redLED alright 1101062506 M * redLED two vservers coming up 1101062874 M * redLED Bertl, should i use a specific --context for those vservers? 1101062893 M * Bertl I'd suggest 100 and 200 1101062911 M * redLED hmm 1101062918 M * redLED what is the effect of not specifying a --context ? 1101063005 M * Bertl you get a dynamic context id, whih is a) depreciated and b) will change on every startup 1101063013 M * redLED oh 1101063023 M * redLED thats how all my existing production vservers are set up :) 1101063436 M * redLED hmmpfh 1101063451 M * redLED lots of new stuff to learn; the new util-vserver breaks on the repos i normally use 1101063458 M * Bertl it's never to late to change that ... 1101063470 M * Bertl just assign a specific xid to each vserver ... 1101063516 M * redLED what does apt-rpm expect to find inside distro/name/.apt ? 1101063567 M * Bertl probably a repository list or something like that ... 1101063619 M * redLED ftp.ultra.csn.tu-chemnitz.de doesen't appear to exist externally, and i fail to find a mirror which has apt compatible repository in it... 1101063652 M * daniel_hozac freshrpms IIRC. 1101063970 M * redLED my cluelessness seems to be ever growing :| 1101063982 M * redLED i do see a freshrpms fedora mirror 1101063992 M * redLED but no apt-enabled repository in it 1101064054 M * Bertl google: apt rpm repository 1101064828 M * redLED oook 1101064830 M * redLED we're all good 1101064840 M * redLED apparently newest util-vserver drops no rpmpriorities file 1101064849 M * redLED so had to create one 1101064855 M * redLED and find a good apt repo :) 1101064874 M * redLED Bertl, thanks for this :) it's more educational for me than it is for you so far :p 1101064897 M * Bertl np ;) 1101065140 J * Shuri Dew@dsl.speedline209.226.electronicbox.net 1101065149 M * Bertl welcome Shuri! 1101065160 M * Shuri hi 1101065241 M * Bertl guess you are here to partiticapte on the current ngn event, right? 1101065439 N * Doener|gone Doener 1101065449 M * Doener morning! 1101065502 M * Bertl morning Doener! 1101065514 M * Bertl how is your exam preparation going? 1101065597 M * Doener rather good, about 1/3 done, then i fell asleep... must've been a nice picture, a bed with me, a bunch of paper, some bottles and a cup of coffee on it... 1101065627 A * Doener is pretty glad that he didn't make the cup spread its contents over the bed while he was asleep 1101066761 M * redLED hmm 1101066770 M * redLED i can't get a single distibution up with the new utils :| 1101066783 M * Bertl have you read the alpha utils page? 1101066790 M * Bertl (tried some of the examples maybe) 1101066806 M * redLED see uh, .190 work fine 1101066817 M * redLED .196 however, don't 1101066826 M * redLED first of all, 190 came with preconfigured rpmpriorities files 1101066840 M * redLED which seem not to be (or not to be installed w/the spec rpm build) in .196 1101066887 M * redLED nor are the contents of the old 'pkgs' directory seem to be there, insisting that filesystem be reinstalled... (ending up with me having a broken proc inside the vserver) 1101066890 M * redLED so i'm a little lost :) 1101066940 M * Bertl broken proc sounds like - not having run vprocunhide yet 1101066991 M * redLED which means the modified initscripts haven't been copied, right? 1101067030 M * Bertl don't know, usually vprocunhide is installed and executed on installation 1101067098 M * Bertl but you can run it by hand ... 1101067640 M * redLED ok 1101067644 M * redLED almost there i think 1101067750 J * mugwump sv@210-54-92-188.ipnets.xtra.co.nz 1101067756 M * Bertl welcome mugwump! 1101067783 M * Doener hi mugwump! 1101067845 M * redLED ok! 1101067849 M * redLED i got 2 vservers up 1101067855 M * Bertl congrats! 1101067864 M * redLED and they appear to work, as well as tcp/ip 1101067868 M * redLED quite... normally 1101067872 M * Bertl okay, excellent! 1101067909 M * redLED whats my next step? :) 1101067938 M * Bertl reducing the kernel size, because we are going to compile it a few more times 1101067997 M * Bertl so check what modules are loaded, note them somewhere ... 1101068010 M * Bertl then start removing .config options which are not related ... 1101068042 M * Bertl for example, you are not using SCSI, then no SCSI support is required, remove it and all drivers ... 1101068065 M * daniel_hozac don't the drivers depend on CONFIG_SCSI? 1101068085 M * Bertl yep, they should ... 1101068093 M * redLED here's what i'm going to do if you don't mind Bertl 1101068105 M * Bertl but hey, I actually believed that 2.6.10-rc2 would compile on my ppc ;) 1101068116 M * redLED i'm going to keep the kernels as they are, but enable distcc across a few of the more powerful boxes in the farm, so compiles go a lot quicker 1101068119 M * redLED does that sound acceptible? 1101068147 M * Bertl if you make this work, no problem 1101068147 M * redLED it's not early enough in the morning for me not to f*ck up my kernel configuration completely and forget my IDE chipset out of it :p 1101068187 M * Bertl a typical kernel compile for testing should not take more than ... hmm 5-10 minutes 1101068333 M * eyck or, with my .config - 25-45 minutes 1101068361 M * daniel_hozac my kernel builds usually take 3-4 hours. 1101068370 M * eyck on what hardware? 1101068373 M * Bertl ahem, well, no that was supposed to be the time after using distcc ;) 1101068403 M * daniel_hozac P4 1.7 GHz, 512 MiB RAM, 80 GiB WD with 8 MiB cache. 1101068420 M * eyck with distcc it usually fails, so it usually takes 2-3 days to figure out, and then ~45 to compile it with traditional method 1101068466 M * eyck daniel_hozac: wow, that is reasonably fast hardware, I've got 1.8+ AMD, how can such big discrepancy in compile times be posible? 1101068524 M * daniel_hozac eyck: Red Hat kernel RPMs... one UP kernel, one SMP kernel, module signing, debugging data extraction... 1101068594 M * redLED hehe eyck 1101068638 M * redLED lets see if it'll fail with distcc here too; if it does, i give up for the day :) 1101068642 M * Bertl hmm .. just before you actually tested the ngn stuff? 1101068653 M * daniel_hozac eyck: and of course, including every single module in the config doesn't help to speed it up... 1101068739 M * eyck daniel_hozac: that's how my .config looks like, that's why it takes ~40 minutes to compile. all in all my compiles cycle is longer ( I compile sequentially with 2.95, 3.3.3 and 3.4.2 ) 1101068757 M * eyck daniel_hozac: why do you need UP kernel? 1101068763 M * redLED well 1101068767 M * redLED it's definitely doing something :D 1101068778 M * Bertl yeah, but it's not patched in yet ;) 1101068778 M * daniel_hozac eyck: yeah, ~45 minutes is what the build takes. 1101068796 M * daniel_hozac eyck: well, i only have one SMP machine. 1101068804 M * redLED and it's doing that something across multiple machines... 1101069974 M * Bertl for 20 minutes now ;) 1101069985 M * redLED indeed :| 1101070097 M * Doener with my config it takes about 8 minutes to compile a kernel on my box, there must be something wrong (or bloated ;) 1101070135 M * Bertl yeah, he has the kitchen sink configured ;) 1101070166 M * redLED 4 identical boxes now 1101070176 M * redLED going to throw one more into it which is a bit more powerful 1101071034 M * redLED ah 1101071035 M * redLED it finished 1101071042 M * redLED that's still too long though 1101071050 M * redLED shorter than before, but still too long 1101071113 M * Doener well, a recompile should be a lot faster (if you don't clean...) 1101071135 M * redLED i don't know what Bertl has in store for me, so i'm working on perfecting the proccess :p 1101071159 M * redLED doing a half-arsed upgrade of a dual-xeon machine so i can run distcc off it :) 1101071372 J * mhepp mhepp@r72s22p13.home.nbox.cz 1101071702 M * daniel_hozac Bertl: did you put my coreutils and findutils patches somewhere? 1101072083 M * Bertl hmm, let's see, I put them somewhere .. yes ... 1101072175 M * daniel_hozac because the coreutils patch is broken and i updated the findutils one.. 1101072213 M * Bertl any hint how they where named? 1101072268 M * daniel_hozac coreutils-5.2.1-xid-libvserver-*.patch findutils-4.1.20-xid-libvserver.patch 1101072749 M * redLED ahahah 1101072752 M * redLED now it's flying well 1101072765 M * redLED 2x Xeon 2.4 added to the other build servers has done well for itself 1101072776 M * redLED Bertl, i'm ready for the next stage of our plan :) 1101072794 M * Bertl okay, I'll upload a patch in a few seconds ... 1101072797 M * redLED kernel build is now within limits of sensible tolerance :) 1101072947 M * Bertl http://vserver.13thfloor.at/Experimental/delta-vs1.9.3.7-ng1.1.diff 1101072974 M * Bertl this aptch (ontop of 1.9.3.7) adds a config option called VSERVER_NGNET 1101073000 M * Bertl now it is important to test if the kernel without this option enabled, works like the unpatched version 1101073011 M * Bertl after that we start with a kernel with that option enabled ... 1101073151 Q * mhepp Remote host closed the connection 1101073291 M * redLED *building* 1101073781 Q * v00dY Ping timeout: 480 seconds 1101073793 J * v00dY v00dy@62.241.52.143 1101073800 M * Bertl wb v00dY! 1101073934 J * monrad monrad@213083190130.sonofon.dk 1101073951 M * monrad evening 1101074007 M * Bertl evening monrad! 1101074067 M * redLED wow 1101074070 M * redLED build is done! 1101074074 M * redLED less than 11 min :) 1101074080 M * Bertl that sounds acceptable ... 1101074104 M * Bertl okay, did you disable the NGNET option this time? 1101074122 M * redLED yup, new build, but NGN disabled 1101074136 M * redLED going to send that box for a reboot in a few; it's finishing up another lil task for me 1101074139 M * Bertl and did it compile successfully or did it bail out somewhere? 1101074150 M * redLED compiled fine it seems 1101074156 M * Bertl okay, just checking ... 1101074178 M * redLED i'll try to remember to make a hobby out of always writing stderr to log and uploading from now on 1101074222 M * Bertl well, if the bzImage has a new timestamp, everything should be fine ... 1101074246 J * expiryjames james@S01060004e24bdb23.ok.shawcable.net 1101074256 M * Bertl welcome expiryjames! 1101074266 M * expiryjames good evening 1101074276 M * redLED hmm 1101074289 M * redLED thats interesting 1101074295 M * redLED although the distcc build has finished 1101074304 M * redLED now when i did 'make install' it appears to have started from scratch 1101074317 M * redLED perhaps it *did* bail out somewhere (since i was building from clean...) 1101074411 M * redLED *lets it go on with logging on* 1101074457 M * redLED ah no 1101074458 M * redLED my bad 1101074464 M * redLED all is well :) 1101074489 M * redLED reboot into new ngn disabled kernel? 1101074542 M * redLED i'll take the silence as a sign of approval :) 1101074553 M * Bertl ah, yep 1101074559 M * Bertl please do so ;) 1101074588 M * redLED i never imagined distcc is so useful :) 1101074599 M * redLED might have something to do with me being an rpm monkey which never writes his own code 1101074614 M * redLED but atleast i have the infrastructure in place now :) 1101074676 M * Bertl well, let's use it then ... reboot and test the new kernel 1101074686 M * Bertl and in the meantime compile with NGN enabled 1101074798 M * redLED vservers started successfully 1101074803 M * redLED (ngn enabled allready building) 1101074810 M * redLED tcp/ip still appears functional 1101074818 M * redLED no kernel log dumps, all seems well 1101074825 M * Bertl excellent ... 1101074834 M * redLED any specific suggestions abot what should i stress the vservers with during testing? 1101074870 M * redLED something which would do some disk io, some kernel calls, and some network usage? 1101074926 M * Bertl basically we are only interested in network stuff 1101074940 M * redLED hmm 1101074941 M * Bertl so I'd suggest doing some tcp and udp tests, a little pinging 1101074946 M * redLED i'll roll out iperf then 1101074969 M * Bertl maybe an apache on a server, which can be connected to with lynx from the other server, or something like that 1101075011 M * redLED apache doesen't do udp 1101075014 M * redLED iperf does 1101075029 M * Bertl okay, that's fine for me ... 1101075042 M * redLED plus it will let me see if any of what we do causes any performance impact on the ammount of packets it can push through 1101075141 M * Bertl good point! 1101075502 M * redLED allright 1101075535 M * redLED 93.4Mbps between vserver and world, 1.37Gbps between 2 vservers on same machine 1101075551 M * redLED nothing evil going on, all looking well 1101075584 M * redLED ngn enabled kernel just finished building 1101075591 M * redLED unless there's anything else you want to know, reboot it is 1101075602 M * Bertl yep, reboot is fine ... 1101075620 M * Bertl btw, we do not expect the vservers to work out of the box right now 1101075641 M * redLED noted 1101075874 M * redLED ok 1101075877 M * redLED ngn enabled kernel up 1101075879 M * redLED what now? 1101075927 M * Bertl okay, let's start a vserver .. just for the fun of doing it 1101075938 M * Bertl and see if it complains about anything 1101075974 M * redLED it's up 1101075977 M * redLED no complaints 1101075980 M * redLED tcp/ip stack dead 1101075984 M * Bertl okay, can you reach it from outside? 1101075988 M * redLED no access to host, or network 1101075991 M * redLED lets see. 1101075993 M * Bertl okay, that's fine 1101076035 M * redLED yes 1101076040 M * redLED it appears to still be reachable from the outside 1101076046 M * redLED but won't allow me to initiate anything from the inside 1101076053 M * Bertl but ifconfig shows the assigned ip, and the various services didn't complain about anything? 1101076073 M * Bertl still reachable means 'ping' is working or what? 1101076084 M * redLED it's pingable from outside, yes 1101076086 M * redLED ifconfig shows no ip 1101076096 M * Bertl check with ip addr ls 1101076097 M * redLED i would'nt have noticed that myself, i use 'ip', not ifconfig 1101076106 M * redLED ip checks out 1101076132 M * Bertl okay, the ping is answered from the host ... so that is fine 1101076137 M * redLED hmm 1101076142 M * Bertl any 'connection' type request should fail 1101076143 M * redLED another possibly ammusing fact 1101076155 M * redLED ip addr ls inside vserver shows bound v6 address too 1101076167 M * Bertl that is fine too ;) 1101076212 M * redLED the v6 bound to the host, even 1101076220 M * Bertl okay, let's now see if we can 'enable' that vserver by tagging incoming packets destinated to the vserver ip with an fw mark 1101076243 M * redLED got a command in mind, or do i need to remember my iptables ? 1101076245 M * Bertl (lets keep with ipv4 for now, as the ipv6 part isn't completed yet 1101076278 M * Bertl out of my head: iptable -A INPUT -d -m 1101076312 M * daniel_hozac -m would be loading a match module ;) 1101076312 M * redLED hmm 1101076316 M * redLED -m is for loading a module 1101076319 M * redLED so yeah 1101076320 M * daniel_hozac -j MARK --set-mark ? 1101076339 M * Bertl yep, thanks ... 1101076372 M * Bertl does it require the mangle table too? 1101076380 M * daniel_hozac i would assume so. 1101076458 M * Bertl yep, so the command should be 1101076480 M * Bertl iptables -t mangle -A INPUT -d -j MARK --set-mark 1101076480 Q * berni Read error: Connection reset by peer 1101076492 J * berni berni@obelix.ipv6.birkenwald.de 1101076548 M * redLED by you refer to context id? 1101076563 M * Bertl yes, either 100 or 200 if you followed my suggestions ... 1101076686 M * redLED rule is in place 1101076694 M * redLED connectivity outwards still appears impossible 1101076768 M * daniel_hozac does anyone know what kind of magic is required for using vc_xidopt2xid? vc_xidopt2xid("test", (true|false), NULL) segfaults for me. 1101076805 M * Bertl hum, what is vc_xidopt2xid ? 1101076830 M * daniel_hozac a util-vserver function for turning xids/vserver names into xid_t's. 1101076865 M * daniel_hozac chcontext --xid test true does not segfault, but it uses the same function... 1101076870 M * redLED Bertl, rules in place, both vservers up, connectivity from outside still appears possible (atleast as far as ping goes), no connectivity from inside the vserver, not even to host. 1101076918 M * Bertl okay, the 'ping' from outside isn't worth anything 1101076932 M * Bertl it is answered by the host itself, so we can not use that for testing 1101076938 M * redLED i could try something more serious 1101076965 M * Bertl connecting to an apache service for example could work as test 1101076975 M * redLED iperf server inside vserver running now :) 1101076991 M * redLED 93.4Mbps sustained as before 1101076996 M * redLED connectivity inwards works. 1101076998 M * Bertl ah? 1101077009 M * Bertl sounds good! 1101077014 M * albeiro hey folks 1101077020 M * Bertl evening albeiro! 1101077021 M * redLED but, i still can't connect from the vserver to the outside 1101077024 M * albeiro mcp: are you here ? 1101077034 M * Bertl redLED: let's investigate why that is so ... 1101077041 A * albeiro thinks about adding latest vserver to wolk-17s... 1101077074 M * Bertl redLED: first try with a tracepath from inside ... (add CAP_NET_RAW if not already there ;) 1101077091 M * Bertl and tcpdump the outbound interface on the host 1101077093 M * redLED you'll need to elaborate about that 'add CAP_NET_RAW' business 1101077095 M * albeiro dream kernel - 2.4 wolk with grsecurity, rsbac and vserver ;p 1101077124 M * Bertl redLED: you know the flower page? 1101077131 M * redLED aright 1101077135 M * redLED *gone reading* 1101077152 M * Bertl I assume you have a newstyle config, so just add the cap to the appropriate file 1101077176 M * Bertl ah, another quick test idea 1101077209 M * Bertl remove that mark rule, and see if you can reach the iperf server 1101077263 M * redLED nope 1101077264 M * redLED no more. 1101077268 M * redLED no rule - no reach. 1101077268 M * Bertl excellent! 1101077300 M * Bertl what routing info do you see from inside the vserver? 1101077356 M * Bertl albeiro: mcp didn't answer for some time now, maybe you should send him an email? 1101077356 M * redLED appears identical to host machine 1101077371 M * Bertl okay, that is fine ... 1101077397 M * albeiro Bertl: i will try. anyway, i got about rejects in 42 files, almost 100 (!) of them 1101077457 M * Bertl what kernel version is the wolk based on? 1101077481 M * albeiro 2.4.20 but do not be scared - all eeded patches are synced up to 2.4.27 1101077493 M * albeiro it is mcp whop says what is important 1101077500 M * albeiro s/whop/who/ 1101077512 M * Bertl so it applies cleanly to 2.4.27 or maybe even 2.4.28? 1101077524 M * albeiro no 1101077537 Q * Shuri Quit: Leaving 1101077548 M * albeiro i will just use vanilla 2.4.28 for vserver, too much of work and very error prone 1101077566 J * thh thh@dsl-084-057-069-087.arcor-ip.net 1101077573 M * Bertl it's probably the best ... 1101077579 M * Bertl welcome thh! 1101077582 M * thh Hi :) 1101077640 M * thh since an hour I am experiing a strange problem - when I envoke df in certain vservers the is nothing listed, not even / 1101077676 M * Bertl that is not that unusual 1101077676 M * thh everythings works (httpd etc.) but SQL aborts telling me it couldnīt wirte to /tmp 1101077710 M * Bertl let's check if /etc/mtab is there inside such a vserver 1101077721 M * Bertl and if, let's see what it contains ... 1101077749 M * thh proc /proc proc rw 0 0 1101077753 M * thh nothing else 1101077760 M * Bertl add a line like this: 1101077760 M * albeiro hmmm... could xorg work inside vserver ? 1101077775 M * Bertl /dev/hdv1 / ext2 rw 0 0 1101077781 M * redLED xorg as in xwindows? 1101077795 M * albeiro no, just xorg 1101077808 M * Bertl thh: and df should work fine 1101077809 M * albeiro xfree fork :) 1101077815 M * redLED yeah 1101077823 M * redLED i got a vserver running xfree proper 1101077828 M * redLED but it's framebuffer is vnc 1101077835 M * redLED i have no idea if it can be done with proper local video 1101077852 M * Bertl it can, but it is a security issue 1101077857 M * redLED Bertl, here's what we have... 1101077870 M * redLED Bertl, connections from outside in (atleast, tcp) seem to work 1101077870 M * albeiro running xfree/xorg is security issue itself 1101077880 M * redLED Bertl, the ping packet gets sent, on the wire, and comes back 1101077890 M * redLED Bertl, if sent from inside a vserver 1101077898 M * redLED Bertl, however, the response never makes it into the vserver 1101077908 M * thh tnx - df works now, but I still get "Database error: [Can't create/write to file '/tmp/#sql_772c_0.MYI' (Errcode: 13)]"-- the website worked on friday and I didnīt even log in 1101077912 M * redLED Bertl, outbound tcp connections from inside the vserver seem not to get established either 1101077935 M * Bertl thh: do you know what (Errcode: 13) means? 1101077948 M * Bertl maybe the /tmp is just full? 1101077957 M * Bertl add a line like this too: 1101077970 M * Bertl none /tmp tmpfs rw 0 0 1101077981 M * thh Error code 13: Permission denied 1101078004 M * Bertl okay, then it's probably not disk full ... 1101078006 M * thh root@taurus-iv:/# df 1101078008 M * thh Filesystem 1K-blocks Used Available Use% Mounted on 1101078009 M * thh /dev/hdv1 286189200 38207832 247981368 14% / 1101078055 M * Bertl what kernel/userspace versions are we talking about? 1101078090 M * thh wait.. looking - something that was acuall an beginning of october 1101078108 M * Bertl and what does: df /tmp/ say 1101078117 M * thh Linux 2.4.26-vs1.27 i686/0.30/0.30 [E] 1101078136 M * Bertl okay, so we are on stable/2.4 ... 1101078149 M * thh root@taurus-iv:/# df -h /tmp/ 1101078151 M * thh Filesystem Size Used Avail Use% Mounted on 1101078152 M * thh /dev/hdv1 273G 37G 237G 14% / 1101078155 M * Bertl do you use xid tagging? 1101078184 M * thh as I dont know what that is probably not ;) 1101078192 M * Bertl redLED: try to add a mangle rule for icmp too 1101078208 M * albeiro hm,, any ideas how could i protect xid tagging between software upgradees ? 1101078258 M * Bertl thh: okay, let's check a few things then ... from inside that vserver, try 1101078274 M * Bertl echo "five" >/tmp/five.txt 1101078308 M * thh that works 1101078318 M * Bertl okay, then remove it, and try again with 1101078342 M * thh STOP 1101078344 M * Bertl su - mysql bash -c 'echo "five" >/tmp/five.txt' 1101078355 Q * v00dY Quit: Serverwechsel 1101078356 M * thh just hit me! 1101078360 M * Bertl hmm? 1101078387 M * thh tmp was mode 711 1101078398 M * Bertl ah ;) 1101078449 M * thh stange all I did was installing openldap via dselect... that shouldnt change modes on tmp! 1101078472 M * Bertl it also should not modify /etc/mtab ... but ... 1101078523 M * Bertl redLED: okay, let's try with a tcp or udp request going from inside out, and try to tcpdump that on the host 1101078940 M * Bertl redLED: still there? 1101078947 M * redLED yep 1101078956 M * Bertl okay, was worried ... 1101078967 M * redLED icmp seems to be sent out, generates a reply, but the reply never makes it into the vserver 1101078976 M * redLED tcp seems to be sent out, but never generates any reply 1101078981 M * redLED now trying to tcpdump destination box 1101078989 M * redLED to see if packet ever made it there, and why did it chose not to reply 1101078992 M * Bertl the icmp part is okay ... 1101079006 M * Bertl we probably have to use some tricks for that 1101079124 M * matti Herbert :-)))))))) 1101079137 M * Bertl matti: :-))))))))) 1101079193 M * albeiro matti: ;p 1101079347 M * matti :D 1101079404 M * redLED aha 1101079408 M * redLED Bertl, got it figured out 1101079449 M * matti Huh... 1101079449 M * redLED Bertl, the reason connectivity is broken, is because on their way out, packets from connections originated by the vserver use the ip address of the host, rather than the secondary ip address assigned to them 1101079477 M * redLED Bertl, the vserver doesen't *see* the host's address in 'ip addr ls', but the packets get sent from the primary address of the interface 1101079548 M * albeiro matti: what shall we install in vserver today ? ;p 1101079566 M * matti ? 1101079597 M * matti albeiro: You mean? 1101079611 M * albeiro i have no idea what to put inside vserver ;p 1101079623 M * matti Hehehe. 1101079625 M * albeiro i will end up with gentoo probably\ 1101079708 M * Bertl redLED: ah, okay, that pretty much explains it 1101080244 M * Bertl okay, I guess that is as far as we get tonight ... 1101080298 M * Bertl if you want to do some further testing, you could try to make the vserver use the host ip .. which should solve this issue (Q&D fix) 1101080321 M * Bertl but still would require the packets to be tagged to be accepted 1101080333 M * Bertl (you would have to make that tagging selective on service) 1101080464 M * redLED that sounds perverse :) 1101080485 M * Bertl you could also use a secondary ip for ssh (on the host ;) 1101080544 M * redLED as in, you basically want to know if packets would correctly reach the vserver in case i actually *do* tie the host's ip address to the vserver? 1101080568 M * Bertl yeah, should work quite well, IMHO 1101080583 M * redLED indeed, that's not much of a feature though ;) 1101080587 M * Bertl the thing is, we do not restrict the binding to specific ips now 1101080602 M * Bertl (I lifted that limit for testing) 1101080637 M * Bertl and we will need advanced limitations for ipv4/ipv6 to work in that setup 1101080652 M * Bertl (but that is nothing I will implement tonight ;) 1101080667 M * redLED alright :) 1101080679 M * redLED well, i'll keep the setup warm and ready for when you have more patches to throw my way 1101080686 M * redLED i'll try to come park my nickname here on occasion 1101080698 M * Bertl porbably I will have some tests/patches tomorrow evening 1101080712 M * redLED as far as testing weither it works with the same IP as host 1101080722 M * redLED i happen to have some machines with two physical interfaces on them 1101080732 M * Bertl that should work too 1101080734 M * redLED i'll try to bind the vserver to the 2nd interface 1101080761 M * Bertl at least if you try to reach a 'local' node on that interface 1101080772 M * Bertl or add a specific routing entry for that ip 1101080791 M * redLED i'll look into it tomorrow morning 1101080799 M * redLED today is done and over with 1101080810 M * redLED time for a warm cup of tea and some sleep 1101080812 M * Bertl okay, thanks for the testing, I guess we are heading somewhere ... 1101080843 M * redLED heh, thanks for bothering me into getting distcc up and running and figuring out the new alpha utils :p 1101080856 M * Bertl you're welcome ;) 1101080870 M * redLED boy i can't wait to see the smile on your face when you get to implement proper interface binding limits for ipv6 1101080879 M * redLED and have to handle the auto-generated link local interfaces 1101080889 M * redLED and net local interfaces 1101080896 M * redLED and all the other generated autoscoped things :p 1101080901 M * Bertl I have no idea what you are talking about ;) 1101080912 M * redLED that's a good start! :p