1109894546 M * hillct I forget... what's a good ruly of thumb for a ration of dick block count to inode count? 1109894571 M * hillct for a server of unknown generic purpose? 1109894602 M * hillct er rule of thumb 1109895558 M * locksy Is there a paste server for here? 1109895748 M * Doener AFAIK no, just use pastebin.com or whatever 1109896106 M * hillct geez, I should pay more attiontion when I type 1109896219 M * hillct OK, ratio of diSk block count to inode count 1109896242 M * Doener *lol* i didn't even notice that typo 1109896257 M * hillct I didn't notice the second one 1109896268 M * hillct until the third read 1109896336 M * daniel_hozac lol 1109896568 Q * matta Quit: Hey! Where'd my controlling terminal go? 1109896573 Q * matta-lt Remote host closed the connection 1109897538 M * Doener Bertl_zZ: http://doener.homeip.net/doener/vserver/diff-2.6.11-rc5-vs1.9.4.9-ng9.1-find_arp_fix.diff 1109897603 M * Doener that fixes arp virtualization regarding the used device and adds debugging to find_arp, guess the used bit to trigger debug output for that one is object to adjustment ;) 1109897903 M * Doener hm, interesting... the comment says only broken drivers are allowed to use those functions... guess ethernet, wireless and twelve other are broken then... ;) 1109898108 M * hillct I guess one inoe for every 4 blocks is reasonable... 1109898123 M * hillct 1K blocks 1109899004 N * Bertl_zZ Bertl 1109899009 M * Bertl greetings! 1109899123 M * Bertl hillct: hmm, why not divide up the available inodes among the vservers? 1109899136 M * Bertl Doener: reading now ... 1109899156 M * Doener wb Bertl, slept well? 1109899168 M * Bertl yeah, really neede a nap! fine now ;) 1109899203 M * Doener i'm now looking into receiving of arp replies... or to be correct: why the vserver doesn't emit any arp requests :) 1109899329 M * Bertl hmm, that should have been 'trying to read ...' 1109899342 M * Bertl doener.homeip.net -> 10.0.1.128 ? 1109899356 M * Doener uh? 1109899368 M * daniel_hozac indeed. 1109899394 A * Bertl had to check his dns proxy first ;) 1109899412 M * Doener hm, same here... 1109899430 M * Doener 217.225.35.7 1109899465 M * Bertl tx 1109899519 M * Bertl +struct net_device *dev = vn ? vn->vndev : skb->dev; 1109899530 M * Bertl is the skb->dev wrong here? 1109899538 M * Doener yep... 1109899542 M * Bertl (I mean in the vn exists case?) 1109899550 M * Doener see vnet_rebuild_headers 1109899595 M * Doener and that's pretty much the fix we needed, the other changes are made since we need to put the device later... 1109899741 M * Bertl hum, if I now could remember why we do the skb->dev play in vnet*header() ... 1109899781 M * Doener probably because the header should be build depending on the real dev... 1109899782 M * Bertl ah, because we do not provide hard_header and rebuild_header yet 1109899794 M * Bertl yeah, right ... 1109899945 M * Bertl hmm, now the questions: could we do with the vnet device there? 1109899966 M * Bertl i.e. call the 'real' rebuild_header but leave the skb->dev alone? 1109900005 M * Bertl eth_rebuild_header() should be fine AFAICT, same for the generic function 1109900116 M * Doener yep, haven't looked at the other ones yet 1109900142 M * Bertl what kind of 'test' did you do for that? the same ping from real->guest? 1109900148 M * Doener yep 1109900160 M * Bertl k, sec trying now ... 1109900195 M * Doener hmm... dyndns blocked my account... i wonder if i had too many updates because of the massive number of disconnects lately... 1109900232 M * Doener though i had worse connection problems before 1109900236 M * Bertl is it changing that often? (your ip) 1109900290 M * Doener normally once a day, but my isp has trouble now and then and that has caused a high number of disconnects (and ip address changes)... 1109900336 M * Bertl don't they do some kind of lease scheme? 1109900350 J * chairuou ~chairuou@210.245.70.144 1109900356 M * Bertl welcome chairuou! 1109900380 M * Doener doesn't seem so ;) new ip address on every connect 1109900453 M * Bertl okay, after changing the vnet_rebuild_header() we get what we expected ... the arp is done from within the context, and the answer is not relayed ... 1109900512 M * Bertl I'll add your debug stuff and a comment in vnet_rebuild_header() and we keep that for now ... until we encounter any issues ... 1109900528 M * Doener i guess we now do: skb->dev->rebuild_headers() without changing the skb's dev? 1109900539 M * Bertl your approach is correct, but it adds some overhead which we do not necessarily need atm ... 1109900566 M * Bertl /* hmm, could this 'confuse' any device? */ 1109900566 M * Bertl // skb->dev = dev; 1109900566 M * Bertl v = dev->rebuild_header(skb); 1109900566 M * Bertl // skb->dev = vndev; 1109900689 M * Doener yep, that's what i meant... i just didn't do that, cause i didn't want to break anything that may need the real dev ;) 1109900698 M * Bertl I change the vnet_hard_header too, it should not be confused by a 'wrong' dev in skb 1109900738 M * Bertl vnet_header() 1109900826 M * Bertl that should now do the arp correctly from within the context, right? 1109900835 M * Bertl (but answer is lost, of course) 1109900870 M * Bertl now what if we add a simple loop to check each vnet context too, just for testing (very simple and inefficient arp switch) 1109900871 M * Doener i'm atm trying _without_ the local route, and no arp request are emitted 1109900887 M * Bertl hmm ... 1109900904 M * Bertl okay, checking in a jiffie ... 1109900957 M * Doener arp.txt 1109900987 M * Doener that's while doing a ping from guest to real 1109901061 J * Nik ~Nik@cable-153-130.online.bg 1109901089 M * hillct hmm 1109901104 M * hillct Looks to me that vdlimit isn't quite all there 1109901112 P * FgL1986 Abandonando 1109901112 M * hillct loths of functions not implemented 1109901118 M * hillct [root@laptop vdlimit-0.02]# ./vdlimit -a -x 2 -S 0,1048576,0,1048576,50 /vservers/fourth 1109901118 M * daniel_hozac hmm? 1109901118 M * hillct vc_add_dlimit: Function not implemented 1109901118 M * hillct vc_set_dlimit: Function not implemented 1109901118 M * hillct vc_get_dlimit: Function not implemented 1109901119 M * hillct [root@laptop vdlimit-0.02]# 1109901135 M * Bertl which kernel is that? 1109901173 M * hillct 2.6.10 with 1.9.4 plus the xfs link invert patch 1109901189 M * Bertl but on alpha/whatever, right? 1109901201 M * Bertl (non x86 I mean) 1109901232 M * Bertl Doener: changed the debug output to: 1109901237 M * Bertl vxdprintk(VXD_CBIT(ngnet, 1), 1109901237 M * Bertl "arp_find(%u.%u.%u.%u, %p[%d,%u])" 1109901237 M * Bertl NIPQUAD(haddr), skb, skb->nfvnet, skb->nfxid); 1109901243 M * hillct x86_64 1109901257 M * Doener ok 1109901264 M * Bertl okay, you have to 'adjust' the syscall by hand ... 1109901288 M * hillct in vdlimit or the kernel patch? 1109901306 M * Bertl in vdlimit, it's a hack tool, basically a proof of concept 1109901313 M * hillct K 1109901344 M * Bertl vserver.h, change #define __NR_vserver 273 1109901380 M * Bertl to 236 1109901596 M * hillct wow 1109901611 M * hillct what's that definition? 1109901627 A * hillct really needs to learn more about the code 1109901638 M * Bertl it controls what syscall number is used for linux vserver 1109901648 M * hillct ah 1109901740 M * Bertl Doener: hmm, of course the NIPQUAD part is bogus *G* 1109901751 M * hillct way cool! 1109901760 M * Doener right :) 1109901764 M * hillct thanks 1109901770 M * Bertl you're welcome! 1109901861 Q * Nik Ping timeout: 480 seconds 1109901907 M * Bertl Doener: is there no macro for the haddr stuff? like typical mac output? 1109902133 A * hillct updates installation notes 1109902205 M * Doener at least the function for /proc/net/arp doesn't use one... 1109902221 M * Doener ( arp_format_neigh_entry() ) 1109902232 M * Bertl yep, guess I define one for our debug stuff ... 1109902386 M * Bertl #define VXD_HEXFMT "%02X:%02X:%02X:%02X:%02X:%02X" 1109902387 M * Bertl #define VXD_HEXA(v) (v)[0], (v)[1], (v)[2], (v)[3], (v)[4], (v)[5] 1109902429 M * Bertl vxdprintk(VXD_CBIT(ngnet, 1), 1109902429 M * Bertl "arp_find(" VXD_HEXFMT ", %p[%d,%u])", 1109902429 M * Bertl VXD_HEXA(haddr), skb, skb->nfvnet, skb->nfxid); 1109902471 M * Bertl (the defines in include/linux/vserver/debug.h) 1109902895 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/ping_guest_to_real.txt 1109902903 M * Bertl (okay, that now looks somewhat expected) 1109902955 M * Bertl well, except for the haddr which is still weird?! 1109902961 M * hillct what tool exists to set the context IDs of the contents of a directory tree? 1109902972 M * Bertl vi 1109902986 M * hillct you're kidding 1109902986 M * Doener yep, same here (btw, target() has also the wrong debug thing (net instead of ngnet) 1109903006 M * daniel_hozac hillct: chxid -R 1109903015 M * hillct ah 1109903041 M * Bertl hillct: sorry misinterpreted your question, I thought you meant the tree-style config ;) thanks daniel_hozac! 1109903074 M * hillct :) 1109903076 M * Bertl Doener: target()? 1109903099 M * Doener the netfilter hook thing (no idea how to call that...) 1109903127 M * Bertl file/line? 1109903131 M * Doener vnet_target(), sorry 1109903161 M * Bertl hum hum ... not here ... 1109903191 M * hillct so when I copy files from my skeleton server I should change the XID on those files that are copied rather than linked 1109903203 M * Bertl that's an option ... 1109903203 M * Doener net/ipv4/netfilter/ipt_VNET.c:38 1109903225 M * Doener ok, it's misleading ;) the function is target() the debug message says vnet_target() 1109903236 M * Bertl yeah, right! 1109903241 M * hillct the xid will have no impact on whether root in a particular vserver will be able to unlink a file right? 1109903260 M * Bertl Doener: I#ll change that to vnet_target (although it doesn't really matter) 1109903276 A * hillct imagines it wouldn't 1109903298 M * Bertl hillct: the access rights basically work like this: 1109903303 M * Doener yeah, just easier communication ;) the VXD_CBIT(net... -> VXD_CBIT(ngnet change is more important :) 1109903326 M * Bertl - filexid=0 (blend through) it belongs to xid=0 but any context can access 1109903350 M * Bertl - filexid == current xid (owned) access is there in this context 1109903366 M * Bertl - filexid != current xid (denied) sorry no access 1109903456 M * hillct K. so my skeleton files that are being linked in should have xid=0 and those that are copied, should have xid=current(vserver), which will properly handle access as well as disk limits 1109903473 M * hillct this will actually work.... cool! 1109903479 A * hillct is getting psyched 1109903484 M * Bertl ;) 1109903512 M * hillct not entirely happy about the prospect of putting it in production, but what the hell. It's only my livlihood... :) 1109903551 M * Bertl well, I guess folks like lycos would not use it if it would break that easily ;) 1109903574 M * hillct all reports are that it's pretty solid 1109903581 M * Bertl Doener: oaky, I'll upload a patch to ng9.0 (for the changed done here) 1109903581 M * hillct I wasn't doubting your work 1109903605 M * hillct It's just the little things like xfs and tweaking syscalls 1109903636 M * hillct I really appreciate all your help and your quick feedback on things. It just worries me a little 1109903641 M * hillct just a little ;) 1109903653 M * Bertl I take that as compliment ;) 1109903670 M * hillct it was meant to be 1109903671 M * Bertl xfs and x86_64 isn't that common yet ... 1109903692 M * hillct hey if I'm going ot take a risk, what the hell. take a big one 1109903701 M * hillct been hosting some sites with johncompanies.com where they use virtuozo 1109903708 M * Doener Bertl: 9.0? why not 9.1? ;) 1109903708 M * Bertl for example, I'm still looking for some test-machine to implement the x86_64 32bit syscall compatibility layer ... 1109903723 M * Bertl hmm, right 9.1 is what I meant ... 1109903729 M * Doener ok 1109903762 M * hillct Virtuozo seems to have a lot more problems than I've encountered with this so far 1109903762 M * Bertl hillct: so if you feel like testing 32 bit userspace to 64 bit x86_64 interaction in a week or so, just let me know ... 1109903801 M * hillct I need to get this box deployed actually.. 1109903815 M * Bertl hillct: does it? (virtuozzo I mean) 1109903816 M * daniel_hozac hillct: with util-vserver 0.30.205+, vdlimit will be included and the syscall number should be automatically detected ;) 1109903816 M * hillct I have clients that have prepaid and I'm almost a month behing 1109903836 M * hillct daniel_hozac cool! 1109903846 M * Bertl well, glad then that we can make up some time for you ;) 1109903851 M * hillct er behind 1109903875 M * hillct I'll be happy to test whatever I can to help 1109903894 M * hillct I expect to get another box quite soon for that purpose 1109903915 M * hillct if I'm going to do any serious hosting in this enviroment I'll need a sandbox 1109903922 M * hillct which will be my next purchase 1109903946 M * Bertl guess you are already testing a lot, and after all, the xfs bug-fix is partially your merit 1109903994 M * hillct what I tried it and found it broken? heh. I'm still stunned that it took you only 20 minutes to get a fix 1109903997 M * hillct :) 1109904026 M * Bertl the hard part with bug fixing is to reproduce it ... 1109904045 M * Bertl bug is reported -> I can reproduce it (that's the long time usually) 1109904050 M * hillct What I will be able to do in the short term is produce some documentation 1109904107 M * hillct And I'll likely be writing a webmin module that will act as a user control pannel 1109904113 M * Bertl Doener: http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.1-ng9.2.diff 1109904137 M * Bertl hillct: webmin on the host that is? 1109904142 M * hillct yup 1109904147 M * Doener is the dump_stack() call included intentionally? 1109904168 M * hillct although I'm not crazy about consuming host resources with it 1109904168 M * Bertl yes, we do not want to see those, right? 1109904186 M * hillct and it's a bit of a security nightmare 1109904194 M * hillct webmin that is 1109904207 M * hillct er webmin running on the host box anyway 1109904212 M * Bertl Doener: yes, we do not want to see those, right? 1109904226 M * Bertl yeah, sounds good the webmin approach ... 1109904232 A * Doener tries to understand that one... 1109904258 M * daniel_hozac a webmin seems to be a quite common feature request. 1109904261 M * Doener we include the call to dump_stack() because we don't want to see something? 1109904263 M * Bertl simple, we do not want to have any 'unknown/untagged' packets 1109904274 M * hillct I also want to put together a generic perl vserver object 1109904285 M * Bertl Doener: so if we get some, we have the stack trace to locate the origin 1109904286 M * Doener ah ok... 1109904298 M * daniel_hozac hillct: Perl bindings to the libvserver library? 1109904311 M * hillct probably not that low level 1109904331 M * hillct I was thinking as a wrapper to the existing tools 1109904343 M * hillct mostly for changing config settings 1109904356 M * hillct changing rlimits, etc 1109904369 Q * no_maam Ping timeout: 480 seconds 1109904391 M * hillct I guess I could try for true bindings but my C is a little rusty 1109904419 M * Bertl it would be a good idea to do some 'config' editor (maybe menu based?) or maybe the often discussed tree-config <-> file-config converter? 1109904456 M * hillct that'd be a good excercise for me. It'd force me to learn the config details 1109904458 M * Bertl a config editor could also change most of the settings on the fly (without restarting the vserver) 1109904465 M * daniel_hozac when would you use the tree-config -> file-config converter? 1109904488 M * Bertl for all that folks who do not like the tree-style config 1109904493 M * hillct to avoid having to use the tools contained in util-vserver-lagacy 1109904495 M * Bertl (see it like bzip2/bunzip2) 1109904515 M * Doener ok, changes look good 1109904568 M * Bertl updated the ping_guest_to_real.txt 1109904585 J * no_maam ~erik@datenzone.de 1109904605 M * Bertl Doener: btw, thanks for your work/help so far! 1109904614 M * Doener np, it's fun! 1109904641 M * Bertl okay, the arp itself is 'blocked' atm ... 1109904657 M * Bertl (which is expected, as we have no matching rules for that) 1109904669 M * Doener and i'm listed as a developer in the HoF, so i got to do something ;) 1109904699 M * Bertl yeah, right, that is binding, isn't it? ;) 1109904753 M * Bertl but it looks to me like I have to change a little there ... 1109904862 M * Bertl a short statement to your location(s)? 1109904881 M * Bertl Germany is large ... well, at least for me ;) 1109905051 M * Doener hm, city is "Rahden" northest north of northrhine-westphalia 1109905090 M * Bertl is that where the Immanuel-Kant-Oberschule is? 1109905099 A * Doener .oO( pretty "northy" ) 1109905152 M * Doener no, google says that one is in Berlin ;) 1109905194 M * Bertl right! ... 1109905275 M * Bertl now I probably asked that several times now, is it Björn or Bjoern? 1109905314 M * Doener it's Björn 1109905379 M * Doener Rahden is about 70-80km west of Hannover 1109905525 M * Bertl now, why is that haddr so weird? 1109905604 M * Bertl shouldn't that be the hwaddr of the device? 1109905617 M * Doener what is the haddr of the device? 1109905622 M * Bertl en0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 1109905707 T * Bertl http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5-rc1, ng9.2 -- 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 ;) 1109905775 M * Bertl hmmm, vndev->hard_header_len = 0; could be a reason for that ... 1109905835 M * hillct oh, in case anyone cares, here's a dietlibc RPM with the required 'nice' patch 1109905838 M * hillct www.pinnacledigital.com/SRPMS/dietlibc-0.28-vserver.src.rpm 1109905873 M * Bertl if it will stay there, please add the url to the Tools and patches section ... 1109905883 M * daniel_hozac hillct: for what distro? 1109905901 M * hillct I'm putting together my thoughts for an x86_64 howto 1109905915 M * hillct daniel_hozac fc2 + 1109905948 M * hillct I'll put everything up after I put it in some semblence of order 1109905953 M * daniel_hozac hillct: (sidenote: Enrico himself will be maintaining dietlibc for FC4+) 1109905979 M * hillct the needed patch never seemed to get in 1109905981 M * daniel_hozac is the x86_64 patch in upstream yet? 1109905984 M * Bertl daniel_hozac: hmm ... he will? 1109905987 M * daniel_hozac send it to him ;) 1109905988 M * hillct It's been around since 0.27 1109906006 M * hillct several people have 1109906026 M * hillct I found it on a mailing list somewhere and updted it for 0.28 1109906028 M * daniel_hozac Bertl: yep, http://www.redhat.com/archives/fedora-extras-list/2005-March/msg00060.html 1109906037 M * hillct guess another attempt can't hurt 1109906272 M * Bertl daniel_hozac: cool! 1109906324 M * hillct er, I meant that people have submitted the patch to Felix von Leitner several times without any response 1109906534 M * Bertl Doener: ah, stupid me, the haddr is a pointer where the address will go to ... *sigh* 1109906548 M * Doener ah! 1109906562 M * Bertl so we make that two debug messages ... 1109906857 M * hillct guess I should look at fc4 extras before sending this to Enrico... 1109906961 M * Bertl Doener: http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2-ng9.2.1.diff 1109907057 M * Doener hm, would be nice to know whether we got a result from arp_set_predefined or not i guess 1109907096 M * Bertl well, we should know '(pd) 1109907127 M * Doener ah, missed that 1109907147 M * Doener in-brain diff is broken ;) 1109907160 M * Bertl well, it's not easy to see there ... 1109907207 M * Bertl but I think the predefined thingy might be a good point for the virtual arp switch, hmm? 1109907283 M * Doener well, according to the comments in the code, both functions are to be removed 1109907317 M * Doener and we can deduce that most network drivers are broken ;) 1109907736 M * Bertl hmm, well, okay, who is going to do the arp stuff then? 1109907785 M * Bertl probably arp_solicit is replacing that? 1109907846 M * Bertl maybe we should look into 'fixing' the eth driver then? 1109907876 M * Doener and wireless and 12 others? *g* i tried to find out when that comment has been added, but didn't find anything 1109907890 M * Bertl funny thing is this: in eth.c 1109907895 M * Bertl * This routine CANNOT use cached dst->neigh! 1109907895 M * Bertl * Really, it is used only when dst->neigh is wrong. 1109907931 M * Doener hm, the other comment says that not using dst->neigh is stupid, right? 1109907972 M * Bertl yeah ... sec ;) 1109908357 M * Bertl okay, let's allow all outgoing arp requests for now ... 1109908399 M * Doener hm, yeah... doing a ping from host to real we use arp_solicit... guess we break something somewhere 1109908416 M * Bertl vxD: neigh_lookup(803008c0,83d5cc00[en0,#10]) : 010010ac 1109908427 M * Bertl here is where it probably breaks ... 1109908427 Q * roswel Quit: Leaving 1109908587 J * Nik ~Nik@cable-153-130.online.bg 1109908641 M * Bertl IMHO the following happens: 1109908650 M * Doener btw, what does fib stand for? 1109908713 M * Bertl Funny Internet Buffer? no idea ... 1109908729 M * Doener *g* 1109908755 M * Bertl * IPv4 FIB: lookup engine and maintenance routines. 1109908759 M * Bertl * Authors: Alexey Kuznetsov, 1109908782 M * Bertl * IPv4 Forwarding Information Base: FIB frontend. 1109908787 M * Bertl ah, that's better ;) 1109908804 M * Doener thx 1109908898 M * Bertl okay, back to what happens ;) 1109908918 M * Bertl the ping 'requests' a packet to 172.16.0.1 1109908921 Q * chairuou Ping timeout: 480 seconds 1109908932 M * Bertl the route-cache is empty (expected) 1109908945 M * Bertl so the ip_route_output_slow() kicks in 1109908959 M * Bertl of course the fib_lookup() fails ... 1109908974 M * Bertl which leads to a neigh entry to be created 1109908984 M * Bertl (waiting for an arp reply) 1109908984 J * chairuou ~chairuou@210.245.71.48 1109909004 M * Bertl this doesn't happen (because we ignore it) 1109909016 M * Bertl (both arp request and reply actually) 1109909063 M * Bertl --- here beginns the speculative part 1109909082 M * Bertl probably some 'timer' kicks in, and does the arp 'by hand' 1109909114 M * Doener yeah, i've seen some 'timer' stuff...at least some function with 'timer' in its name 1109909460 M * Bertl hmm, maybe change 1109909461 M * Bertl #define NEIGH_DEBUG 1 1109909494 M * hillct Bertl is there a compelling reason not to include the disk limits right in the vserver config tree, much like the other rlimit items? 1109909504 M * Bertl yes 1109909514 M * hillct flexibility I suppose... 1109909516 M * Bertl the limits are per context and per device ... 1109909523 M * hillct ah 1109909528 M * Bertl so it would require some devicetree there ... 1109909544 M * Bertl maybe we add something like a default for the root or so 1109909561 M * Bertl (but some values have to be calculated anyway) 1109909577 M * hillct I can see where a vserver may have multiple devices but would it have more than one context? 1109909596 M * Bertl no, that not 1109909611 M * Bertl context == vserver here ... 1109909617 M * hillct yah 1109909630 M * Bertl would work similar to the interfaces ... 1109909637 M * Bertl (it that is where you are heading) 1109909647 M * hillct yup 1109909651 Q * Nik Ping timeout: 480 seconds 1109909684 M * Doener Bertl: where's that #define? 1109909714 M * Bertl net/core/neighbour.c 1109909753 M * Bertl but it's not worth the efford ;) 1109909757 M * Doener ah, started vi in the wrong directory, no surprise that it couldn't find it 1109909764 M * Bertl neigh 83675b80 is created. 1109909772 M * Bertl (the one and only message ;) 1109909793 M * Doener woohoo 8-) 1109909892 M * Bertl but I fail to see where the arp request would be generated ... 1109909936 M * Bertl I mean except for the arp_find 1109909961 M * Bertl n->confirmed = jiffies - (n->parms->base_reachable_time << 1); 1109909967 M * Bertl this seems to be the timeout 1109910087 M * Doener i fail at the same atm 1109910136 M * Bertl int neigh_resolve_output(struct sk_buff *skb) 1109910162 M * Bertl (possible candidate) 1109910727 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.1-ng9.2.2.diff 1109910732 M * Bertl (small update) 1109910740 M * Bertl hmm, and broken too ;) 1109910856 M * Bertl updated, please reload 1109910971 M * Bertl nice to have, but doesn't help here :( 1109911369 M * Bertl maybe the arp_find() is really the 'normal' thing here ... 1109911417 M * Bertl no, definitely not, upload a pign from host->real 1109911449 M * Doener yep, that does arp_solicit... but too late for an arp request AFAICT 1109911499 M * Bertl nope, looks good to me ... 1109911520 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/ping_host_to_real.txt 1109911566 M * Bertl (the arp_process debug is new) 1109911606 J * nox- ~nox@213.39.193.231 1109911723 M * Bertl hmm, looks like vxD: ip_route_output_flow() 1109911724 M * Bertl vxD: __ip_route_output_key(#0) 1109911728 M * Doener btw, with the fixed arp_find/vnet_rebuild_headers, real->guest is broken ;) 1109911731 M * Bertl is the last common point ... 1109911742 Q * ciphernaut Ping timeout: 480 seconds 1109911754 M * Bertl well, I almost expected that ... 1109911783 M * Bertl nevertheless I think we are heading in the right direction 1109911936 M * Doener hmm... is it the fact that we steal the package in the netfilter part, that makes the packets show up on en0 (guest) only, but not on eth0 (host) when pinging from real to guest? 1109911936 Q * nox Ping timeout: 480 seconds 1109911953 M * Doener s/package/packet/ 1109911965 N * nox- nox 1109911976 M * Bertl Doener: hmm, yeah, guess so 1109911998 M * Bertl if you do tcpdump, then either on the real or the guest 1109912159 M * Bertl hmm hmm ... 1109912277 M * Bertl yes, the difference between both pings is right after ip_route_output_flow() 1109912292 M * Bertl (or within it, actually) 1109912391 M * Bertl I'll add some more debug output there 1109913071 M * Doener hum hum... 1109913114 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.2-ng9.2.3.diff 1109913127 M * Bertl any ideas? 1109913150 M * Doener nothing yet... 1109913185 M * Doener but a feeling of getting somewhere... my brain usually needs some pieces and then it makes click, but before that i've got nafc 1109913223 M * Bertl k, keep collecting pieces then ... 1109913458 M * Bertl updated both debug traces .. 1109913516 M * Doener k 1109913571 M * Bertl looks to me like the vnet_target() is simply blocking the arp request 1109913608 M * Bertl -vxD: raw_sendmsg(811b0760[#0]) 1109913613 M * Bertl +vxD: raw_sendmsg(811b0760[#10]) 1109913617 M * Bertl -vxD: ip_route_output_flow(82f79c90,82f79ce4[#0],811b0760[#0],1) 1109913623 M * Bertl +vxD: ip_route_output_flow(82f79c90,82f79ce4[#10],811b0760[#10],1) 1109913631 M * Bertl -vxD: __ip_route_output_key(#0) 1109913638 M * Bertl +vxD: __ip_route_output_key(#10) 1109913646 M * Bertl -vxD: neigh_resolve_output(83d0cc00[65535,#0]) 83e36140,839d8c40 1109913656 M * Bertl +vxD: vnet_target(65535,#10) [101,3] 1109913656 M * Bertl +vxD: vnet_get(101) = 83e6fe40[101,#10] 1109913656 M * Bertl +vxD: arp_find(811e7202, 83934be0[101,10]) 1109913712 A * Doener .oO( now if we combine that with the comment that dst is broken when arp_find is called... ) 1109913820 M * Bertl as I don't see any neigh_* calls in __ip_route_output_key() 1109913842 M * Doener let's add a dump_stack to neigh_compat_output 1109913853 M * Bertl good idea! ;) 1109913895 M * Bertl hmm, resolve_output() I gues? 1109913932 M * Bertl but right, compat output should get a debug too ... 1109913943 M * Bertl I guess we'll see that in the guest dump then ... 1109914040 M * Bertl of course, I guess that's it ... 1109914083 A * Bertl is verifying that right now ... 1109914216 M * Bertl yep, guest is calling 1109914217 M * Bertl vxD: neigh_compat_output(839ecbe0[101,#10]) 83d7ac00[en0,#10] 1109914235 M * Bertl while host is doing 1109914264 M * Bertl vxD: neigh_resolve_output(83d3ac00[65535,#0]) 83e3e140,83ea6c40 1109914362 M * Bertl struct neigh_ops arp_broken_ops = { 1109914370 Q * chairuou Ping timeout: 480 seconds 1109914389 M * Doener yup 1109914424 M * Bertl drivers/net/vnet.c 1109914429 M * Bertl n->ops = &arp_broken_ops; 1109914433 M * Bertl self inflicted ;) 1109914441 M * Doener hehe :) 1109914533 M * Bertl but that's exactly the place where we should hook in any arp stuff, I guess 1109914827 J * chairuou ~chairuou@210.245.71.48 1109914982 M * Bertl how about that? 1109914987 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.3-ng9.2.4.diff 1109915398 M * Bertl hmm, something is still missing, no arp_solicit() 1109915525 M * Doener hm, will patch up to 9.2.4 now... 1109915851 J * infowolfe ~infowolfe@a.ns.xhcl.net 1109915856 M * Bertl welcome infowolfe! 1109916102 Q * sannes Read error: Connection reset by peer 1109916291 Q * chairuou Ping timeout: 480 seconds 1109916373 J * Nik ~Nik@cable-153-130.online.bg 1109916735 J * chairuou ~chairuou@210.245.71.48 1109916856 Q * Nik Ping timeout: 480 seconds 1109917187 M * Doener Bertl: hm, i get a kernel panic with ng9.2.4 1109917202 M * Bertl where? 1109917231 M * Doener ip_route_output_key (it seems)... while ping from real to guest 1109917264 M * Doener eip is at net/ipv4/route.c:2275 1109917311 M * Bertl hmm, maybe flp can be NULL 1109917332 M * Bertl well, guess that's very likely the cause 1109917359 M * Bertl change the flp->nfxid args to flp?flp->nfxid:0 1109917408 M * Doener no, the message is printed... 1109917439 M * Bertl same for the sock/sk 1109917462 M * Doener http://217.225.46.88/doener/vserver/trace.txt 1109917573 M * Doener yep, it was the sk 1109917604 M * Bertl can we assume that flp always exists? 1109917652 M * Bertl a quick scan says yes ;) 1109917656 M * Doener yep 1109917815 M * Bertl vxD: neigh_lookup(80300900,83475c00[en0,#10]) : 010010ac 1109917815 M * Bertl vxD: neigh_create(80300900,83475c00[en0,#10]) : 010010ac 1109917815 M * Bertl vxD: arp_constructor(83fffb80,83475c00[en0,#10]) 1109917832 M * Bertl the differencence seems to be here ... 1109917860 M * Doener could you update the traces? 1109917867 M * Bertl sure, sec 1109917972 M * Bertl updated 1109917979 M * Doener thx 1109918177 M * Bertl hmm, maybe not ... 1109918177 Q * hillct Read error: Connection reset by peer 1109918235 Q * infowolfe Quit: leaving 1109918456 M * Bertl no, I guess I know what happens ... 1109918473 M * Bertl the neigh_resolve_output() calls into the device functions 1109918488 M * Bertl with dev->hard_header() and friends 1109918527 M * Bertl the device is used from neigh, so that might not be what we expect ... and very likely the packet gets discarded 1109918545 M * Bertl I'll add a few debug messages there, tracking the flow ... 1109919042 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.4-ng9.2.5.diff 1109919056 M * Bertl vxD: neigh_resolve_output(82ca9bc0[101,#10]) 83e74d40,8390bb80 1109919056 M * Bertl vxD: neigh_resolve_output() -1- 1109919056 M * Bertl vxD: neigh_resolve_output() -4- 1109919056 M * Bertl vxD: __sock_sendmsg: 82cc03c0[811b0760,83e8b800;#10]:64/64 1109919085 M * Bertl vs 1109919086 M * Bertl vxD: neigh_resolve_output(83c73be0[65535,#0]) 83e08d60,83f80ba0 1109919086 M * Bertl vxD: neigh_resolve_output() -1- 1109919086 M * Bertl vxD: neigh_resolve_output() -2- 81158000[eth0,#0] 1109919086 M * Bertl vxD: neigh_resolve_output() -3.a- 1109919088 M * Bertl vxD: neigh_resolve_output() -4- 1109919091 M * Bertl vxD: netif_receive_skb(83c73b20[#65535]) 1109919182 M * Bertl looks like some debug infos for neigh_event_send are required ... 1109919966 M * Doener Bertl: any idea how much the networking code has changed between 2.4 and 2.6? iow are guides on 2.4 networking still at least generally valid for 2.6? 1109920052 M * Bertl hmm, it changed significantly ... 1109920065 M * Bertl but I guess general stuff is still the same ... 1109920085 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.5-ng9.2.6.diff 1109920095 M * Bertl (ping*.txt are updated) 1109920129 M * Bertl s/are/have been/ 1109920171 M * Bertl vxD: __neigh_event_send() -1.a- vxD: __neigh_event_send() -1.a- 1109920175 M * Bertl vxD: __neigh_event_send() -2- < 1109920177 M * Bertl vxD: __neigh_event_send() -3- < 1109920180 M * Bertl vxD: neigh_resolve_output() -4- vxD: neigh_resolve_output() -4- 1109920280 M * Bertl so I conclude (and please correct me if I'm wrong here) 1109920293 M * Bertl neigh->parms->mcast_probes + neigh->parms->app_probes = 0 1109920297 J * DaPhreak ~DaPhreak@p3E9EEB5D.dip.t-dialin.net 1109920307 M * Bertl morning DaPhreak! 1109920348 M * Doener yep, has to be 1109920357 M * Doener morn' DaPhreak 1109920460 M * DaPhreak mornin Doener, Bertl :) 1109920500 M * DaPhreak i think i gonna try the grsec patches later :) 1109920604 M * Bertl Doener: hmm, looks like this is a 'property' of the dn_neigh_table 1109920653 M * Doener Bertl: cscope limitation, try with symbol search :) 1109920673 M * Bertl seems that the neigh stuff brings it's own neigh_ops?! 1109920684 M * Bertl static struct neigh_ops dn_long_ops = { 1109920717 M * Doener that's decnet stuff 1109920728 M * Bertl hmm ... hmm .. maybe we should 'just' copy them from the real device for now? 1109920907 M * Bertl hmm, or maybe leave them out for now ... 1109920982 M * Bertl drivers/net/vnet.c (now trying) 1109920985 M * Bertl // vndev->neigh_setup = vnet_neigh_setup_dev; 1109921020 M * Doener hmm... damn, i should've tried that again... forgot it after the kernel panic 1109921110 M * Bertl now that looks pretty good ... 1109921167 M * Bertl ping_guest_to_real.txt (updated) 1109921303 M * Doener hm, why isn't it tagged? 1109921464 J * FEN_HIN ~JFOC@latarius.tkdgroup.com 1109921465 M * Bertl guess arp_solicit() is building that packet 1109921473 M * FEN_HIN hi Bertl 1109921487 M * Doener yep, and arp_xmit sends it to NF_HOOK 1109921489 M * Bertl hey FEN_HIN! 1109921492 M * FEN_HIN :) 1109921495 M * FEN_HIN hi Doener 1109921505 M * Doener hi FEN_HIN 1109921564 M * Bertl okay, guess adjusting arp_create() should fix that 1109921688 M * FEN_HIN Doener: do you know where i can download vconfig ? 1109921704 M * Bertl vlan-utils 1109921713 M * FEN_HIN oh 1109921715 M * Doener or vconfig on debian IIRC 1109921751 M * Bertl yeah, I know the 'v' is misleading ;) 1109921755 M * FEN_HIN what's IIRC stand for ? 1109921772 M * Bertl (those folks should really change it ;) 1109921778 M * FEN_HIN hehe i got vconfig requirement when trying configuring utils-server 1109921793 M * Doener ah, wrong chain/table... 1109921836 M * FEN_HIN wrong chain ? 1109921838 M * Bertl http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=iirc&Find=Find 1109921861 M * Doener FEN_HIN: been talking to Bertl ;) 1109921875 M * Bertl (probably he meant: Isn't It Really Cool?! *G* ) 1109921882 M * FEN_HIN oh i see 1109921915 M * FEN_HIN hehehe have many meaning for IIRC 1109922009 M * Bertl Doener: wouldn't it be a good idea to make the 1109922019 M * Bertl vnet_header() autotagging? 1109922080 M * FEN_HIN hmm i can't found vlan-utils source code 1109922089 M * FEN_HIN :( 1109922140 M * Bertl http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/vlan-utils-1.8-1mdk.src.rpm 1109922153 M * Doener Bertl: hm, we would probably loose most (all?) packets which should not be on that interface then, wouldn't we? vnet_header is called for each and every packet i guess... 1109922164 M * FEN_HIN hmm rpm again 1109922175 M * Bertl Doener: hmm, good point ... 1109922190 M * Doener FEN_HIN: what distro are you using? 1109922202 M * FEN_HIN i'm using debian for testing 1109922210 M * Doener then: apt-get install vconfig 1109922215 M * FEN_HIN but i more like source than precompiled 1109922226 M * FEN_HIN because i can do much with source 1109922233 M * DaPhreak apt-get install source vconfig ? :) 1109922238 M * Doener err s/vconfig/vlan/ 1109922249 M * Doener DaPhreak: s/install// ;) 1109922261 A * DaPhreak hasn't used debian for *think* 3 years ? 1109922278 M * Bertl *nothing changed since* 1109922284 M * FEN_HIN hehe i love debian 1109922292 M * DaPhreak hmm ... damn hunk correcting :) 1109922351 M * FEN_HIN debian has great gnu and open source concept like linux :D 1109922355 M * Bertl Doener: where was that cool output packet tagging macro? 1109922382 M * Bertl sure I wrote it, doesn't mean I can remember where I did put it ... 1109922404 M * Doener vx_tag_output_skb 1109922435 M * Bertl yeah, I guess we do a similar one for devices, no? 1109922459 M * FEN_HIN Doener: do you have experience using ss7 or sctp in linux platform ? 1109922478 M * Doener not at all 1109922494 M * Bertl what's that btw? 1109922498 M * FEN_HIN i always get failed to using ss7 module even i've been recompile kernel for many times 1109922518 M * FEN_HIN ss7 / sctp is signalling protocol for telecommunication 1109922540 M * Bertl ah, right! 1109922547 M * FEN_HIN i'm working at telecommunication company, so i doing converting all of windows ss7 application to unix platform 1109922569 M * FEN_HIN for 1st step is to converting into linux, after that to solaris 1109922601 M * Doener hm, one step forward and one backwards? ;) 1109922625 M * FEN_HIN not really 1109922654 M * Doener Bertl: for devices? please elaborate 1109922664 M * FEN_HIN because almost every telecommunication application in my country already using solaris for their based, so we must make justify to them 1109922673 M * Bertl void vx_tag_dev_skb(struct net_device *dev, struct sk_buff *skb) 1109922692 M * Doener yeah, guess that's fine 1109922739 M * Bertl should be able to deduce the vnet too ... 1109922824 M * DaPhreak next lesson, cu later :) 1109922826 Q * DaPhreak Quit: leaving 1109923071 M * Bertl how about that?: 1109923072 M * Bertl { 1109923072 M * Bertl if (dev->priv_flags & IFF_VNET) { 1109923072 M * Bertl struct vnet *vn = dev->priv; 1109923072 M * Bertl skb->nfvnet = vn->nfvnet; 1109923074 M * Bertl skb->nfxid = vn->nfxid; 1109923077 M * Bertl } else { 1109923079 J * sannes ~ace@home.skarby.no 1109923079 M * Bertl skb->nfvnet = VNET_UNTAGGED; 1109923082 M * Bertl skb->nfxid = dev->nfxid; 1109923084 M * Bertl } 1109923087 M * Bertl } 1109923094 M * Bertl morning sannes! 1109923133 M * Doener can a dev have a nfxid without having IFF_VNET= 1109923146 M * Bertl yep, else case 1109923177 M * Doener hm, where is that set? 1109923193 M * Bertl the dev->nfxid ? 1109923252 M * Doener yup 1109923277 M * Bertl probably nowhere yet ... but we have to do so on device creation 1109923320 M * FEN_HIN vconfig and vlan-utils is has same function ? 1109923349 M * Bertl Doener: for example, if xid=10 creates a tun device, it has to have nfxid=10 1109923366 M * Doener good point 1109923415 M * Bertl the vn->nfxid is redundant (basically) 1109923520 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1109923539 M * Bertl welcome erwan_ho! 1109923569 M * erwan_ho hi Bertl 1109923579 J * Nik ~Nik@cable-153-130.online.bg 1109923711 M * Bertl excellent! 1109923717 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ng9.2.6-ng9.2.7.diff 1109923781 M * Bertl okay, connection is getting really bad here .. so I'm basically off to bed ... 1109923806 M * Doener ok, enough ngnet for me now... will do something non technical or sleep or whatever, my brain needs a break 1109923808 M * Bertl but before ... I'll upload some updated ping_* 1109923817 M * Doener night Bertl! 1109923824 M * Doener cya folks 1109923828 N * Doener Doener|gone 1109923829 M * Bertl night Doener! 1109923835 M * FEN_HIN cya 1109923838 M * FEN_HIN night 1109924061 Q * Nik Ping timeout: 480 seconds 1109925117 J * _are_ ~are@mail.foehl.de 1109925391 Q * FEN_HIN Read error: Connection reset by peer 1109925409 M * Bertl okay, night everyone! 1109925414 J * FEN_HIN ~JFOC@latarius.tkdgroup.com 1109925431 N * Bertl Bertl_zZ 1109925523 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1109925790 J * ntrs_ ntrs@Dardeene-68.188.50.87.charter-stl.com 1109925790 Q * ntrs Read error: Connection reset by peer 1109925984 J * prae ~prae@ezoffice.mandrakesoft.com 1109926054 M * FEN_HIN welcome prae 1109926279 M * prae Hi Fen 1109926838 M * prae question, Bertl_zZ is only one to develop vserver ? 1109926879 M * FEN_HIN don't know, i dont have idea 1109926933 M * prae ok :p 1109926951 M * FEN_HIN :D 1109926963 M * FEN_HIN you're working at mandrakesoft ? 1109926984 M * prae I found this presentation of vserver, it's not bad http://www-user.tu-chemnitz.de/~ensc/util-vserver/doc/lt2004/main-en.pdf 1109926989 M * prae FEN_HIN: yes 1109927009 M * FEN_HIN what you do? developing application ? 1109927094 M * prae erwan_* is an older worker into mdksoft too,he was left this year but continue to work with 1109927106 M * prae me ? hmmm Profesionnal Support and Consulting 1109927126 M * FEN_HIN yes you. wow you're the prof :) 1109927161 M * prae arf! me ? profesionnal ? no :) 1109927183 M * prae I make only coffee for customers :) 1109927205 M * FEN_HIN hehe but you must be the prof 1109927234 M * prae waht do you mean by "prof" ? :) 1109927235 M * FEN_HIN 4 years ago i'm using mandrake, but now i'm using debian and slack 1109927241 M * prae :) 1109927260 M * FEN_HIN oh sorry, prof i mean is professional 1109927263 M * prae I work for mandrake but I prefer debian and bsd ;-) 1109927302 Q * DaCa Ping timeout: 480 seconds 1109927339 M * prae oO( I know, i'm a bad debian guy ! :) 1109927355 A * prae autoslapping itself 1109927356 M * FEN_HIN hehe weird hah? work for mandrake but much prefer to debian and bsd 1109927357 M * prae =) 1109927375 M * FEN_HIN bad debian guy? i think not as long you still love debian and keep the debian motto :D 1109927423 M * prae :p 1109927432 M * FEN_HIN prae: you using vserver? 1109927442 M * prae yes, of course 1109927445 M * FEN_HIN i cant found vconfig / vlan-utils sourcecode :( 1109927459 M * prae hmmm, vconfig ... 1109927466 M * prae what is ? 1109927474 M * FEN_HIN when i'm configuring utils-server it told i don't have vconfig/vlan-utils installed 1109927515 M * prae "vconfig is vlan config (802.*)" 1109927518 M * prae aaahh ok ! 1109927538 M * prae it is not a specific software ? 1109927546 M * FEN_HIN yes vlan config for configuring vlan 1109927549 M * prae include into your distro ? 1109927566 M * FEN_HIN don't know, but utils-server ask for it 1109927567 M * prae "apt-cache search vlan" give something ? 1109927597 M * FEN_HIN yes debian has it. but i looking for sourcecode :D 1109927608 M * prae ah ok! you see source code, not binaries :) 1109927616 M * prae apt-get source vlan :p ? :) 1109927627 M * FEN_HIN yes :) 1109927655 M * FEN_HIN see, you're nice debians :) 1109927656 M * prae http://ftp.debian.org/debian/pool/main/v/vlan/vlan_1.5.orig.tar.gz 1109927661 M * prae no ? :p 1109927678 M * prae http://ftp.debian.org/debian/pool/main/v/vlan/vlan_1.8.orig.tar.gz (testing version) 1109927692 M * FEN_HIN oh pool package 1109927705 M * FEN_HIN okey thx 1109927710 M * prae :) 1109927914 M * prae http://scrymud.net/~greear/vlan.html 1109927954 M * prae # zcat vlan_1.5.orig.tar.gz | strings | grep http ;) 1109927999 M * FEN_HIN great 1109928055 M * prae this method is for lazy people like me :) 1109928080 J * rs ~rs@194.98.28.2 1109928094 M * prae morning' rs 1109928175 M * FEN_HIN hehe me too 1109928184 M * FEN_HIN http://packages.debian.org/unstable/source/vlan unstable for debian 1109929513 M * prae question, if I don't set my /vservers/myname with setattr --barrier, it's a big problem ? 1109929557 M * FEN_HIN dont know 1109929570 M * FEN_HIN Bertl_zZ and Doener|gone are sleeping 1109929634 Q * erwan_ho Remote host closed the connection 1109929743 M * prae :p 1109930752 M * FEN_HIN :p 1109931082 Q * mhepp Quit: mhepp caught signal: Autobus error 1109931208 J * matti matti@linux.gentoo.pl 1109931832 J * DuckMaster ~duckx@195.75.27.158 1109932026 M * prae FEN_HIN: We use vserver for what ? 1109932043 M * FEN_HIN i'm using for my irc shell hosting 1109932051 M * FEN_HIN and webhosting 1109932114 M * prae for tkd ? 1109932455 M * prae I think to something ... why vps should need /proc/meminfo absolutely ? 1109932469 M * prae without /proc/meminfo (into vserver), vps stop 1109932501 M * Zoiah prea: if you don't have the barrier, root can break out of the vserver quite easily. 1109932508 Q * chairuou Read error: Connection reset by peer 1109932521 M * prae Zoiah: no kidding ? 1109932530 M * Zoiah prae: no kidding. 1109932534 M * prae ouch ! 1109932536 M * prae ok 1109932540 M * prae thx :p 1109932663 M * prae Zoiah: we must set "barrier" into /vservers or /vservers/name ? 1109932678 M * prae if I set this into /vservers/name I can't start or entering into my vserver 1109932680 M * Zoiah prea: /vservers afaik. 1109932705 M * prae so, attackers can't be "jump" into another vserver ? 1109932713 M * prae s/be// 1109933103 M * prae or /vservers (with attr B) is considered like a giant wall where we can't bypass 1109933140 M * prae (no access into /vservers, but access into /vservers/vserver.nX/) 1109933856 Q * Hollow Ping timeout: 480 seconds 1109934032 M * FEN_HIN for tkd ? --> no, i just working at tkd. But i have my own business on jfoc.net and teamshell.org 1109934098 M * prae ok :) 1109934170 M * FEN_HIN sorry took to long for answer :) 1109934285 M * prae :) 1109934302 M * prae hmmm, groumpf ... I lost url for latest util-vserver 1109934324 M * prae FEN_HIN: have you url with experimental util-vserver ? 1109934350 M * FEN_HIN http://linux-vserver.org/alpha+util-vserver 1109934381 M * prae *thx* :) 1109934398 M * prae You're my hero :) 1109934452 M * FEN_HIN complete URL http://www-user.tu-chemnitz.de/~ensc/util-vserver/alpha/util-vserver-0.30.204.tar.bz2 1109934460 M * FEN_HIN :) 1109934475 M * prae :) 1109935875 M * erwan_taf prae 1109935961 M * prae M. du wan :) 1109936074 M * erwan_taf M du prae 1109936098 M * erwan_taf prae: that's M. moufle for closed friends 1109936107 M * prae =)) 1109936110 M * prae it's true :) 1109936113 M * prae Mister Moufle 1109936126 M * prae Mister _Giant_ Moufle :) 1109936218 M * prae erwan_taf: I read this since one hour 1109936227 M * prae http://www-user.tu-chemnitz.de/~ensc/util-vserver/doc/lt2004/main-en.pdf 1109936276 M * prae it's a good presentation of vserver 1109936336 M * prae hmmm 1109936337 M * FEN_HIN is it same presentation with virtual-server.pdf ? 1109936344 M * prae i don't know 1109936348 M * erwan_taf prae: sound good 1109936355 M * prae but ... in page 34 ... 1109936360 M * erwan_taf prae: please send the link to the ml :) 1109936364 M * prae i don't like this :| 1109936383 M * prae "infiltration foreign chroots" 1109936394 M * prae "root-rights for 'red' in 'wwww' 1109936414 M * FEN_HIN i see 1109936423 M * prae * Unsolved in vserver; perhaps preventable with SELinux or partly with namespaces 1109936425 M * prae :'( 1109936428 M * prae with grsec ?! 1109937236 M * FEN_HIN . 1109937240 M * FEN_HIN so quite 1109940107 M * prae I'm afraiiiiiiiddd when it's so quiteeee 1109940108 M * prae :) 1109940684 M * FEN_HIN ehehehhe 1109940688 M * FEN_HIN why ? 1109941008 M * prae I tell you something ... 1109941010 M * prae I ... 1109941015 M * prae I see dead people 1109941019 M * erwan_taf :b 1109941030 A * erwan_taf wave its arms 1109941031 M * erwan_taf \\o 1109941033 M * erwan_taf o// 1109941039 M * erwan_taf prae: do you see me ? 1109941050 M * erwan_taf I'm alive 1109941051 M * erwan_taf :b 1109941069 M * prae you .... are dead 1109941087 M * prae but you don't know it 1109941132 M * erwan_taf arrrrrg 1109941262 M * prae rest in peace, dear erwan ! 1109941512 J * kjo_ ~kjo@193.159.216.61 1109941643 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1109941725 M * FEN_HIN heuheuheue 1109942821 J * FEN_HIN__ ~JFOC@latarius.tkdgroup.com 1109942824 Q * FEN_HIN Read error: Connection reset by peer 1109942955 Q * IrishKitty Read error: Operation timed out 1109943726 Q * FEN_HIN__ Ping timeout: 480 seconds 1109944934 Q * mhepp Quit: mhepp caught signal: Autobus error 1109945385 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1109945569 Q * mhepp Quit: 1109946026 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1109946351 J * turtle- ~turtle500@210-85-23-143.cm.dynamic.apol.com.tw 1109946450 Q * mhepp Quit: mhepp caught signal: Autobus error 1109946459 J * mhepp ~mhepp@r30s12p13.home.nbox.cz 1109946713 P * turtle- 1109947577 Q * mhepp Quit: KVIrc 3.0.1.99 'Realia' 1109949874 J * monrad ~monrad@213083190130.sonofon.dk 1109949934 J * peet ~del@rein57.demon.nl 1109951733 Q * _are_ Quit: Disconnecting 1109952675 Q * lilo Quit: bbiab 1109952794 N * Bertl_zZ Bertl 1109952803 M * Bertl morning folks! 1109953203 P * peet Client Exiting 1109953295 M * Bertl prae: especially worried about chroot escape scenarios? 1109953424 M * prae yes 1109953519 M * Bertl well, I can assure you, that scenarios as Enrico painted them are not very realistic, because they all require support from the host side 1109953550 M * Bertl aside from that, the namespaces used in recent kernels do not allow for such 'changes' at all 1109953575 M * prae Have you seen my mail with loop-AES ? 1109953602 M * Bertl so a 1.9.x default (newstyle) server will not have any directory above it's root 1109953607 M * Bertl yes I read it ... 1109953694 M * Bertl and yes, it's probably possible, but only if he a) has access to the other loop device and b) knows the key (given the the loop device is mounted _inside_ the namespace) 1109953888 M * Bertl (does this answer your question?) 1109953932 M * prae so, If he hasn't access to other loop device (/dev/loop/* into MAIN), hacker can't read another vserver (hacker is in vserver) 1109953971 M * Bertl not unless he manages to 'switch' the namespace ... 1109954004 M * prae I have a problem with "namespace" definition 1109954050 M * Bertl it's basically a dentry tree based on vfsmounts 1109954091 M * Bertl i.e. a root vfsmount starts with a number of dentries below it, which can be attachment points to other vfsentries 1109954135 M * Bertl every vserver with a separate namespace (all new style vservers) has a separate tree 1109954205 M * Bertl maybe an example here: 1109954259 M * Bertl let's forget about the chroot and stuff, just consider two namespaces starting with / 1109954301 M * Bertl if you do 'mount /dev/some /mnt' in namespace A, then namespace B will still see an empty /mnt 1109954336 M * Bertl (the vfsmount added in namespace A is not present in namespace B) 1109954370 Q * erwan_taf Quit: Leaving 1109954477 M * prae so, when you say "the loop device is mounted _inside_ the namespace", you say "only if the loop device is mounted from vserver" ? 1109954501 M * Bertl not necessarily, but from the vservers namespace, that is 1109954530 M * prae *lost in space* 1109954534 M * Bertl if you do the mount in the hosts namespace, then this and any derived namespace, might be able to see it 1109954635 M * Bertl look, if you are _really_that concerned, why not start developing an exploit? that will help you to understand the mechanisms and at the same time verify that it works as expected ;) 1109954680 M * prae why not :p 1109954761 M * prae thanks for your answer :) 1109954852 M * Bertl you're welcome! 1109955686 J * lilo ~lilo@lilo.usercloak.oftc.net 1109955765 M * Bertl wb lilo! 1109956773 Q * DuckMaster Ping timeout: 480 seconds 1109957473 J * _are_ ~are@dsl-084-056-162-241.arcor-ip.net 1109957596 Q * sannes Read error: Operation timed out 1109958316 M * prae See'ya ! 1109958324 M * Bertl cya! 1109958331 Q * prae Quit: Client exiting 1109958390 Q * BWare Read error: Operation timed out 1109958743 Q * kjo_ Quit: Verlassend 1109958942 M * Bertl okay, off for now, back later ... 1109958946 N * Bertl Bertl_oO 1109960351 J * DaPhreak ~DaPhreak@pD9FB5356.dip.t-dialin.net 1109960459 Q * DaPhreak Quit: 1109961248 N * Doener|gone Doener 1109962384 J * vex vdjerek@sshfd.phy.hr 1109962394 M * vex hi everyone! 1109962430 J * DuckMaster ~Duck@dyn-83-157-160-69.ppp.tiscali.fr 1109962459 M * vex i've got a soft of a problem...not directly with the vserver, that turned to work perfectly :) 1109962504 M * vex i don't know how to tell portmap, nfs and rpc daemons to listen only on the host ip... 1109962553 M * vex i managed to kill everything except ports 111,950,954 and 2049 1109962575 M * vex anyone has a clue? 1109962613 M * daniel_hozac do you really need to run those services on the host as well? 1109962642 M * vex yes, i really do. that server exports his /var/mail to the public server, and mounts /home via the nfs :( 1109962644 M * daniel_hozac there is a patch for portmap though, that adds an -l option to just bind it to lo. 1109962666 M * vex yes, i know that. but i need portmap both on 127.0.0.1 and 192.168.0.2 1109962699 M * vex i guess i could firewall that ports, but then i can forget about nfs inside vservers 1109962712 M * daniel_hozac i guess you're in for some patching then. 1109962721 M * vex :) 1109962750 M * vex nevermind, i don't really need nfs inside a vserver. i could always use samba instead 1109962793 M * vex but it would be nice to have a perfectly clean host that listens only what it should, though 1109962820 M * daniel_hozac so why are you running services on the host at all? 1109962849 Q * duckx Ping timeout: 480 seconds 1109962881 M * vex well, i'm short on servers, and i need to run a bunch of websites that will use potentially harmful php scripts... 1109962910 M * vex and i need user management limited to those websites...i don't want tens of users on my secured server 1109962954 M * vex so i thought i could just jail the unsecure stuff and forget about it for a while :) 1109963065 M * vex anyway, thanks a lot. see you! 1109963208 Q * vex Quit: [BX] Mr. Peanut uses BitchX. Shouldn't you? 1109964602 J * prae ~prae@sherpadown.net 1109964898 M * prae re :) 1109965386 J * sannes ~ace@home.skarby.no 1109966132 M * prae welcome sannes 1109970218 M * sannes :) 1109971559 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1109971916 Q * monrad Ping timeout: 480 seconds 1109971958 J * monrad ~monrad@213083190130.sonofon.dk 1109972375 J * Pazzo ~thomas@host130-250.pool8172.interbusiness.it 1109972542 M * prae *scare* 1109972577 M * prae *fear* 1109972677 J * Nik ~Nik@cable-153-130.online.bg 1109972689 M * Nik hi all 1109972926 Q * monrad Read error: Operation timed out 1109973055 J * monrad ~monrad@213083190130.sonofon.dk 1109973171 Q * Nik Ping timeout: 480 seconds 1109973303 Q * monrad Quit: 1109974374 J * Nik ~Nik@cable-153-130.online.bg 1109974856 Q * Nik Ping timeout: 480 seconds 1109974960 Q * erwan_ho Remote host closed the connection 1109975471 Q * Pazzo Quit: Download Gaim: http://gaim.sourceforge.net/ 1109978568 Q * prae Quit: Pwet