1142035547 Q * rs Quit: rs 1142035610 J * lilalinux_ ~plasma@dslb-084-058-195-121.pools.arcor-ip.net 1142036049 Q * lilalinux Ping timeout: 480 seconds 1142036585 P * jayeola 1142036648 M * daniel_hozac Bertl: re mmouse's problem: how is userspace supposed to know how to act? (i.e. async or sync) 1142036678 M * Bertl excelent question, probably based on the version number 1142036688 M * daniel_hozac vshelper is certainly not doing the right thing. 1142036713 M * Bertl the ebst would be to use the vci info for that (now that the flag is fixed :) 1142036771 M * Bertl VCI_KCBIT_LEGACY (already correct in all versions) 1142037019 M * Bertl okay, if possible I'd like to get an okay to each of the patches from you (all) 1142037050 M * daniel_hozac they all looked fine to me. 1142037066 M * Bertl okay, good ... thanks for checking! 1142037222 M * daniel_hozac question though about delta-debug-stab01, why define __HERE__ to 0 if history tracing isn't enabled? 1142037249 M * Bertl checking 1142037281 M * Bertl because of calls like: 1142037283 M * Bertl #define get_vx_info(i) __get_vx_info(i,__FILE__,__LINE__,__HERE__) 1142037283 M * daniel_hozac oh, i see. i got confused by the init_vx_info and friends hunks. 1142037313 M * Bertl well, no problem, as I said, better a funny question than something missed 1142037316 M * daniel_hozac i thought __HERE__ was actually used for something other than the history tracing. 1142037748 Q * doener Quit: leaving 1142038234 M * Bertl ah, forgot two of them, actually ... 1142038247 M * Bertl http://vserver.13thfloor.at/Experimental/delta-signal-stab01.diff 1142038337 M * Bertl http://vserver.13thfloor.at/Experimental/delta-var2-stab01.diff 1142038549 M * daniel_hozac i was wondering where vcmd_ctx_migrate came from :) 1142038553 M * daniel_hozac they look fine too. 1142038601 M * Bertl samv_home: any comments on your side? 1142038716 Q * coocoon Quit: KVIrc 3.2.0 'Realia' 1142040065 Q * samv_home Quit: Lost terminal 1142040533 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net 1142040538 M * Bertl wb rs! 1142040980 M * Bertl daniel_hozac: okay, so we leave the sync vs. async as is for now? 1142041482 Q * gerrit_ Ping timeout: 480 seconds 1142041487 Q * gerrit Ping timeout: 480 seconds 1142041764 Q * rs Quit: rs 1142042011 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1142042012 J * gerrit_ ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1142042350 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net 1142042958 M * Bertl cd .. 1142042961 M * Bertl oops 1142043119 M * Bertl okay, as it seems that everybody has fallen asleep or was disconnected somehow, and I'm not fully awake anymore too, I'll upload the latest versions as rc11, and we'll see tomorrow :) 1142043158 T * Bertl http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc11 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | 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 ;) 1142043184 M * Bertl I would have submitted it to plm too, but plm seems down atm ... 1142043196 M * Bertl have a good whatever everyone, cya tomorrow! 1142043201 N * Bertl Bertl_zZ 1142043467 Q * matta Ping timeout: 480 seconds 1142043555 Q * gerrit Ping timeout: 480 seconds 1142043559 Q * gerrit_ Ping timeout: 480 seconds 1142044127 J * gerrit_ ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1142044159 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1142044876 J * torabora ~asdasd@178gis168.gulftel.com 1142045208 P * torabora 1142045895 J * pflanze ~chris@84-73-53-93.dclient.hispeed.ch 1142045901 M * pflanze Hello 1142047230 J * matta ~matta@71.224.125.126 1142048186 N * VxJasonxV[A] VxJasonxV 1142048612 Q * Loki|muh Ping timeout: 480 seconds 1142048667 Q * pflanze Quit: [x]chat 1142048850 J * Loki|muh loki@satanix.de 1142049517 Q * PilatomiK Remote host closed the connection 1142049582 Q * Loki|muh Ping timeout: 480 seconds 1142049666 J * Loki|muh loki@satanix.de 1142049702 Q * phedny Read error: Operation timed out 1142051948 J * Smutje_ ~Smutje@xdsl-87-78-40-114.netcologne.de 1142052054 Q * Smutje Ping timeout: 480 seconds 1142052054 N * Smutje_ Smutje 1142067796 Q * Loki|muh unununium.oftc.net oxygen.oftc.net 1142067796 Q * lonewolff unununium.oftc.net oxygen.oftc.net 1142067796 Q * michal` unununium.oftc.net oxygen.oftc.net 1142067796 Q * Wenix unununium.oftc.net oxygen.oftc.net 1142067796 Q * teukka unununium.oftc.net oxygen.oftc.net 1142067796 Q * meebey unununium.oftc.net oxygen.oftc.net 1142067796 Q * Geert unununium.oftc.net oxygen.oftc.net 1142067807 J * Loki|muh loki@satanix.de 1142067807 J * lonewolff lonewolff@adleman.lonewolff.info 1142067807 J * michal` ~michal@www.rsbac.org 1142067807 J * Wenix ~wenix@81.7.189.11 1142067807 J * teukka ~tmatilai@backport.ri.fi 1142067807 J * meebey meebey@booster.qnetp.net 1142067807 J * Geert geert@geert.irssi.be 1142067807 T * xenon.oftc.net http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc11 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | 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 ;) 1142067830 Q * michal` Read error: Operation timed out 1142067832 Q * Loki|muh Read error: Connection reset by peer 1142067843 J * michal` ~michal@www.rsbac.org 1142067878 J * Wenix_ ~wenix@81.7.189.11 1142067883 Q * Wenix Read error: Operation timed out 1142067883 Q * teukka Read error: Operation timed out 1142068010 J * Loki|muh loki@satanix.de 1142068657 J * coocoon ~coocoon@p54A07A19.dip.t-dialin.net 1142068877 M * coocoon morning 1142068882 J * Viper0482 ~Viper0482@p5497742B.dip.t-dialin.net 1142070340 Q * Wenix_ Quit: leaving 1142070355 J * Wenix ~wenix@81.7.189.11 1142070636 N * Bertl_zZ Bertl 1142070641 M * Bertl morning folks! 1142070682 J * meandtheshell ~markus@85-124-9-50.dynamic.xdsl-line.inode.at 1142070719 M * Wenix morning Bertl 1142071014 M * Bertl hey Wenix! 1142071230 M * coocoon morning bertl 1142071353 M * Bertl is everybody testing rc11? 1142071374 M * coocoon no 1142071389 M * coocoon maybe later i will install it with the latest kernel 1142071438 M * coocoon bertl: have some questions about installing suse distro 1142071465 M * Bertl let's hear 1142071580 M * coocoon bertl: vserver build works and also the vserver starts but during updating wiht yast always udevs filesystem packages failled to install, this happens with suse9.3 and also with 10.0, the error message is that there is no permission (proc), for detail I can paste it in patebin, maybe it is easy to answer for u 1142071598 M * coocoon udevs and filesystem 1142071617 M * Bertl well, don't install them/don't update them 1142071627 M * Bertl inside a guest, they do not make sense 1142071650 M * coocoon bertl: yes so I do, but it nerves to get at every new installation these depnding messages 1142071666 M * coocoon new installation of another package 1142071669 M * Bertl add it only to the database 1142071689 M * coocoon bertl: hm thats sounds simple, but how to do this 1142071692 M * Bertl rpm --justdb 1142071711 M * Bertl no idea what the 'yast' command for that is 1142071728 M * coocoon bertl: I think this will help 1142071738 A * Bertl did abandon yast with SuSE 6.4 :) 1142071748 M * coocoon bertl: u have fast answer to a lot of problems thanx very much 1142071774 M * Bertl you're welcome! 1142072669 J * alexx ~alexx@proxy.ikse.net 1142072759 Q * jkl Ping timeout: 480 seconds 1142073101 A * h01ger waves at Bertl 1142073107 M * coocoon bertl: this I got http://pastebin.com/595992 during patching kernel linux-2.6.16-rc5-vs2.1.1-rc11 1142073108 A * Bertl waves back 1142073167 Q * Viper0482 Remote host closed the connection 1142073174 M * Bertl coocoon: you're sure it wasn't patched somehow? 1142073200 J * bonbons ~bonbons@83.222.39.180 1142073231 M * Bertl welcome bonbons! 1142073236 M * coocoon bertl: i made a hardlink of my other kernel linux-2.6.14.3, shall I download complete kernel and patch it 1142073250 M * coocoon bertl: no probs 1142073279 M * Bertl I assume you _modified_ your previous kernel 1142073287 M * coocoon bertl:yes 1142073289 M * bonbons morning Bertl and the others 1142073318 M * Bertl coocoon: so as the patch is for the vanilla kernel, it will not work with a modified kernel 1142073370 M * coocoon oh ok so I will make it with the vanilla kernel, and having breakfast ;-) 1142073381 M * Bertl good idea :) 1142073710 J * tuxmania ~bonbons@83.222.39.180 1142073720 M * Bertl welcome tuxmania! 1142073726 Q * alexx Quit: Bye 1142073829 Q * bonbons Ping timeout: 480 seconds 1142075064 N * tuxmania bonbons 1142077302 M * daniel_hozac Bertl: re sync/async: i guess util-vserver will just have to require legacy support for a bit longer. 1142077333 M * Bertl hmm, shouldn't it work with devel? 1142077380 M * Bertl I mean the (now stable?) rkill should work, no? 1142077397 Q * michal` Ping timeout: 480 seconds 1142077586 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk 1142077664 M * Bertl welcome vrwttnmtu! 1142077803 M * daniel_hozac yeah, but a guest without VXF_REBOOT_KILL on a kernel without legacy, will still try to do a vshelper sync operation that's just not supported. 1142077847 M * Bertl okay, now where is the problem? a tool bug? something which can not work? 1142077884 M * Bertl IMHO it doesn't make sense to have a setup which just does not work, no? 1142077902 M * daniel_hozac it is a tool bug, vshelper just doesn't handle the sync case. 1142077908 M * daniel_hozac i agree. 1142077919 M * Bertl okay, so can we file a bug report for that to savannah? 1142077987 J * michal` ~michal@www.rsbac.org 1142077989 M * daniel_hozac yeah, i can file it. 1142078026 M * Bertl okay, then we leave everything as is, try to keep in mind that without REBOOT_KILL legacy is required, and wait for Enrico requesting more input :) 1142078048 M * daniel_hozac hehe. 1142078527 M * daniel_hozac https://savannah.nongnu.org/bugs/?func=detailitem&item_id=16066 1142078538 M * Bertl tx! 1142078568 M * vrwttnmtu Bertl, If you only have 1 IP address for example, but you wanted to run port 80 within a vserver, is there a way (possibly using IPtables) to do this? Maybe run the vserver on a private IP, and NAT port 80 to that? Does this work? 1142078593 M * daniel_hozac vrwttnmtu: are you also running something on port 80 on the host? 1142078603 M * vrwttnmtu Nope 1142078617 M * vrwttnmtu (At home I am short of IP addresses.. :) ) 1142078629 M * Bertl vrwttnmtu: yep, a private IP for the guest and a DNAT works 1142078642 M * vrwttnmtu OK, brilliant 1142078717 Q * lonewolff Ping timeout: 480 seconds 1142082124 J * lonewolff lonewolff@adleman.lonewolff.info 1142084277 M * tokkee Is there any way to have different routing tables in the vservers and the host? 1142084459 M * Bertl no, but you can have different routing tables on the host, basically giving you a routing table per guest 1142084512 M * tokkee How do I do that? 1142084548 M * Bertl http://linux-vserver.org/Documentation 1142084555 M * Bertl http://archives.linux-vserver.org/200311/0470.html 1142084564 M * Bertl (more than one gateway) 1142084742 M * tokkee thx... 1142084817 M * tokkee iirc I found some howto describing changing network settings without a reboot... Is there anything like that? 1142084845 M * Bertl you can change all network settings without reboot 1142084863 M * Bertl but the processes inside a guest will not pick up the changes unless restarted 1142084926 M * tokkee Do I only need to change the settings in interfaces/0? 1142084937 M * tokkee ... and restart all daemons afterwards? 1142084955 M * Bertl no, that wouldn't be sufficient 1142084983 M * Bertl but the simplest way would be to stop the guest, change the settings and restart it 1142084999 M * Bertl (this will ensure that everything is updated properly) 1142085008 M * harry Bertl: is there an easy way to configure different networks for vps'es? 1142085026 M * Bertl see urls above :) 1142085028 M * harry e.g. i have 1 interface on a certain vlan, which has more than 1 ip range 1142085033 M * harry ah 1142085034 M * harry lol 1142085073 M * Bertl or do you mean several networks for one guest? 1142085082 M * harry no 1142085087 M * daniel_hozac it's funny how the same question can be asked 5 times in a few days, and then not be asked for a month. 1142085106 M * harry i have 4 guests, 2 on 10.33.113.0/24 2 on 134.58.10.0/26 1142085117 M * Bertl daniel_hozac: yup, that's true radomness :) 1142085123 M * harry the only interface the host needs is a 192.168.28.0/23 on eth1 1142085146 M * Bertl so you probably would want to have three tables 1142085156 M * harry uhu 1142085157 M * harry :) 1142085172 M * harry need to set it up later... 1142085175 M * harry not today 1142085183 A * harry totally wasted from working out 1142085190 A * harry always exaggerates ;) 1142085225 M * harry luckily that advanced routing stuff isn't strange to me... 1142085234 A * harry loves funky network setups :) 1142085250 M * harry magic happens, noone knows what happens, but all works perfectly in all situations 1142085338 M * harry Bertl: only q... how do i make sure that interfaces are NOT shut down if the first ip address of the interface is removed 1142085346 M * harry you told it here a few times 1142085352 M * harry but i don't remember where to find it 1142085485 M * Bertl hehe, yes there are actually three ways to avoid that 1142085505 M * harry nodev ? ;) 1142085507 M * Bertl first, to recap (maybe for tokkee and others) the issue: 1142085539 M * Bertl if you have more than one ip on _any_ network, only one of those IPs can be a primary, all others will become secondaries 1142085566 M * Bertl the result of this (generic linux) behaviour is, that when you take down the primary, all secondaries go with it 1142085576 M * harry (personally i would like NO primary, all secondaries and the interface never brought down) 1142085587 M * Bertl now the 'solutions': 1142085590 M * harry (since vmware uses the same interfaces for bridging) 1142085611 M * Bertl - obviously having only one IP per network is a solution 1142085659 M * harry - not using the primary ip for a vps 1142085669 M * Bertl that's the second one 1142085674 M * Bertl and finally 1142085679 M * harry both no option for me :) 1142085701 M * Bertl - using a brand new feature in recen kernels, which allow to 'elect' a new primary if the primary goes down 1142085705 M * Bertl *recent 1142085726 M * harry sounds fishy 1142085755 M * Bertl well, it's what the kernel network folks came up with after a few years of complaints :) 1142085765 M * harry that would mean that, if all vps'es are down, the interface is brought down too 1142085778 M * Bertl yep 1142085785 M * harry BUT... my vmware still uses those interfaces for bridging! 1142085793 M * tokkee harry: You could simply configure one IP on that interface in the host... 1142085798 M * Bertl well, why not have a bridge ip then? 1142085819 M * harry tokkee: that would mean i lose 1 ip per interface 1142085823 M * Bertl (could even be on a completely different network) 1142085828 M * harry Bertl: i don't need that ;) 1142085839 M * harry just... spit out the packets on that interface 1142085844 M * harry same for vservers actually ;) 1142085847 M * tokkee harry: That's true.... if thats a public network that might be a problem... 1142085861 M * harry tokkee: it's 3 public networks, 1 private 1142085884 M * harry Bertl: hmm... you've got a point... just use a "dummy ip" 1142085898 M * harry and firewall the hell out of it 1142085899 M * Bertl another way for you to do it is to assign all (or at least one) guest ips on the host 1142085918 M * Bertl and add the nodev entry to the guest config 1142085941 M * Bertl this will not even try to take any of the ips down 1142085945 M * harry Bertl: that would mean the machine can never be actually down for the vps'es 1142085967 M * harry naaah... /me likes the sollution of dummy primary ip better:0 1142085968 M * harry ;) 1142085980 M * harry just drop all packets to it, no matter what 1142086007 M * harry make my own little subnet (like 192.168.255.253/32 1142086008 M * harry ) 1142086020 M * harry will probably never harm anyone 1142086031 M * harry no routing or other crap 1142086040 M * harry just advanced routing for all networks on the system 1142086050 M * harry haha... collegues will like to see this! 1142086063 M * harry they still have no clue on the last setup :) 1142086093 M * harry 1 ip, 2 loadbalancers, 4 servers, 3 loadbalanced for some ports, SNAT to them, still only 1 ip comes out, ... ;) 1142086113 M * harry trying to explain what happens makes people want to kill themselves :) 1142086150 M * harry completely stateless, but still sessions are maintained for all connections 1142086386 M * waldi hmm, it may be okay to select the vserver patch if i want to build a vserver kernel ... 1142086416 M * Bertl probably ... 1142086454 J * hw ~Hartmut@85.124.100.166 1142086461 M * Bertl welcome hw! 1142086466 M * hw hi 1142086603 M * harry Bertl: 15:01 < Bertl> - using a brand new feature in recen kernels, which allow to 'elect' a new primary if the primary goes down 1142086606 M * harry how do you enable that? 1142086827 M * Bertl http://list.linux-vserver.org/archive/vserver/msg11905.html 1142086966 M * waldi Bertl: hmm, you did not fix the s390 bug in rc11? 1142087030 M * Bertl hmm, didn't I? 1142087156 M * Bertl waldi: could you point me to the diff/patch? 1142087212 M * waldi arch/s390/kernel/ptrace.c, out_task vs. out_tsk 1142087245 M * Bertl you did submit a patch I assume? 1142087258 M * Bertl (or it was uploaded somewhere?) 1142087382 M * waldi http://lophos.multibuild.org/linux/diff 1142087465 M * Bertl okay, tx, will put it into the next rc 1142088174 M * waldi i'm currently updating to -rc11 1142088216 M * Bertl okay, hoepfully all is fine .. we had the first report of something breaking, but I'm not sure it was rc10/rc11 related 1142088235 M * harry hehe... mega patch! : 1142088236 M * harry :) 1142090175 Q * matta Ping timeout: 480 seconds 1142091177 M * coocoon bertl: sorry I am installing suse vservers, so I cannot tested I have patched and compiled the kernel all works fin ;-) 1142091185 M * coocoon bertl: but not restarted 1142091236 M * Bertl okay, good ... 1142091437 M * phreak`` Bertl: will test it in a minute or so (currently unpacking) 1142091961 Q * Medivh Quit: changing servers 1142092209 J * Medivh ck@paradise.by.the.dashboardlight.de 1142092523 M * phreak`` Bertl: http://phpfi.com/106731 (works for me) 1142092562 M * Bertl good 1142093111 M * phreak`` Bertl: http://phpfi.com/106733 (now Extended Attributes for reiser, and no jfs -support in my kernel) 1142093114 M * phreak`` *no 1142093151 M * Bertl okay, did you check with a guest or two too? 1142093176 M * phreak`` Bertl: got a guest currently running (doing a long-waited update in it) 1142093184 M * Bertl excellent! 1142093217 M * phreak`` http://phpfi.com/106734 1142093506 M * phreak`` hrm, weird 1142093507 Q * sladen Ping timeout: 480 seconds 1142093532 M * Bertl phreak``: yep? 1142093543 J * mmouse ~mmouse@office.haefft.de 1142093549 M * Bertl welcome mmouse! 1142093554 M * mmouse hi bertl 1142093599 J * sladen paul@starsky.19inch.net 1142093619 M * mmouse bertl: I wanted to compile my new kernel and came across the highmem and memory split options 1142093638 M * Bertl how much memory do you have? 1142093642 M * mmouse is there any documentation about what that does? 1142093642 M * phreak`` seems like _rc11 is having some problems again (well or apache2) -> http://phpfi.com/106736 1142093651 M * mmouse 2GB in one, 4GB in another machine 1142093684 M * phreak`` (as in I'm unable to get a file from my apache inside the vps, neither from the host, the vps or some machine in the same segment) 1142093721 M * bonbons phreak``: sendfile() issue? 1142093732 M * Bertl phreak``: hhm could you verify that the sendfile fix is in rc11? 1142093734 M * phreak`` bonbons: no idea :) its -rc11 :) 1142093742 M * phreak`` sure, just a sec Bertl 1142093803 M * Bertl it seems so here ... 1142093845 M * phreak`` Bertl: yup, same here .. but still broken ;) 1142093869 M * Bertl hmm, I thought (somebody?) tested it with doener? 1142093896 M * Bertl will look into it shortly ... 1142093930 M * phreak`` ok :) 1142093935 M * phreak`` thanks a lot Bertl ;) 1142094002 M * Bertl ah, maybe you could check the stable branch if that shows similar behaviour? 1142094025 M * phreak`` hmm, yeah :) 1142094238 M * mmouse bertl: I know, I'm slightly offtopic, but if I got it right - there's no need to activate high memory support even with 2GB/4GB of physical RAM? 1142094262 M * Bertl ah, sorry, forgot about you :) 1142094274 M * mmouse :) 1142094284 M * Bertl for the 2GB machine you want a 2/2 split or 2.5/1.5 1142094306 M * Bertl you can even go with a 3/1 (1/3 is default) 1142094333 M * mmouse err, which is which, config says default is 3/1 (user/kernel) 1142094334 M * Bertl (maybe with numbers exchanged) 1142094350 M * Bertl yes, you want 2-3GB kernel 1142094367 M * Bertl so 2/2 1.5/2.5 or 1/3 1142094393 M * Bertl on the 4GB machine you have two options 1142094406 M * Bertl you can ignore 1GB and use it with 1/3 1142094423 M * cehteh mhm .. btw where is the split at 64 bit machines? 1142094426 M * Bertl or you can enable highmem in which case you probably want 2/2 1142094443 M * daniel_hozac cehteh: does it matter? :) 1142094446 M * mmouse ah, I think I got it :) 1142094455 M * Bertl cehteh: on 64bit machines the entire address space of x86 is as large as a byte 1142094472 M * cehteh daniel_hozac: maybe not .. at least not before i have 48TB ram :) 1142094485 M * Bertl not even then :) 1142094490 M * mmouse on the 4GB machine, will the remaining 1GB ignored completely, or just by the kernel (and userland uses it)? 1142094508 M * Bertl mmouse: without highmem it will be completely ignored 1142094567 M * mmouse ok thanks 1142094911 M * eyck what would you do if you would have machine with 16G of RAM? 1142094931 M * Bertl PXE or PAE? 1142094945 M * eyck AMD64 1142094950 M * eyck no need for PAE 1142094959 M * Bertl well, not 32bit x86, no? 1142094972 M * FaUl Bertl: 17:37:05 AMD64 1142095006 M * Bertl FaUl: Bertl> cehteh: on 64bit machines ... 1142095032 M * Bertl so it is _not_ an issues, not even an option on non x86 machines 1142095061 M * phreak`` thats pretty much weird :) 1142095089 M * phreak`` with 2.0.2-rc11 the vserver ain't even starting .. 1142095112 M * Bertl ah, okay, we are getting somewhere, something got really broken 1142095161 M * Bertl good that five different people checked the patches :) 1142095171 M * phreak`` well the test-scripts look fine though http://phpfi.com/106744 1142095201 M * daniel_hozac error messages= 1142095201 M * Bertl yeah, test scripts did all run yesterday too 1142095214 M * daniel_hozac s/=/?/ 1142095280 M * phreak`` daniel_hozac: yah, forgot that :P http://phpfi.com/106745 1142095310 M * daniel_hozac hmm, interesting. 1142095320 M * phreak`` daniel_hozac: on 2.1.1 its starting up fine, but I can't access the apache inside the vps .. 1142095348 M * phreak`` (17:14:44) < phreak``> (as in I'm unable to get a file from my apache inside the vps, neither from the host, the vps or some machine in the same segment) 1142095503 J * Smutje_ ~Smutje@87.78.99.119 1142095517 M * coocoon bertl: next minutes I will check it too 1142095602 M * Bertl phreak``: try to revert the namespace.c hunk from http://vserver.13thfloor.at/Experimental/delta-var-stab01.diff 1142095609 Q * Smutje Ping timeout: 480 seconds 1142095609 N * Smutje_ Smutje 1142095614 J * Dr4g Dr4g@82-40-44-190.cable.ubr06.uddi.blueyonder.co.uk 1142095626 Q * mmouse Quit: ChatZilla 0.9.61 [Mozilla rv:1.7.11/20050728] 1142095742 M * phreak`` Bertl: for which one ? 2.0.2 or 2.1.1 ? 1142095750 M * Bertl 2.0.2 1142095801 M * phreak`` ah, yeah, figured that after looking at the headers :) 1142095836 M * phreak`` only the namespace.c hunk, right ? 1142095841 M * Bertl yep 1142095850 M * phreak`` rebuilding .. 1142095995 M * phreak`` Bertl: yup that helped .. 1142096006 M * phreak`` (as in the vservers are now starting again) 1142096028 M * Bertl okay, does apache work now? 1142096044 M * daniel_hozac apache was on 2.1.1 ;) 1142096046 M * phreak`` yeah, works fine 1142096060 M * coocoon bertl: here is my small test http://pastebin.com/596446 1142096060 M * phreak`` and daniel_hozac is right :) 1142096081 M * phreak`` apache problems were indeed only on 2.1.1 1142096084 M * Bertl yes, but I wanted to know where to look, that's why we tested 2.0.2 remember? 1142096113 M * phreak`` yeah :) 1142096130 M * phreak`` as I said, works fine on 2.0.2 now :) 1142096167 M * daniel_hozac Bertl: vnamespace calls vc_set_namespace(0, 0). 1142096221 M * daniel_hozac (which is just wrong. should be -1, 0) 1142096247 M * Bertl k, so we missed that change ... 1142096270 M * daniel_hozac i don't know, i think the kernel does the right thing. 1142096303 M * Bertl ahem, okay, so why does that part work on 2.1.x? 1142096321 M * daniel_hozac i have no idea :) 1142096335 M * Bertl phreak``: could I get the testme.sh of your 2.0.2? 1142096350 M * phreak`` sure, sec 1142096387 M * phreak`` Bertl: http://phpfi.com/106749 1142096409 M * Bertl tx 1142096413 M * phreak`` yw 1142096472 M * Bertl hmm, yeah, the set_namespace was bumped ... 1142096498 M * Bertl let's revert that hunk for now .. will look into a better solution later 1142096515 M * Bertl I'll upload a patch in a few minutes 1142096517 M * daniel_hozac hmm? 1142096523 M * Bertl +#define VCMD_set_namespace_v0 VC_CMD(PROCALT, 3, 0) 1142096523 M * Bertl +#define VCMD_set_namespace VC_CMD(PROCALT, 3, 1) 1142096537 M * daniel_hozac aahh, ok. 1142096561 M * Bertl + case VCMD_set_namespace_v0: 1142096561 M * Bertl + return vc_set_namespace(-1, data); 1142096579 M * daniel_hozac is that really necessary? was vc_set_namespace initially defined as "set to current, always"? 1142096591 M * Bertl seems so 1142096601 M * daniel_hozac it would seem more logical to have the same semantics as everywhere else. 1142096742 M * Bertl nah, I decided to add the proper fix right now 1142096772 M * Bertl http://vserver.13thfloor.at/Experimental/delta-namespace-fix01.diff 1142096792 M * Bertl phreak``: could you apply that to the unmodified 2.0.2 and retry? 1142096814 M * Bertl I'll check regarding the sendfile issues now ... 1142096841 M * phreak`` Bertl: sure, rebuilding now 1142096852 M * Bertl tx 1142097123 M * phreak`` Bertl: works now as expected 1142097140 M * Bertl coocoon: the fstest is funny .. you do not have any tools to create filesystems installed? 1142097159 M * Bertl coocoon: or wasn't the loop setup, or something like that? 1142097174 M * Bertl phreak``: excellent, now let's fix the sendfile issue :) 1142097180 M * phreak`` Bertl: sure :) 1142097222 M * coocoon bertl: right i hope thats no prob for the test i only use this os for yumming vservers 1142097301 M * coocoon bertl: it is not so easy to do this with debian so i installed fc 1142097344 M * Bertl coocoon: no, no problem, but funny, as it basically tests _nothing_ :) 1142097389 M * coocoon bertl: it takes too much time to install all other stuff, sorry 1142097465 M * eyck niiiice.... -> 2.6.8 kernel compile on 1 CPU - real 21m26.462s, on 8 CPUs - real 4m23.257s 1142097513 M * eyck and I'm used to multiple hours kernel compiles... 1142097543 M * Bertl eyck: is something wrong? 1142097564 M * Bertl eyck: or did you just download the wrong kernel :) 1142097583 M * bonbons Bertl: I have a question about BCAPS... in 2.6.16-rc5-vs2.1.1-rc10 I see "vxi->vx_bcaps &= vc_data.bcaps", that means it's only possible to remove bcaps!? 1142097597 M * daniel_hozac bonbons: with vc_set_ccaps, yes. 1142097600 M * Bertl bonbons: yep 1142097612 M * bonbons why so? 1142097643 M * eyck Bertl: I'm testing some new hardware... it's looking sweet 1142097649 M * Bertl bonbons: mainly because the entire capability system is based on _removing_ caps 1142097684 M * Bertl bonbons: but I'm not strictly against adding bcaps to the mask 1142097713 M * bonbons but that also means, we can not create a guest with by default limited bcaps, where more caps could be added later on (even if the just apply for newly started processes in the guest) 1142097744 M * Bertl right, that's why I said I'm not strictly against it 1142097761 M * Bertl (i.e. we could have a v1 set_bcaps or so 1142097804 M * bonbons I would find it better to be able to add caps at runtime -> guest can run with limited bcaps, and would get special ones added only when really needed 1142097849 M * Bertl that's tricky, as every suid process started will get that caps immediately 1142097869 M * Bertl and it will not drop them (as it is implemented right now) 1142097898 M * bonbons a set_bcaps would be fine, but with mask (as it's done for ccaps) 1142097951 M * bonbons so removing bcaps from running guest leaves the caps on already started processes? Are those still inherited by their children? 1142097967 M * Bertl they are kept, but not inherited 1142098032 M * bonbons and new bcaps added would only be obtained by processes started after cap addition? 1142098052 M * Bertl started with suid, or when transferred explicitely 1142098113 M * bonbons and started by guest's root? (e.g. init which would respan a process) 1142098171 M * Bertl hmm, no, I think those will not obtain the new caps 1142098353 M * Bertl phreak``: could you try to change the following lines for 2.1.1? 1142098372 M * Bertl fs/read_write.c ~ 660 1142098406 M * Bertl - ret = rw_verify_area(FLOCK_VERIFY_READ, in_file, ppos, count); 1142098406 M * Bertl + ret = rw_verify_area(READ, in_file, ppos, count); 1142098433 M * Bertl and 20 lines below 1142098439 M * Bertl - ret = rw_verify_area(FLOCK_VERIFY_WRITE, out_file, &out_file->f_pos, count); 1142098439 M * Bertl + ret = rw_verify_area(WRITE, out_file, &out_file->f_pos, count); 1142098640 M * bonbons Bertl: what are the costs to adjust BCAPS for all processes of a context when changing a context's bcaps? (are "unmasked" bcaps remembered?) 1142098665 M * Bertl well, you ahve to walk _all_ processes and check 1142098684 M * Bertl then you also need some criterion which process should get the new cap 1142098712 M * Bertl (it could be a root process or a user process or just a restricted root one) 1142098779 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net 1142098790 M * Bertl welcome yang! 1142098886 M * phreak`` Bertl: nope, that didn't fix it (http://phpfi.com/106759) 1142098935 M * Bertl okay, hmm, any chance to strace that apache? 1142098942 M * yang Hello ! I recently discovered that proftpd on my "guest", drops me on to my profdtpd of my host ? how is that? 1142098970 J * W0nka debian-tor@chaos.in-kiel.de 1142098989 M * Bertl phreak``: ah, wait, I see something else 1142098993 M * W0nka re 1142098999 M * W0nka wtf? funny ident i have... 1142099008 M * Bertl welcome W0nka! 1142099018 N * W0nka Wonka 1142099026 M * phreak`` Bertl: well need do install strace anyway :) 1142099030 M * Bertl yang: I _assume_ (out of the blue) that your host has a proftpd running which is not restricted 1142099055 M * Bertl yang: so your guest's proftpd doesn't even succeed to bind to the guest ip 1142099055 M * yang Bertl: should i specify the IP on my proftpd host? 1142099062 M * bonbons Bertl: for restricted processes, is the list of removed caps remebered? In another way of thinking, is it possible to alter check for caps? (capable()) 1142099090 M * Bertl yang: only on the host you need to restrict services, for the guests they will be automagically restricted to the guest IPSs 1142099129 M * Bertl bonbons: no, the list if 'current' caps is there and the masks for inheritance 1142099230 M * Bertl phreak``: okay, somehow doener's fix seems backwards to me ... checking now 1142099269 M * bonbons if capable() could be altered in a non-expensive way it would certainly be easier to have a dynamic mask for the context and changes of context caps would apply instantly 1142099321 M * Bertl phreak``: let's try to revert that one: http://vserver.13thfloor.at/Experimental/delta-sendfile-fix02.diff 1142099402 M * phreak`` Bertl: doing that now (along with recompiling and rebooting9 1142099452 M * bonbons Bertl: is it possible to get capable() to test something like (pid.bcaps & ctx.bcaps & req_cap)? 1142099506 M * yang jason:/etc/interfaces# /etc/init.d/proftpd reload ; Reloading proftpd configuration...failed ; done. 1142099536 M * phreak`` Bertl: yup, that did the trick 1142099538 M * Bertl yang: that's on the host? 1142099542 M * yang i have put this section 1142099558 M * yang 1142099636 M * Bertl yang: is that on the host or inside the guest? 1142099641 M * yang host 1142099711 M * Bertl you probably want some Listen directive or so 1142099728 M * Bertl if proftpd doesn't have that, you can wrap it with chbind 1142099742 M * SiD3WiNDR it has that ;) 1142099742 M * Bertl (actually there should be a v_ftp wrapper somewhere) 1142099817 M * yang it doesnt have Listen command 1142099847 M * bonbons yag: maybe it's called bind? 1142099879 M * bonbons yang: maybe it's called "Bind" and not "Listen"? 1142099883 M * SiD3WiNDR well 1142099891 M * SiD3WiNDR the way I do it is, have a 1142099899 M * SiD3WiNDR and SocketBindTight on 1142099908 M * Bertl yang: yup: http://www.proftpd.org/docs/directives/linked/config_ref_Bind.html 1142099910 M * SiD3WiNDR that way it only binds to the vhost ip's separately and not to 0.0.0 1142099915 M * SiD3WiNDR dunno if there is a separate command :) 1142099921 M * Bertl yang: try to use that with the host IP 1142099928 M * SiD3WiNDR (i have multiple vhosts) 1142099943 M * yang just bind 86.110.64.2 1142099954 M * yang or is it 1142099964 M * Bertl yang: see the url I pasted :) 1142099982 M * yang bind [86.110.64.2] 1142099991 M * phreak`` Bertl: http://dev.gentoo.org/~phreak/4912_vs2.1.1-rc11-sendfile-fix02.patch works for me :) 1142100102 M * Bertl phreak``: okay, and together with the previous fix? 1142100120 M * Bertl FLOCK_VERIFY_WRITE/READ -> WRITE/READ ? 1142100129 M * phreak`` ah :) was just about to ask :) 1142100131 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net 1142100150 Q * rs Quit: rs 1142100152 M * Bertl well, we also have to check the implications on the CoW for that 1142100712 Q * shedi Quit: Leaving 1142101070 M * phreak`` Bertl: http://dev.gentoo.org/~phreak/4912_vs2.1.1-rc11-sendfile-fix02.patch still works for me (with the previous fix of course!) 1142101087 M * Bertl excellent! could you make a simple cow test for me? 1142101096 M * phreak`` sure, just tell me how :) 1142101118 M * Bertl hmm .. sec 1142101137 J * aradtech ~aradtech@h-72-245-0-9.lsanca54.dynamic.covad.net 1142101156 M * aradtech goodmorning everyone :) 1142101189 M * phreak`` morning aradtech .. 1142101197 M * aradtech I am trying to figure out which I should use in my gentoo install Vserver or OpenVZ anyone have any information on why to use one over the other? 1142101252 M * phreak`` aradtech: hrm, vserver is quite tested on Gentoo, while openvz is still being tested .. 1142101272 M * aradtech ok well stability is a good start :) 1142101280 M * Bertl hey aradtech! 1142101289 M * aradtech Hey Bertl :) and Phreak 1142101291 M * phreak`` aradtech: just be sure, to not merge vserver-sources-2.1.1_rc11 ATM .. 1142101301 M * aradtech ahh hehe which of course 1142101305 M * phreak`` otherwise you won't get that good results *g* 1142101307 M * aradtech was what I was gonna do 1142101316 M * aradtech hehe ok so which should I merge? 1142101322 M * Bertl rc10 for now 1142101336 M * Bertl rc12 in a few hours? 1142101341 M * aradtech I am a long time vmware user this stuff is all new to me looks a lot better for resource usage 1142101354 M * Bertl aradtech: it definitely is 1142101356 M * aradtech hehe ok so maybe I should wait a few hours? 1142101370 M * yang setting: bind [86.110.64.2] in proftpd.conf fails to start the server...? 1142101371 M * phreak`` aradtech: yeah, vmware is really bloated to virtualize a linux guest .. 1142101383 M * aradtech yeah hardcore bloated 1142101389 M * aradtech but easy for the masses 1142101393 M * Bertl yang: try 'Bind 86.110.64.2' instead 1142101435 M * aradtech ok anything else I should know gents , like kernel vers and such , does it work with nitro? 1142101437 M * Bertl aradtech: well, looking at the features, Linux-VServer and OpenVZ are quite similar (give or take a feature) 1142101451 M * aradtech Right which is why I was not sure which to go with 1142101472 M * aradtech but I like the tested stability aspect of Vserver on gentoo 1142101482 M * Bertl aradtech: if you look at the code, you will find that Linux-VServer has a much cleaner implementation 1142101510 M * aradtech ok seems to have more tools as well 1142101518 M * Bertl aradtech: but, if you want to have commercial support and/or 'buy' a product, you have to go with VZ 1142101570 M * yang Bertl: ok, now it started...but still when i connect on the "guest" proftpd, I get "host" proftpd login...? 1142101588 M * Bertl yang: what ip has the guest? 1142101597 M * yang Bertl: 86.110.64.200 1142101603 M * aradtech I'll go with Vserver for now brb lunch time! 1142101621 M * Bertl yang: and do you have a virtual host directive for that on the host? 1142101628 M * yang no 1142101648 M * Bertl yang: okay, try to restart the proftpd of the guest 1142101658 M * Bertl yang: check if that gives any error messages 1142101717 M * yang also, it says that i am starting proftpd from inetd...but there is no entry in /etc/inetd.conf for proftpd 1142101841 M * Bertl okay, let's check the following on the host: 1142101846 M * Bertl lsof -i | grep ftp 1142101854 M * Bertl (please upload if longer than 3 lines) 1142102076 M * yang well, now i think it will work 1142102089 M * Bertl ah, sounds good? 1142102136 J * zo9o ~zoom@cpc3-blfs6-0-0-cust45.belf.cable.ntl.com 1142102142 M * yang Restarting ProFTPD ftp daemon.. - getaddrinfo 'shells.prunk.be' error: Name or service not known ; - warning: unable to determine IP address of 'shells.prunk.be' ;- error: no valid servers configured ; - Fatal: error processing configuration file '/etc/proftpd.conf' 1142102143 M * Bertl welcome zo9o! 1142102166 M * yang now i have to wait for the hostname to come into cache... 1142102181 M * Bertl yang: or you can define it in /etc/hosts 1142102189 M * yang ok 1142102457 J * matt1 ~matta@c-68-32-239-173.hsd1.pa.comcast.net 1142102471 M * yang Bertl: well, each time i try to connect on "guest" it drops me on "host" proftpd... 1142102488 M * Bertl try the line I pasted: lsof -i | grep ftp 1142102501 M * Bertl and upload the output somewhere (if it is more than 3 lines) 1142102649 M * yang http://pastebin.com/596608 1142102696 M * Bertl okay, so it seems that you still have a few connections open to the guest ip 1142102719 M * Bertl and inetd (on the host) is listening to _all_ ips 1142102748 M * Bertl so I think your real issue is to restrict the inetd (or the ftp configuration for that) to the host IP 1142102772 M * Bertl but IMHO it would be simpler to just start the host proftpd as service and not via inetd 1142102802 M * yang yes 1142102814 M * yang so maybe i just change in the config to 1142102856 M * yang ServerType inetd ; ServerType standalone 1142102897 Q * matta Ping timeout: 480 seconds 1142103000 Q * matt1 Ping timeout: 480 seconds 1142103016 M * Bertl yang: yep, that might help, just restart it after that, and check with the beforementioned commands if it binds to * or just the host IP 1142103055 M * yang well, it was installed in a "inetd" mode, now it doesnt start as standwalone 1142103089 M * Bertl maybe it doesn't start because the 'inetd' version is still running? 1142103098 M * Bertl try to restart the inetd service too 1142103102 M * yang i had 1142103234 M * yang jason:/etc/interfaces# /etc/init.d/proftpd start 1142103234 M * yang Starting ProFTPD ftp daemon: proftpd 1142103244 M * yang but i cant connect now... 1142103251 M * harry ps aux|grep proftpd 1142103261 M * harry lsof -i :21 1142103277 M * yang Mar 11 19:53:36 jason proftpd[15693]: jason - Failed binding to 0.0.0.0, port 21: Address already in use 1142103277 M * yang Mar 11 19:53:36 jason proftpd[15693]: jason - Check the ServerType directive to ensure you are configured correctly. 1142103277 M * yang Mar 11 19:53:44 jason proftpd[15696]: connect from 86.110.64.2 (86.110.64.2) 1142103296 M * harry there we go 1142103308 M * harry allready smth hogging your port 21 1142103340 M * Bertl yang: alternatively you can add a bind directive to inetd (assuming xinetd here) 1142103350 A * harry off 1142103354 M * harry cya'll later 1142103355 M * Bertl cya 1142103358 M * yang inetd 15121 root 4u IPv4 65551221 TCP *:ftp (LISTEN) 1142103359 M * yang ftp 15695 yang 4u IPv4 65552117 TCP tnib.prunk.be:44564->tnib.prunk.be:ftp (CLOSE_WAIT) 1142103373 M * yang well i restarted inetd and it still says ftp runs there 1142103396 M * Bertl yang: what distro? 1142103400 M * harry debian 1142103408 M * Bertl does that have chkconfig? 1142103416 M * harry don't know 1142103422 M * harry don't think so 1142103428 M * yang ok now it will work 1142103430 M * Bertl yang: well, if you have a command called chkconfig 1142103434 M * harry they do have an update-rc.d 1142103439 M * yang seems like it didnt restart before well 1142103446 M * Bertl ah, good :) 1142103481 J * shedi ~siggi@inferno.lhi.is 1142103484 M * yang ok now its running as a standalone on the host 1142103494 M * yang but still drops me there 1142103531 M * yang nobody 16203 0.0 0.2 4760 2364 ? Ss 19:57 0:00 proftpd: (accepting connections) 1142103531 M * yang yang 16209 0.0 0.1 2672 1200 pts/48 S+ 19:57 0:00 ftp 1142103531 M * yang nobody 16210 0.0 0.2 4860 2504 ? S 19:57 0:00 proftpd: connected: 86.110.64.200 (86.110.64.200:44108) 1142103599 M * Bertl what does 'lsof -i | grep ftp' say on the host now? 1142103610 M * yang and in my "guest" i have Bind 86.110.64.200 setting 1142103621 M * Bertl yang: that's not neccessary 1142103629 M * Bertl yang: but it doesn't hur 1142103747 M * Bertl *hurt 1142103761 M * yang this lsof takes ages....bind seems to listen on every IP 1142103798 M * yang jason:/etc/interfaces# lsof -i | grep ftp 1142103798 M * yang proftpd 16203 nobody 0u IPv4 65552957 TCP *:ftp (LISTEN) 1142103817 M * Bertl so still bound to all IPs :/ 1142103865 M * yang weird, its not accepting the Bind option 1142103899 M * Bertl check if it is in the right place and so 1142103935 M * yang i put it on the end of the config 1142103990 M * yang Cause of too much confusion this directive has been deprecated with Proftpd 1.3.0rc1. 1142104007 M * yang i run 1.2.10 1142104061 M * Bertl try setting the SocketBindTight stuff 1142104181 M * Bertl http://www.proftpd.org/docs/directives/linked/config_ref_SocketBindTight.html 1142104184 M * yang Restarting ProFTPD ftp daemon.proftpd 1142104184 M * yang ..jason - SocketBindTight in effect, ignoring DefaultServer 1142104204 M * yang hmmm 1142104216 M * Bertl check again with lsof 1142104217 M * yang now i dont get any output on lsof -i | grep ftp 1142104252 M * Bertl now you probably need a virtual host or whatever directive 1142104254 M * yang seems the proftpd doesnt start 1142104320 M * yang ahhh 1142104327 M * yang no 1142104343 M * yang lets continue some other day 1142104364 M * Bertl okay, but you guest's proftpd will now work 1142104446 M * yang yeah that is true:) 1142104474 M * yang thanks Bertl 1142104495 M * Bertl so once you figure how to have the host's ftpd bind to host addresses only, or you add some bind to xinetd, or you use the v_ftp wrapper, you should get both working 1142104502 M * Bertl yang: you're welcome! 1142105181 T * Bertl http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc12 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | 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 ;) 1142105217 M * Bertl so rc12 should fix both issues, but I just realize that I missed the s390 fix again (at least I think so) 1142105223 M * daniel_hozac lol 1142105248 M * daniel_hozac namespace for 2.0.2, sendfile for 2.1.1? 1142105256 M * Bertl yup 1142105632 M * Bertl bonbons: I will have a deeper look at the ipv6 stuff pretty soon 1142105717 M * bonbons I'm trying to get some time over the week-end to continue working on it too 1142107236 M * Hollow bonbons: did you, by any chance try v-u 1.0* on rc12? 1142107278 M * daniel_hozac oh right, v-u is supposed to work on stable now. 1142107286 M * Hollow :P 1142107303 M * bonbons Hollow: no, not yet, the box with rc* is currently locked at rc10, building for a celeron466 1142107332 M * Hollow ok, but you plan to test it? so i can test only trunk, don't have much time atm 1142107356 M * bonbons Yep, will test it some time this week-end 1142107366 M * Hollow fine :) 1142107379 M * bonbons will need to do a few little changes too, to work around current limitation that BCAPS can only be removed 1142107436 M * daniel_hozac just set it to ~0 all the time? 1142107459 M * bonbons vcontext by default creates context and reduces bcaps to minimim, and vps.sh tries to readd what's required later on (and that fails) 1142107474 M * Hollow ok, will try to test and look through the new code, and we'll see if we can release 1.0.4 in the next few weeks 1142107511 M * Hollow bonbons: did you see the changes in libvserver trunk for VC_INSECURE_BCAPS? 1142107533 M * bonbons no 1142107564 M * Hollow i added a define to vserver.h so one can easily remove the insecure bcaps, everything else should be done by the user 1142107572 M * Hollow manuyll or by config 1142107596 M * Hollow wait 1142107601 M * bonbons releasing in the next time should be possible (I did mostly test the basics, create/enter/login/start/stop guests, not limits & co) 1142107605 M * Hollow i added it to v-u trunk of course 1142107606 M * Hollow in vc.h 1142107675 M * bonbons I think I will alter vcontext a bit so it has minimal defaults, but merges commandline input instead of overriding, and will put caps application directly at context creation 1142107683 M * Hollow guess i have some time tomorrow, so will look at the branch and play around with it 1142107697 M * Hollow yup, sounds good... 1142107737 M * Hollow also check references to chroot... they should always appear before vx_migrate as enrico pointed out on the ml 1142107759 M * Hollow iirc i have done this wrong ever since 1142107760 M * Hollow :) 1142107760 M * bonbons I saw that, and did a few fixes for that 1142107764 M * daniel_hozac wouldn't it make sense to make a generic vc_enter function? 1142107776 M * daniel_hozac that does all the right things, in the right order? 1142107779 M * Hollow daniel_hozac: probably 1142107814 M * Hollow will implement things like that in trunk, but the 1.0* branch is out of that scope imo 1142107865 M * bonbons Hollow: currently 1.0.* branch is aligned to trunk libvserver, so it that vs+enter function goes to libvserver it can catch up easily 1142107916 M * Hollow libvserver trunk will be released shortly, just have to check the new scheduler interface wrt compatibility 2.0 <-> 2.1 1142107922 M * Bertl Hollow: IIRC, you wanted to test your tools with stable, right? 1142107932 M * Hollow Bertl: yep, will do that 1142107955 M * Hollow but i'll test only trunk, whereas bonbons will do it for the 1.0* branch 1142108010 M * bonbons Would need to see what limitation stable has :) especially on the init thing :) 1142108037 M * daniel_hozac 2.0.2-rc11+ should have everything you need. 1142108046 M * daniel_hozac or at least that was the intention. 1142108047 M * Hollow bonbons: i already told bertl all features missing, at least i couldn't think of any more.. 1142108055 M * Hollow daniel_hozac: indeed 1142108077 M * bonbons Ok, so that will be a big todo-list for tomorrow 1142108455 M * bonbons Hollow: I see no change on SVN for v-u trunk, and my last update is quite "old" 1142108493 A * Hollow goes look 1142108495 M * Hollow ing 1142108644 M * Hollow http://dev.croup.de/proj/vserver-utils/changeset/110#file13 1142108660 M * Hollow last hunk 1142108689 M * bonbons so change is already quite old :) 1142108710 A * Hollow nods 1142109429 J * matta ~matta@66.216.160.94.dynamic.dejazzd.com 1142109499 J * matt1 ~matta@71.224.125.126 1142109515 M * Bertl hey matta's! 1142109887 M * bonbons Hollow: I got an issue with vu_printf: if I have multiple 64bit items (e.g. "1: %lx 2: %lx 3: %lx 4: %lx") the resulting string is incorrect 1142109917 Q * matta Ping timeout: 480 seconds 1142109933 M * daniel_hozac %lx isn't 64-bit, unless you're on x86_64. 1142109982 M * Bertl yup, careful with %l %ll and %L 1142110045 M * daniel_hozac is long long 64-bit on 64-bit archs too? 1142110059 M * bonbons hm, that would explain it 1142110163 M * daniel_hozac you might want to use ATTRIBUTE_PRINTF so you'll get warnings about that sort of thing. 1142110201 M * bonbons -WATTRIBUTE_PRINTF to gcc? 1142110223 M * daniel_hozac no, ATTRIBUTE_PRINTF(n,m) in the declaration of the function. 1142110250 M * Bertl as usual, wikipedia has a page :) 1142110254 M * Bertl http://en.wikipedia.org/wiki/Integral_data_type 1142110282 Q * matt1 Ping timeout: 480 seconds 1142110309 M * Bertl note, there are no _max_ guarantees 1142111056 M * daniel_hozac Bertl: will you add a vc_set_bcaps or similar for 2.0.2? or should i submit my vattribute-resets-bcaps patch to savannah? 1142111121 M * Bertl I think one is not related to the other 1142111142 M * Bertl but I will not add a new command to 2.0.2 now 1142111174 M * daniel_hozac well, the vattribute issue is due to the vc_set_ccaps lack of bmask. 1142111174 M * Bertl we will very likely add such a command to 2.1.1 or later 1142111203 M * Bertl daniel_hozac: yeah, but this is so since 2.0 or am I wrong? 1142111214 M * daniel_hozac yep. 1142111220 M * Bertl i.e. it is the _stable_ interface 1142111271 M * daniel_hozac ok, so i'll submit it. 1142111280 M * Bertl yes, please 1142111381 M * bonbons Bertl: is the init-migration (pid=1) in stable? 1142111573 M * Bertl you mean the new migration code? 1142111601 M * bonbons yep 1142111624 M * Bertl http://vserver.13thfloor.at/Experimental/delta-init-stab01.diff (looks like :) 1142111648 M * bonbons ok :) 1142111719 M * bonbons Hollow: for libvserver do you also [plan] support [for] "older" kernel syscall versions? 1142111785 M * Hollow not sure how to handle it, but we need to find a solution wrt the new scheduler syscall in 2.1 1142111788 M * Bertl ah, we should probably bump the announced interface version 1142111814 M * Bertl so _assume_ for now that 2.0.2 has a higher version than rc12 now 1142112573 M * coocoon Bertl: hello working hard I see, but a little question to this page should I create here http://linux-vserver.org/SuseVserverHowTo a patch by myself 1142112614 M * coocoon Bertl: or put it in the verserver.start (whate I wanted to know is below 1142112710 M * coocoon Bertl: and when is there no risk 1142112806 M * Bertl the patch on this page is requred to make it work with suse guests? 1142112829 Q * Hunger helium.oftc.net arion.oftc.net 1142112829 Q * meandtheshell helium.oftc.net arion.oftc.net 1142112829 Q * Wonka helium.oftc.net arion.oftc.net 1142112829 Q * tokkee helium.oftc.net arion.oftc.net 1142112829 Q * SiD3WiNDR helium.oftc.net arion.oftc.net 1142112829 Q * tam helium.oftc.net arion.oftc.net 1142112829 Q * waldi helium.oftc.net arion.oftc.net 1142112829 Q * micah helium.oftc.net arion.oftc.net 1142112829 Q * mire helium.oftc.net arion.oftc.net 1142112829 Q * eyck helium.oftc.net arion.oftc.net 1142112840 M * coocoon Bertl: they work but have some updfate problems 1142112847 J * Hunger Hunger.hu@Hunger.hu 1142112865 M * coocoon Bertl: maybe it depends on suse 1142112885 M * Bertl coocoon: I didn't quite get what you were trying to tell me, let's try again, maybe in smaller pieces? 1142112972 M * coocoon Bertl: I think I do not need this patch, because of my suse guests are working, u right with u r question "the patch on this page is requred to make it work with suse guests?" 1142113016 M * Bertl ah, so your guest work without that patch, right? 1142113053 M * coocoon Bertl: yes, but I wanted to solve everything, but I think doing this is more critical than it will help 1142113053 M * Bertl maybe your guests use 'plain' init style instead of 'sysv'? 1142113067 M * coocoon Bertl: yes I use plain 1142113083 M * Bertl looks to me like the patch fixes a 'sysv' issue 1142113104 M * Bertl i.e. the case where the guest scripts are started from outside, not from init 1142113112 M * coocoon Bertl: oh ok thanx 1142113135 M * Bertl I don't know that for sure, but it would be my guess 1142113172 M * Bertl so maybe try with changing your guest to sysv, and if that doesn't work, if it works with that patch 1142113191 M * coocoon Bertl: so I do not patch it 1142113256 M * Bertl the difference between plain and sysv is that the former starts a _real_ init inside, where the latter gives nice startup/shutdown messages :) 1142113548 M * coocoon Bertl: I am wondering why most of the vservers starts only after set plain 1142113552 M * coocoon setting 1142113580 M * Bertl well, probably _because_ the patch is missing? 1142113622 M * Bertl if this is really a suse related issue, maybe somebody should submit that patch to savannah 1142113644 M * daniel_hozac well, it would be much better to set it in vserver.functions:prepareInit. 1142113652 M * coocoon Bertl: no it isn't I mean other distros too I have watched it 1142113668 M * daniel_hozac coocoon: what errors do you get? 1142113716 M * Bertl I basically always use the sysv init, and it works for me ... 1142113721 M * daniel_hozac me too. 1142113760 M * Bertl we know that gentoo has no 'sysv' style atm 1142113767 M * coocoon when I erase init/style plain start a suse vserver no messages, at other distros i have got messages that it is Fc or redhat related 1142113826 M * coocoon now with suse 9.0 i got after setting sysv "find: var/lock: Datei oder Verzeichnis nicht gefunden" 1142113871 M * coocoon with other distros I can't say it actually if u wanna know I can untar it 1142113902 Q * zo9o Quit: 1142113919 M * coocoon is it better to use sysv than plain 1142113923 M * Bertl coocoon: maybe you get the _same_ message with plain, you just don't see it? 1142113936 M * coocoon :-) 1142113937 M * Bertl maybe var/lock is really missing? 1142113945 M * coocoon hm but with plain the vserver starts 1142113968 M * Bertl I'm just speculating ... I don't know your setup :) 1142113976 M * daniel_hozac var/lock is part of the vserver cleanup. 1142113988 M * coocoon my vserver-stat http://pastebin.com/596937 1142113994 M * coocoon after starting it 1142114001 M * coocoon with sysv 1142114049 M * coocoon vserver suse9.0 stop --> vserver 'suse9.0' is not running but I have started it 1142114096 M * coocoon it is not a problem if plain is also good, I am content with plain ;-9 1142114103 M * coocoon ;-) 1142114115 M * daniel_hozac if you use plain, are there any processes running? 1142114129 M * daniel_hozac other than init. 1142114199 Q * aradtech Quit: Leaving 1142114202 M * coocoon http://pastebin.com/596951 1142114471 M * coocoon another thing which is maybe interesting for installing suse vserver guests I am using util-vserver-30.208, because of after "failled instakllation" (it works really), the guest weren't removed, as in 209 and 210 1142114484 M * coocoon -k 1142114517 M * Bertl hmm? 1142114557 M * coocoon Bertl: after updating to 209 I got mad but I must say I like the vserver page because of history 1142114566 M * coocoon ;-9 1142114569 M * coocoon ;-) 1142114590 M * daniel_hozac vserver ... build --keep 1142114621 M * coocoon really if there appears failures during installation, the utils after 208 removed all of the installed files and the folders 1142114903 J * matta ~matta@66.216.160.94.dynamic.dejazzd.com 1142114944 M * Bertl coocoon: ah, well, if it works for you ... 1142114969 M * coocoon yes 1142115010 M * coocoon but why is these 'feature' not implemented anymore 1142115048 M * Bertl which one? the --keep daniel mentioned? 1142115129 M * bonbons Hollow: BCAPS now work as expected in 1.0.* branch, did you already (partially) port testme.sh to v-u (1.0.* style)? 1142115156 M * coocoon I don't know but that also a failled installation stays because of most of them works, if I install suse guests there appears a lot of errors after that, but with some working it works 1142115174 M * coocoon and also the guests starts at the beginning, why remove them 1142115333 M * Hollow bonbons: no 1142115342 M * Hollow didn't even look at it tbh 1142115393 M * bonbons should be done at some time, to do kind of dual check ;) test v-u and kernel 1142115416 M * Hollow .oO(test-suite) 1142115486 M * bonbons yep, full test-suite is for longer-term 1142115566 M * Hollow we should do a vserver coding camp *g* 1142115614 M * bonbons that would be a nice thing for some programming class *g* 1142115627 Q * matta Ping timeout: 480 seconds 1142115684 Q * FireEgl Ping timeout: 480 seconds 1142115708 J * FireEgl Atlantica@Atlantica.Tcldrop.Com 1142117741 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net 1142118024 Q * bonbons Quit: Leaving 1142118415 J * Wonka debian-tor@chaos.in-kiel.de 1142118415 J * tokkee tokkee@casella.verplant.org 1142118415 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1142118415 J * tam ~tam@nettam.com 1142118415 J * waldi ~waldi@bblank.thinkmo.de 1142118415 J * micah ~micah@69.90.134.205 1142118415 J * mire ~mire@79-166-222-85.COOL.ADSL.VLine.Verat.NET 1142118415 J * eyck eyck@81.219.64.71 1142118628 M * coocoon good night 1142118632 M * coocoon to all 1142118634 Q * coocoon Quit: KVIrc 3.2.0 'Realia' 1142119171 M * daniel_hozac Hollow: http://daniel.hozac.com/vserver/util-vserver-0.30.210-vlogin.patch 1142120072 M * waldi Bertl: util-vserver uses a broken clone wrapper. on s390 the first parameter is the stack, the second the flags 1142120138 M * Bertl it is the dietlibc one, yes? 1142120163 M * Bertl strange, because IIRC it worked fine when I tested with hercules 1142120177 M * waldi no 1142120181 M * waldi it uses its own 1142120207 M * Bertl aha, okay, maybe that is new 1142120212 M * waldi lib_internal/sys_clone.h 1142120236 M * waldi dietlibc don't export clone, even if it defines it in the headers 1142120341 M * Bertl ah, okay ... please file a bug reaport to savannah so that it isn't lost 1142120404 Q * hw Quit: cya 1142121008 M * waldi and it violates the: never use the _syscallX macros 1142121055 M * Bertl hmm, the syscall macros should be correct 1142121068 M * waldi no, they are only for the libc 1142121070 M * Bertl if not, then please let me know 1142121080 M * Bertl no, they are my asm code :) 1142121097 M * Bertl at least I hope so ... otherwise try changing the configure options 1142121148 M * waldi i don't think you wrote asm-s390/unistd.h 1142121154 M * Bertl http://vserver.13thfloor.at/Stuff/SYSCALL/syscall.h 1142121159 M * Bertl this should be used 1142121169 M * Bertl if not, then the configure options are wrong 1142121198 M * Bertl trust me, I wrote it because most glibc implementations are slightly wrong 1142121239 M * daniel_hozac Hollow: seems to work fine. 1142121308 M * Bertl waldi: what does vserver-info - SYSINFO output? 1142121330 M * Bertl vserver(2) syscall#: 273/fallback 1142121346 M * Bertl this is the important line, if it says fallback, then its fine 1142121357 M * waldi vserver(2) syscall#: 263/fallback 1142121357 M * Bertl syscall(2) invocation: alternative 1142121364 M * waldi syscall(2) invocation: alternative 1142121365 M * Bertl and this should say alternative 1142121378 M * Bertl precisely, so you should _not_ be using glibc code :) 1142121412 M * Bertl haven't checked if enrico uses those wrappers for the clone call though 1142121428 M * Bertl but for the vserver call, they should be in use 1142121441 M * Bertl daniel_hozac: do you know if the clone is done separately? 1142121519 M * daniel_hozac it should use the alternative code too. 1142121529 J * rs ~rs@vol75-7-82-229-177-124.fbx.proxad.net 1142121588 M * Bertl waldi: so, what might be true is that sys_clone() is defined differently for s390 than for x86 and Enrico overlooked that fact