1105056220 M * we2by yep 1105056224 M * we2by read and write 1105056229 M * we2by one for read 1105056235 M * we2by and one read+write 1105056437 M * Bertl you do not use xid tagging, I guess? (which kernel version) 1105056659 M * Hollow lo all 1105056787 M * Bertl welcome Hollow! 1105056810 M * Hollow hey Bertl, sorry for being absent so long... not much time lately 1105056940 M * we2by Bertl, 2.4.28 1105056968 M * Hollow but i have soem news.. today i became gentoo dev and i started triggering vserver developement on gentoo (see http://article.gmane.org/gmane.linux.gentoo.devel/23881) 1105057017 M * Bertl hmm, sounds good ... 1105057053 M * we2by Bertl, is it posible? 1105057060 M * Bertl we2by: try mount --bind /path/to/some/dir /path/to/vserver/dir 1105057069 M * we2by sorry if I take long to reply 1105057073 M * we2by I;m a bit busy 1105057076 M * Bertl (for each vserver) and avoid tagxid ... 1105057081 M * we2by k 1105057095 M * we2by mhhh 1105057103 M * we2by that;s a problem 1105057119 M * we2by if user a rooted vserver1, he can mount /vserver/2 1105057127 M * we2by so, he can access vserver2 file system 1105057156 M * we2by isn;t that so? 1105057175 M * Bertl well, you can not mount as root inside vserver/1 1105057183 M * Bertl (at least not with sane capabilities) 1105057223 M * we2by Bertl, I have to run the mount in the vserver? 1105057235 M * Bertl no, you do it on the host 1105057243 M * we2by ahhh 1105057252 M * we2by I see 1105057254 M * we2by cool 1105057259 M * Bertl and you do it before you start the vserver 1105057268 M * we2by yea, 1105057295 M * we2by that;s read or read+write? 1105057317 M * Bertl that's whatever the original dir is ... 1105057433 M * we2by cool 1105057908 M * Bertl but as I said, be careful not to use xid tagging with such a setup 1105057956 Q * Hollow Quit: Leaving 1105057962 J * Hollow ~Hollow@home.xnull.de 1105058011 M * we2by Bertl, xid tagging? 1105058641 M * Bertl if you don't know what I'm talking about, then it's probably fine ... 1105058653 M * we2by :) 1105061879 Q * monrad Quit: Leaving 1105063026 J * chrish01 ~chrish01@69.90.131.10 1105063084 M * Bertl welcome chrish01! 1105063094 M * chrish01 hey dude 1105063129 M * chrish01 im building a new kernel package right now...so hopefully i can test some stuff out soon 1105063169 M * Bertl well, IMHO for testing a kernel source tree is far superior to a kernel package ... 1105063188 M * chrish01 i just do a package so i can ssh it easily to the server 1105063196 M * chrish01 server is much slower than my dev box 1105063229 M * Bertl building it monolithic would allow you to ssh just the bzImage ;) 1105063246 M * chrish01 very true 1105063290 M * chrish01 Bertl, met with some investors and they would really like us to see where vserver goes for our needs...looks like the cash may start rolling :) 1105063307 M * Bertl sounds good to me ;) 1105063311 M * chrish01 yup yup 1105063580 M * Bertl Doener: still around? 1105063852 M * Doener partly ;) 1105063882 M * Bertl k, just when you get around ... 1105063886 M * Bertl http://vserver.13thfloor.at/Stuff/delta-2.4.28-vs1.29-vs1.29.1.diff 1105064296 M * Doener looks good... why the change from IS_IMMUTABLE_LINK(inode) to ((inode)->i_flags & S_IMMUTABLE_LINK)) ? 1105064438 M * Bertl because this conforms to the 'original' definition of the 'extended' barier, i.e. IUNLINK flag 1105064462 M * Bertl where IS_IMMUTABLE_LINK is actually IUNLINK ^ IMMUTABLE 1105064496 M * Bertl (so we don't care about IMMUTABLE here anymore ;) 1105064522 M * Doener ok 1105064528 M * Bertl but as a sidenote: recent util-vserver (alpha) seem to get the barrier wrong ... 1105064549 M * Bertl not sure if this is the kernels fault or the tools ... 1105064557 M * Doener in which way? 1105064593 M * Bertl setattr --barrier /dir does .. chmod 000 and sets the immutable flag 1105064618 M * Bertl showattr -d /dir shows ----Bu--- 1105064641 M * Bertl where the former is wrong, and the latter is misleading 1105064677 M * Bertl doing chattr -i /dir and setattr --iunlink /dir fixes it ;) 1105064727 M * Bertl needs some investigation, and then a bug report I guess .... 1105064745 M * Bertl anyway .. nap attack! ;) 1105064756 M * Bertl cya later folks ... 1105064764 N * Bertl Bertl_zZ 1105064764 M * Doener night! 1105065101 N * Doener Doener_zZz 1105066145 Q * elCount Ping timeout: 480 seconds 1105066410 Q * ndim Ping timeout: 480 seconds 1105066744 J * ndim U2FsdGVkX1@helena.bawue.de 1105070120 Q * chrish01 Quit: Quit XChat 1105070361 J * chrish01 ~chrish01@69.90.131.10 1105070547 Q * chrish01 Quit: 1105070703 J * chrish01 ~chrish01@69.90.131.10 1105073218 J * nox- ~nox@213.39.207.157 1105073460 Q * nox Ping timeout: 480 seconds 1105073517 N * nox- nox 1105073704 N * Bertl_zZ Bertl 1105073709 M * Bertl morning folks! 1105074058 M * chrish01 hehe morning Bertl 1105074068 M * chrish01 didnt you leave just a few hours ago lol 1105074102 M * Bertl yes, but I woke up a few minutes ago ... ;) 1105074106 M * chrish01 nice 1105074121 M * Bertl so I'll be around a little, and then off to bed again I guess ... 1105074124 M * chrish01 i got a context bootstrapping right now...kernel seems to work well. i got vnet tools too 1105074183 M * Bertl good, check out the vnet3_setup.sh script, adapt it to your 'local' network config 1105074206 M * chrish01 yea, im building two contexts so i can test that 1105074231 M * Bertl (it basically assumes that there is a local network 192.168.0.x with an external machine 192.168.0.1 and two vserver contexts at 192.168.0.2 and .3) 1105074243 M * chrish01 yup yup 1105074264 M * chrish01 i can come up with some crazy applications of this to stress test it 1105074291 M * chrish01 like local VOIP conference call between 3 contexts lol 1105074340 M * Bertl well, I guess it will work fine (regarding stress testing) but there are some yet unsolved issues (like the missing virtual switch) and it requires certain changes in the config/setup process for the tools ... 1105074385 M * chrish01 does the virtual switch keep traffic from going between contexts? 1105074434 M * Bertl yep, currently the two 'contexts' are isolate against each other ... but they can both speak to the external machine 1105074464 M * chrish01 hmm...i might take a stab at that after i get familiar with the source and how this works 1105074496 M * Bertl basically the missing pieces are: a) a local (virtual) arp responder, and b) the packet switch (for context crosstalk) 1105074539 M * Bertl I'm not sure what the best implementation is there, so I didn't implement anything in this regard ... 1105074541 M * chrish01 ah, so for b, we need to make it so context 2 can talk to 3 withouth 1 knowing? 1105074569 M * Bertl yes, but that part is already working (in theory) 1105074598 M * Bertl it's more the 'selection' criterion and the neigh management 1105074624 M * chrish01 hmm 1105074633 M * Bertl basically I could short circuit some stuff there, but that would make the contexts behaviour less realistic ... 1105074668 M * chrish01 yea 1105074682 M * chrish01 brb...gonna raid the kitchen 1105074694 M * Bertl good idea ;) 1105079659 J * jfmrec ~jf.meyer@230.239-200-80.adsl.skynet.be 1105079780 M * Bertl welcome jfmrec! 1105079789 M * jfmrec Can somebody give indication on how to avoid /proc mount error and acces error with vserver 1.9.3 on kernel 2.6.9 distribution mandrake? 1105079853 M * Bertl http://linux-vserver.org/Linux-Vserver+FAQ (I.1) 1105079892 M * Bertl http://linux-vserver.org/Proc-Security 1105080229 M * eyck 1.2.10 1105080241 M * Bertl tx 1105080690 M * Bertl jfmrec: does that work for you? 1105080826 M * jfmrec I have to check how to enable/disable the feature. I would have search a simple way to disable /proc usage at first. 1105080846 M * Bertl yep, you can simply disable the feature at compile time 1105080869 M * jfmrec I try to do so. Thanks! 1105080884 M * Bertl (just do not select CONFIG_VSERVER_PROC_SECURE) 1105080903 M * Bertl but the proc security is there for good reason ... 1105080936 M * Bertl somebody with vserver root could easily mess up your host system, with a fully visible/accessible proc 1105080967 M * jfmrec That's why I want to disable it completely 1105080978 M * Bertl hmm? 1105080986 M * Bertl you want to disable /proc? 1105081017 M * jfmrec If it is not mandatory for the kernel to work, yes. 1105081033 M * Bertl no, for the kernel not, userspace normally requires it ... 1105081050 M * Bertl (that is why you get the misleading proc not mounted messages) 1105081071 M * jfmrec Ok, thus I have to tailor it the correct way. 1105081163 M * jfmrec Thanks, I have to leave now I will give feedback later. 1105081167 M * Bertl cya 1105081180 Q * jfmrec Quit: 1105082754 M * sannes Bertl : there? 1105082760 M * Bertl yep 1105082763 M * sannes just tried to do an update on the production server :) 1105082771 M * sannes upgraded the BIOS to newest (beta release) 1105082795 M * Bertl and? 1105082809 M * sannes and did the 2g/2g, and disabled highmem 1105082827 M * sannes now both my network devices worked like a charm and all and the dmesg was different.. 1105082833 M * sannes and everything seemed to work just fine.. 1105082839 M * Bertl until? 1105082849 M * sannes until I got a kernel panic.. 1105082861 M * sannes which is great, because earlier I only got a freeze.. :) 1105082876 M * sannes but, I didn't have my cam of course, so I have typed it down.. 1105082886 M * Bertl hmm .. k 1105083006 M * sannes Bertl : where are you located exactly? 1105083025 M * Bertl in Austira, Europe 1105083039 M * sannes what is the time there? 1105083052 M * Bertl 8:30am 1105083109 M * sannes morning then :) 1105083127 M * Bertl yeah, I'm off to bed soon ... ;) 1105083238 M * chrish01 Bertl: we remember how that went last time you said that :) 1105083254 M * sannes Bertl : http://www.sannes.org/panics/panic.txt <-- very short and readable .. hehe 1105083337 M * Bertl hmm, kmem_cache_alloc ... very interesting ... 1105083358 M * sannes it seems to me it happens about the same time it should start swapping some pages out.. 1105083385 M * Bertl hmm, you have swapping enabled, right? 1105083387 M * sannes anyways, can't test until after 16:00 (when most people end their jobs) on that hardware.. 1105083391 M * sannes swapping enabled yes.. 1105083405 M * sannes tried to use another swapping partition.. just in case.. heh 1105083493 M * sannes anyways, you should sleep now.. heh, I'll look around, havn't had the time to google it even yet (just got back, was up 0530 to try the bios upgrade out) 1105083497 M * Bertl k, do you have the kernel source tree at hand? 1105083502 M * sannes yes :) 1105083532 M * Bertl hmm, try 'addr2line -e vmlinux 083e2490 083e2490 80140fb3' 1105083545 M * sannes tried addr2line -e vmlinux 80146f4b on it, just gave ??:00... ah, but I was mistaken just two secs 1105083592 Q * _are_ Quit: Disconnecting 1105083610 M * sannes just ??:0 on all of them.. 1105083611 M * sannes sorry 1105083629 M * sannes do I have to enable anything to make the symbols available? 1105083633 M * Bertl hmm, you did disable the kernel debug info again? 1105083643 M * sannes .. 1105083652 M * Bertl (or wasn't it enabled at all?) 1105083669 M * sannes never enabled on that computer.. 1105083706 M * Bertl well, happens ... 1105083751 M * sannes "Compile the kernel with debug info" ? 1105083760 M * Bertl yep, that's the option 1105083773 M * sannes because I wasn't able to boot on other computers with any of the debugging enabled.. 1105083834 M * sannes ok, but they panic is really easy to reproduce so it isn't really a problem, willt ry again with debugging later today.. 1105083844 M * sannes (and I'll grab my cam this time.. heh) 1105083858 M * Bertl hmm, if so, please enable the slab debugging too ... 1105083892 M * sannes isn't that really really slow? I'll compile up one for that too to test.. 1105083921 M * Bertl yeah, it's really really slow, but maybe it's catching something ... 1105083937 M * Bertl anyway if you _can_ reproduce it, it should be easy to locate 1105083944 M * sannes wouldn't hurt :) 1105083963 M * sannes I wonder if my eatmyram program will trigger it, that would be neat.. heh 1105083979 M * sannes (just mallocing and writing to ram until it is killed) 1105083994 M * Bertl well, if so, the better ... 1105084014 M * sannes because now I just fire up alot of vservers .. 1105084059 M * sannes (all of them comes up cleanly by the way) 1105084257 M * Bertl CONFIG_DEBUG_PAGEALLOC <-- this is what we actually want 1105084313 M * Bertl sannes: do you use the ACPI enumeration patch there too? the one which fixed the silent slab corruption? 1105084482 M * sannes yes :) 1105084574 M * sannes copying a source tree takes forever when you are rebuilding a mirror.. heh 1105084594 M * Bertl hmm, why do you copy it? 1105084616 M * sannes ok, got one tree with debug info on, and one with debug info + debug page alloc 1105084629 M * Bertl okay, sounds good ... 1105084657 M * sannes so I can keep tabs on them if you need some info from them later.. 1105084669 M * Bertl cp -la helps here a lot ... 1105084692 M * Bertl but maybe copying it is safer ... 1105084831 M * sannes Use 4Kb for kernel stacks instead of 8Kb .. should I disable this? 1105084839 M * Bertl not yet ... 1105084905 M * sannes I'll probably have some great screenshots for you later today then.. hehehe :) 1105084997 M * sannes anyways, for those who always wonder where they should get a bootdisk in these days where no-one is running windows.. freedos is the answer! :) worked like a charm :) 1105085021 M * Bertl yep, using it too for such porposes ... 1105085075 J * _are_ ~are@gateway-dsl.lihas.de 1105085078 M * sannes I was really surprised it was soo good.. well not really, .. but relieved I didn't have to get one of those ms-dos images.. heh 1105085158 M * _are_ hi 1105085172 M * Bertl hey _are_! 1105085369 M * sannes OPmorning _are_ :) 1105085524 A * sannes was so happy that it wasn't a complete freeze today, feel like I'm getting somewhere.. 1105085864 M * sannes .. that there is hope.. hehehe :> 1105085875 M * sannes Bertl : shouldn't you be sleeping? :) 1105085885 M * Bertl well, I'm not convinced that your hardware is okay ... 1105085972 M * Bertl yep, you are right ... off to bed ... 1105085980 M * sannes MPS 1.4 was on, and pnp os .. not that I've enabled ACPI PNP (it was marked experimental) .. 1105086001 M * Bertl night everyone! 1105086002 M * sannes and I've ran memtest86 for days on that computer before without hickup.. 1105086004 M * sannes night! :) 1105086007 N * Bertl Bertl_zZ 1105086575 Q * BWare Ping timeout: 480 seconds 1105086844 Q * Hollow Quit: Leaving 1105086884 J * Hollow ~Hollow@home.xnull.de 1105087182 M * meebey hi all 1105087190 M * meebey I need some cron magic, can someone help me? 1105087198 M * _are_ hi meebey 1105087208 M * meebey its about random runtimes 1105087211 J * BWare ~bware@212.26.196.110 1105087220 M * meebey 5 vservers on one host, all run at the same time 1105087227 M * meebey the daily cron is very bad 1105087232 M * meebey load average of 4 1105087256 M * meebey I don't want to hardcode the times, because I swap the vservers sometimes 1105087263 M * meebey so some cron random magic would be cool 1105087275 M * _are_ at first sight not possible 1105087286 M * sannes I'm guessing it is running updatedb? 1105087294 M * _are_ at a second lance: 'at' has a possibility to only run a job if load is below n 1105087308 M * sannes heh, but they all start at the same time, heh... :> 1105087330 M * sannes meebey : you could change you /etc/localtime so the crontabs will be off.. 1105087334 M * _are_ well, replace the start procedure by a sleep with a random time and then an at-job in 1 minute or similar 1105087345 M * sannes but then again.. your clocks will be off.. 1105087380 M * meebey are's solution sounds better 1105087396 M * sannes that'll work, sleep somethingthatgivesrandomtime 1105087425 M * _are_ yes, just looking if there is a standard binary giving a random *number* 1105087427 M * sannes but 4 in load isn't so bad.. 1105087460 Q * sannes Read error: Connection reset by peer 1105087473 M * meebey sleep $(($RANDOM % (3*60*60))) 1105087477 M * meebey something like that? 1105087478 M * _are_ well, updatedb = load 1, 10 servers -> load 10 1105087496 M * _are_ yes 1105087507 J * sannes ~ace@home.skarby.no 1105087510 M * sannes .. he could make one, use perl, python .. whatever.. 1105087513 M * _are_ but you can do a by far slower amount of time 1105087522 M * _are_ 09:44 sleep $(($RANDOM % (3*60*60))) 1105087528 M * meebey I would put that at 4 o clock 1105087534 M * _are_ he found a quite nice solution already .-) 1105087556 M * sannes hey, didn't relize the random there.. heh 1105087753 M * _are_ meebey: so basically sleep $(($RANDOM % (3*60*60))) && echo 'your old job' | batch 1105087796 Q * sannes Read error: Connection reset by peer 1105087798 M * _are_ this will fail if the jobs themselves are jobs that wait for network for long times, then continue with high local load 1105087822 M * _are_ because as they wait for external resources, the load will drop -> more jobs will be started 1105087825 Q * DuckMaster Quit: Client exiting 1105087833 M * meebey its not that bad 1105087876 M * _are_ most cron.* jobs from normal systems should rarely have that waiting anyway, I can think of virus pattern updates mostly 1105087908 M * meebey why using batch though? 1105087923 M * _are_ batch executes stuff when load is below a certain point 1105087929 M * _are_ by default < 1.5 1105087935 M * meebey ic 1105087937 J * sannes ~ace@home.skarby.no 1105087951 M * meebey the daily stuff I will for sure "delay" 1105087957 M * meebey the hourly stuff probably not 1105087962 M * sannes my connection is going up and down .. up and down up and down... whee.. .. 1105087964 M * meebey like logcheck 1105087988 Q * sannes Read error: Connection reset by peer 1105088110 M * meebey I don't want delay when I get compromised :) 1105088117 M * _are_ :-> 1105088128 M * meebey its a pretty cool setup 1105088164 M * meebey vserver (each vserver got its own internal IP)+aide+logcheck+external syslog+chkrootkit 1105088191 M * meebey so the vserver can only communicate when the host netfilter allows it 1105088213 M * chrish01 meebey: dont i know you from mono/monodevelop? 1105088232 M * meebey chrish01: could be, I am the debian package maintainer of i 1105088235 M * meebey chrish01: +t 1105088248 M * chrish01 nice 1105088279 M * meebey I got a real-life, work etc, there I am the sys-admin :) 1105088344 M * meebey it's fun as long it's linux ;) 1105088367 M * chrish01 sure nough...im proding Bertl_zZ to do some custom work for me 1105088388 M * meebey hehe I got a custom feature already 1105088392 M * chrish01 i too am a sys-admin 1105088393 M * meebey made by Doener 1105088396 M * chrish01 nice 1105088409 M * chrish01 im trying to mold vserver into a virtual router :) 1105088423 M * meebey that patch allows to run open/freeswan in a vserver 1105088455 M * chrish01 i need that on steriods...each context needs to have overlapping ip space, seperate routing tables, separate iptables, etc.. 1105088460 M * meebey it needed write access to proc, vserver doesnt allow that by default 1105088472 M * meebey chrish01: wow 1105088476 M * chrish01 hehe ya 1105088487 M * chrish01 i wrote our current setup using UML, but thats too slow 1105088500 M * meebey so its a virtual multi router 1105088510 M * chrish01 yes 1105088521 M * chrish01 similar to cisco, alcatel, redback SMS, etc... 1105088526 M * chrish01 although much less $$ 1105089160 J * rs rs@ice.aspic.com 1105089166 M * rs hi folks 1105089173 M * chrish01 hi rs 1105089313 M * _are_ both enhancements sound intresting, though I very much doubt I have the time to use any of these in near future. 1105089401 M * _are_ but this brings me back to some older stuff we did without vservers aleady: using a vlan-capable switch as 'port extender' to some server. e.g. the linux box sees the whole vlan trunk, the clients think they are alone in the ... 1105089401 M * _are_ network. 1105089416 M * _are_ probably the only way to get rid of windows virii/worms. 1105089426 M * chrish01 interesting 1105089457 M * _are_ but to my understanding, this should already be possible with vserver, just have to configure the mainserver with iptables accordingly 1105089466 M * chrish01 i have say 2000 vlans with different customers traffic on each. we do all their core routing (many have overlapping ip space). i want to use vserver contexts to do the routing 1105089479 M * chrish01 what i want takes *extensive* patches 1105089484 M * chrish01 which is where NGN comes into play 1105089487 M * _are_ uhm, yes :-> 1105089533 M * _are_ so far I have not have any need to look into ngn and right now I am short of time enough not to be sad about that. ;) 1105089576 M * chrish01 i bet 1105089596 M * chrish01 its some interesting work, but the speed difference between uml and vserver is so worth it for me 1105089633 M * _are_ yes, for the current projects I originally thought about uml and to to some wrong understanding of mine I landed in vserver and liked it :-) 1105089690 M * _are_ the first box i did will be the one that has to do the most, it is planned to migrate an old NT-Server into a vswerver running vmware or a similar tool. 1105089711 M * chrish01 nice 1105089804 M * _are_ well, this box and its partner (same, but 4 CPUs, 16GB RAM) should do a fialover cluster an dreplace 2*HP9000 with HP-UX, 1 old linux oracle db and the old linux fileserver, mail, print, inrranet failover cluster. 1105089815 M * _are_ the last thing is already in productive use 1105089819 M * chrish01 hehe nice 1105089841 M * chrish01 i would like to migrate a single p4 HT running about 20 customers on UML to a vserver running about 100-150 1105089887 M * _are_ Bertl said something about 64MB RAM, 100MHz CPU per vserver instance running webservices 1105090948 J * Raj_Online ~amit@203.124.158.219 1105091594 N * Doener_zZz Doener 1105091617 J * sannes ~ace@home.skarby.no 1105091626 M * Doener morning! 1105091632 M * _are_ hi Doener 1105091705 M * sannes Doener :) 1105091723 M * Raj_Online gug all 1105092067 M * chrish01 night all 1105096070 M * we2by 64mb really? 1105096088 M * _are_ we2by: per instance, not total 1105096101 M * _are_ so 10 webservers -> 640MB RAM, to my understanding 1105096116 M * we2by damn, that sucks 1105096120 M * we2by so I need 1GB ram 1105096140 M * _are_ i rarely buy a desktop with < 1GB ram, let alone servers 1105096146 M * we2by it is not true 1105096155 M * we2by I have had 5 vservers running 1105096160 M * we2by and I only have 256 ram 1105096164 M * _are_ but you can always try with less, it depends on your profile 1105096197 M * _are_ well, make it 5 verservers getting a few hits/minute and doing some databasedriven pages and you will get nowhere with 256 1105096225 M * we2by I also do alot compiling 1105096499 M * _are_ well, it is an estimated value for general use, as you don't do compiling 24x7 an dmight serve mainly static pges you can get away with less ressources 1105096533 M * _are_ I myself have a database running here for a webserver that has barely enoough ram with 1GB dedicated to it. 1105097300 J * elCount ~count@pD9E7D5F0.dip0.t-ipconnect.de 1105097301 M * elCount re 1105097321 M * _are_ hi elCount 1105097382 M * eyck Bertl_zZ: sorry, I'm having problems with scheduling lately:(... I haven't yet read your specification... and it seems like it will be the same for few more days :( 1105097526 M * elCount hey _are_ :) 1105100852 M * _are_ the server unification: does anyone have a script by chance to find double files and unify them with the vserver unification method? I don't want to unify entire vservers, but to my understanding this should work for anything ... 1105100852 M * _are_ in vservers. E.g. if every user decides to stuff a Knoppix image into the $HOME. 1105103550 J * Duckx ~duckx@c2fa9710.adsl.oleane.fr 1105103654 M * we2by this is like what I wanted 1105103672 M * we2by u can share a dir for more than 1 vservers 1105103679 M * _are_ guess I have to write it then :-) 1105103683 M * we2by by doing so, all vservers have access to the same dir 1105103695 M * we2by it means u don;t need duplicate the dir for vservers 1105103714 M * _are_ yes, ofc, this they do anyway here, if the data is the same 1105103725 M * we2by yea 1105103737 M * we2by isn;t this like unification? 1105103740 M * _are_ but all my vservers do different stuff, so I have different software installed and want to update it independently 1105103751 M * we2by mhh 1105103779 M * _are_ it is like unification, but the past few days when I asked about unification here I got no answer and I find no docs for new tools+unification, either 1105103784 J * A-Wing ~a-wing@nsnoc.plus.com 1105103820 M * _are_ -> I guess Ibetter write my own global unification script and have the possibility to not only use it to get rid of double binaries,but of double data like knoppix images, too 1105103892 M * we2by yea, correct, u can have one /bin 1105103913 M * we2by u can use 1 /bin for all ur vservers if they are the same distro 1105103934 M * we2by _are_, nice idea., I can save alot space by doing so 1105103957 M * we2by thanks for recalling me on unification 1105103966 M * _are_ i definitly can save much space 1105104055 M * A-Wing I have got a vserver kernel (latest patches & tools) on a core 3 setup, anyone know why the NAME field in vserver-stat is empty for thr vservers? 1105104107 M * A-Wing playing guess the context at the moment until I can get ti to show the names :) 1105104174 M * _are_ which tool version? stable or alpha? 1105104259 M * A-Wing util-vserver-0.30.196 1105104311 M * _are_ ok, I guess your run and run.rev links are broken 1105104345 M * Doener A-Wing: dynamic or static context ids? IIRC dynamic contexts don't have their name shown 1105104375 M * _are_ Doener: shouldn't matter with new tools, if I get it correctly as it is all handled via links that get set on startup 1105104379 M * A-Wing dynamic, usually use static on my old 2.4 core servers, but experimenting 1105104476 M * A-Wing Could be something to do with the security in Fedora Core 3, had a few hurdels to get this far 1105104578 M * A-Wing just made it static context, still no name 1105104605 M * A-Wing so probably is th run and run.rev 1105104613 M * _are_ A-Wing: check your /etc/vservers/servername 1105104646 M * _are_ you find there: run -> /usr/var/run/vservers/servername 1105104653 M * _are_ and run.rev -> /etc/vservers/.defaults/run.rev 1105104738 M * _are_ well, might be different directories at your place, ofc, but make sure the aequivalent to usr/var/run/vservers/ exists and there is some /etc/vservers/.defaults/run.rev with a numeric link (the context id) that points to the ... 1105104738 M * _are_ 'name' in your verver directory 1105104744 M * Doener _are_: stable tools show names of dynamic contexts, but IIRC that does not yet work with alpha tools... 1105104800 M * _are_ # vserver-stat 1105104800 M * _are_ CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1105104800 M * _are_ 0 65 52.9M 4.5K 0m04s52 0m05s37 2h28m53 root server 1105104800 M * _are_ 49152 4 6.4M 623 0m00s00 0m00s00 0m04s90 base 1105104811 M * _are_ just deleted my 'context' file, seems to work fine 1105104825 M * Doener hm, maybe that was just with the legacy config... would make sense... 1105104836 M * A-Wing noepe, there is no /etc/vservers/servername 1105104850 M * _are_ A-Wing: #servername' is your vserver name 1105104865 M * Doener A-Wing: are you using the legacy config format? 1105104875 M * A-Wing Doner: yep 1105104880 M * _are_ eeeeeek 1105104898 M * A-Wing is that where I buggered up? 1105104903 M * _are_ I changed to new config format as I ran in all kinds of troubles with legacy 1105104912 M * A-Wing ah :) 1105104916 M * _are_ and I had no names either with legacy format 1105104966 M * A-Wing so I have to build new format configs, any doc you can point me to so i can use the newer format? 1105105005 M * Doener http://linux-vserver.org/alpha+util-vserver 1105105015 M * Doener http://www.tu-chemnitz.de/~ensc/util-vserver/doc/conf/configuration.html <-- infamous flower page 1105105030 M * _are_ and for the last one, better use a text only browser :-> 1105105037 M * A-Wing I used legacy on vserver-build as copy said the copy script didn't exist 1105105044 M * Doener make sure to use one of the alternative style sheets 1105105095 M * A-Wing thanks guys :) 1105105102 M * _are_ I wrote myself a simple script to copy vservers with new config, doesn't do unification, yet, just copies a source server to a destination and alters IP+context + sets up ssmtp 1105105129 M * _are_ if anyone has use for this, give me a shout and I can upload somewhere, else I will look into unification, first 1105105208 M * A-Wing I would find that useful, having to copy vservers for new customers all the time 1105105229 M * we2by A-Wing, are u using it for hosting? 1105105259 M * A-Wing yep 1105105281 M * we2by how ell does vservers run on such a production server? 1105105298 M * A-Wing uptime of 500 days on our first one 1105105299 M * we2by how many vservers what is the load? I just want to have an idea 1105105323 M * A-Wing about 3-4 per server, load depends on what is installed, but not much overhead as far as I can see 1105105357 M * A-Wing the host server fell over after 497 days due to an uptime bug 1105105387 M * we2by don;t u recompile kernel? 1105105410 M * A-Wing not often, we are doing major upgrades now 1105105434 M * A-Wing almost everything is RedHat 7.3 based, I'm making it all Fedora Core 2-3 based 1105105468 M * A-Wing needed now we are doing some advanced LVS and NFS stuff on most of the servers 1105105717 M * we2by cool 1105105732 M * we2by one thing that piss me off is when servers get compromised 1105105777 M * A-Wing one of our clients is all the time, we tell him how to lock it down and he doesn't bother, just restores from the backup server once a week! :) 1105105779 M * _are_ http://lihas.de/vcopyserver.sh is my current version (running Debian here, /etc/vserver as config, /vservers as root for the vrservers data) 1105105781 M * we2by if u run a server with 10+ websites on it and the server get compromised, all the sites will go down 1105105797 M * we2by A-Wing, lol 1105105807 M * we2by A-Wing, can u tell me how to lock it down? 1105105848 M * A-Wing main way is to make /tmp and /var/tmp is noexec by mounting it as a loopback file 1105105857 M * _are_ A-Wing: you talk about normal servers, not vservers with taking down everything, right? 1105105858 M * A-Wing the other way is to chroot php-apache-mysql 1105105867 M * A-Wing are: yep 1105105871 M * _are_ phuuu 1105105893 M * A-Wing although if you do it on the host server for the vserver's tmp directory it works 1105105935 Q * Duckx Ping timeout: 480 seconds 1105105945 M * A-Wing anyway, were off to lunch (nearly 2pm here in the UK), later 1105107294 M * we2by _are_, can u chroot services like apache in a vserver? 1105107340 M * _are_ we2by: a vserver is a secure way to do a chroot, a normal chroot is something quite useless, so no idea, never tried it. 1105107383 A * _are_ fights against people that believe chroot gives security for years now. It is more like locking a door on an open field. 1105107465 M * we2by yea, but if u also have chroot in a vserver. this is like u have 2 doors locked before some one can break in 1105107498 M * _are_ well, you have 1 door in a wall that is locked and 1 door that you just walk around. 1105107508 M * Doener ok, so you walk through the open field, around the first door... too slow... 1105107557 M * we2by but using vservers, u lock down all services in one room 1105107564 M * _are_ we2by: if you want a separate chroot for something, do a separate vserver with only that process running. 1105107573 M * we2by if u do chrooted also, u will lock each service individually 1105107587 M * we2by great idea 1105107601 M * _are_ i have distinct vservers for every service, e.g. samba, cups, mail, some java tool, webserver 1105107605 M * we2by but I need to run a control panel which need access to other service config files 1105107616 A * elCount would like a Debian on the host system which runs only the services in different contexts 1105107655 M * _are_ we2by: well, if you really need this, you have to run it on the master and patch it to find the right config files. 1105107673 M * we2by I am thinking the solution 1105107684 M * we2by maybe make a sahte for the config file only 1105107687 M * _are_ elCount: I think this is already existent, you just run a minimal vserver for each service 1105107687 M * we2by read write 1105107707 M * _are_ anothe rsolution: mount --bind the config files to the config-server 1105107711 M * we2by share* 1105107715 N * Raj_Online Raj_Offline 1105107726 M * we2by yea, I am thinking that too 1105107800 M * _are_ 6 virtual minutes till my test-xp-install in a qemu is finished, if that works, I will try and get qemu in a vserver to run the only program that makes a nt box necessary at all at that place .-) 1105107826 M * _are_ unfortunately 6 minutes is more like 40 minutes :-> 1105107985 J * Duckx ~duckx@c2fa9710.adsl.oleane.fr 1105108064 M * we2by vserver is cool 1105108082 M * we2by this will safe me alot work each time they compromised a service 1105108470 Q * sebd Remote host closed the connection 1105109773 M * A-Wing _are_: are there any pre-made config dirs or a script to create a default skeleton config? 1105109774 J * jfm ~jfm@125-77.244.81.adsl.skynet.be 1105109824 M * _are_ A-Wing: you can try vserver slavename build -m skeleton, but I'd advise to use debootstrap or the rpm-equvalent instead 1105109844 Q * jfm Quit: 1105109858 M * _are_ if it is only for migration purposes from the old config, the skeleton might be enough, don't forget to add the network info or you will ned up with no sample for the etwork 1105109892 M * A-Wing cool, thanks :) 1105110109 M * A-Wing The configured vshelper '/sbin/vshelper' does not match the 'vshelper' script of the util-vserver package 1105110121 M * _are_ if you need a working sample: http://vgn.lihas.de/vservers-cfg-sample.tar.gz 1105110147 M * _are_ yes, add kernel.vshelper = /usr/lib/util-vserver/vshelper 1105110167 M * _are_ to 7etc/sysctl.conf, then do sysctl -p /etc/sysctl.conf 1105110179 M * _are_ to /etc/sysctl.conf, then do sysctl -p /etc/sysctl.conf 1105110205 M * A-Wing cheers 1105110406 N * Bertl_zZ Bertl 1105110406 Q * sannes Read error: Connection reset by peer 1105110414 M * Bertl morning folks! 1105110417 M * Doener hi Bertl! 1105110418 M * _are_ Hi Bertl 1105110514 M * Bertl hey looks like there is a bunch of new folks here?! 1105110558 M * Bertl eyck: don't worry too much! ;) 1105110718 M * _are_ is there anyway to tell a vserver to give a different result for uname -m? 1105110812 M * Bertl yep, with 1.9.x you can 'customize' any utsname field 1105110829 M * _are_ well, then I have not found the right field, yet 1105110855 M * _are_ would have assumed uts/machine 1105110870 M * Bertl (to the flower page we go ...) 1105110875 M * _are_ yes, been there 1105110917 M * _are_ i tried uts/machine and uts/sysname 1105110948 M * Bertl machine looks fine to me ... 1105110957 M * _are_ wel, then it just doesn't work 1105110984 M * Bertl let's verify that ... sec 1105111038 M * _are_ stop, works 1105111043 M * Bertl ;) 1105111055 M * Bertl what was wrong? 1105111064 M * _are_ i configured the server 'source' and checked in 'source32' :-> 1105111083 M * Bertl okay, happens .... so everything fine now ... 1105111092 M * _are_ I get lost in all these vservers ;) 1105111139 M * _are_ but now I hav a hopefully working qemu in a vserver on amd_64, just some image missing to really test it, will be there monday 1105111522 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/ 1105111547 M * Bertl there is a 32MB image (6.6 megabyte compressed) 1105111560 M * Bertl which works fine with qemu ... 1105111607 M * _are_ ok, then I can't resist, given that box is behnd a 128kbit/s line I don't dare anything bigger 1105111616 M * elCount hey Bertl :) vs1.29.1 works for me :) 1105111651 M * Bertl excellent .. but be careful, the tools might get the security wrong ... 1105111672 M * elCount Bertl: okay, thanks for the warning! 1105111686 M * elCount Bertl: what would you recommend for a productive system instead? 1105111692 M * Bertl (you have to verify that /path/to/vserver/.. has the IUNLINK flags set and chmod 000) 1105111766 M * Bertl it's fine, the only thing is, the rules for the barrier were not so tight before (i.e. chmod 000 was basically sufficient) 1105111802 M * Bertl (which is what caused your issues, so make sure the barrier is intact, then it's equally secure as vs1.29) 1105111834 M * elCount Bertl: how do I set the IUNLINK flag? 1105111893 M * Bertl setattr --iunlink /path/to/vserver/dir/.. 1105111903 M * A-Wing ok, last issue (so much has changed since I last did this from scratch), it says I have to append 'true' to a file because of /rtc/rc.d/rc on fedora core 1 vserver, where do i append it to? 1105111937 M * Bertl hey A-Wing! that is true for runlevel scripts which exit with an error code ... 1105111938 M * elCount Bertl: all the servers root directories, yes? 1105111974 M * A-Wing cool, thanks Bertl. I'm off home now, I'll fix it next week :) 1105111976 M * A-Wing later 1105111990 M * Bertl elCount: basically you want to do it on the directory directly above any vserver, so if all vservers are in the same directory, doing it once is sufficient 1105112020 Q * A-Wing Quit: Using KVIrc 3.0.1 'System Virtue' 1105112065 M * elCount Bertl: hm. --iunlink doesn't work? 1105112098 M * _are_ ah, for the flags: unifying means it is a hardlink + immutable attribute + iunlink attribute, right? 1105112116 M * elCount Bertl: would chattr +t /var/lib/vservers mean the same? 1105112135 M * elCount (if /var/lib/vservers is the home of all servers) 1105112148 M * Bertl up to a certain kernel version, yes ... 1105112163 M * elCount Bertl: 2.4.28? 1105112262 M * Bertl hmm, I have to update the wiki page for that, sec ... 1105112505 M * Bertl yep should be fine, but please check it with doing 'cd /; chmod +x ..' inside a vserver 1105112524 M * Bertl (you expect a warning message in the logs, and an unchanged directory) 1105112661 M * elCount Bertl: looks like :) thanks. 1105112767 M * Bertl my pleasure! 1105112916 M * elCount glad you see it that way ;) 1105113180 M * _are_ Bertl: unifying means it is a hardlink + immutable attribute + iunlink attribute, right? And if so, does the copy on unlink work for 'unified' files within the same vserver/for the main server, too, with the vserver patch in ... 1105113180 M * _are_ the kernel? 1105113253 M * Bertl first part: yep that's right ... copy on unlink? 1105113320 M * Doener _are_: there's no magic going on... if your process tries to modify a file, it will fail. if it unlinks the file it's gone. to replace the file it has to unlink it and provide a new version of the file (most common tools do that by default, f.e. patch) 1105113373 J * ola ~ola@c-adt-5.ataco.se 1105113381 M * Doener package management also works this way (delete old, put new) 1105113386 M * ola Hello 1105113391 M * Bertl hey ola! 1105113397 M * Bertl good to see you here! 1105113404 M * ola I have finally find the IRC channel . :) 1105113404 M * Doener hi ola! 1105113522 M * _are_ hmm 1105113527 M * ola God to have found the channel so I can discuss things quicker than the list. :) 1105113551 M * Bertl yeah, this way we probably make fast progress ... 1105113598 M * Bertl okay, so where do we start? 1105113631 M * ola I'm not sure. 1105113633 M * ola :) 1105113691 M * Doener what about decisions about what packages we want? 1105113724 M * Doener on the list i said, that i'd prefer something like: kernel-patch-ctx (2.4 branch) 1105113731 M * Doener util-vserver (stable) 1105113733 M * Bertl hmm, maybe we should check the various modifications the debian packages do first ... and see what we can include into mainline and what we should drop entirely ... 1105113757 M * Bertl (although I'm the wrong person here, except for kernel changes) 1105113767 M * Doener kernel-patch-linux-vserver (2.6 branch, naming sucks a little, but we should get away from the ctx thing) 1105113789 M * Bertl ah, yes, ctx is basically obsolete ... 1105113807 M * Doener util-vserver(2|-alpha|-ng|-whatever-ensc-would-like) 1105113867 M * Bertl ctx was short for 'context' we now use 'vserver' or 'linux-vserver' because it has become more than just the context stuff (even for 2.4) 1105113906 M * Bertl and ctx is a little misleading as it also referred to the context id, which is now called 'xid' 1105113910 M * ola Doener: I think the 2.6 patches can be included in the normal kernel-patch-ctx package when they are considered a bit more stable. 1105113953 M * ola Or if I just document in the README.Debian file that 2.6 patches are not yet supported by the util-vserver tools... So you need to compile alpha ones. 1105113964 M * Bertl we should try to make the alpha util-vserver available parallel to the stable tools ... 1105113971 M * ola Bertl: Ahh it has changed. 1105113979 M * Bertl (and try to bring it out of alpha, btw) 1105113991 M * ola Yes then it is misleading. We should change it to -vserver then. :) 1105114032 M * Bertl yeah, I would prefer such naming ... but that are details ... 1105114053 M * ola :) 1105114063 M * Bertl regarding tools, why alpha util-vserver? 1105114096 M * ola I do not understand the question. 1105114123 M * Bertl (rhetorical, I'm just lagging ;) simple, because most debian folks download some 2.6 patch ... 1105114135 M * ola :) 1105114142 M * Bertl then get the debian util-vserver and can't do anything ... 1105114149 M * ola Yes. 1105114155 M * Bertl nothing seems to work, because they are missing vital features 1105114178 M * Bertl OTOH, alpha util-vserver is working fine with 2.4 stable patches 1105114187 M * _are_ well, the most 'alpha' on alpha util-vserver is the documentation for vserver build -m debootstrap options, I'd say 1105114190 M * ola Yes I know. I have decided not to support the alpha version, becuase we are close to a new stable release of Debian. 1105114216 M * dominance ola: would you think forming a pkg-vserver on alioth would help? 1105114220 M * ola After the release of sarge I may change my mind. :) 1105114229 M * dominance ola: and to put util-vserver alpha into scud (i.e. experimental)? 1105114231 M * ola dominance: Yes maybe. 1105114246 M * dominance ola: that way others can join and help getting the util-vserver into shape 1105114257 M * dominance ola: btw. your build-depends lack some stuff 1105114268 M * Bertl I guess it's not so important if they are in a stable release or wherever as long as they are maintained 1105114276 M * ola dominance: What do I miss? 1105114280 M * dominance ola: if you want that pkg cleaned out a bit, we should try to get the new util-vserver alpha dep changes back into mainline 1105114289 M * dominance ola: like dietlibc and others 1105114299 M * Doener that's the reason why i'd prefer a seperate package for the 2.6 branch. dependencies can be set so that you get the right tools for the new patch. Also that should allow to have stable patch+tools in sarge, while keeping development patch+tools in sid only. or doesn't debian allow that (i don't know debian's policies that well) 1105114322 M * dominance ola: i'm not sure if we want graphviz in the build-deps as ensc will have that in the make dist of the next version anyway 1105114354 M * dominance ola: but the list is far from being complete.. we're still not 100% satisfied with the util-vserver alpha deb if i read ndim right 1105114358 M * dominance though we're close 1105114364 M * ola Why dietlibc? 1105114368 M * dominance and once this new deb is in shape we can try to backport stuff 1105114387 M * ndim ola: glibc has issues in chroot environments. 1105114391 M * Bertl ola: because of name resolver reasons ... 1105114401 M * ndim and vservers are big bad chroots. 1105114403 M * ola Ohh I was not aware of that. 1105114418 M * ola I'll add it at once. 1105114439 M * Bertl also we need to verify that the barrier is working as expected for stable ... 1105114466 M * Bertl I did an update patch for elCount, to make things like this work again inside a vserver ... 1105114469 M * ola Have added dietlibc to build depends now. 1105114477 M * Bertl cd /tmp; mkdir foo; mkdir foo/bar 1105114477 M * Bertl chmod 0000 foo; chmod 0000 foo/bar 1105114487 M * Bertl (which seems to happen with dpkg and friends) 1105114503 M * Doener ola: IIRC the dietlibc stuff is only necessary for alpha tools 1105114532 M * ola Ahh ok, but I have seen such problems with the stable release too. 1105114541 M * ndim beware: the standard dietlibc detection of alpha fails on Debian. 1105114554 M * ndim Probably heritage has the same code. 1105114558 M * Bertl I guess it's relevant on both, but the stable tools have 'other' issues ... (please ask enrico for details) 1105114571 M * dominance ola: you need --enable-dietlibc in the configure flags too 1105114612 M * Doener ola: ok, maybe i'm just plain wrong here ;) 1105114643 A * ola *brb* 1105114950 M * ola Back now. 1105114978 M * dominance wb ola 1105115149 M * Bertl elCount: you are still around? 1105115291 M * Bertl well, maybe later ... 1105115331 M * elCount Bertl: yes, I am 1105115340 M * Bertl ah, okay, you use debian, right? 1105115383 M * elCount Bertl: right 1105115400 M * ola Hmm do you think dietlibc works on the stable version? 1105115440 M * Bertl elCount: okay, could you tell us (and especially ola) what issues you encoutnered so far? 1105115463 M * ndim I have no idea about the heritage utils. 1105115533 M * _are_ ola: if you give me an url to alpha util-vserve debs I am willing to test them on i686 (Xeons) and amd64 (both sarge) 1105115628 M * dominance _are_: the alpha debs are not official yet 1105115646 M * dominance ndim: do i need to rebuild the deb with cvs or with .30.196? 1105115648 M * ola _are_ I have not prepared any alpha tools. 1105115650 M * _are_ dominance: debian for amd64 is not official, either 1105115652 M * ola :) 1105115672 M * dominance _are_: yep, but amd64 deb would be feasible to build for me =) 1105115692 M * ola I'm not sure who on this channel that have prepared the alpha tools. 1105115711 M * ola I have no mapping of IRC names to real names or email. ;) 1105115719 M * dominance ola: ndim and myself 1105115753 M * ola ok. 1105115927 M * ndim dominance: Tarball is here: http://vserver.lauft.net/util-vserver/dist--merge/ Patches here: http://vserver.lauft.net/util-vserver/patches--merge/ 1105115945 M * dominance or just take 0.30.196 release and svn, right? 1105115945 M * Bertl something completely different: what about the newvserver stuff/scripts? 1105115967 M * ndim dominance: A working debian/ is in SVN. 1105115974 M * Bertl IIRC, there is a debian? specific script, right? 1105115987 M * ndim Right, different package, different maintainer, and stuff. 1105115987 M * dominance ndim: ok.. building new debs 1105116035 M * ola I'm the maintainer of newvserver and it is in the package vserver-debiantools. 1105116052 M * Bertl okay, how far is that debian specific? 1105116065 M * ola I split it out to let the util-vserver tools be more as is. 1105116065 M * ndim ola: Oh sorry, then my memory seems to be degrading fast. 1105116076 A * ndim needs a brain memory refresh cycle 1105116099 M * ola newvserver in vserver-debiantools depends on debootstrap so in that sense it is quite debian specific. 1105116118 M * Bertl ola: because there is/was a newvserver in stable tools 0.30 (util-vserver) 1105116123 M * dominance it should probably switch to cdebootstrap now 1105116128 M * ola It is actually a very simple script. Take a few arguments, run debootstrap with some arguments and then generate some debian specific files. 1105116155 M * ola cdebootstrap? What is the difference? 1105116161 M * Bertl okay, because there are some things to check with that ... 1105116167 M * ola Bertl. Yes I know. 1105116170 M * ndim ola: Will those few debian specific files survive a distupgrade within the vserver? 1105116181 M * dominance debootstrap is old (and buggy) and cdebootstrap is the new d-i reimplementation 1105116181 M * _are_ well, probably it can be aliases to vserver build. i completly switched to vserver build from newvserver 1105116187 M * ola I removed the newvserver tool becuase it was so rpm-specific. 1105116193 M * Bertl ola: do you have a debian-newvserver created vserver at hand? 1105116242 M * Bertl ola: what if we do something like newvserver.rpm, newvserver.deb and create an alternative entry for that? 1105116247 M * ndim BTW, before we move the new util-vserver out of "alpha" status, we should have sorted out the /etc/vserver/*/* layout so that introducing NGNET won't break configurations again. 1105116249 M * ola dominance: I thought that cdebootstrap just was a dietlibc version. 1105116300 M * ola Bertl: That would be a really good solution. 1105116305 M * dominance well, it's a full reimplementation 1105116327 M * dominance ola: but maybe ask waldi about that, he does work on cdebootstrap and can tell you full details 1105116340 M * dominance ola: but from what i hear debootstrap is fully obsoleted 1105116341 M * ola I have a newnfsvserver too but that is not very important. With it you have create a vserver to manange a nfs-boot-root 1105116358 M * ola dominance: That would be nice to know. 1105116407 M * Bertl ola: I guess a new (0.31) release might happen soon ... so maybe if we 'prepare' that a little to make it easier for enrico (who is currently very busy with his thesis), then we could have a mainline util-vserver (stable, 0.31) which also works for debian (except for minimal modifications) 1105116442 Q * _are_ Quit: Disconnecting 1105116449 M * ola Bertl: The sources to vserver-debiantools are available in subversion and on ... I'll upload the version to my repository. Wait a min. 1105116469 M * Bertl ola: hmm, how is the newnfsvserver supposed to work/be used? 1105116517 M * ola It is now available at: 1105116518 M * ola http://fsp.opal.dhs.org/vserver-debiantools/ 1105116525 M * ola You run it like this: 1105116551 M * ola newvserver --hostname foobar --domain barfoo.com --ip 192.168.0.1 1105116581 M * ola Then it creates a new vserver with the name foobar and ip 192.168.0.1 and in the DNS domain barfoo.com 1105116587 M * ola It is just as simple as that. 1105116598 M * Bertl okay, that looks similar to the alpha util-vserver ... 1105116651 M * Bertl back to the newnfsvserver, what does it do? 1105116764 M * ola The same thing but do not remove hardware specific stuff. So you can use this root for nfs-roots or similar. 1105116777 M * ola It is a bit depricated but working. 1105116800 M * ola It is very similar to just running debootstrap. 1105116808 M * ola It create some files too though. 1105116811 M * Bertl okay ... 1105116838 M * ola I'm not sure if you have any such thing in the alpha tools. 1105116844 M * Bertl back to the results of debian-newvserver, do you have a 'bootstrapped' vserver somewhere ... 1105116864 M * ola Yes a lot of them. What do you want from it? 1105116877 M * ola The entire content or? 1105116882 M * Bertl could you show me the contents of the /dev dir right after bootstrap? 1105116901 M * Bertl (means when debian-newvserver is finished) 1105116917 M * dominance _are_: checkout http://backend.verfaction.de/~kk/util-vserver/ for debs 1105116919 M * ola ola@diopsid:~/build/horde3/horde3-3.0.2$ ls -l /dev 1105116919 M * ola total 0 1105116919 M * ola lrwxrwxrwx 1 root root 13 Dec 18 23:25 fd -> /proc/self/fd 1105116919 M * ola crw-rw-rw- 1 root root 1, 7 Aug 29 09:10 full 1105116919 M * ola srw-rw-rw- 1 root root 0 Jan 3 09:41 log 1105116922 M * ola crw-rw-rw- 1 root root 1, 3 Aug 29 09:10 null 1105116924 M * ola crw-rw-rw- 1 root tty 5, 2 Jan 7 17:55 ptmx 1105116927 M * ola drwxr-xr-x 2 root root 0 Jan 3 09:39 pts 1105116929 M * ola crw-rw-rw- 1 root root 1, 8 Aug 29 09:10 random 1105116930 M * dominance _are_: for now only i386,but i can add amd64 if you need them 1105116932 M * ola drwxr-xr-x 2 root root 6 Dec 18 23:25 shm 1105116935 M * ola lrwxrwxrwx 1 root root 4 Dec 18 23:25 stderr -> fd/2 1105116937 M * ola lrwxrwxrwx 1 root root 4 Dec 18 23:25 stdin -> fd/0 1105116939 M * ola lrwxrwxrwx 1 root root 4 Dec 18 23:25 stdout -> fd/1 1105116942 M * ola crw-rw-rw- 1 root tty 5, 0 Aug 29 09:10 tty 1105116944 M * ola cr--r--r-- 1 root root 1, 9 Aug 29 09:10 urandom 1105116947 M * ola prw-r----- 1 root adm 0 Jan 7 12:38 xconsole 1105116949 M * ola crw-rw-rw- 1 root root 1, 5 Aug 29 09:10 zero 1105116952 M * ola ola@diopsid:~/build/horde3/horde3-3.0.2$ 1105116979 M * Bertl okay, that looks fine, what is xconsole? 1105116996 M * ola Have to check. 1105117014 M * Bertl okay, but I was worried about other stuff like reboot and such ... 1105117026 M * Bertl (because some debian folks had such entries ...) 1105117118 M * ola Hmm interesting. 1105117132 M * ola It may be because of the woody tools. 1105117142 M * ola They did not do things perfect. 1105117184 M * dominance ola: btw. you're also welcome to comment on the deb i posted above 1105117198 M * dominance ;)) 1105117325 M * Bertl ola: does the debian-newvserver tool, or any other tool enforce the barrier? 1105117357 M * ola Bertl: What barrier? 1105117438 M * Bertl http://linux-vserver.org/chroot-barrier 1105117463 M * Bertl (it's important for 2.4 linux-vserver security) 1105117538 M * ola The util-vserver postinst do chmod 000 on the vserver directory (where vservers are stored). 1105117543 J * sannes ~ace@home.skarby.no 1105117558 M * Bertl ola: yep, but that isn't sufficient ... 1105117714 M * ola Hmm ok. What do I need to do more? 1105117746 M * ola The kernel patch include something with /vserver but I have not checked what it is. 1105117785 M * ola chattr +t /vservers 1105117789 M * ola Or anything more? 1105117901 M * Bertl chattr +t + chmod 000 should be fine for 2.4 1105117968 M * ola Ok. I have added chattr to the postinst script. 1105118005 Q * Duckx Ping timeout: 480 seconds 1105118141 M * ola Have to eat some. May be back later if I can catch some time. 1105118158 M * Bertl okay, will be back in about 1-2 hours (translocating) 1105118166 M * ola ok 1105118168 M * Bertl thanks for you time! 1105118200 N * Bertl Bertl_oO 1105118301 M * ola Thanks for your time too. 1105118587 M * Snow-Man Are the packages done yet? 1105118588 M * Snow-Man :) 1105118664 A * Snow-Man pokes ola 1105118672 M * dominance Snow-Man: you can try the new alpha ones 1105118701 M * Snow-Man dominance: Right, debs of the alpha util-vserver stuffs. 1105118716 M * dominance Snow-Man: not officially accepted yet 1105118721 M * Snow-Man dominance: Any clue when? 1105118734 M * Snow-Man Like, what's the status on getting the new stuff into sid? 1105118751 M * dominance *ggggggggggggggggg* 1105118752 M * Snow-Man You're just going to update the existing package, right? 1105118760 M * Snow-Man We don't need to deal with waiting for ftpmaster, do we? 1105118766 M * dominance who knows 1105118778 M * Snow-Man Erm, the maintainer should know. :P 1105118796 M * Snow-Man Isn't that ola? 1105118801 M * dominance yes, but it's rathter the question if it's gonna be a "util-vserver" or "util-vserver-alpha" deb 1105118810 M * Snow-Man oh, ffs. 1105118814 M * Snow-Man Just make it util-vserver. :P 1105118820 M * dominance so if there's gonna be 2 packages then there MIGHT be also 2 maintainers 1105118833 M * Snow-Man Don't make it 'util-vserver-alpha' that'll just have to become 'util-vserver' eventually. 1105118844 M * dominance yes, EVENTUALLY =) 1105118850 M * Snow-Man No, it's a *bad* idea. 1105118855 M * dominance so you also think it should be uploaded "when it's ready"? 1105118856 M * Snow-Man It also means we have to wait around forever. 1105118865 M * dominance hehe, that's the point 1105118869 M * Snow-Man When it doesn't break my shit overly much, it should be uploaded. 1105118869 M * ola Snow-Man: I wont accept a upload of the alpha branch unless it has been considered stable, at least before sarge is released. 1105118875 M * dominance so having 2 debs in the archive may be a somewhat faster way to sort this out 1105118879 M * Snow-Man ola: It *is* stable. 1105118890 M * Snow-Man ola: I've been down that damn road w/ Bertl already. 1105118899 M * Snow-Man ola: Hell, they recommend it *over* the 'stable' series. 1105118918 M * Snow-Man dominance: If it has to go through the NEW queue, it ain't gonna be faster. 1105118940 M * Snow-Man Not to mention that it might get rejected (and rightfully so). 1105118943 M * ola Well when they consider it be something else than developement branch I may accept it. 1105118952 M * ndim The NEW queue is probably faster than a Sarge release. :) 1105118954 M * dominance Snow-Man: faster than "when it's stable".. i thin so 1105118957 M * ola It CAN be uploaded to exprimental though. 1105118965 M * dominance ola: that was the idea 1105118972 M * Snow-Man ola: They consider it alpha because they don't think 2.6 is stable. 1105118972 M * ola I know. :) 1105118983 M * Snow-Man ola: Obviously we *have* 2.6 kernels in the archive already, and will be released w/ sarge. 1105118990 A * Snow-Man should just NMU the damn thing. 1105118996 M * ola ok, but util-vserver for that do not need to be considered alpha. 1105118997 M * Snow-Man I'm sure there's at least one RC bug in the old stuff. 1105119021 M * ola snow-Man. No there is no RC bug on util-vserver. 1105119025 M * Snow-Man ola: Upload the alpha tools as util-vserver. 1105119031 M * Snow-Man ola: I bet I could find at least one. 1105119040 M * ola bugs.debian.org/util-vserver 1105119076 M * Snow-Man ola: This stupid game is *really* annoying. 1105119077 M * ola The bug with highest severity is minor. 1105119104 M * Snow-Man ola: The 'stable' tools are depreciated, not currently maintained, and not currently *useful*. 1105119120 M * ola It is very useful if you run 2.4 kernel. 1105119151 M * Snow-Man ola: The 'alpha'-labeled utils aren't alpha. 1105119156 M * ola Please convince upstream people here to release it as stable then. 1105119159 M * Snow-Man ola: They're *recommended*. 1105119171 M * ola Where are they recommended? 1105119177 M * Snow-Man In here, every damn day. 1105119182 M * Snow-Man By the authors. 1105119203 M * ola It is recommended because you use 2.6. 1105119229 M * Snow-Man I bet it'd be recommended for people using 2.4. 1105119239 M * Snow-Man I havn't seen it, but I don't pay attention all the time. 1105119241 M * ola I do not know if they recommend it for 2.4 for production use. I have not followed the discussion here. Joined today. 1105119254 M * Snow-Man I'm pretty sure they do. 1105119319 M * Snow-Man The only reason to use the stable tools that I've seen is if you've already got a setup using them. 1105119325 M * ola Well they may do so, but I want to hear it from them. 1105119330 M * Snow-Man Which I'm not sure any of the upstream *authors* do anymore. 1105119382 M * Snow-Man I know the current main developer (or so it seems to me) of util-vserver doesn't have any systems which use the stable utils anymore. 1105119387 M * ola I made a setup quite recently that I wanted rock stable. As I was uncertain on 2.6 kernel (have seen problems with that) I decieded the well tested 2.4 with well tested 2.4 vserver patches. 1105119404 M * Snow-Man The one box he did have which was running 2.4 died and he reinstalled it w/ 2.4 and the alpha tools. 1105119409 M * ola Well anyay I have to get some food. I'll be back later (maybe). 1105119423 M * ola See ya. 1105119425 Q * BWare Ping timeout: 480 seconds 1105119432 M * Snow-Man ola: Upload the alpha tools as util-vserver. :P 1105119794 M * ndim IMHO, the config format in /etc/vservers/*/* has to be changed before phasing the "alpha" util-vserver into "beta". 1105119877 M * Snow-Man ndim: eh? 1105119900 M * Snow-Man Is this something ensc is planning already or something? 1105119960 M * Snow-Man I mean, I hate the config format of /etc/vservers/* as much as the next person, but there's alot of config formats I hate. 1105120002 M * ndim Snow-Man: The networking stuff is pretty much IPv4 centered. 1105120017 M * ndim And it shouldn't be. 1105120024 M * Snow-Man ndim: erm, so? That's going to be fixed with that other thing. 1105120032 M * Snow-Man Or whatever, I thought. 1105120037 M * ndim Hehe :) 1105120046 M * Snow-Man The 'generic' socket or some such. 1105120055 M * ndim With NGNET? 1105120060 M * Snow-Man yeah, that thing. 1105120077 M * Snow-Man Not that it actually matters, there's *lots* of released stuff that's ipv4-only. 1105120095 M * Snow-Man What you're talking about is a feature addition, not an alpha/beta distinction. 1105120110 M * Snow-Man Feature additions are fine for release goals of future stable versions. 1105120116 M * ndim IMHO, there should be /etc/vserver/*/ipv4/* for IPv4 settings, and similar for ipv6, or any other networking protocol NGNET might support in the future. 1105120160 M * dominance ndim: i386 and amd64 updated with latest b-d 1105120163 M * ndim Otherwise, you get a horrible mixture between ipv4 stuff scattered all over the place and $OTHER_NET_FAMILY cleanly separated somewhere. 1105120170 M * dominance ndim: svn too =) 1105120182 M * Snow-Man ndim: I don't have a problem with that, but I don't think that's a determining factor for being beta vs. alpha. 1105120219 M * dominance Snow-Man: not having a problem with people encountering problems on ipv6 only for you have no ipv6 is not very nice 1105120245 M * Snow-Man dominance: That doesn't make it any less of a feature addition. 1105120255 M * ndim Snow-Man: IMHO, it is. "alpha" is when the interface to the outside world is still subject to change, "beta" is when the interface is set in concrete and there are still bugs to be ironed out. 1105120275 M * Snow-Man ndim: Are you nuts? We're talking config files here. 1105120279 M * ndim Right. 1105120282 M * Snow-Man Not an ABI 1105120285 M * Snow-Man Or even an API 1105120295 M * ndim Config files generated by whatever script you may use for it. 1105120298 M * Snow-Man And those even change. 1105120333 M * ndim But if you see it that way, then it shouldn't be any problem at all to move to */ipv{4,6}/* style setup :) 1105120365 M * Snow-Man I don't care if you move them there, but don't make that hold up releasing a stable version. 1105120846 M * ndim Hmm... ok. 1105121757 J * jfm ~jfm@125-77.244.81.adsl.skynet.be 1105121815 M * jfm where to find init(util-vserver) needed by util-vserver-0.30.196-1mdk 1105121992 Q * rs Quit: leaving 1105122050 J * Duckx ~duckx@c2fa9710.adsl.oleane.fr 1105122111 Q * Duckx Remote host closed the connection 1105122483 M * ola ndim: I agree with you. 1105122513 M * ola Configuration file format changes are just as bad as API and or ABI changes. Or even worse. 1105122535 J * _are_ ~are@84.56.128.89 1105122580 M * ola Snow-Man: I do not really see whay you complain so much. If you want bleeding edge development versions, there is no problem in compiling it yourself. 1105122632 M * ola Maintaining a package in a distribution is another thing as people tend to be very frustrated when you change configuration formats or break their systems. 1105122695 M * _are_ hi 1105122700 M * ola Hello 1105122704 M * Snow-Man ola: I've already made my own debs, but it's more than a little annoying. 1105122710 M * jfm where to find init(util-vserver) needed by util-vserver-0.30.196-1mdk 1105122723 M * Snow-Man ola: The point of Debian is to not have to do that. 1105122737 M * ola ? 1105122741 M * Snow-Man ola: I'm also a DD. 1105122769 M * Snow-Man So I have some familiarity with dealing with configuration format changes. :) 1105122775 M * Snow-Man And distributions. :) 1105122776 M * ola Ok. Then you should be aware that uploading alpha packages is not a very good thing. 1105122811 M * ola Especially when we are ... releasing soon... or should at least. 1105122824 M * ola I'm still waiting for sarge to be released. 1105122831 M * _are_ well, if it is easy migratable config files I see no reason not to do it. but loegacy config -> new style is not that easy to do automatically 1105122851 M * Snow-Man ola: They're not alpha. 1105122922 M * _are_ if one of the files in new config gets renamed in next version, this is easily migrated, I think the general way how the configuration looks like is fixed now (directories and files used like variable names with the value ... 1105122922 M * _are_ being the content) 1105122943 M * _are_ Snow-Man: they are *named* alpha, which indeed is a bit scaring for quite some people 1105122968 M * ola Snow-Man: According to at least ndim they are alpha. 1105123021 M * _are_ ola: they work in most situations, I have seen 'stable' softwrae in debian that broke more often. 1105123031 M * ola Snow-Man: So instead of complaining on me, please help them get it into a releaseable state. 1105123055 M * _are_ and they mostly fail when the configuration is incorrect, which is basically true for most other software, too ;) 1105123061 M * ola _are_: I just want to know that upstream do not plain to change big things. 1105123074 M * Snow-Man ola: they're already in a releasable state. :) 1105123078 M * ola As they seem to do. 1105123123 M * _are_ ola: i am not the utils-developer, so can't promise anything, but I very much doubt there will be changes except file renames and additional directories 1105123136 M * _are_ and I even doubt on the file renames 1105123149 M * sannes :) 1105123285 M * _are_ what probably will change is network configuration stuff with NGN, but even there I think it will be mostly additional files for new features, so nothing to migrate there. The vserver utils already use sane defaults if a file ... 1105123285 M * _are_ is missing to what I have experienced. 1105123626 A * ola is eating dinner. See you later. 1105123690 M * ola If I can get the same statement from upstream and that they want to get inte beta or alpha state I may change my mind. 1105124282 N * _are_ are|afk 1105124572 J * vdb ~vdb@d54C2D21D.access.telenet.be 1105125640 M * Hollow Bertl_oO: ping 1105125668 M * eyck ZZzz.. 1105127043 Q * vdb Quit: using sirc version 2.211+KSIRC/1.3.11 1105127250 Q * virtuoso Quit: leaving 1105127298 J * virtuoso ~s0t0na@tranq.dorms.spbu.ru 1105128378 Q * sannes Read error: Connection reset by peer 1105129119 J * nayco ~nayco@lns-th2-8-dij-82-64-116-200.adsl.proxad.net 1105130056 N * Bertl_oO Bertl 1105130067 M * Bertl evening folks! 1105130091 M * Bertl welcome nayco! 1105130096 M * Bertl Hollow: hmm? 1105130097 M * virtuoso Hi Bert 1105130109 M * Bertl hey virtuoso! everything fine? 1105130156 M * virtuoso Not really, but it doesn't matter that much. :) 1105130174 M * Bertl well, it matters to us?! 1105130195 M * virtuoso No. 1105130206 M * Bertl what's up, let's hear! 1105130226 M * virtuoso It will, after I upgrade to 1.9.3-16. 1105130239 M * virtuoso I'm behind gprs now, that bothers me. :( 1105130290 M * Bertl General Packet Radio Service? 1105130308 M * virtuoso Exactly. 1105130327 M * Bertl and that is so bad? 1105130349 M * virtuoso Slow and latent. 1105130406 M * chrish01 Bertl: quick bug report on NGN 1105130413 M * Bertl yeah? 1105130418 M * chrish01 iptables Match Inet Type conflicts with the patch 1105130428 M * chrish01 kernel doesnt build with that 1105130439 M * chrish01 i think thats because the change of the inet_addr_type method 1105130479 M * Bertl yes, might be, leave it out for now, but send a message to the ml or maybe we should start a wiki ToDo list for that? 1105130546 M * chrish01 ill let you choose the method you would like bug reports to be done, and i will make sure to get the info in there 1105130725 M * Bertl http://linux-vserver.org/ToDo+List+NGNet 1105130741 M * chrish01 great 1105130780 M * chrish01 as i get some time to play with this, im sure i can fill that page up 1105130849 M * we2by Bertl, I;m glad you;r back 1105130850 M * Bertl well, hopefully I can clean it up as fast as you go ;) 1105130857 M * we2by can I limit a vserver memory use? 1105130882 M * Bertl hey we2by! yes, it is possible to do that with 2.6/1.9 1105130900 M * we2by :9 I;m running 2.4.28 1105130908 M * we2by :( 1105130945 M * Bertl http://linux-vserver.org/Release+FAQ 1105130946 M * we2by any hack for this version? 1105130993 M * Bertl not really, you can limit the space for single applications and the number of processes, which will give you a total upper limit ... but that's it 1105131035 M * Bertl so for example, if you limit every process to 64MB and allow a maximum of 10 processes, you have a 640MB limit for example 1105131059 M * we2by :\ 1105131075 M * we2by every process in the vserver? 1105131082 M * we2by or every proces in the host oS 1105131124 M * Bertl every process in the vserver (resource limits aka ulimit will work here) 1105131139 M * we2by mh, that won;t help that much 1105131226 M * Bertl well, that's why 2.6/1.9.x has new features ;) 1105131259 M * we2by but I can;t get 2.6 working beside 2.6 is not stable or good as 2.4.28 1105131348 M * Bertl can't believe that is should not be possible to run 2.6 on your systems, but of course the latter is true ... 1105131358 M * Bertl (at least for the stable part) 1105131383 M * nayco hello !!! 1105131383 M * we2by the probelm is that I have to recompile the kernel remotely 1105131394 M * we2by if I get kernel panic with 2.6, I am in big problem 1105131407 M * Bertl hey nayco! 1105131437 M * Bertl we2by: well, if it _really_ fails, I'm sure you have remote hands there which can select a different kernel on bootup? 1105131441 M * we2by with the 2.4 I feel alot safer than 2.6 1105131456 M * we2by Bertl, yep, but it will cost $$$ 1105131472 M * nayco 'llo ;-). I've got a problem to run vservers on Mdk... Can someone help pls ? 1105131488 M * Bertl what problem? 1105131514 M * nayco well, the kernel compiles fine, 1105131546 M * nayco but after installing utils-vservers (rpm or src) 1105131558 M * nayco I cannot setup a single vserver 1105131577 M * Bertl how/where does it fail? 1105131589 M * nayco first, it seems that some dirs or file are missing (/var/lib/run...) 1105131643 M * nayco and for example, "vserver test build apt-rpm ...... -- -d... does not work at all 1105131667 M * Bertl let's start with a simple one ... 1105131675 M * nayco yes ? 1105131705 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh 1105131721 M * Bertl try that on the host, and let me know what it returns? 1105131754 M * nayco only "vserver test build debootstrap....." download something, then there are errors ("cannot find locale..., falling back to C..." 1105131760 M * chrish01 Bertl: this ngnet stuff is freakin awesome 1105131786 M * Bertl ah, looks like you got it working ;) 1105131820 M * chrish01 yeah, i had it working yesterday, but neglected to edit the networking section with proper drivers :( 1105131833 M * chrish01 i kept my config and just copied your networking section over rather than configuring it too 1105131849 M * nayco then, "vserver test enter" gives me an error like "....cannot suexec..." 1105131882 M * Bertl one step after the other, first check with the script please! 1105131907 M * nayco "vserver test start" fails because of the kernel not aware of vshelper, and "/var/lib/run/vserver...." missing. 1105131917 M * chrish01 Bertl: is there a way to duplicate vserver 1105131962 M * Bertl cp -va (or vserver test build copy) 1105131981 M * chrish01 ok cool 1105131985 Q * serving Ping timeout: 480 seconds 1105132001 M * nayco however, mkdir'ing and touch'ing the missing dirs and files enables to go a little farther, but it seems then that 1105132030 M * Bertl It's easy, just download and execute it ... 1105132032 M * nayco ".../etc/init.d/rc3 ???" is not working properly. 1105132060 M * nayco Bertl It's easy, just download and execute it ... => talking to me ? 1105132068 M * chrish01 Bertl: when passing traffic, i get a lot of debug messages on console 1.... 1105132080 M * chrish01 !!! dev_queue_xmit_nit(.....) 1105132082 M * Bertl nayco: yes, as I did the other 4 times ;) 1105132111 M * nayco ok, I read ;) 1105132117 M * Bertl chrish01: that's normal, I have some debugging stuff enabled ;) 1105132128 M * chrish01 ok np 1105132244 M * Bertl if you really want to see what debug output looks like, then do 'echo 255 >/proc/sys/vserver/debug_ngnet' 1105132255 M * chrish01 haha 1105132266 M * Bertl you can undo that by 'echo 0 >/proc/sys/vserver/debug_ngnet' ;) 1105132268 M * chrish01 im afraid that would be unreadable 1105132272 M * nayco ok, i've got a problem for testing this script, I do not have a working vserver kernel at home (here), and I do not have irc at work ;-). So i'll have to try it monday... Or I may install a vserver kernel here... But I'll start reading the script, to learn how it work: Hell, there may be an answer in it :P ! 1105132274 M * chrish01 i figured that ;) 1105132297 M * chrish01 nayco: i solved the home problem by using vmware 1105132318 M * nayco well, that's not free, is it ? 1105132330 M * Bertl nayco: hmm, guess not, because it just tests basic stuff ... but QEMU (or vmware if you prefer proprietary software) is a choice too 1105132340 M * chrish01 naw, i bought it, but im sure you can get a trial 1105132401 M * Bertl nayco: 2.6/1.9.3+ kernel runs without modifications in qemu-fast, you can even get a config and command line for that (if you like) 1105132424 M * nayco but I can think I can test it on my home machine, I got LVM and I found (At work) that the Vs kernel is working correctly. So I think I'll compile one here, and run my box on it. 1105132465 M * Bertl which kernel/patch did you use? 1105132480 M * nayco ok, first, "urpmi qemu". What do you mean by "get a config and command line" ? 1105132493 M * nayco kernel 2.6.9-vs1.9.3 1105132579 M * Bertl QEMU can run your linux kernel in a terminal (no fancy graphics stuff) or on a full featured graphics window 1105132586 M * nayco I saw that there is no precompiled vs kernel for mandrake, I may provide one for the contribs, but I don't know how to build rpms... I'm reading a tutorail these days, but it may be hard for a strat. 1105132632 M * nayco bertl: terminal will do it (If you mean that this terminal can be displayed under X ;-)) 1105132675 M * Bertl well, it's running in mgt here (but xterm or whatever terminal will do) 1105132789 M * nayco ok. I just installed qemu... It seems to need root image. Where do i find it ? 1105132792 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/2.6.10-vs1.9.3.17.config <-- kernel config 1105132805 Q * jfm Ping timeout: 480 seconds 1105132806 M * Bertl you should make sure to have qemu 0.6.1 1105132825 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/TEST_32M_public.img.bz2 <-- here is a simple test image 1105132847 M * nayco Ok, I'm downlaoding. 1105132859 M * Bertl and here is an explanation how to make bigger images ... 1105132860 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/howto.txt 1105132888 M * Bertl the tools formathd.sh and gohd.sh will help you with populating them ,,,# 1105132898 M * Bertl s/,,,#/.../ 1105132989 M * nayco gohd.sh: 503: Service Unavailable 1105133025 M * Bertl you need to adapt it to your needs ... 1105133073 M * Bertl (probably change it from devfs to udev nodes) 1105133087 M * nayco I cannot download gohd.sh 1105133089 M * nayco :( 1105133107 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/gohd.sh 1105133149 M * Bertl (works fine here) 1105133175 M * nayco Ok, done. 1105133215 M * chrish01 anyone have the link to the page for configuring 1.9.3 vservers (like what files are in /etc/vservers//) 1105133220 M * chrish01 i cant seem to find it on hte wiki 1105133237 M * nayco so, I need to use these information to setup a partition for qemu ? Will 512 MB be enough for testing Vserver ? 1105133246 M * Bertl chrish01: http://linux-vserver.org/alpha+util-vserver 1105133251 M * chrish01 ah thanks 1105133258 M * Bertl (flower page) 1105133259 A * chrish01 bookmarks 1105133280 M * chrish01 hehe wow :) 1105133302 M * Bertl nayco: well, I'd start with the test image, if that works, then create a larger one, you can make them up to 2GB IIRC 1105133398 M * nayco ok, which test image ? 1105133445 M * Bertl the one I mentioned before ... 1105133465 M * nayco Ohhh, I missed it ;-) ok ! 1105133599 M * Bertl and don't forget to compile a kernel, you'll need that too, it's not included in the image .. 1105133613 M * Bertl (which is actually an advantage, as it can be changed quite easily) 1105133907 M * Hollow hi Bertl 1105133936 M * Hollow could you please comment on http://bugs.gentoo.org/show_bug.cgi?id=56171 ? 1105133946 M * chrish01 omg Bertl im loving this ngnet stuff 1105133959 M * Hollow especially the 1.3 and 1.9 part.. 1105133963 M * nayco well... Qemu is stuck at "booting from hard disk" .... 1105133978 M * Bertl Hollow: sure, sec 1105134003 M * nayco it's my first time with qemu... 1105134009 M * Bertl nayco: did you compile a kernel (from 2.6.9/10 + vserver with my config, the one I mentioned above)? 1105134023 M * Bertl if not, please do so in the meantime ;) 1105134085 M * nayco Oooopsss.... I need to compile the kernel _before_ starting Qemu;, and bbot it with that kernel ? (Told you it is my first time ;-)) 1105134092 M * chrish01 Bertl: i cant change ip settings inside the vserver, what capabilities do i need for this? 1105134113 M * Bertl chrish01: just add CAP_NET_RAW and CAP_NET_ADMIN 1105134118 M * chrish01 ok 1105134126 M * chrish01 bcapabilities right? 1105134146 M * Bertl and make sure that the interfaces are configured (vnet stuff) _after_ the context is started ... 1105134159 M * Bertl chrish01: yep bcaps should be fine ... 1105134161 M * chrish01 yea 1105134180 M * chrish01 otherwise you have any empty context :) 1105134190 M * Bertl nayco: yes, you compile the kernel with that config, on your host, and then use the command line I promised you ... 1105134194 M * chrish01 is there a way to kill those *emtpy* context's btw 1105134230 M * Bertl basically they should go away when the last process dies ... 1105134233 M * nayco Ok. This gonna take some time, ibrb ;-) 1105134477 M * chrish01 Bertl: i get permission denied all over in that script 1105134498 M * Bertl hmm, you mean the vnet3_setup? 1105134510 M * chrish01 i made /etc/vservers//bcapabilities with (NET_RAW\nNET_ADMIN) 1105134527 M * chrish01 yes vnet3_setup configured to my setup 1105134540 M * Bertl you execute it on the host, do you? 1105134543 M * chrish01 yes 1105134554 M * Bertl k, that's fine, and you get permission denied? 1105134568 M * chrish01 yup, if i enter the vserver and type it manually i also get denied 1105134618 M * chrish01 i tried the bcapabilties file with both CAP_NET_xxx and NET_xxx and neither worked 1105134624 M * Bertl okay, please start it with bash -x vnet3_setup.sh and upload the output somewhere ... 1105134636 M * Bertl (e.g. pastebin.com) 1105134636 M * chrish01 ok, let me restart vservers 1105134804 M * chrish01 http://www.pastebin.com/226209 1105134808 M * Bertl tx 1105134825 M * Bertl Hollow: yes, that was correct ... 1105134844 M * Bertl (or is correct, as it states that it was fixed ;) 1105134865 M * Hollow it's fixed in 1.[39] too= 1105134866 M * Hollow ? 1105134890 J * sannes ~ace@home.skarby.no 1105134895 M * Bertl hmm, IIRC, I didn't bother updating the 1.3.x branch ... 1105134911 M * Hollow but 1.9 is up-to-date? 1105134922 M * Bertl (but it is probably easy to update for 1.3.x too) 1105134932 M * sannes Bertl :) I'm now sitting at the hardware that is causing me headaches.. heh :) 1105134945 M * Hollow do you recommend using 1.3 instead of 1.9 for 2.6? 1105134945 M * Bertl Hollow: yes recent 1.9.x is considered fine ... 1105134970 M * Bertl 1.3.x is for 2.4 and I really can't recommend it ;) 1105134989 M * Bertl sannes: excellent .. oops capturing? 1105135015 M * Hollow ah, yes.. i really get confused with all these version schemes... 1105135038 M * sannes Bertl : yes, with SMP DEBUG_PAGEALLOC 1105135046 M * Hollow ok, vserver on 2.4 will likely not be supported on gentoo, so i leave it as wontfix 1105135053 M * Hollow erm, fixed 1105135077 M * Bertl hmm, confusing it is ;) 1105135097 M * Hollow you shuold _really_ do sth against it ;) 1105135214 M * Bertl well, actually the versioning is quite simple ... if you know how to read it (that's why I like it) 1105135233 M * Bertl unfortunately we made some compromises on the way ... 1105135265 M * Hollow mhm... will 1.9 become 2.0? 1105135282 M * Bertl yes, once it is stable, it will be released as 2.0 ;) 1105135288 M * sannes Bertl : http://www.sannes.org/panics/panic2.txt 1105135296 M * Bertl tx 1105135297 M * sannes (freshly typed in) :> 1105135318 M * Hollow ok, and will the 2.4 patches be supported at all? 1105135337 M * Bertl you mean, if the support will continue after 2.0? 1105135342 M * Hollow yes 1105135355 M * Bertl really depends on the folks (and when we get there) ... 1105135388 M * Bertl if nobody any longer is using 2.4/1.2.x when 2.0 is released, then we'll probably let it die in peace ... 1105135391 M * Hollow ok, so we'll see... but i really won't like supporting 2.4 on gentoo :P 1105135429 M * Bertl currently 1.2 is _the_ stable branch ... after 2.0 the reason for going 2.4/1.2 will be limited 1105135447 M * Hollow yep... 1105135449 M * Bertl sannes: kernel source tree at hand? 1105135495 M * Bertl ah, and please upload the output of dmesg after startup (with this kernel) somewhere ... 1105135568 M * sannes just crashed again, heh.. two secs 1105135614 M * Bertl take your time ... 1105135626 M * Bertl (and record as much information as possible) 1105135789 M * chrish01 Bertl: i added NET_BIND_SERVICE and SYS_ADMIN and still no luck 1105135805 M * chrish01 although i do get chdir(): Permission denied now 1105135828 M * sannes Bertl : ok, got debug2.txt with the kernel log 1105135861 M * Bertl chrish01: hmm, maybe you already got them started? -- it looks like that ... 1105135879 M * sannes (oh, btw what is supposed to happen if an interface is taken down while vservers is using that interface, got some output for that in my logs I think.. but, we'll take that later) 1105135879 M * chrish01 no, i restarted the vservers first 1105135885 M * Bertl (check with chcontext --ctx 60 /bin/bash; then ifconfig) 1105135901 M * sannes and got the sourcetree at hand now .. :) 1105135924 M * Bertl okay ... 1105135945 M * Bertl we would like to know what 'addr2line -e vmlinux 80250b04' says ... 1105136010 M * sannes include/asm/thread_info.h:89 1105136024 M * sannes 240b04 1105136033 M * sannes (other way around ..) 1105136075 M * Bertl that is here in current_thread_info() is that the same with your source? 1105136097 M * nayco bertl: I've got a kernel (Without modules), and I cannot boot qemu on it. Do I need an initrd or something like tis ? 1105136114 M * Bertl nayco: did you use my config so far? 1105136127 M * sannes yip 1105136130 M * sannes same as me 1105136134 M * Bertl k, tx 1105136140 M * sannes sorry 1105136141 M * sannes heh.. 1105136145 M * sannes thread_info 1105136150 M * sannes yes 1105136151 M * sannes heh 1105136163 M * nayco What do you mean ? Here is my command line : qemu -kernel bzImage TEST_32M_public.img 1105136168 M * sannes someone sitting over my should said I said it wrong.. heh.. but you were correct.. :) 1105136171 M * Bertl sannes: please try to compile a vanilla 2.6.10 kernel and let's see if we can crash that too ... 1105136244 M * Bertl nayco: try: qemu-fast -nographic -m 64 -snapshot -hda TEST_32M_public.img -kernel bzImage -append "rw root=/dev/hda1 devfs=mount" 1105136263 M * Bertl (this is the command line I promised) 1105136316 Q * sannes Read error: Connection reset by peer 1105136357 J * sannes ~ace@home.skarby.no 1105136401 M * sannes Bertl : now we just have to find a way to crash it, guess just a lot of load is the way to go.. hm 1105136421 M * Bertl yes, maybe some userspace memory tester? 1105136452 M * nayco Bertl: Ok, it worked, but I haven't got qemu-fast, I used qemu. funny: " ls /vservers/vservers/vservers/vservers/vserver.................." 1105136460 M * nayco infinite "ls" loop ;-) 1105136466 M * sannes well, didn't really do the trick, didn't have anything with swapping to do atleast.. 1105136470 M * sannes (or so it seems) 1105136478 M * sannes because I did ALOT of swapping and it worked out just fine.. 1105136567 M * Bertl nayco: hmm, you are using a mandrake package, yes? 1105136575 M * nayco ;-) yes ! 1105136597 A * Bertl never bothered to make one ... 1105136623 M * Bertl 0.6.1-1mdk? 1105136675 M * chrish01 Bertl: i should be running this script directly after the vserver starts right? 1105136688 M * chrish01 vserver name start && ./vnet3_setup.sh 1105136713 M * Bertl well, actually I would suggest running it without any vserver start at first ... 1105136732 M * chrish01 does it start the vserver for you? 1105136747 M * Bertl (and just enter the contexts with chcontext --ctx 60 /bin/bash 1105136754 M * chrish01 ah k 1105136761 M * Bertl and chcontext --ctx 61 /bin/bash ) 1105136781 M * Bertl but it will work with a vserver too, just needs more trickery ... 1105136815 M * Bertl sannes: hmm, okay, if you cannot make it crash with 2.6.10, try 2.6.10+1.9.3.17 (without the other stuff) 1105137005 M * chrish01 Bertl: so i reboot the box, and immediately run ./vnet3_setup.sh. output here. 1105137006 M * chrish01 http://pastebin.com/226223 1105137008 M * sannes half of the big vservers depend on bme unfortunatly so can't make them start.. but could probably dupilcate some of them.. heh 1105137018 M * nayco bertl: qemu-0.6.0-2mdk (Sorry, i was long, but qemu hangs my konsole) 1105137020 M * sladen bme? 1105137035 M * sannes bind mount extensions 1105137047 M * sannes bind mount read-only on read-write mounts 1105137087 M * Bertl chrish01: and what does that tell you? (pssst, copy that vnet into /tmp or change the path ;) 1105137118 M * Bertl nayco: k, try the 0.6.1-1mdk then ... 1105137130 M * chrish01 oh shit...whoops, i forgot debian clears the tmp dir hahaha 1105137170 M * Hollow Bertl: can i assume that there is and will be only one vserver version per kernel version (1:1) or one vserver version for more kernel version (1:m)? since this would make version handling much easier... 1105137255 M * Bertl no, because a) we will have different branches for the same kernel, and b) there might be new vserver releases within the same kernel 1105137281 M * Hollow yep i thought so... 1105137397 M * nayco bertl: qemu-0.6.1-1mdk.i586.rpm => "ls /vservers/vservers/vservers/................" 1105137435 M * nayco so, my emulation won't work correclty ? 1105137444 M * Bertl did you try qemu-fast now? 1105137505 M * chrish01 Bertl: it all works now :) 1105137519 M * Bertl great! 1105137532 M * nayco bertl: qemu-fast: command not found 1105137537 M * chrish01 i think i need proxy arp though for the host 1105137550 M * nayco I've got : qemu qemu-img qemu-sparc qemu-system-sparc 1105137551 M * nayco qemu-i386 qemu-ppc qemu-system-ppc 1105137551 M * nayco " 1105137579 M * Bertl hmm, right the package is crap ;) 1105137612 M * nayco ;-) 1105137615 M * Bertl you know how to compile the source? 1105137648 M * nayco Well, I like Mdk, but their packages are always modified/patched so nothing works as expected... :( 1105137663 M * Bertl that is since 10.x ... 1105137686 M * Bertl I'm personally still using Mandrake but a highly modified 8.2/9.x hybrid ... 1105137724 M * nayco Well, compile... If there is not to much dependencies, yes ! But wouldn't it be easier to build and install the kernel on my real machine, then boot it and do my tests on the host ? 1105137752 M * Bertl sure you can do that, but the emulation has some advantages ... 1105137768 M * Bertl (you can try things you wouldn't even dare on your host ;) 1105137791 M * Bertl but it's up to you ... just don't use that kernel as it probably won't work as expected 1105137795 M * sannes Bertl : hm, err, hasn't crashed yet.. 1105137834 M * chrish01 Bertl: so from what i understand, the contexts with different devices still use a shared filesytsem. is there a way i can make them use their own filesystem for different configs and such? 1105137841 M * Bertl sannes: 2.6.10 or 2.6.10+vs1.9.3.17? 1105137867 M * nayco which advantages ? having no risk to lose data ? stability ? Well.... If I setup a lvm partition for /vservers, and play safe, I think that'll do... It was very stable at work :-| 1105137869 M * Bertl chrish01: yes, basically you have separate tools for each kind of 'virtualization' 1105137903 M * sannes 2.6.10 vanilla 1105137903 M * Bertl you are now (with this simple test script) just using the context virtualization, combined with namespaces or chroot you get what we know as vserver 1105137906 M * ola Hello 1105137914 M * Bertl wb ola! 1105137918 M * nayco hello ! 1105137918 M * ola Thanks. 1105137932 M * ola Have watched a lovely movie. "A beatuiful mind" 1105137944 M * Bertl nayco: yes, that is probably fine ... 1105137951 M * Bertl ola: yeah, was a great one ... 1105137970 M * chrish01 Bertl: how do i kill those contexts? 1105137973 M * ola Bertl: Do you know how far from a stable release the development branch is? 1105137996 M * nayco I'll try. brb. 1105138019 M * Bertl chrish01: wait until the last process dies ... (read the script, typically that will take 1000 seconds ;) 1105138045 M * Bertl ola: well, if all turns out to be good, and we get some testing, we should be ready in a month or two ... 1105138063 M * chrish01 Bertl: sorry...thanks! 1105138079 M * ola Ok sounds interesting. 1105138112 M * ola According to Snow-man it is already almost considered stable. 1105138115 M * Bertl ngnet will not be in 2.0 I guess so, the only missing pieces are ... 1105138130 M * Bertl *) the (sub)capability mask solution 1105138154 M * Bertl *) the rcu cleanup and SMP testing 1105138159 M * ndim ola: Right, that movie is *good*. Already noticed you own schizophrenic tendencies? :) 1105138172 M * ola *laugh* 1105138192 M * Bertl good that he didn't ask us ... ;) 1105138236 M * ola So I want to know what your opinion on releasing the developent versions of util-vserver to Debian is. 1105138266 M * ola Debian will soon release its stable version. Stable means no change (almost) at all. 1105138275 M * ola Do you think it is stable enough for that. 1105138298 M * ola ? 1105138328 M * Bertl I'd say alpha util-vserver should get into debian asap, maybe not into debian stable (that is something I can not say), but I guess the alpha util-vserver tools are at least as stable as the current stable tools in debian were (no offense meant) 1105138368 M * chrish01 Bertl: when the context dies, i seem to loose my interfaces in the root context. the get turned off 1105138378 M * chrish01 which means ssh stops =/ 1105138386 M * ola So what you are saying is that the current development packages are more stable (in sense of working) than the stable branch is, right? 1105138386 M * Bertl hmm, interesting ... 1105138416 M * chrish01 i wonder if it is because i have the devices named the same in both the inner and outer contexts 1105138440 M * Bertl ola: yes, at least it seems to me from the list of issues fixed in alpha and the in general good feedback from folks using alpha util-vserver 1105138459 M * ola Great. 1105138472 M * ola Who are the developers on util-vserver tight now? 1105138479 M * Bertl compared to the number of new features, the number of issues are very small ... 1105138506 M * ola s/tight/right/ 1105138521 M * Bertl util-vserver is maintained by Enrico, and the community is providing patches and improvements 1105138529 M * ola Okay. 1105138537 M * Bertl (both the stable and the alpha version) 1105138548 M * ola I'll write a mail to Enrico and ask him for his opinion. 1105138608 M * Bertl as enrico is currently working on his thesis (AFAIK for about 3 more weeks)... I guess he won't have much time to code on it right now .. but he will probably take it out of alpha when we release 2.0 1105138631 M * ola When will that be? 1105138640 M * Bertl but I think that should not stop us from improving the tools within the community and feed back to him ... 1105138651 M * ola Nice. 1105138698 M * Bertl so IMHO if you want to have stable and useful tool on .. hmm, let's say two or three month, I would consider inclusion right now ... 1105138717 M * Bertl s/tool on/tools in/ 1105138758 M * ola Would be a great solution. 1105138774 M * Bertl of course, the community (especially the debian folks) should (and very likely will) help improving and/or adapting them where required ... 1105138786 M * ola Oops. War commenting on a very early discussion. :)) 1105138798 J * serving ~serving@213.186.187.67 1105138820 M * ola But the comment was not that misleading anyway. ;) 1105138850 M * ola I'll try to summarize what has been done and upload a preliminary version to testing. 1105138862 M * ola s/testing/exprimental/ 1105138909 M * Bertl k, keep in contact with dominance and ndim as they are doing most of the work on that right now ... 1105138930 M * ola Do you know where they place their files? 1105138952 M * Bertl it shold not be too hard to find out ... 1105138972 M * Bertl dominance, ndim: where do you place your files regarding debian stuff? 1105138974 M * ola I have found one dir: 1105138975 M * ola http://vserver.lauft.net/util-vserver/dist--merge/ 1105139001 M * ola http://vserver.lauft.net/util-vserver/patches--merge/ 1105139011 M * dominance ola: http://backend.verfaction.de/~kk/util-vserver/ has the debs 1105139040 M * ola Thanks. 1105139080 M * dominance np 1105139115 M * ola Do you have access to more than i386 and ia64 boxes? 1105139151 M * dominance ola: ppc, mips64, amd64, m68k, s390x 1105139154 M * ola I need to know if util-vserver-0.30.196 compiles on all arches that it currently do? 1105139155 M * dominance ola: no ia64 1105139163 M * dominance ola: haven't yet tried the other 1105139167 M * dominance ola: but could try that 1105139181 M * ola It would be really nice. That is something I'm a bit worried about. 1105139184 M * dominance ok 1105139199 M * Bertl ola: did you try the current tools for other archs yet? 1105139222 M * ndim ola: My stuff just takes CVS util-vserver and builds a tarball with all docs included. We want to try to work to convince Enrico that this is a good idea :) 1105139222 M * chrish01 Bertl: is there a limit on vnet device id? like upper limit? 1105139236 M * chrish01 i guess im just asking how many i can make :) 1105139241 M * sannes Bertl : heh, vanilla oopsed.. problem is it oopsed.. then a little bit later it oopsed some more.. and it was alot of do_page_faults.. 1105139248 M * sannes so setting up serial console now.. 1105139256 M * ndim ola: This gets rid of non-free and contrib build dependencies. 1105139256 M * ola From the changelog I can see very little changes. What has really been done? 1105139257 M * Bertl chrish01: yes, currently there can be 2^16 vnets ;) 1105139263 M * chrish01 ok 1105139282 M * ola ndim: nonfree, yeack. ;) 1105139291 M * ndim dominance: Update the goddamn changelog if you change something, will ya? :) 1105139297 M * dominance ndim: NOPE 1105139298 M * Bertl sannes: excellent, so we either have a ahrdware issue here or some mainline problem ... 1105139306 M * dominance ndim: you update the changelog version WHEN YOU UPLOAD 1105139315 M * dominance ndim: thus it will be -1 until it's in scud.. 1105139331 M * dominance ndim: if you want, change dist to UNRELEASED instead of experimental 1105139350 M * ndim dominance: That doesn't mean that you can't add a line " * add patch from foo to do blah". 1105139375 M * dominance ndim: the lines are there.. but most of which are "package cleanup" =) 1105139382 M * ndim *cough* 1105139387 M * dominance ola: indeed there's much more changes than it sounds like 1105139398 M * dominance ola: do a diff for debian/ dirs if you doubt it =) 1105139399 M * ndim OK, let me condense them into the changelog. 1105139400 M * ndim brb. 1105139433 M * chrish01 Bertl: do you know what is stopping me from doing this in a vserver rather than a context? 1105139437 M * Bertl dominance, ndim, ola: would it be possible to do a diff against some mainline version now and then? 1105139442 M * sannes Bertl : I'm going for not that there is a mainline issue (hopefully for my sake..) 1105139447 M * dominance bertl: what you mean? 1105139452 M * sannes err.. that came out all wrong 1105139464 M * dominance bertl: the diff is in the util-vserver*.diff.gz .. 1105139482 M * dominance Bertl: and ensc has most of it in the TODO from ndim 1105139486 M * Bertl k, could you give me an url to such an unified diff? 1105139491 M * dominance Bertl: the rest of the diff is "only the packaging" 1105139510 M * dominance http://backend.verfaction.de/~kk/util-vserver/util-vserver_0.30.196-1.diff.gz 1105139516 M * sannes I hope there is a mainline error, .. if it is a hardware thing I have to find out what part of the hardware it is so I can reuse the rest of the system.. 1105139520 M * dominance that's all the diff we have from util-vserver 1105139528 M * Bertl tx 1105139528 M * dominance and we apply all debian/patches/ before building 1105139529 M * dominance np 1105139538 M * ola dominance: Have you patched anything more than the debian dir? 1105139541 M * dominance Bertl: more precisely all in debian/patches/00list 1105139548 M * dominance ola: nope.. i'm using svn-buildpackage 1105139554 M * ola ok. 1105139555 M * dominance ola: all the rest is dpatch therfore =) 1105139573 M * ola Ohh dpatch. Have actually never used that. 1105139577 M * dominance that also makes reading the diff much more easy =) 1105139581 M * Bertl hmm, those are pathes on patches? 1105139583 M * dominance ola: few DDs have 1105139584 M * ola Have placed a lot of patched in debian/patches though. 1105139589 M * dominance Bertl: yep 1105139595 M * ola And applied them manually. :) 1105139602 M * dominance Bertl: it's a bit tricky, but it helps solving the problem better 1105139613 M * dominance ola: not many patches actually 1105139614 M * Bertl could you simply do a diff -NurpP --minimal from whatever is used on debian to 0.30.196? 1105139634 M * dominance Bertl: check the debian/patches/ndim_rollup.dpatch 1105139647 M * dominance Bertl: iirc the rest in the dpatches was only paths or so 1105139656 M * dominance Bertl: but that's the "large" diff we use ) 1105139657 M * dominance =) 1105139715 M * Bertl please if possible make such a single diff between the debian version (after all patches have been applied) and the mainline version, it helps me to get an idea what the changes are ... 1105139732 M * dominance Bertl: that diff is ndim_rollup.dpatch 1105139737 M * ndim Bertl: If the patches from http://vserver.lauft.net/util-vserver/patches--merge/ were in util-vserver CVS, we'd be totally happy. 1105139738 M * dominance Bertl: the rest is "only packgaing" 1105139752 M * Bertl ola: same would be really appreciated for the current tools (if possible) to find issues and such ... 1105139756 M * dominance Bertl: i.e. that's what the rpm-distros put all into the .spec-file 1105139780 M * ndim Bertl: The rest of the rollup patch is the result of Enrico building a distribution tarball from CVS-with-my-patches. 1105139793 M * Bertl http://vserver.lauft.net/util-vserver/patches--merge/util-vserver--everything-against--ensc.patch <-- that is what I want, right? 1105139823 M * Bertl no obviously not ... 1105139840 M * ndim Bertl: patch-3 is the most important thing. 1105139848 M * ndim The rest is dressing on the cake. 1105139857 M * dominance http://vserver.lauft.normalerweise.net/ohne/ndim_rollup.dpatch 1105139872 M * ndim *LOL* 1105139931 M * Bertl *G* 1105139988 M * Bertl a few questions to the debian folks ... 1105140004 M * dominance bring 'em on ;) 1105140005 M * Bertl a) on x86_64 is there 32bit or 64bit userspace or bot? 1105140019 M * Bertl s/bot/both/ 1105140025 M * dominance amd64 isn't OFFICIAL 1105140035 M * dominance so there's many different unofficial combinations 1105140037 M * Bertl b) similar for ppc64 ... 1105140052 M * dominance there's a pure64 port and the chance to run x86_64 kernel with 32-bit userland 1105140056 M * dominance ppc is 32bit only 1105140067 M * dominance there's also ppc64-kernel with 32bit userland 1105140075 M * dominance yet ppc doesn't do ppc64 userland YET 1105140083 M * dominance multiarch is being though about and worked on 1105140089 M * dominance but nothin near a beta stage 1105140097 M * Bertl k, but x64_64 will probably do, right? 1105140110 M * ndim I'm rebuilding my patches against current util-vserver CVS. 1105140111 M * dominance that's more of a tech. preview.. 1105140126 M * dominance Bertl: x86_64 does usually go 64bit native 1105140130 M * Bertl (okay, was just wondering about the ABI stuff you removed) 1105140135 M * dominance Bertl: if it's running as amd64 arch 1105140158 M * dominance Bertl: but nobody will prevent you from installing a i386 (32bit) userland and have it use a 64bit-enabled kernel 1105140171 M * dominance actually that's something i currently have on my amd64 system =) 1105140181 M * Bertl well, maybe the tool package will ;) 1105140190 M * dominance nope 1105140192 M * Bertl c) netbsdelf*-gnu does that work? 1105140205 M * dominance the kernel-package will wrap up whatever you produced by any means 1105140215 M * dominance and if that means running "gcc-3.4 -m64" then be it 1105140222 M * dominance uhm 1105140226 M * dominance c) is a tricky one 1105140233 M * dominance i actually ain't sure it does, but it should 1105140237 M * Bertl yes, but handling 32bit and 64bit would not be possible/easy 1105140245 M * dominance yet i have no evidence of a Debian/kBSD 1105140263 M * Bertl d) what would be the benefit of c) if it works? 1105140263 M * dominance hehe, yep 1105140283 M * dominance well, you have 3 possible kernels on x86 platforms: 1105140285 M * dominance - Linux 1105140289 M * dominance - *BSD 1105140290 M * dominance - Hurd 1105140299 M * dominance each of 'em can be made a Debian 1105140303 M * Bertl - Darwin/Mach ;) 1105140305 M * dominance and each of them is available 1105140308 M * dominance that's the "hurd" 1105140315 M * Bertl - Solaris 1105140331 M * dominance i don't think Solaris is an opensource kernel, are they? 1105140349 M * dominance and if they're not DFSG-free, they're not gonna be shipped as Debian 1105140351 M * Bertl open source yes, free software no ;) 1105140371 M * dominance then there's no official Debian/Solaris =) 1105140378 M * Bertl anyway, what would the tools do on Hurd? 1105140381 M * Doener well, the license is not available yet, is it? ;) 1105140385 M * Bertl (except for compile ;) 1105140387 M * dominance and Debian doesn't care for what's possible or allowed in the unofficial Debian ports =) 1105140401 M * ola Bertl: Here is a diff for the stable tools. 1105140403 M * ola http://www.opal.dhs.org/involved/patch/util-vserver/debian-modifications-for-util-vserver.patch 1105140409 M * Bertl thanks a lot! 1105140430 M * dominance Bertl: well, what is the question targetting at? 1105140451 M * ola The first file change is just a fix to the manpage so it list the correct section. :( 1105140458 M * ola s/:(/:)/ 1105140503 M * ola After that there are a number of modifications to make it possible for the user to configure the vserver location. I made util-vserver-vars to become a configuration file. 1105140514 M * Bertl dominance: just curious, because the patch adds the target (as check) ... 1105140515 M * ola It may not be the best way, but it was good enough. 1105140527 M * dominance Bertl: that's auto* magic 1105140537 M * dominance Bertl: and as Debian "knows" about these archs it does at them 1105140542 M * dominance Bertl: it was nothin done on purpose 1105140543 M * Bertl ola: testsafelinkdir() what's that for? 1105140549 M * ola The biggest changes are in the vserver script. 1105140555 M * ola I was just about to tell you. :) 1105140578 M * ola It is a security check to avoid symlink attacks such as the ones I have discussed with Enrico. 1105140614 M * Bertl dominance: +m4_include([m4/ensc_pathprog.m4]) <-- what's that? 1105140617 M * ola Check consistency is a function to make sure that two vservers never share the same context. 1105140648 M * Bertl ah, ola, that brings me to another issue often observed on debian ... 1105140667 M * Bertl dynamic contexts are basically depreciated (for vservers) 1105140677 M * Bertl deprecated even ... 1105140700 M * ola I can see that I have changed a cp to a rsync to make sure that copy loops are avoided. :) Did not remember that one. 1105140717 M * ola Yes I have heard so (that dynamic contexts is depricated). 1105140730 M * ola But it works just fine if you do not plan to use quota. 1105140747 M * Bertl well, it works fine as long as you do not use any kind of xid tagging ... 1105140768 M * ola The reason why it is so commonly used (dynamic contexts) is probably that the newvserver script on debian do not set it. 1105140775 M * Bertl (this includes quota as well as disk limits) 1105140796 M * Bertl yes, that is what I would like to see changed in the future ... 1105140798 M * ola What is the difference between ctx and xid? 1105140824 M * ola You would like to see the newvserver script changed or something else? 1105140832 M * Bertl 'ctx' is the name the patch used when it was created ... 1105140834 M * sannes Bertl : http://www.sannes.org/panics/oops.txt 1105140862 M * Bertl ola: (some tools also started to use it for the context number) 1105140868 M * Bertl sannes: thanks! 1105140884 M * ola Bertl: Ok. Then what is xid? 1105140884 M * sannes Bertl : no, thank you :) 1105140890 M * ola Context number? 1105140900 M * dominance ndim: that question is for you =) 1105140903 M * Bertl ola: xid is the 'new' name for context id (it is basically used everywhere, where new options or names appear) 1105140909 M * dominance ndim: about m4/ensc_pathprog.m4 1105140928 M * ola Bertl: Ok. Then I'm no longer confused. :) 1105140940 M * Bertl ola: xid-tagging is making the xid persistant with files 1105140945 M * ola ... Maybe I should get to bed now. It is 00:35 here... 1105140976 M * Bertl okay, np, I hope you'll find your way here when you like ... from now on ;) 1105140987 M * Bertl and thanks for your time! 1105140995 M * ola Bertl: I think I got that ones. I know a bit how the quota patch work. 1105141021 M * ola Bertl: Thanks to you too. I'll try to hang around here more from now on. :) 1105141040 M * Bertl excellent! debian folks will appreciate it! 1105141077 M * ola Good night! See ya. 1105141086 M * Bertl cya! sweet dreams! 1105141106 M * Bertl sannes: looks like a hans-bug to me ... 1105141132 M * chrish01 Bertl: what needs to be done to be able to use NGNet within a vserver? 1105141146 M * Bertl sannes: would it be possible to completely switch from reiser to, let's say ext2/ext3? 1105141170 M * Bertl chrish01: I added the vshelper calls on context creation and destruction ... 1105141209 M * Bertl those would need to be implemented (in the vshelper script) to do the interface creation and destruction (the vnet stuff) 1105141691 M * dominance Bertl: btw. are there any plans to make vserver hook into LSM? 1105141745 M * Bertl well, there are plans, but actually not really my plans ... 1105141751 M * dominance why? 1105141768 M * daniel_hozac wasn't that discussed on the list a month or so ago? 1105141777 M * Bertl the argumentation here is simple: why would I want to make some kind of LSM module, which has the following issues: 1105141788 M * Bertl a) it suffers from double indirection 1105141803 M * Bertl b) it doesn't make any sense without the rest of the kernel changes 1105141821 M * Bertl c) it actually weakens both linux-vserver and the stackable? lsm modules 1105141875 M * chrish01 Bertl: where can i find the changes you made to the context helper? 1105141885 M * chrish01 so maybe i can merge some of them into hte vshelper 1105141941 M * Bertl well, the changes I made are in the kernel, but the calling is similar to the existing one ... 1105141950 M * Bertl sec, digging out some code 1105142001 M * chrish01 anyway i can bribe/prod you to do it ;) 1105142020 M * chrish01 for example do you have an amazon wishlist or anything 1105142091 M * Bertl sure you can ... http://www.13thfloor.at/vserver/donate/ (I'm thinking about a DVD wishlist too, but not done yet ;) 1105142165 M * dominance chrish01: bribing with hardware is usually the best =) 1105142182 M * chrish01 what do you need? ram/cpu/etc... 1105142190 M * dominance "unusual hardware" 1105142202 M * Bertl well, that reminds me of that maxtor II usb/firewire external HD ... 1105142213 M * chrish01 oohhh...how about a 3des vpn accellerator :) 1105142232 M * sannes Bertl : I'm home again atlast.. the server facility gives me a headache.. ugh.. 1105142235 M * chrish01 i think vpn accelleration inside a context would be great. that may already work though 1105142237 M * Bertl dominance: guilty as charged ... 1105142247 M * dominance Bertl: biddewas? 1105142264 M * no_maam_ by the way, did somebody try a crypt-acceleration-card? 1105142278 M * no_maam_ what can I suspect from it if I would like to encrypt gbit ethernet? 1105142292 M * sannes Bertl : chance of ext2/ext3 only.. hm, well, not a chance I'm afraid .. I have to do some trick to do that.. 1105142304 M * chrish01 no_maam_: i think 500mb/sec should be very doable on low hardware 1105142318 M * chrish01 by low im talking 233mhz cpu or so