1124928120 M * Bertl wb Doener! 1124928308 M * litage Bertl: thanks for that info, Bertl. is there any idea as to when ngnet will be stable? 1124928387 M * Bertl no, we had some 'almost working' prototypes ... but I guess it won't be working properly within the next two or three months ... stable, maybe half a year or so ... 1124928408 M * Bertl (unless somebody decides to sponsor ngnet development) 1124928471 M * litage Bertl: what sort of sponsoring are you looking for for the ngnet side of linux-vservers? 1124928524 M * Bertl well, I have to pay my bills too, so I can only reserve so much for linux-vserver ... 1124928527 M * Aiken pre4 is won't compile for me 1124928540 M * Bertl Aiken: what error? 1124928544 M * Aiken fs/inode.c: In function `alloc_inode': 1124928548 M * Aiken fs/inode.c:118: error: structure has no member named `i_dqh' 1124928565 M * Bertl got any rejects? 1124928597 M * Aiken no rejects 1124928612 M * Bertl that's strange ... sec 1124928617 M * litage Bertl: right, so that's why i'm asking what sort of sponsoring would be helpful for this niche of linux-vserver 1124928620 M * Bertl this is on alpha, right? 1124928633 M * Aiken yes 1124928664 M * Bertl litage: you mean what amount would be required to get ngnet done? 1124928691 M * Bertl litage: or in what way you could sponsor development? 1124928804 M * Bertl Aiken: ah, you have quota disabled, right? 1124928899 M * Bertl Aiken: give me a few minutes to fix that up ... download rc7 in the meantime 1124928909 M * Aiken CONFIG_QUOTA? it is disabled 1124928991 M * Bertl litage: basically if somebody pays my bills I can work fulltime on linux-vserver ... 1124929026 M * litage Bertl: what amount (a) would be of more than trivial help for ngnet? and (b) would be required to get ngnet done by the end of 2005? 1124929212 M * Bertl hmm .. my ngnet estimation is about 2-3 man month (including basic testing) so guestimating it would require about 5k EUR to get it done ... considered that we have 4 month left until new year it seems possible to me ... 1124929317 M * litage Bertl: what are the goals of network virtualization? 1124929319 M * Bertl regarding a) every donation basically buys linux-vserver development time ... 1124929356 M * Bertl the idea is to have virtual network devices (those were already tested) which map between guests and host 1124929378 M * Bertl the guest can then have private routing and iptables (to some degree) 1124929401 M * Bertl but in any case fully working network interfaces (like a normal host) 1124929425 M * Bertl this approach will automatically support ipv6 1124929441 M * Bertl (something folks ask for every now and then) 1124929458 M * litage will the network virtualization remove the need for the host to have an ip address? 1124929493 M * Bertl let me put it this way, it can ... 1124929516 M * Bertl the ngnet versions we tested so far allowed that 1124929532 M * litage nice 1124929570 M * Bertl litage: why is the ip less host _that_ important to you, if I may ask? 1124929694 M * litage a log server with no ip address is a very nice machine =) 1124929730 M * Bertl hmm .. and what would you log there? and how? via pipes? unix sockets? 1124929758 M * Bertl so basically you want to supervise the guests, right? 1124929765 Q * neofutur_ Remote host closed the connection 1124929783 M * litage Bertl: promiscuous sniffing 1124929865 J * neofutur ~neofutur@neofutur.net 1124929871 M * Bertl wb neofutur! 1124929892 M * Bertl litage: hmm .. do you want to elaborate? 1124930130 M * litage Bertl: sure. bbiab though 1124930138 M * Bertl np 1124930304 M * Bertl Aiken: http://vserver.13thfloor.at/Experimental/patch-2.6.13-rc7-vs2.1.0-pre4.diff.bz2 1124930325 M * Bertl (you can leave quota disabled with that one) 1124930426 M * litage Bertl: an ip-less log server is useful because without an ip address, a network intruder won't be able to tamper with logs on the log server 1124930458 M * litage Bertl: the log server will obtain logs from other machines on the network by sniffing for log messages sent to a particular ip address that doesn't exist 1124930487 M * litage Bertl: the machines sending the log messages are configured to send their messages to a single, specific ip address that doesn't exist 1124930502 M * Bertl hmm, okay, and what part plays linux-vserver here? 1124930515 M * daniel_hozac and how would the other hosts know that the non-existant IP belongs to that host? 1124930532 M * Bertl static arp 1124930564 M * Bertl (or you could use broadcast ips/macs) 1124930575 M * daniel_hozac ah, right, broadcasts. 1124930615 M * litage Bertl: my organization has a limited amount of hardware. we're interested in running the log server (ip-less) on a machine that will be running vservers 1124930629 M * daniel_hozac but if the logger only does logging anyway, the same risks apply to that as to one with an IP address, no? 1124930637 J * sig ~sig_miche@S0106000f66254626.cg.shawcable.net 1124930644 M * Bertl welcome sig! 1124930653 M * sig hi 1124930662 M * Aiken got the patches 1124930671 M * litage daniel_hozac: how so? if the logger has no ip address, it's inaccessible from the network 1124930681 M * daniel_hozac .. but it's listening to the network. 1124930688 M * daniel_hozac so you can still exploit it. 1124930702 M * Bertl litage: if it has an ip address, but no services, it's probably equivalent 1124930718 M * litage Bertl: right, but the logger has no ip address 1124930803 M * Bertl hmm, I guess you can already do what you want ... 1124930832 M * Bertl if you do not 'dedicate' any ip to the host system 1124930845 M * Bertl (just a bunch of different ips for the guests) 1124930871 M * litage Bertl: but if the host has the ip address of each vserver, then the host is accessible on the network, which defeats the purpose of an ip-less logger 1124930873 M * Bertl then you basically get what you describe ... no 'host' specific ip (just ips for the guests) 1124930873 M * daniel_hozac won't the primary/secondary stuff screw things up if you restart vservers? (or did i misunderstand that issue?) 1124930927 M * Bertl litage: if you run guests on that server, the one and only kernel will always be accessible via the guest ips, no? 1124930953 M * Bertl (but no service outside a guest will run) 1124930996 M * litage Bertl: hrm that's true. the kernel will be accessible 1124931178 Q * alexx Ping timeout: 480 seconds 1124931345 J * alexx ~alexx@proxy.ikse.net 1124931752 M * Bertl litage: why not have some pretty good firewall on the log server, just allowing for certain 'special' log messages? 1124931815 M * litage Bertl: it's safer to prevent all connections to the logger 1124931842 M * litage Bertl: that way, *nothing* can gain access to the logger 1124931868 M * Bertl ok, so you're still interested :) 1124931938 M * litage Bertl: heheh yup. not to be a kill-joy, but don't get excited about sponsorship, cuz i think it'd be a hard sell to management to fund this :( 1124932064 M * Bertl don't worry, I do not expect anything ... 1124932097 M * litage :) 1124932119 M * Bertl this way I can only be positively suprised, not disappointed :) 1124932171 M * Aiken Berlt I'll be back in an hour or so to see if the new kernel OOPs, it is going to take that long to compile 1124932186 M * Bertl okay .. np 1124932238 M * Aiken also building a cross alpha tool chain so I don't have to wait so long next time 1124932264 M * Bertl good idea :) 1124932310 M * Aiken 433 alpha, xp2100 - I wonder which will compile a kernel quicker :) 1124932366 M * litage Bertl: that's exactly my philosophy, too 1124932418 Q * duckx Ping timeout: 480 seconds 1124932489 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1124932523 Q * mugwump Ping timeout: 480 seconds 1124932677 M * Aiken so much for me going 1124932691 M * Aiken I added #include to kernel/vserver/helper.c 1124932724 M * Aiken with out it include/asm-generic/emergency-restart.h dies with a NULL undefined error 1124932737 M * Aiken and the error message traces back to helper.c 1124932757 M * Bertl hmm .. 1124932765 M * Aiken the include was to get NULL defined 1124932789 M * Aiken CC kernel/vserver/helper.o 1124932792 M * Aiken In file included from include/asm/emergency-restart.h:4, 1124932792 M * Aiken from include/linux/reboot.h:72, 1124932792 M * Aiken from kernel/vserver/helper.c:14: 1124932792 M * Aiken include/asm-generic/emergency-restart.h: In function `machine_emergency_restart': 1124932792 M * Aiken include/asm-generic/emergency-restart.h:6: error: `NULL' undeclared (first use in this function) 1124932794 M * Aiken include/asm-generic/emergency-restart.h:6: error: (Each undeclared identifier is reported only once 1124932795 M * Aiken include/asm-generic/emergency-restart.h:6: error: for each function it appears in.) 1124932818 M * Bertl cool! 1124932855 M * Bertl okay, will add that ... 1124932883 M * daniel_hozac litage: for the logger to log events that did not happen to itself, it would have to communicate with the world, no? 1124933168 M * sig Anyone mind if I take the floor? 1124933229 M * litage daniel_hozac: the logger can simply listen promiscuously 1124933277 M * daniel_hozac litage: but then you have the same access as you would should it be a properly firewalled host. 1124933288 M * daniel_hozac sig: just jump in ;) 1124933321 M * sig thanks 1124933394 M * sig Not sure who here is on the mailing list but I posted re:unable to stop the vserver after upgrade 1124933430 M * sig should I recap? 1124933431 M * Bertl sig: and I answered :) 1124933466 M * litage daniel_hozac: nope. since the logger has no ip address, nothing can connect to it. however, since it's sitting on the network and its NIC is in promiscuous mode, it can read packets that are flying around the network 1124933472 M * Bertl sig: so you are here now, let's investigate :) 1124933490 M * daniel_hozac litage: and as such, the service listening can be exploited. 1124933537 M * Bertl sig: first step: http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh (please upload the output to pastebin.com or similar) 1124933585 M * litage daniel_hozac: the logger will be as exploitable as whichever sniffer is exploitable 1124933591 M * sig will do 1124933592 M * daniel_hozac litage: == equivalent to a properly firewalled host. 1124933654 Q * stephenM Ping timeout: 480 seconds 1124933783 M * litage daniel_hozac: not really, since a "properly firewalled host" will be exploitable in other ways, eg: via the firewall software 1124933796 M * sig Bertl: here it is http://magnuson.ca/testme.out 1124933811 M * daniel_hozac litage: ok, so a host with only the logging service running on it. 1124933818 M * Bertl sig: tx! 1124933819 M * daniel_hozac you don't even need the firewall in that case. 1124933851 M * Bertl sig: okay, what does vserver-stat show? 1124933852 M * litage daniel_hozac: with no ip address, you're correct: you don't need a firewall since there aren't any incoming packets 1124933869 M * daniel_hozac a quick run of my fedora-announce archives show no sysklogd security update, while having 6 tcpdump security updates... 1124933905 M * sig sudo vserver-stat 1124933905 M * sig CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1124933905 M * sig 0 48 55.3M 17.8M 1m10s10 0m50s15 1d09h49 root server 1124933905 M * sig 10 4 7.6M 3.1M 0m00s24 0m00s40 1d09h49 vcruxtemplate01 1124933923 M * Bertl and #10 is the problematic one? 1124933947 M * sig yes, everything seems to run fine, but can't stop the thing 1124933997 M * Bertl so, you start it quite fine, no warnings or errors, right? 1124934001 M * sig right 1124934025 M * Bertl and when you stop it, the command hangs ... 1124934026 M * daniel_hozac litage: and you will still receive broadcasts. (as would be required to get the logging packets) 1124934051 M * Bertl sig: how long did you wait for it to finish? 1124934071 M * sig yup cli never returns, vserver never stops. 1124934079 M * sig 5min, perhaps more 1124934127 M * sig here is a trace of the stop: http://magnuson.ca/vserver.log.txt 1124934135 M * sig from yesterday 1124934137 M * Bertl sig: okay, let's force kill it now with vkill --xid 10 -- 0 1124934184 M * Bertl (after that, check with vserver-stat) 1124934200 M * sig still running 1124934205 M * sig sudo vserver-stat 1124934206 M * sig CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1124934206 M * sig 0 48 55.3M 17.8M 1m10s35 0m50s58 1d09h55 root server 1124934206 M * sig 10 1 1.4M 496K 0m00s20 0m00s12 1d09h54 vcruxtemplate01 1124934206 M * sig sig@calvunix01 ~ 1124934206 M * sig :sudo vkill --xid 10 -- 0 1124934206 M * sig sig@calvunix01 ~ 1124934208 M * sig :sudo vserver-stat 1124934208 M * sig CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1124934210 M * sig 0 48 55.3M 17.8M 1m10s35 0m50s60 1d09h55 root server 1124934210 M * sig 10 1 1.4M 496K 0m00s20 0m00s12 1d09h54 vcruxtemplate01 1124934235 M * sig VSZ is down 1124934249 M * Bertl okay, let's see what it is running with 'chcontext --xid 10 ps auxwww' 1124934279 M * sig sudo chcontext --xid 10 ps auxwww 1124934279 M * sig USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1124934279 M * sig root 1 0.0 0.0 1472 496 ? S Aug23 0:00 init [2] 1124934279 M * sig root 29436 0.0 0.0 2300 776 pts/0 R+ 19:44 0:00 ps auxwww 1124934326 M * Bertl is the init identical with the hosts init (check start time) 1124934468 M * sig yes 1124934520 M * Bertl hmm, interesting ... okay, please could you upload the contents of /proc/virtual/10 (best with cat /proc/virtual/10/*) 1124934627 M * sig http://magnuson.ca/proc.txt 1124934633 M * Bertl tx 1124934711 M * Bertl okay, let's check for hanging helper ... with 'vps auxwww | grep helper' 1124934740 M * sig sudo vps auxwww | grep helper 1124934740 M * sig root 4 0 MAIN 0.0 0.0 0 0 ? S< Aug23 0:00 [khelper] 1124934740 M * sig sig 29465 0 MAIN 0.0 0.0 1512 436 pts/0 S+ 19:52 0:00 grep helper 1124934811 M * Bertl hmm, okay, let's try 'vps auxwww | grep -v MAIN' 1124934839 M * sig sudo vps auxwww | grep -v MAIN 1124934840 M * sig USER PID CONTEXT %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1124934840 M * sig root 193 10 vcruxtemplate01 0.0 0.0 1472 496 ? Ss Aug23 0:00 init [2] 1124934840 M * sig root 29483 1 ALL_PROC 0.0 0.0 1528 348 pts/0 S+ 19:53 0:00 vps auxwww 1124934840 M * sig root 29485 1 ALL_PROC 0.0 0.0 2304 784 pts/0 R+ 19:53 0:00 ps auxwww 1124934862 M * Bertl hmm, so we have a real init it seems ... 1124934899 M * Bertl let's try 'vkill --xid 10 -s 9 -- 1' 1124934936 M * Bertl (again, check with vserver-stat) 1124934951 M * sig sudo vserver-stat 1124934951 M * sig CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1124934951 M * sig 0 48 55.4M 17.9M 1m10s53 0m51s70 1d10h07 root server 1124934951 M * sig 10 1 1.4M 496K 0m00s20 0m00s12 1d10h06 vcruxtemplate01 1124934951 M * sig :sudo vkill --xid 10 -s 9 -- 1 1124934952 M * sig :sudo vserver-stat 1124934952 M * sig CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1124934954 M * sig 0 32 34.1M 12.9M 1m10s58 0m51s26 1d10h07 root server 1124934969 M * Bertl so that eliminated it .. right? 1124934975 M * sig yup 1124934999 M * Bertl the tools should do that by default ... 1124935012 M * Bertl but obviously they don't ... 1124935051 M * Bertl do you have debugging compiled into the kernel, especially the VSERVER_DEBUG* stuff? 1124935081 M * sig no 1124935101 M * sig when I try to start the vserver: 1124935102 M * sig sudo /etc/rc.d/vcruxtemplate01 start 1124935103 M * sig RTNETLINK answers: File exists 1124935124 M * Bertl do you want to investigate this further, or is this sufficient for you? (you could hack around the kill issue by adding a custom stop script) 1124935183 M * sig yup to you, it's your time I'm using :) 1124935206 M * Bertl well, I'd prefer to investigate it a little further ... 1124935217 M * Bertl but that would require to enable debugging ... 1124935224 M * sig I can do that 1124935231 M * sig will start now 1124935244 M * Bertl okay, then please enable the following config options (kernel): 1124935260 M * Bertl CONFIG_VSERVER_DEBUG=y 1124935265 M * Bertl CONFIG_VSERVER_HISTORY=y 1124935270 J * Loki|muh_ loki@satanix.de 1124935271 M * Bertl CONFIG_VSERVER_HISTORY_SIZE=64 1124935275 M * Bertl welcome Loki|muh_! 1124935363 Q * Loki|muh Read error: Connection reset by peer 1124935366 M * Bertl sig: and I'd suggest to reinstall the tools, just to make sure ... 1124935388 M * Bertl sig: did you build them from scratch? 1124935410 M * Bertl ah, and please use dietlibc ... 1124935486 M * sig yeah I built tool from scratch, tried with and without patch-0.30.208-fix02.diff 1124935503 M * Bertl okay, then first do a 'make uninstall' 1124935526 M * Bertl then rebuild with dietlibc, and 'make install' again 1124935545 M * Bertl it will inform you then that you should do a distro-install or something like that 1124935552 M * Bertl (do as advised there) 1124935611 M * sig I did see that but have never needed to do that before (1.9X), now necessary? 1124935637 M * Bertl I don't think so, but just to make sure .. we can narrow it down later ... 1124936130 M * Aiken just rebooting 1124936314 M * Aiken one OOPS :( 1124936334 M * Bertl Aiken: okay, debug is compiled in I hope? 1124936366 M * Bertl (the vserver debug I mean) 1124936424 M * Aiken http://pastebin.com/345615 1124936428 M * Aiken yes 1124936447 M * Bertl okay, please try again, just before you 'crash' it, do: 1124936448 M * Aiken I have stopped using nfs and network block devices 1124936460 M * Aiken I have everything local to the machine this time 1124936479 M * Bertl echo 255 >/proc/sys/vserver/debug_misc 1124936481 M * Aiken /usr/sbin/vserver: line 691: 1062 Segmentation fault $_CHROOT_SH truncate /etc/mtab <"$mtab_src" 1124936507 M * Aiken I also get the above line and a status D process that the only way I can get rid of it is to reboot 1124936527 M * Bertl yep, that's expected 1124936546 M * Aiken just waiting for the machine to come back up 1124936605 M * Aiken lot more stuff came up 1124936628 M * Bertl is it readable or too much? 1124936639 M * Aiken read able 1124936644 M * Bertl excellent! 1124936656 M * Aiken http://pastebin.com/345617 1124936965 M * Aiken directory listing http://pastebin.com/345621 1124936976 M * Aiken notice the many mtab files 1124937005 M * Bertl yeah, good that I reduced the number :) 1124937036 M * Bertl in the first version I allowed all chars down to ascii 32 :) 1124937048 M * Aiken mtab is a symlink 1124937054 M * Aiken or was 1124937060 M * Bertl bingo! 1124937068 M * Aiken I just made it a real file and the cow vserver started 1124937101 M * Bertl now the question is, did the symlink have COW attributes? or was it the real file ... 1124937137 M * Bertl i.e. can we try again with a newly created symlink to the same destination as before? 1124937156 M * Bertl (and please remove the other mtab files) 1124937218 M * Aiken I used find russell -type f -exec setattr --iunlink {} ';' 1124937239 M * Aiken so symlinks should not have been touched 1124937278 Q * alexx Ping timeout: 480 seconds 1124937322 J * alexx ~alexx@proxy.ikse.net 1124937339 M * Aiken after this reboot :( 1124937555 M * Aiken and this reboot 1124937569 M * Bertl hmm? 1124937701 M * Aiken still goes spat with a normal host created sym link 1124937721 M * Bertl okay, where does the symlink point to? 1124937725 M * Aiken for awhile I have had mtab as a symlink to /proc/mounts 1124937737 M * Bertl is this still the case? 1124937749 M * Aiken I am aware there are arguements againts this but it has always worked better for me than mtab being a real file 1124937750 M * Aiken yes 1124937752 M * Aiken it is 1124937763 M * Bertl okay, that sound easy to test ... 1124937782 M * Bertl sec, let me try to recreate your scenario .. 1124937808 M * Aiken I played with another symlink to a normal file and it was ok 1124937819 Q * litage Remote host closed the connection 1124937834 M * Aiken I am wondering if it is just the symlink to proc 1124938020 M * Bertl Aiken: could you do: showattr /vservers//etc/mtab and showattr /proc/mounts for me? 1124938096 M * Aiken Awh-ui- /proc/mounts 1124938100 M * Aiken ----ui- /vservers/russell/etc/mtab 1124938246 M * Bertl okay, I still don't understand why the COW condition triggers in your case, but I guess I know what happens ... 1124938295 M * Bertl the symlink is basically transparent to the COW, the flags are checked on the destination (where the symlink points to) 1124938309 M * Bertl which is incorrect! 1124938330 M * Bertl well, it's correct, but it requires a different copy approach 1124938366 M * Bertl let me check something ... 1124938417 M * Aiken the /proc/mounts should that been the host or vserver? 1124938430 M * Bertl host is fine .. 1124938528 M * Bertl hehe, I can reproduce it without proc 1124938539 M * Bertl mkdir /tmp/X 1124938539 M * Bertl touch /tmp/X/a 1124938539 M * Bertl ln /tmp/X/a /tmp/X/b 1124938539 M * Bertl ln -s /tmp/X/a /tmp/y 1124938539 M * Bertl setattr --iunlink /tmp/X/a 1124938541 M * Bertl echo 255 >/proc/sys/vserver/debug_misc 1124938544 M * Bertl echo "test" >/tmp/y 1124938626 M * Aiken (root@pebbles) echo "test" >/tmp/y 1124938629 M * Aiken Connection to pebbles.bedrock closed. 1124938638 M * Bertl [ 131.894295] kernel BUG at fs/namei.c:1235! 1124938644 M * Aiken and recorded the OOPS 1124938671 M * Bertl yeah, now the interesting question is how to handle this properly 1124938671 M * Aiken Aug 25 12:56:54 localhost kernel: Kernel bug at fs/namei.c:1235 1124938711 M * Bertl we do the copy in the wrong directory ... 1124939048 M * Aiken have you tried doing a ls /tmp lately? 1124939072 M * Bertl well, my tmp vanishes on reboot (test setup) 1124939101 M * Bertl but I suspect a /tmp/y© there 1124939127 M * Aiken on that machine /tmp is real instead of tmpfs, I get a OOPS everytime I try ls /tmp now :( 1124939158 M * Bertl hmm ... 1124939163 M * Bertl same oops? 1124939201 M * Aiken mabe not, there are only 2 oops 1124939224 M * Aiken back shorty, it is a reset button job :( 1124939236 M * Bertl *brrr* 1124939294 M * sig Bertl: Have reinstalled, and can now stop the vserver 1124939305 M * sig It appears to be dietlibc 1124939313 M * Bertl okay, good to know ... 1124939313 Q * duckx Ping timeout: 480 seconds 1124939326 M * sig I have removed it and now vserver won't stop again 1124939328 M * Bertl sig: anyway, can't hurt to file a bugreport to savannah ... 1124939342 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1124939366 M * Bertl http://savannah.nongnu.org/projects/util-vserver 1124939391 M * Bertl (although I doubt that Enrico will address it soon) 1124939461 M * Bertl sig: ah, and could you pretty, pretty, please follow up yourML thread and let the folks know how it was resolved ... (for the archives) 1124939521 M * sig The warnings about not using dietlibc are not stong enough :) 1124939535 M * sig someone should put a !!!! behind it :) 1124939540 M * sig wil do 1124939547 M * Bertl yeah :) thanks! 1124939561 M * sig thanks a bunch for your time, much appreciated 1124939570 M * Bertl you're welcome! 1124939597 M * Aiken Bertl I have a resuce partition I set up just in case, booted with that 1124939602 M * Aiken (root@pebbles) rm -rf X 1124939605 M * Aiken rm: cannot remove `X/a': Operation not permitted 1124939605 M * Aiken rm: cannot remove `X/b': Operation not permitted 1124939618 M * Bertl that's fine .. I guess ... 1124939632 M * Bertl try chattr -i X/a 1124939650 M * Aiken cool, that did it 1124939674 M * Bertl it's the immutable part of the immu-unlink that kept you from removing it 1124939690 M * Bertl as you booted a non vserver kernel the iunlink part was not active 1124939708 M * Aiken ok 1124939792 M * Aiken was only the one oops before 1124939922 J * _Hunger Hunger.hu@Hunger.hu 1124939932 M * Bertl welcome _Hunger! 1124939954 Q * Hunger Read error: Connection reset by peer 1124940246 N * _Hunger Hunger 1124941600 M * locksy Has anyone had problems connecting to mysql running inside a vserver? 1124941630 M * Bertl what kind of problems do you encounter? 1124941657 M * Bertl permission issues? 1124942229 M * Bertl Aiken: okay, guess I fixed it :) 1124942372 M * Aiken cool 1124942377 M * Aiken I am ready to try it 1124942414 M * Bertl http://vserver.13thfloor.at/Experimental/delta-2.6.13-rc7-vs2.1.0-pre4.1.diff 1124942422 M * Bertl (includes the helper include) 1124942455 M * Bertl (i.e. the second hunk will fail for you, but that's fine) 1124942529 M * Aiken patching file fs/namei.c 1124942533 M * Aiken patching file kernel/vserver/helper.c 1124942533 M * Aiken Hunk #1 succeeded at 15 (offset 1 line). 1124942549 M * Bertl ah, well .. won't hurt :) 1124942561 M * Aiken I like --dry-run 1124942649 M * Aiken I had stddef before reboot.h 1124942676 M * Aiken having it after reboot.h leaves me with the NULL undefined error 1124942767 M * Bertl ah, okay ... 1124942802 M * Bertl heh, so the NULL issue happens outside the vserver files? 1124942832 M * Bertl will test this now ... 1124942876 M * Aiken http://pastebin.com/345664 1124942906 M * Aiken the offending file is asm-generic/emergency-restart.h 1124942980 M * Aiken I am still trying to workout exactly where NULL should have been defined (included) 1124942999 M * Bertl don't worry, I'll track this down ... 1124943110 M * Aiken hoppy is the reall image (260 meg), avon is the hardlink copy (3 meg) 1124943119 M * Aiken avon just started without error :) 1124943137 M * Bertl excellent! 1124943190 M * Aiken not sure if I should also be running the master copy or not 1124943219 M * Bertl you could make another copy and start that too 1124943234 M * Aiken oh 1124943269 M * Aiken have a new oops 1124943331 Q * micah Quit: leaving 1124943335 J * micah micah@micha.hampshire.edu 1124943355 M * Aiken I had entered the master copy and got this when I hit ctrl-d to exit http://pastebin.com/345669 1124943378 M * Aiken rebooting 1124943382 Q * micah Quit: 1124943385 J * micah micah@micha.hampshire.edu 1124943473 M * Bertl hmm .. probably an unhandled error path ... 1124943491 Q * keyser_soze Quit: Abandonando 1124943525 M * Aiken rebuilding the vservers, I'll leave the master alone and start up 2 cows 1124943548 M * Bertl Aiken: I'd need a objdump -d (of the cow_break_link only) 1124943636 M * Bertl objdump -d vmlinux | grep -A 500 'cow_break_link>:' (or similar) 1124943764 M * Aiken getting that now 1124943864 M * Aiken I'll email it 1124943888 M * Bertl hmm .. okay ... 1124943926 M * Aiken I don't feel like pasting 454 lines into pastebin 1124943968 M * Bertl yeah, it's fine ... 1124944081 M * Bertl Aiken: moving the reboot.h include two lines down fixes the issue :) 1124944127 M * Aiken cool 1124944490 M * Aiken compiled cleanlt for me 1124944765 M * Bertl good, hmm, could you use addr2line on the kernel which last oopsed with the ra and pc addresses? 1124945173 M * Aiken all I am getting in ??:0 1124945191 M * Bertl hrmpf, again? 1124945241 M * Bertl I suspect that we are missing something ... 1124945263 M * Bertl could you try with c00003a543c instead? 1124945293 M * Aiken (root@pebbles) addr2line -e vmlinux c00003a543c 1124945296 M * Aiken ??:0 1124945359 M * Bertl hmm, must be something with your compile options ... 1124945361 M * Bertl alpha-linux-addr2line -e vmlinux fffffc00003a543c 1124945363 M * Bertl fs/namei.c:767 1124945420 M * Bertl could you send me your .config? 1124945503 M * Aiken done 1124945511 M * Bertl tx 1124945637 M * Aiken would it be DEBUG_INFO? 1124945641 M * Aiken which is not set 1124945653 M * Bertl probably ... 1124945943 M * Bertl hmm, seems your last email was delayed by my greylisting ... 1124945970 M * Bertl (funny that you send via different mailers :) 1124946001 M * Aiken ? 1124946026 M * Aiken same machine, same client, same mail server (both local and isp) each time 1124946107 M * Bertl mail28.syd.optusnet.com.au, fallbackmx02.syd.optusnet.com.au 1124946123 M * Bertl last one I got from mail12.syd.optusnet.com.au :) 1124946153 M * Aiken wonder if mail.optusnet.com.au is a load balancer 1124946315 M * Bertl okay, I guess we continue tomorrow, when I get your email :/ 1124946359 M * Bertl and thanks for testing ... I updated your Hall'o'Fame entry ... 1124946387 M * Bertl okay, off to bed now ... back tomorrow ... 1124946399 N * Bertl Bertl_zZ 1124946658 M * Aiken you should have the config sometime, it has left my system 1124946664 M * Aiken good night 1124946713 Q * sig Quit: 1124947554 J * keyser_soze ~cimarron@host30.201-252-10.telecom.net.ar 1124947559 Q * keyser_soze Quit: 1124953184 J * Neubix ~brian@p54B06B88.dip.t-dialin.net 1124955544 J * Aiken_ ~james@tooax8-214.dialup.optusnet.com.au 1124955848 Q * Aiken Ping timeout: 480 seconds 1124958554 J * comdata ~mertins@mx01.scheller.de 1124958571 Q * Aiken_ Quit: Leaving 1124959340 Q * mnemoc Read error: Operation timed out 1124959366 J * mnemoc ~amery@200.75.27.72 1124959942 J * ntrs ~ntrs@Dardeene-68.188.50.87.charter-stl.com 1124959942 Q * ntrs_ Read error: Connection reset by peer 1124965152 J * renihs ~renihs___@193.170.52.70 1124966574 Q * pzYsTorM Ping timeout: 480 seconds 1124969853 Q * lonewolff Quit: leaving 1124970272 M * renihs hmm is it possible to have ssh running on the vserver host AND on the guest on the same ports? (different ips?, i set sshd_config Listenadress in the guest and host to a specific ip/port but it claims already used) 1124970286 M * renihs i guess i should listen on different ports and dnat? 1124970345 M * TheSeer no 1124970356 M * TheSeer each guest and the host have its own ip 1124970372 M * TheSeer you need to make sure the host-sshd only binds to the host-ip 1124970382 M * TheSeer not to * or any ip used by a guest 1124970391 M * renihs hmm i tried to set in guest ListenAdress: 192.168.5.100:22 , and on host :22 1124970405 M * renihs the hosts only listens on its public (not 0.0.0.0) 1124970417 M * renihs hmm 1124970422 M * TheSeer then it should work 1124970432 M * renihs aah 1124970443 M * renihs i should maybe stop the vserver or its still in its context or whatever 1124970467 M * TheSeer the vserver shouldn't have a problem 1124970488 Q * atsab Ping timeout: 480 seconds 1124970498 M * TheSeer you'd have to restart the host-sshd though to get it use the modified setup 1124970504 M * renihs yap 1124970504 M * TheSeer in case it was set to listen to * first 1124970505 M * renihs i did 1124970509 M * renihs it was :) 1124970528 M * TheSeer then it should be happy ;> 1124970539 M * renihs hmm strange, HOST: tcp 0 0 193.170.xxx.xxx:22 0.0.0.0:* 1124970707 M * BWare You dont' have to specify the port after ListenAddress 1124970734 M * BWare You specify the Listen port with the Port option 1124970734 M * renihs hmm i know but i shouldnt harm? 1124970739 M * renihs ListenAddress 192.168.5.100:22 1124970745 M * renihs for example (guest) 1124970746 M * BWare Skip the :22 1124970748 M * renihs k 1124970758 M * BWare And use Port 22 1124970767 M * renihs that did the trick :) 1124970769 M * TheSeer which would be redundant ;> 1124970774 M * renihs hehe thx 1124970777 M * BWare y/w 1124971350 Q * Neubix Quit: Verlassend 1124971921 J * lonewolff ~lonewolff@host86-128-17-74.range86-128.btcentralplus.com 1124974777 J * keyser_soze ~cimarron@host241.201-252-63.telecom.net.ar 1124976569 N * Bertl_zZ Bertl 1124976578 M * Bertl morning folks! 1124976649 M * BWare morning ;) 1124976694 M * Hollow morning Bertl! 1124976777 M * Hollow Bertl: i updated some of the tools today, but i had problems with bcaps, is it possible one can only disable them, and not enable them again? 1124976854 M * Bertl Hollow: yes, looks like ... 1124976866 M * Hollow why so? 1124976867 M * Bertl we had a similar report on the ML ... 1124976890 M * Bertl I haven't investigated yet ... but it smells like a bug 1124976895 M * Hollow k 1124976915 M * Hollow beside of this vcontext and vflags are working great :) 1124976924 M * Bertl good to hear! 1124976964 M * Bertl btw, I can imagine why we did not allow to raise bcaps back then ... 1124977032 M * Bertl it is an upper limit for the guest processes, which is considered on fork/exec and whenever somebody raises capabilities 1124977072 M * Bertl so even if changed, it will only affect new processes and/or capability settings 1124977135 M * Hollow so, bcaps are always process sepcific? 1124977138 M * Hollow not context specific 1124978215 M * Bertl yep, they are what build up the root vs. nonroot 1124979358 M * Bertl but the bcap setting for a context is an upper limit (hope you didn't get that wrong) 1124981194 Q * keyser_soze Quit: Abandonando 1124981962 M * Bertl Hollow: so, regarding sys_reboot() should I add the flag and delayed helper to the next devel release, for testing? 1124982031 Q * comdata Quit: using sirc version 2.211+KSIRC/1.3.12 1124982105 M * Bertl Hollow, Greek0, Doener: or do we want another discussion round? 1124982147 M * Doener i'm fine with the flag being added 1124983351 M * Greek0 Bertl: always 1124983418 M * Bertl Greek0: guess that was 'pro' discussion round? 1124983470 M * Greek0 yep, I have time 1124983580 M * Greek0 (as always ;) 1124983639 M * Bertl well, it's good that you have time ... we can make good use of it .. the question is more, do we want to discuss the delayed helper/sys_reboot() kills processes flag once again? 1124983673 M * Bertl (or are we done with that, and the only thing left is the implementation in kernel and userspace) 1124983915 M * Greek0 well, one thing I was asking myself is when you thought you'd really need that delayed-killall-from-host logic, in case shutdown of the guest takes too long. It's pretty clear that's used when you shut down the guest from the host, but in what scenario exactly? 1124983950 M * Greek0 I thought it was pretty clear to me, and Hollow seemed like that too, but then he asked some question about it and you seemed that you meaned something different 1124983980 M * Greek0 (well, and just imagine the last sentence in proper english ;) 1124983999 M * Bertl yeah, my english is pretty bad today too .. no idea why :) 1124984045 M * Bertl okay, why do we need/want a wait process which kills off everything after, let's say 30 seconds? 1124984071 M * Bertl simple: because once somebody decided to reboot/halt a context, he doesn't like to wait forever ... 1124984084 M * Greek0 well, that's all pretty clear to me. if you shut down from the host you probably want the context to be killed, either way. 1124984110 M * Bertl right ... 1124984128 M * Greek0 but I thought you need it in all host-shuts-guest-down scenarios, while you stated once that this wasn't strictly the case 1124984276 M * Greek0 or I misinterpreted that, which is also possible.. 1124984319 M * Bertl well, if you do a shutdown/reboot from inside the guest 1124984340 M * Bertl you might just put that under self inflicted if it doesn't reboot it ... 1124984381 M * Greek0 no, you misunderstood me now I think 1124984501 M * Greek0 I'm only talking about the host-shuts-guest-down thing. Is the delayed-killall necessary there in _any_ case (i.e. init-mode)? 1124984553 M * Greek0 init-mode = init-style (to talk in util-vserver terms :) 1124984565 M * Bertl ah, well, I guess yes ... 1124984581 M * Bertl because nobody knows what init _or_ the sysv scripts will do, no? 1124984608 M * Bertl *please ignore nick changes* 1124984616 N * Bertl Bertl_oO 1124984691 N * Bertl_oO Bertl_zZ 1124984847 N * Bertl_zZ Bertl 1124984921 M * Greek0 Bertl_zZ: ok. that's clear then. this was actually what I was thinking all the time, I just thought you had another opinion 1124984939 M * Greek0 must have misunderstood something you said to Hollow.. 1124984973 M * Bertl maybe I was unclear there ... 1124985533 Q * obi Ping timeout: 480 seconds 1124985553 J * obi ~obi@asus.saftware.de 1124986103 Q * obi Ping timeout: 480 seconds 1124986286 J * obi ~obi@asus.saftware.de 1124986386 M * obi re 1124986643 M * Bertl wb obi :) 1124986894 M * Hollow back 1124986903 M * Hollow Bertl: yeah, let's do it! ;) 1124986933 M * Hollow we could also check if init is the only process left and kill it before the 30 sec timeout, no? 1124986959 M * Hollow well, on the other hand... has reboot -f a timeout? 1124986982 M * Hollow s/has/will have/ 1124987068 M * Bertl currently? from inside? 1124987106 M * Hollow in the future from inside 1124987142 M * Bertl reboot -f would result in killing off all processes, no? 1124987227 M * Hollow without a timeout? 1124987244 M * Bertl reboot -f .. per definition without a timeout 1124987251 M * Hollow fine then :) 1124987336 M * Hollow wrt bcaps: upper-limit means noone can raise the capabilities the process has, just lower them, right? 1124987361 M * Hollow and after lowering them, the setting becomes the upper limit 1124987381 M * Bertl upper-limit means, processes can, if they have the proper capability, raise them up to the given bcaps 1124987397 M * Hollow ah 1124987417 M * Bertl CAP_SETPCAP 1124987423 M * Bertl remove any capability in your permitted set from any pid */ 1124987431 M * Bertl *argl* 1124987435 M * Bertl Transfer any capability in your permitted set to any pid, 1124987440 M * Bertl remove any capability in your permitted set from any pid 1124987461 M * Bertl so given that a process has CAP_SETPCAP 1124987481 M * Bertl it can transfer any capability it owns to any other pid 1124987508 M * Bertl when we start a process which is suid root, usually the default cap mask is applied 1124987512 M * Hollow and default caps a process has are those in bcaps? 1124987516 M * Hollow mhm 1124987526 M * Bertl in a linux-vserver guest, the bcap mask is applied too 1124987551 M * Bertl so every cap not set in bcaps will not be set in any suid root process 1124987566 M * Hollow and what about non-suid root? 1124987582 M * Bertl will not affect capabilities 1124987614 M * Hollow i.e.? 1124987625 M * Hollow they donÄt have capabilities? 1124987650 M * Bertl they do not change capabilities ... and usually they will not have many ... 1124987666 M * Hollow they do not or they can not? 1124987673 M * Bertl just try it out, you can read the current capabilites in /proc/self/status 1124987679 M * Hollow k 1124987730 M * Hollow i c 1124987747 M * Hollow so bcaps only limit the root account in the guest.. 1124987813 M * Bertl no, they limit all processes and all cap sets to that 1124987837 M * Bertl i.e. no cap set in any guest process should contain a cap which is not in bcaps 1124987838 M * Hollow well, if non-root processes don't have any caps.. 1124987869 M * Bertl look, root or superuser is just a piece of your imagination, it's all caps, really :) 1124987912 M * Hollow k... ;) 1124987936 M * Bertl no, seriously, the caps are dropped when not needed ... 1124987960 M * Bertl this makes the difference between 'normal' users and adminstrators (root) 1124987962 M * Hollow and who does decide when what cap is not needed? 1124987971 M * Bertl userspace 1124988026 M * Hollow so, e.g., i login via ssh, which is root and probably has many caps lowers the caps of my sshd process? 1124988228 M * Bertl of the shell spawning part, yes 1124988299 M * Hollow k, thx 1124988338 M * Bertl np 1124988583 M * Hollow Bertl: i have another problem.. if i include stdlib.h it includes sys/types.h, which will conflict with linux/types.h which is defined in vserver/switch.h, best course of action would be..? 1124988629 M * Bertl hmm .. sec 1124988680 M * Bertl /usr/include/linux/types.h is part of the kernel headers, no? 1124988686 M * Hollow yep 1124988725 M * Bertl try including sys/types.h after that? 1124988761 M * Hollow it is 1124988766 M * Bertl okay, sec 1124988771 M * Hollow switch.h is the first thing i include 1124988842 M * Bertl ahem, the other way round ... 1124988854 M * Bertl #include 1124988854 M * Bertl #include 1124988859 M * Hollow k 1124988870 M * Bertl so shuffle the includes in your .c 1124988898 M * Hollow genius ;) 1124988912 M * Bertl btw, I always try to include the vserver specific files at the end (in kernel after all linux includes, but before the asm includes) 1124989285 M * Hollow Bertl: http://phpfi.com/75679 1124989651 M * Bertl cool! 1124989698 M * Hollow :) 1124991714 J * fobi wht@liiifeeee.com 1124991714 J * Neubix ~brian@Jd175.j.pppool.de 1124991717 M * fobi hi all 1124991765 Q * Neubix Quit: 1124991783 J * Neubix ~brian@Jd175.j.pppool.de 1124991795 M * Neubix Hi all 1124991796 M * fobi is there any chance to use iptables in guest vserver ? 1124991804 M * fobi hi Neubix 1124991808 M * Bertl welcome Neubix! fobi! 1124991819 M * Bertl fobi: yes, but not in the way you probably expect ... 1124991820 M * Neubix hi Bertl, Fobi 1124991828 M * fobi Bertl: probably.... ;) 1124992031 M * fobi so normally i need to send iptable rules to root of whole vserver ? 1124992046 Q * obi Ping timeout: 482 seconds 1124992054 M * fobi he can set specific rules only for my vserver ?? 1124992061 M * fobi "can he" ;) 1124992096 M * Bertl yes, basically you 'could' allow a guest to mess with the iptables 1124992110 M * fobi but? 1124992124 M * Bertl but that would in turn allow that guest to mess with all ip tables entries, so you should know what you are doing there 1124992549 M * fobi thanks 1124992551 M * fobi bbl 1124992626 J * obi ~obi@asus.saftware.de 1124993551 J * menomc ~amery@200.75.27.82 1124993720 Q * mnemoc Ping timeout: 480 seconds 1124993876 M * Neubix Bertl : have you see Medivh ? I send him a mail, but still no contact .. 1124993923 M * Bertl no, sorry, maybe he is on vacation? 1124994032 M * Neubix vacation and online here ?? that's no normal DSL connect :) 1124994103 Q * monrad Quit: Leaving 1124994553 M * Hollow ever heard of static ip adresses? :) 1124994562 M * Hollow even with DSL 1124995323 J * keyser_soze ~cimarron@host241.201-252-63.telecom.net.ar 1124996115 M * Bertl okidokili ... off for dinner now .. back later 1124996124 N * Bertl Bertl_oO 1124996696 J * monrad ~monrad@213083190134.sonofon.dk 1124998275 Q * monrad Quit: Leaving 1124999776 J * yarihm ~yarihm@80-218-5-17.dclient.hispeed.ch 1125001308 J * monrad ~monrad@213083190134.sonofon.dk 1125002181 Q * zobel Ping timeout: 480 seconds 1125002481 J * zobel zobel@zobel.irc.ftbfs.de 1125003246 Q * monrad Quit: Leaving 1125003919 Q * lilo_ Read error: Connection reset by peer 1125003993 J * lilo ~lilo@lilo.usercloak.oftc.net 1125004078 Q * keyser_soze Quit: Abandonando 1125004938 Q * Neubix Quit: Verlassend 1125005360 N * Bertl_oO Bertl 1125005454 J * jonsmel ~jscottorn@209.33.206.3 1125005468 M * jonsmel Hi all 1125005481 M * Bertl welcome jonsmel! 1125005492 M * jonsmel is context disk limits included with vs2.0 1125005496 M * jonsmel Hey Berthl 1125005500 M * jonsmel oops, Bertl 1125005513 M * jonsmel been a bit 1125005676 M * daniel_hozac context disk limits have been present since 1.9.3 or so, IIRC. 1125005695 M * jonsmel is there a wiki on how to set them up 1125005745 M * daniel_hozac http://linux-vserver.org/Disk+Limits 1125005749 M * jonsmel I need to limit one vservers disk usage 1125005752 M * jonsmel cool, thanks 1125005762 M * jonsmel I'll check that out 1125005837 M * Bertl jonsmel: yeah, has been a while now ... 1125005846 M * jonsmel yep 1125005866 M * jonsmel been busy 1125005880 M * jonsmel just getting back to working on vserver-cluster issues 1125005882 M * jonsmel :) 1125005897 M * Bertl good! what are the issues? 1125005932 M * jonsmel not really any major issues, just fine tunning the functionality 1125005941 M * jonsmel working really good though 1125005967 M * jonsmel the only major problem that I am starting to see is that GFS is so slow because of all the locking it has to do 1125005998 M * jonsmel so the vservers will slow down sometimes depending on what is happening with the FS 1125006140 M * jonsmel We are still going to work on getting Lustre FS working because the locking is handled much cleaner and it is loads faster 1125006153 M * jonsmel that will really speed up the servers 1125006251 M * micah how many interface numbers can you have in /etc/vservers//interface? 1125006346 M * Bertl jonsmel: so GFS is working fine with linux vserver 2.0? 1125006366 M * Bertl micah: you can assign up to 15/16 ips for each guest 1125006396 M * micah Bertl: does that mean 15 or 16? :) 1125006415 M * Bertl depends on the tools, older ones had a bug, limiting it to 15 1125006425 M * micah hehe 1125006456 M * jonsmel Bertl: Yes, it works great, no issues what so ever, I've been running like this for 3 months in production environment 1125006475 M * jonsmel 1 backend and 3 front ends with 30 vservers 1125006485 M * jonsmel between the 3 front ends 1125006594 M * Bertl interesting .. I somehow remember reports that GFS did not work for whatever reason ... good to hear that it actually does work :) 1125006652 M * jonsmel well, keep in mind it works but once you get about as many vserver running on it that we do GFS starts to struggle 1125006693 M * jonsmel and it would be even worse if you have vservers that access the disk a lot 1125006762 M * Bertl guess, so, is it over GB ethernet? 1125006801 M * jonsmel yep 1125006871 M * jonsmel at what we have right now on it it works with little times where that issue arises 1125006901 M * jonsmel We don't want to put any more on it to keep those times minimized 1125006947 M * jonsmel but it is quick, if a frontend goes down, it takes a matter of about 30s to bring the vservers that were running on the down frontend up on one of the others 1125006970 M * Bertl i.c. be careful with the disk limits, they require 'some' filesystem support ... 1125006998 M * Bertl so I would not expect them to work over GFS out of the box ... 1125007005 M * jonsmel make SA requirements easy to stay with in 4 or 5 9's 1125007015 M * jonsmel ok, I will check it out 1125007020 M * jonsmel thanks for the heads up 1125007037 M * jonsmel it will not cause any problems if they don't work though would it 1125007074 M * jonsmel meaning it wouldn't corrupt the FS or anything like that 1125007145 M * Bertl no, it just will show no changes on addition/removal of files 1125007158 M * jonsmel ok, cool 1125007178 M * Bertl and if you come up with a kernel/patch for the GFS stuff, we can also look into it ... 1125007195 M * jonsmel okie 1125007200 M * Bertl does GFS do quota (user/group)? 1125007213 M * jonsmel not sure yet 1125007236 M * jonsmel us having to set quotas just came up today so I am just starting to look into it 1125007275 M * jonsmel on the wiki, does the vdlimit need to be run in a pre-start script everytime the vserver starts, or how does that work 1125007334 M * Bertl basically once after host startup you have to 'configure' the disk limits for every filesystem/xid combination 1125007354 M * jonsmel ok 1125007445 M * jonsmel on the wiki it says that post-start script didn't auto set the limits 1125007469 M * daniel_hozac i use something very similar in a pre-start script, and it works. 1125007515 M * jonsmel would you just set a script to start in the rc.d or init.d, 1125007533 M * jonsmel ah, i'll just play with it and see what happens 1125007536 M * jonsmel :) 1125007598 M * jonsmel btw thanks everyone for the help 1125007817 M * Bertl you're welcome! (in everyones name :) 1125008483 Q * renihs Quit: Leaving 1125009252 Q * yarihm Quit: Leaving 1125009769 J * monrad ~monrad@213083190134.sonofon.dk 1125010095 Q * monrad arion.oftc.net quasar.oftc.net 1125010095 Q * ntrs arion.oftc.net quasar.oftc.net 1125010095 Q * duckx arion.oftc.net quasar.oftc.net 1125010095 Q * alexx arion.oftc.net quasar.oftc.net 1125010095 Q * Doener arion.oftc.net quasar.oftc.net 1125010095 Q * OliverA arion.oftc.net quasar.oftc.net 1125010095 Q * dsoul arion.oftc.net quasar.oftc.net 1125010095 Q * sven111 arion.oftc.net quasar.oftc.net 1125010095 Q * Vudumen arion.oftc.net quasar.oftc.net 1125010095 Q * Hollow arion.oftc.net quasar.oftc.net 1125010095 Q * daniel_hozac arion.oftc.net quasar.oftc.net 1125010095 Q * Snow-Man arion.oftc.net quasar.oftc.net 1125010095 Q * Bertl arion.oftc.net quasar.oftc.net 1125010095 Q * BobR_oO arion.oftc.net quasar.oftc.net 1125010095 Q * locksy arion.oftc.net quasar.oftc.net 1125010095 Q * Greek0 arion.oftc.net quasar.oftc.net 1125010095 Q * MooingLemur arion.oftc.net quasar.oftc.net 1125010095 Q * pusling arion.oftc.net quasar.oftc.net 1125010096 Q * wibble arion.oftc.net quasar.oftc.net 1125010096 Q * Medivh arion.oftc.net quasar.oftc.net 1125010096 Q * gregster arion.oftc.net quasar.oftc.net 1125010138 J * monrad ~monrad@213083190134.sonofon.dk 1125010138 J * ntrs ~ntrs@Dardeene-68.188.50.87.charter-stl.com 1125010138 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1125010138 J * alexx ~alexx@proxy.ikse.net 1125010138 J * Doener ~doener@p548750B8.dip.t-dialin.net 1125010138 J * OliverA ~kvirc@ti200710a080-11067.bb.online.no 1125010138 J * sven111 ~sven@GKCDVI.dsl.saunalahti.fi 1125010138 J * dsoul darksoul@vice.ii.uj.edu.pl 1125010138 J * Vudumen vudumen@perverz.hu 1125010138 J * Hollow ~Hollow@home.xnull.de 1125010138 J * daniel_hozac ~daniel@c-6f1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1125010138 J * Snow-Man ~sfrost@snowman.net 1125010138 J * Bertl ~herbert@212.16.62.52 1125010138 J * BobR_oO ~georg@212.16.62.52 1125010138 J * locksy ~locksy@mrtg.sisgroup.com.au 1125010138 J * Greek0 ~greek0@81.189.246.175 1125010138 J * MooingLemur ~troy@shells200.pinchaser.com 1125010138 J * pusling pusling@195.215.29.124 1125010138 J * wibble ~tim@sophie.wobb1e.co.uk 1125010138 J * Medivh ck@paradise.by.the.dashboardlight.de 1125010138 J * gregster ~gregor@greart.de 1125010138 T * nova.oftc.net http://linux-vserver.org/ | latest stable 2.0, 1.2.10, devel 2.1.0-pre4 -- 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 ;) 1125010435 Q * gregster jupiter.oftc.net quasar.oftc.net 1125010435 Q * Medivh jupiter.oftc.net quasar.oftc.net 1125010435 Q * wibble jupiter.oftc.net quasar.oftc.net 1125010435 Q * MooingLemur jupiter.oftc.net quasar.oftc.net 1125010435 Q * daniel_hozac jupiter.oftc.net quasar.oftc.net 1125010435 Q * Hollow jupiter.oftc.net quasar.oftc.net 1125010435 Q * Vudumen jupiter.oftc.net quasar.oftc.net 1125010435 Q * sven111 jupiter.oftc.net quasar.oftc.net 1125010435 Q * OliverA jupiter.oftc.net quasar.oftc.net 1125010435 Q * Doener jupiter.oftc.net quasar.oftc.net 1125010435 Q * alexx jupiter.oftc.net quasar.oftc.net 1125010435 Q * duckx jupiter.oftc.net quasar.oftc.net 1125010435 Q * ntrs jupiter.oftc.net quasar.oftc.net 1125010435 Q * monrad jupiter.oftc.net quasar.oftc.net 1125010435 Q * locksy jupiter.oftc.net quasar.oftc.net 1125010435 Q * pusling jupiter.oftc.net quasar.oftc.net 1125010435 Q * BobR_oO jupiter.oftc.net quasar.oftc.net 1125010435 Q * dsoul jupiter.oftc.net quasar.oftc.net 1125010435 Q * Snow-Man jupiter.oftc.net quasar.oftc.net 1125010435 Q * Greek0 jupiter.oftc.net quasar.oftc.net 1125010435 Q * Bertl jupiter.oftc.net quasar.oftc.net 1125011903 J * Aiken ~james@tooax6-010.dialup.optusnet.com.au 1125012289 J * monrad ~monrad@213083190134.sonofon.dk 1125012289 J * ntrs ~ntrs@Dardeene-68.188.50.87.charter-stl.com 1125012289 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1125012289 J * alexx ~alexx@proxy.ikse.net 1125012289 J * Doener ~doener@p548750B8.dip.t-dialin.net 1125012289 J * OliverA ~kvirc@ti200710a080-11067.bb.online.no 1125012289 J * sven111 ~sven@GKCDVI.dsl.saunalahti.fi 1125012289 J * dsoul darksoul@vice.ii.uj.edu.pl 1125012289 J * Vudumen vudumen@perverz.hu 1125012289 J * Hollow ~Hollow@home.xnull.de 1125012289 J * daniel_hozac ~daniel@c-6f1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1125012289 J * Snow-Man ~sfrost@snowman.net 1125012289 J * Bertl ~herbert@212.16.62.52 1125012289 J * BobR_oO ~georg@212.16.62.52 1125012289 J * locksy ~locksy@mrtg.sisgroup.com.au 1125012289 J * Greek0 ~greek0@81.189.246.175 1125012289 J * MooingLemur ~troy@shells200.pinchaser.com 1125012289 J * pusling pusling@195.215.29.124 1125012289 J * wibble ~tim@sophie.wobb1e.co.uk 1125012289 J * Medivh ck@paradise.by.the.dashboardlight.de 1125012289 J * gregster ~gregor@greart.de 1125012473 Q * monrad Server closed connection 1125012475 Q * ntrs Server closed connection 1125012475 Q * duckx Server closed connection 1125012475 Q * alexx Server closed connection 1125012475 Q * Doener Server closed connection 1125012475 Q * OliverA Server closed connection 1125012475 Q * dsoul Server closed connection 1125012475 Q * sven111 Server closed connection 1125012475 Q * Vudumen Server closed connection 1125012475 Q * Hollow Server closed connection 1125012475 Q * daniel_hozac Server closed connection 1125012475 Q * Snow-Man Server closed connection 1125012475 Q * Bertl Server closed connection 1125012475 Q * BobR_oO Server closed connection 1125012475 Q * locksy Server closed connection 1125012475 Q * Greek0 Server closed connection 1125012475 Q * MooingLemur Server closed connection 1125012475 Q * pusling Server closed connection 1125012475 Q * wibble Server closed connection 1125012475 Q * Medivh Server closed connection 1125012475 Q * gregster Server closed connection 1125012477 J * dsoul_ darksoul@vice.ii.uj.edu.pl 1125012478 J * Bertl_ ~herbert@212.16.62.52 1125012479 J * locksy ~locksy@mrtg.sisgroup.com.au 1125012485 J * sven111 ~sven@GKCDVI.dsl.saunalahti.fi 1125012488 J * Doener ~doener@p548750B8.dip.t-dialin.net 1125012489 J * Greek0 ~greek0@81.189.246.175 1125012490 J * Vudumen vudumen@perverz.hu 1125012490 J * alexx ~alexx@proxy.ikse.net 1125012490 J * BobR_oO ~georg@212.16.62.52 1125012492 J * pusling pusling@195.215.29.124 1125012493 J * wibble ~tim@sophie.wobb1e.co.uk 1125012494 J * MooingLemur ~troy@shells200.pinchaser.com 1125012494 J * OliverA ~kvirc@ti200710a080-11067.bb.online.no 1125012495 J * Medivh ck@paradise.by.the.dashboardlight.de 1125012495 J * Hollow ~Hollow@home.xnull.de 1125012496 J * gregster ~gregor@greart.de 1125012496 J * duckx ~Duck@mna75-1-81-57-39-234.fbx.proxad.net 1125012502 J * daniel_hozac ~daniel@c-6f1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1125012502 J * monrad ~monrad@213083190134.sonofon.dk 1125012630 N * Bertl_ Bertl 1125012635 M * Greek0 *grml* 1125012786 J * Snow-Man ~sfrost@snowman.net 1125012828 M * Greek0 Bertl: in delta-2.6.13-rc7-vs2.1.0-pre4.1.diff, where is the (semantical) difference in cow_break_link()? 1125013081 M * Bertl you mean: what was actually the cool fix you did there, right? :) 1125013225 M * Greek0 yep 1125013251 M * Bertl it's much easier to understand if you see the test case causing the original error ... 1125013256 M * Bertl *sec* 1125013422 J * ntrs ~ntrs@Dardeene-68.188.50.87.charter-stl.com 1125013542 M * Bertl http://vserver.13thfloor.at/Stuff/cow_fix.txt 1125013594 M * Bertl in the first version, we simply assumed that 'pathname' would be where the file is ... 1125013619 M * Bertl but that's not always true, especially if that is a symlink 1125013646 M * Greek0 yep 1125013659 M * Bertl so with symlinks, we have to work on the target the link points to 1125013672 M * Greek0 and I guess that "pad" thing in cow_break_link is also not thought to be there permanently, or? 1125013677 M * Greek0 mm 1125013697 M * Bertl well, we need something to create the copy, if you come up with something smarter, we can remove that :) 1125013733 M * Greek0 *bam* that's what it's for 1125013769 M * Greek0 I've started looking at cow_break_link about 5 minutes ago, and was wondering a bit about the pad stuff.. 1125013789 M * Bertl yeah, it's cruel, I know :) 1125014041 M * Greek0 hmm. is this some version that you'd consider final (at least half-way), or is this still a very hacky thing (as the missing checks for all kinds of retvals suggest)? 1125014089 M * Greek0 I'm just wondering if it's ok to not do all the checks you don't do there, and if you say "yep, skipped all those, will be added later", I can skip that head-scratching phase. 1125014098 M * Bertl from the design POV, it would be the best to remove the link, copy the inode and replace it in the dentry ... 1125014116 M * Bertl and yes, it's pretty experimental, and yes, patches to add additional checks are welcome ... 1125014142 M * Bertl I'm pretty sure we might add one or the other today, once Aiken is really back :) 1125014228 M * Greek0 and why do you do the copy-to-hopefully-unexistent-file way currently? i.e. what is the problem with doing it the "right way"? 1125014252 M * Bertl that there simply is no way in the kernel to copy an inode ... 1125014276 M * Bertl even the sendfile copy approach requires heavy patching ... 1125014337 M * Greek0 hrmpf 1125014374 M * Bertl if you can provide a simple copy_inode() taking an old inode as input, return a new one (as copy of it) then the whole COW becomes pretty trivial 1125014380 M * Aiken I was having more problems last night, I try working out exactly what this morning 1125014385 Q * Doener Ping timeout: 480 seconds