1139961678 Q * Dr4g Quit: HydraIRC -> http://www.hydrairc.com <- State of the art IRC 1139962445 J * grant mep@p5091953B.dip0.t-ipconnect.de 1139962865 Q * grant_ Ping timeout: 480 seconds 1139963757 Q * gerrit Ping timeout: 480 seconds 1139963943 J * marl ~matt@84.92.193.226 1139964158 M * marl hi can anyone tell me if there is a way to use the vserver build script to setup all the networking etc. but without actually installing any rpms/debs? 1139964212 M * marl also is there a way to customize the list of rpms installed by vserver build? i have a list of rpms from an install.log and a copy of the rpms locally, is there a way to create a new dist in the vserver configs to use this information? 1139964371 J * gerrit ~gerrit@bi01p1.co.us.ibm.com 1139964502 A * Skram waves to everybody 1139964530 M * Skram gerrit: which "plant" do you work at? 1139964666 M * Skram Denver? 1139964669 M * Skram eh. 1139964972 Q * gerrit Ping timeout: 480 seconds 1139967360 M * Skram so PHP and Apache are installed.. 1139967362 M * Skram and ram is low, but when i execute something in php it 1139967363 M * Skram goes up, but never goes back down 1139967460 M * ebiederm What is consuming the ram. Frequently what you describe is simply caused by using the ram efficiently to cache data. 1139967596 M * Skram Right. 1139967616 M * Skram But, it will keep caching until there is no more ram or the kernel says to stop 1139967630 M * Skram but the vps has no limit, so it will cache to it's heart's content 1139967662 M * ebiederm So everyone shares the cache no problem. 1139967668 M * Skram okay 1139967742 M * ebiederm At least if it is normal cached data causing it. In free is it the cached column that increases? 1139967760 M * Skram nope, actually Mem, used: 1139967792 M * ebiederm ? 1139967838 M * ebiederm Does cached also go up. Used should be a global, and should count the cached data. 1139969088 J * Aiken_ ~james@tooax6-120.dialup.optusnet.com.au 1139969415 Q * Aiken Ping timeout: 480 seconds 1139969485 M * Skram hehe, emerging php5 on two different vpses @ the same time. 1139969487 M * Skram fun... 1139969758 M * W0nka one should be able to use ccache there 1139969765 M * W0nka with shared cache 1139969818 M * W0nka in a secure way, so no vps owner can inject bogus stuff into the cache... 1139970530 M * Skram hmm 1139973764 M * cehteh mhm 1139973900 J * stefani ~stefani@c-24-19-46-211.hsd1.wa.comcast.net 1139973970 P * stefani 1139974831 Q * marl Quit: Leaving 1139976550 J * shuri ~shuri@64.235.209.226 1139977177 J * gerrit ~gerrit@c-67-160-130-59.hsd1.or.comcast.net 1139979319 J * tudenbart ~willi@xdsl-213-196-252-6.netcologne.de 1139979767 Q * dothebart Ping timeout: 480 seconds 1139980386 Q * shuri Quit: Quitte 1139981694 Q * FireEgl unununium.oftc.net arion.oftc.net 1139981694 Q * zobel unununium.oftc.net arion.oftc.net 1139981694 Q * Aiken_ unununium.oftc.net arion.oftc.net 1139981694 Q * Smutje unununium.oftc.net arion.oftc.net 1139981694 Q * mef unununium.oftc.net arion.oftc.net 1139981694 Q * monrad unununium.oftc.net arion.oftc.net 1139981694 Q * cohan unununium.oftc.net arion.oftc.net 1139981694 Q * Adrinael unununium.oftc.net arion.oftc.net 1139981694 Q * Psy0rz_ unununium.oftc.net arion.oftc.net 1139981694 Q * jkl unununium.oftc.net arion.oftc.net 1139981694 Q * andrew_ unununium.oftc.net arion.oftc.net 1139981694 Q * harry unununium.oftc.net arion.oftc.net 1139981694 Q * Duckx unununium.oftc.net arion.oftc.net 1139981694 Q * DuckMaster unununium.oftc.net arion.oftc.net 1139981694 Q * kilian unununium.oftc.net arion.oftc.net 1139981694 Q * Snow-Man unununium.oftc.net arion.oftc.net 1139981694 Q * weasel unununium.oftc.net arion.oftc.net 1139981694 Q * Hunger unununium.oftc.net arion.oftc.net 1139981694 Q * tudenbart unununium.oftc.net arion.oftc.net 1139981694 Q * mkhl unununium.oftc.net arion.oftc.net 1139981694 Q * SuperLag unununium.oftc.net arion.oftc.net 1139981694 Q * hallyn unununium.oftc.net arion.oftc.net 1139981694 Q * mire unununium.oftc.net arion.oftc.net 1139981694 Q * michal_ unununium.oftc.net arion.oftc.net 1139981694 Q * BartVB unununium.oftc.net arion.oftc.net 1139981694 Q * baggins unununium.oftc.net arion.oftc.net 1139981694 Q * mnemoc unununium.oftc.net arion.oftc.net 1139981694 Q * micah unununium.oftc.net arion.oftc.net 1139981694 Q * sladen unununium.oftc.net arion.oftc.net 1139981694 Q * cemil unununium.oftc.net arion.oftc.net 1139981701 J * Aiken_ ~james@tooax6-120.dialup.optusnet.com.au 1139981701 J * Smutje ~Smutje@87.78.99.184 1139981701 J * mef ~mef@targe.CS.Princeton.EDU 1139981701 J * monrad ~mikkel@213083190131.sonofon.dk 1139981701 J * kilian kk@projects.verfaction.de 1139981701 J * DuckMaster ~duckx@195.75.27.158 1139981701 J * Duckx ~duckx@195.75.27.158 1139981701 J * harry ~harry@d515321D1.access.telenet.be 1139981701 J * weasel weasel@weasel.noc.oftc.net 1139981701 J * andrew_ ~andrew@tnlug.linux.org.tw 1139981701 J * jkl eric@c-67-172-156-116.hsd1.co.comcast.net 1139981701 J * cohan ~cohan@koniczek.de 1139981701 J * Adrinael adrinael@hoasb-ff09dd00-79.dhcp.inet.fi 1139981701 J * Snow-Man ~sfrost@kenobi.snowman.net 1139981701 J * Psy0rz_ ~psy0rz@lounge.datux.nl 1139981730 J * Hunger Hunger.hu@Hunger.hu 1139981743 J * FireEgl Atlantica@Atlantica.DollarDNS.Net 1139981743 J * zobel zobel@2001:7b8:385::2 1139981760 J * sladen paul@starsky.19inch.net 1139981798 J * mnemoc ~amery@200.75.27.90 1139981978 J * dothebart ~willi@xdsl-213-196-252-6.netcologne.de 1139981980 J * mire ~mire@183-166-222-85.COOL.ADSL.VLine.verat.net 1139981980 J * cemil ~cemil@defiant.wavecon.de 1139981983 J * BartVB ~BartVB@84.35.54.120 1139982033 N * nokoya nokoyaz 1139982041 N * nokoyaz nokoya 1139982250 J * hallyn ~xa@c-24-11-243-196.hsd1.in.comcast.net 1139982292 J * baggins baggins@kenny.mimuw.edu.pl 1139982300 J * micah ~micah@69.90.134.205 1139983186 Q * cemil iridium.oftc.net arion.oftc.net 1139983186 Q * dothebart iridium.oftc.net arion.oftc.net 1139983296 J * cemil ~cemil@defiant.wavecon.de 1139983298 J * dothebart ~willi@xdsl-213-196-252-6.netcologne.de 1139985342 M * jkl hm, anyone here? 1139985548 M * Skram Yeapps. 1139985636 M * jkl what's the latest kernel that has vserver support 1139985673 M * jkl oh, i found it 1139985791 M * Skram ;) 1139986271 Q * BartVB Quit: Leaving 1139986793 M * jkl do you know if you can run a vserver created in 1.x on a kernel with vserver 2.x? 1139987217 M * Skram im pretty darn sure 1139989271 J * PauloRCJR ~Paulo@dial-up-200-157-112-65.intelignet.com.br 1139989330 M * PauloRCJR ! 1139989423 Q * PauloRCJR Remote host closed the connection 1139992732 Q * shedi Quit: Leaving 1139995734 N * Bertl_oO Bertl 1139995740 M * Bertl morning folks! 1139995761 M * ebiederm Good morning Bertl. 1139995919 M * ebiederm I can tell I have been staring at /proc too much I just found a bug in a patch by Al Viro :) 1139995967 M * ebiederm Either that or that I could find a bug is proof of how much a mess /proc really is. 1139995969 M * ebiederm :) 1139996180 M * Bertl yup, it is 1139996225 M * Bertl daniel_hozac: what did I miss yesterday (had no connectivity) regarding syslog? 1139996271 J * prae ~prae@ezoffice.mandriva.com 1139996424 M * Bertl welcome prae! 1139996507 M * ebiederm Bertl: I found a way to easily OOM a system by opening files in /proc.... 1139996571 M * ebiederm Only takes about 80000 file descriptors open to files of defunct processes... :) 1139996599 M * ebiederm And I lock in just short of 1GB of low memory. 1139996631 M * Bertl ot too bad, ebcause of the task ref? 1139996657 M * ebiederm Yes because of the pointer to the task in struct inode. 1139996664 M * Bertl that's why Linux-VServer context entries in proc have only the IDs stored 1139996679 M * Bertl (and do a context lookup when read) 1139996689 M * ebiederm My earlier task_ref work actually is the fix for it. 1139996744 M * ebiederm I stopped messing with it earlier because I thought it was a solution looking for a problem :) 1139996757 M * ebiederm Well I found the problem! :) 1139996770 M * prae Hi Bertl 1139996789 M * ebiederm Bertl: Linux-VSever changes the struct proc_inode to not have a pointer to struct task_struct? 1139996827 M * ebiederm Hmm. I will have to look at that. 1139997009 M * Bertl no, not for the tasks, for the contexts 1139997022 M * Bertl /proc/virtual//* 1139997100 M * ebiederm Ok. The you are suseptible to this one too.. :( 1139997201 M * ebiederm Anyway it is late. And I have fixed my bug. 1139997202 M * Bertl sure, we seldom fix issues we can blame on mainline in our tree 1139997216 M * ebiederm :) 1139997219 M * Bertl we try to fix them in mainline instead (see BME) 1139997255 M * Bertl btw, LInux-VServer protects against this kind of DoS 1139997259 M * ebiederm Sounds like a good way of doing business. 1139997271 M * Bertl because there are FD and File limits as well as memory limits 1139997292 J * brc_ bruce@20151202102.user.veloxzone.com.br 1139997303 M * ebiederm Currently I can trigger it with 80 processes with 1000 fd's each. 1139997314 M * ebiederm That is a fairly small number. 1139997329 M * Bertl yeah, but file limits are per context 1139997357 M * ebiederm What do you usually have your file limits set to? 1139997377 M * Bertl usually unlimited, but I advise something about 500 1139997401 M * ebiederm Ok. That works for modest servers :) 1139997406 M * Bertl you can easily see how many were used (max) and then adjust 1139997421 M * Bertl kind of auditing :) 1139997469 M * ebiederm I certainly like the idea of the global limits. 1139997484 M * Bertl it's essential for all kind of DoS 1139997549 M * ebiederm It is something I will have to revisit one of these times. 1139997581 M * ebiederm To a certain extent there need to be sufficiently light weight mecahnisms in the kernel so DoS attacks are not easy :) 1139997620 M * ebiederm So I am going to fix this one in main line, and use the same mechanism to prevent pid wrap around from causing problems as well. 1139997630 M * Bertl excellent! 1139997639 M * ebiederm When I am done there should be very few pids hanging around in the kernel. 1139997658 M * ebiederm Well only the kernel won't get confused with pid wrap around... 1139997707 M * ebiederm Anyway. It is late and I need to head to bed. 1139997711 M * ebiederm Have a good one Bertl. 1139997716 N * ebiederm ebiederm_zZ 1139997809 M * Bertl good night ebiederm_zZ! cya later! 1139997834 A * ebiederm_zZ *snore* 1139998123 M * daniel_hozac Bertl: not much, apparently the tools don't give VXC_SYSLOG by default. 1139998172 J * alexb ~alex@dslb-084-056-076-151.pools.arcor-ip.net 1139998175 M * Bertl ah, okay, that's unfortunate but I guess (somewhat) okay when we know 1139998180 M * Bertl welcome alexb! 1139998182 Q * zobel Read error: Connection reset by peer 1139998189 M * alexb hello 1139998191 M * alexb thx Bertl 1139998262 M * alexb Bertl, this vserver-stuff is a nice peace of software... i'm just experimenting with it 1139998277 M * Bertl you bet it is! 1139998278 M * alexb *piece of course ;) 1139998760 Q * alexb Ping timeout: 480 seconds 1139998788 J * alexb ~alex@dslb-084-056-076-151.pools.arcor-ip.net 1139998864 Q * alexb Quit: 1139999074 J * alexb ~alex@dslb-084-056-076-151.pools.arcor-ip.net 1139999204 M * daniel_hozac Bertl: i guess you've fixed the plm issues? 1139999240 M * Bertl new ones? no, haven't had a look yet 1139999338 M * daniel_hozac oh, ok. 1139999485 M * Bertl will upload the diffs shortly 1139999526 M * daniel_hozac 2.6.15.4-vs2.0.2-rc5 needs the drivers/mtd/devices/blkmtd.c fix (name_to_dev_t declaration mismatch) present in devel. 2.6.16-rc2-vs2.0.2-rc1 has a #include in arch/ia64/ia32/sys_ia32.c 1139999575 M * daniel_hozac the rest of the failures look like mainline problems. 1139999721 M * Bertl it seems that the diff script fails on certain patch numbers :) 1139999729 M * daniel_hozac lol 1139999741 M * Bertl well, it just sits there and waits :) 1139999750 M * daniel_hozac well, one of the logs was giant. 1139999765 M * daniel_hozac made mozilla drain my RAM. 1139999775 M * Bertl ah, really? maybe I'm just to impatient ... 1139999811 M * Bertl guess I start a bunch of them and see if they finish within the hour :) 1139999816 M * daniel_hozac haha. 1139999856 J * infowolfe ~infowolfe@ip68-2-108-24.ph.ph.cox.net 1139999938 P * infowolfe 1140000352 J * lilalinux ~plasma@80.69.35.186 1140000386 Q * alexb Ping timeout: 480 seconds 1140000396 J * alexb ~alex@dslb-084-056-076-151.pools.arcor-ip.net 1140001145 Q * alexb Ping timeout: 480 seconds 1140001169 M * Bertl indeed the reports finished within the hour :) 1140001202 M * Bertl *uploading* 1140001405 M * daniel_hozac ah, i guess the #endif /* CONFIG_INET */ in 2.6.16-rc2-vs2.1.1-rc3/kernel/vserver/network.c will need to be moved up a function. 1140001442 M * daniel_hozac or does nx_set_persistant really depend on CONFIG_INET? :) 1140001647 J * alexb ~alex@dslb-084-056-076-151.pools.arcor-ip.net 1140001876 J * shedi ~siggi@tolvudeild-204.lhi.is 1140002474 M * Bertl daniel_hozac: well, hmm, guess no 1140002558 Q * brc_ Quit: [BX] I theenk I need a beeger box! 1140003243 M * Bertl daniel_hozac: did we add the mount.h there? 1140003255 M * daniel_hozac in fs.h? 1140003260 A * Bertl is now catching up :) 1140003265 M * Bertl drivers/mtd/devices/blkmtd.c 1140003273 M * daniel_hozac ah, no, it includes fs.h. 1140003281 M * daniel_hozac which in turn includes mount.h 1140003311 M * Bertl k, so we have to remove one of those mount.h s? 1140003322 M * daniel_hozac hmm? 1140003335 M * Bertl no, we have to fix the drivers/mtd/devices/blkmtd.c not to do that, yes? 1140003349 M * daniel_hozac to not redeclare a function from mount.h? i'd say so. 1140003362 M * daniel_hozac i wonder why it didn't just include mount.h from the beginning. 1140003366 M * Bertl looks like a mainline patch 1140003388 M * Bertl interested in fixing this up for mainline? 1140003445 Q * mire Read error: Connection reset by peer 1140003485 J * mire ~mire@116-166-222-85.COOL.ADSL.VLine.Verat.NET 1140003492 M * Bertl the increadibly funny 14Meg diff data seems to be a plm bug, no? 1140003569 M * daniel_hozac yeah. 1140003603 M * daniel_hozac i guess the fix would be to remove the declaration and #include instead? 1140004501 M * Bertl yes, at least if they are identical 1140004541 M * Bertl so, this and the nx_set_persistant are the only issues left, right? 1140004562 M * Bertl (according to the plm cross compile of course) 1140005044 M * daniel_hozac and the vs_pid issue i noted above. 1140005078 M * Bertl ah, yep, right :) 1140005520 Q * Aiken_ Ping timeout: 480 seconds 1140005522 J * Smutje_ ~Smutje@xdsl-87-78-63-39.netcologne.de 1140005640 Q * Smutje Ping timeout: 480 seconds 1140005640 N * Smutje_ Smutje 1140005709 M * nox Bertl: can't get the kernel with debuggingsupport crashing, whatever i do 1140006173 M * Bertl interesting ... 1140006184 M * Bertl maybe you changed something different too? 1140006193 M * nox no 1140006220 M * Bertl what kernel version do you test/use now? 1140006244 M * nox 2.6.15.4-vs2.0.2-rc2-debug2 1140006247 J * mkhl mkhl@200-153-181-170.dsl.telesp.net.br 1140006306 M * Bertl hmm, could you try to upgrade to rc5 and enable kernel debug info, but leave the vserver debugging disabled? 1140006326 M * nox http://pastebin.com/555791 <-- diff 1140006342 M * nox Bertl: ok 1140006446 M * nox Bertl: vs rc3 you mean? 1140006485 M * daniel_hozac 2.6.15.4-vs2.0.2-rc5 1140006515 M * nox again impressed by ya speed 1140006877 M * daniel_hozac Bertl: what does the __init in extern dev_t __init name_to_dev_t(const char *line); mean? does it do anything? 1140006900 M * Bertl yes, it removes the function after the kernel initialized 1140006901 J * mnmr ~mnmr@217.116.235.96 1140006904 M * daniel_hozac i can see __init in the definition putting the function in the special init section of the binary. 1140006907 M * Bertl welcome mnmr! 1140006910 M * daniel_hozac but in the prototype? 1140006917 M * Bertl daniel_hozac: just for consistancy 1140006926 M * daniel_hozac well, it's not consistent ;) 1140006938 M * Bertl well, then it's probably a bug :) 1140006952 M * daniel_hozac extern dev_t name_to_dev_t(char *name); is from mount.h 1140006952 M * Bertl will look into it after lunch ... 1140006979 M * Bertl and who has the __init? 1140006992 M * daniel_hozac the mtd stuff. 1140007001 M * Bertl btw, keep in mind that mtd is _very_ broken :) 1140007020 M * daniel_hozac hehe. 1140007023 M * Bertl okay, off now, back shortly ... 1140007027 N * Bertl Bertl_oO 1140007518 P * mnmr 1140008001 N * Bertl_oO Bertl 1140008006 M * Bertl back now 1140008088 J * Doener doener@i5387EFE7.versanet.de 1140009403 M * Bertl hey Doener! 1140009410 M * Doener hey Bertl 1140009750 Q * andrew_ Ping timeout: 480 seconds 1140009974 J * andrew_ ~andrew@tnlug.linux.org.tw 1140010232 M * mef morning 1140010307 M * Bertl hey mef! 1140010731 Q * Doener Quit: Leaving 1140010735 J * Doener doener@i5387EFE7.versanet.de 1140011892 Q * alexb Quit: Leaving 1140012332 J * meandtheshell ~markus@85-125-230-154.dynamic.xdsl-line.inode.at 1140012367 M * Bertl welcome meandtheshell! 1140012381 M * meandtheshell hi there ;-) 1140015336 J * shuri ~shuri@64.235.209.226 1140015518 M * Bertl welcome shuri! 1140015612 M * shuri hi Bertl ! 1140016888 M * Roey Hey all! 1140017215 M * Bertl okay, off for a while, back later ... 1140017215 N * Bertl Bertl_oO 1140017314 J * brc_ bruce@20151205113.user.veloxzone.com.br 1140017460 M * Roey :) 1140017775 J * cdrx ~legoater@pixpat.austin.ibm.com 1140017870 Q * mkhl Ping timeout: 480 seconds 1140018711 Q * gerrit Ping timeout: 480 seconds 1140018815 J * mkhl mkhl@200-153-181-170.dsl.telesp.net.br 1140019729 N * Bertl_oO Bertl 1140020397 J * Vudumen ~vudumen@217.20.138.14 1140020401 Q * Vudumen Quit: 1140020800 J * Vudumen cc309f318d@217.20.138.14 1140020833 Q * Vudumen Quit: 1140020922 J * gerrit ~gerrit@c-67-160-130-59.hsd1.wa.comcast.net 1140021633 J * Vudumen 643891d63e@217.20.138.14 1140021649 Q * Vudumen Quit: 1140022269 J * Viper0482 ~Viper0482@p549758A0.dip.t-dialin.net 1140022346 Q * gerrit Ping timeout: 480 seconds 1140022395 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1140022416 M * Bertl welcome flock! 1140022482 Q * shedi Quit: Leaving 1140022683 J * gerrit ~gerrit@c-67-160-130-59.hsd1.or.comcast.net 1140022689 M * Bertl wb gerrit! 1140022780 M * gerrit Hi Bertl! 1140022950 M * Bertl okay, dinnertime .. back shortly ... 1140022960 N * Bertl Bertl_oO 1140023127 Q * jkl Remote host closed the connection 1140023205 Q * prae Quit: Execute Order 69 ! 1140023355 J * bonbons ~bonbons@83.222.39.180 1140023632 J * stefani ~stefani@superquan.apl.washington.edu 1140023999 N * ebiederm_zZ ebiederm 1140024059 J * ntrs_ ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140024060 Q * ntrs Read error: Connection reset by peer 1140024104 N * Bertl_oO Bertl 1140024115 M * Bertl back now ... 1140024123 M * Bertl morning ebiederm! 1140024144 M * ebiederm morning. 1140024329 M * stefani hola 1140024507 J * tudenbart ~willi@xdsl-213-196-247-10.netcologne.de 1140024514 M * Bertl hey stefani! everything fine? 1140024671 M * stefani everything? no. mostly ok 1140024945 Q * dothebart Ping timeout: 480 seconds 1140025536 J * Vudumen ~vudumen@perverz.hu 1140025802 M * Bertl Vudumen: ping! 1140025956 Q * gerrit Ping timeout: 480 seconds 1140026022 J * michal` ~michal@www.rsbac.org 1140026072 M * Bertl welcome michal`! 1140026326 J * gerrit ~gerrit@c-67-160-130-59.hsd1.wa.comcast.net 1140026718 M * michal` hey Bertl :) 1140026731 M * michal` seems like oftc is beeing unstable a bit this days 1140026749 J * liquid3649_ ~Viper0482@p54977A56.dip.t-dialin.net 1140026795 M * Bertl well, as an IRC admin said once, IRC is perhaps the most extreme TCP stressing application out there 1140026826 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140026852 M * Bertl so, it is sensitive to all kinds of network issues .. and oversea networking seems to have some 'new' issues lately 1140026859 Q * ntrs_ Read error: Connection reset by peer 1140026939 M * michal` indeed ! 1140027144 J * ntrs_ ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140027144 Q * ntrs Read error: Connection reset by peer 1140027181 Q * Viper0482 Ping timeout: 480 seconds 1140027252 Q * ntrs_ Read error: Connection reset by peer 1140027312 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140027436 J * ntrs_ ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140027436 Q * ntrs Read error: Connection reset by peer 1140027760 Q * gerrit Ping timeout: 480 seconds 1140028238 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140028238 Q * ntrs_ Read error: Connection reset by peer 1140028280 J * gerrit ~gerrit@c-67-160-130-59.hsd1.or.comcast.net 1140028711 M * micah Bertl: wondering if you got a chance to look at http://linux-vserver.org/ChangeLogExperimental -- its getting quickly out of date, and I want have your signoff on 2.1.0.5 before I try to figure out 2.1.0.6 1140028736 M * Bertl lol 1140028749 M * Bertl *sorry* 1140028789 M * micah :) 1140028799 M * Bertl we've reached 2.0.2/2.1.1-rc state 1140028812 M * micah I should've reminded you sooner, but you have seemed very busy lately, and I've been sick 1140028817 M * micah yeah, I saw! 1140028827 M * Bertl oh, sad to hear, better now? 1140028855 M * micah today I feel normal, so I think I might be, but I will have to see (flu) 1140028907 M * Bertl okay, will look into updating the changelogs ... if you promise to prepare for debian apckages once 2.0.2/2.1.1 is out :) 1140028990 M * micah definately, I'll start working on that 1140028999 M * Bertl k, deal! :) 1140029090 M * micah I see patch-2.6.15.4-vs2.1.1-rc6.diff, the topic says "exp 2.1.1-rc4"? 1140029105 M * Bertl see how easily stuff gets outdated :) 1140029106 M * daniel_hozac the topic is stale ;) 1140029114 M * micah I know, its hard to keep up 1140029122 M * daniel_hozac i didn't update it when i saw how long it got with all the experimental versions... 1140029138 M * daniel_hozac (plus having both 2.0.2-rc1 and 2.0.2-rc5 looks odd) 1140029174 M * micah how about we do: 1140029256 M * micah mm, confusing :) 1140029591 Q * gerrit Ping timeout: 480 seconds 1140029949 J * comfrey ~comfrey@h-64-105-87-234.sttnwaho.covad.net 1140029957 M * Bertl welcome comfrey! 1140029994 M * micah ok, it looks to me like these are the latest: 1140029997 M * comfrey yo Bertl, hows it hangin'? 1140030010 M * micah vs2.0.2: patch-2.6.15.4-vs2.0.2-rc5.diff and patch-2.6.16-rc2-vs2.0.2-rc1.diff 1140030018 M * Bertl comfrey: fine, fine, and for you? 1140030031 M * micah vs2.1.1: patch-2.6.15.4-vs2.1.1-rc6.diff and -2.6.16-rc2-vs2.1.1-rc3.diff 1140030044 M * micah hey comfrey 1140030047 M * comfrey Bertl: yeah, keeping things moving. 1140030053 M * comfrey yo micah 1140030068 M * daniel_hozac micah: correct. 1140030069 M * Snow-Man What's the 'recommended' vserver version to be using these days? 1140030079 M * Snow-Man 2.0.1.3, or 2.1.0? 1140030086 M * Bertl micah: hmm, don't want to disappoint you, but the web listing is sorted by time, so the four patches at the bottom are the ones you're looking for :) 1140030096 M * Snow-Man Looking at running on at least 2.6.15 and possibly 2.6.16 if it comes out soonish. :) 1140030112 M * daniel_hozac Snow-Man: 2.0.1.3 is _old_, 2.0.2-rc5 is the latest. 1140030119 M * Bertl Snow-Man: the *-rc patches are a good choice IMHO 1140030134 M * Snow-Man daniel_hozac: mkay, was just looking at 'Downloads' on linux-vserver.org.. 1140030185 M * Snow-Man Bertl: so, 2.0.2-rc5 or 2.1.1-rc4, or...? :) 1140030200 M * micah Snow-Man: 2.0.2 unless you want experimental things, which is 2.1.1 1140030204 M * Snow-Man I guess a dumb question, but what's the difference between 2.0 and 2.1? :) 1140030213 M * Snow-Man micah: hmm, ok. 1140030226 M * Snow-Man Sounds like probably 2.0.2-rc5 then. 1140030235 M * Snow-Man Which patches cleanly against 2.6.16-rc3? 1140030246 M * Bertl Snow-Man: 2.0.x is the stable branch, more tested stuff, less features, 2.1.x is the devel branch 1140030273 M * Snow-Man Bertl: ok, but the 2.0 stuff is still good for more recent kernels (ie: 2.6.15, etc) 1140030277 M * Snow-Man right? :) 1140030322 M * Bertl yes, both branches are independant from the kernel version 1140030326 Q * ntrs Ping timeout: 480 seconds 1140030332 M * Bertl (i.e. they will follow recent kernel development) 1140030345 M * Snow-Man k. 1140030352 A * Snow-Man just remembers the 1.2 days... :) 1140030430 T * micah http://linux-vserver.org/ | latest stable: 2.01, 1.2.10 | Stable release candidates: patch-2.6.15.4-vs2.0.2-rc5.diff, patch-2.6.16-rc2-vs2.0.2-rc1.diff | Experimental: patch-2.6.15.4-vs2.1.1-rc6.diff, patch-2.6.16-rc2-vs2.1.1-rc3.diff | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifeti 1140030436 M * micah how about that? 1140030441 M * Snow-Man micah: Thanks. :) 1140030446 M * Bertl eeek! 1140030454 M * micah too noisy? 1140030491 M * Bertl more important, it is too long 1140030512 M * Bertl (even cuts off the half of our motto :) 1140030530 M * Snow-Man hehe. 1140030545 T * Doener http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.1.1-rc4, 2.0.2-rc3 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1140030574 M * Bertl tx 1140030576 M * Doener np 1140030578 M * micah was about to change to: http://linux-vserver.org/ | latest stable: 2.01, 1.2.10 | Stable release candidates: (2.6.15.4) 2.0.2-rc5, (2.6.16-rc2) 2.0.2-rc1 | Experimental: (2.6.15.4) 2.1.1-rc6, (2.6.16-rc2) 2.1.1-rc3 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1140030639 M * micah don't you want to include the 2.0.2 -rcs in the topic? 1140030640 A * Snow-Man notes the topic is now also out of date... 1140030652 M * Snow-Man micah: It's there, but for -rc3.. 1140030670 M * daniel_hozac rc3 is the mean of the -rcs :) 1140030675 M * Doener I just reset it to the previous state 1140030679 M * daniel_hozac (rc1 and rc5 :)) 1140030682 J * gerrit ~gerrit@c-67-160-130-59.hsd1.wa.comcast.net 1140030683 M * Snow-Man daniel_hozac: haha. 1140030689 M * Bertl give me a minute 1140030690 M * Doener s/reset/resetted/ 1140030701 M * Doener maybe #kernelnewbies style? 1140030704 M * micah hehe 1140030741 M * micah i like including the actual patch name because its a bit hard trying to figure out which is which in http://vserver.13thfloor.at/Experimental/ at the moment :) 1140030768 T * Bertl http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.1.1-rc6/3, 2.0.2-rc5/1 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1140030803 M * Bertl and the next -rc* will sync 2.6.15 and 2.6.16 so that folks don't get confused by that *sigh* 1140030821 M * daniel_hozac hehe. 1140030825 M * eyck those folks... they always get confused.. 1140030843 M * eyck btw, any chance for 1.2.12? 1140030851 M * micah hehe 1140030855 M * daniel_hozac eyck: and skip 1.2.11? 1140030863 M * Bertl eyck: there is always a chance :) 1140030883 M * eyck daniel_hozac: I've been using 1.2.11 for over a year now..., I want 1.2.12 now. 1140030890 M * Bertl eyck: but it's really a tough decision with 1.2.12 1140030927 M * Bertl just think about it, today I release 1.2.12 and tomorrow a million folks have to update as 1.2.11 got superceeded :) 1140030942 M * Bertl not sure I can really do that *G* 1140030954 M * eyck oh....you're evil and you know it. 1140030979 M * micah hehe 1140031194 M * Bertl eyck: please remind me, what was your reason for sticking to 2.4? 1140031210 M * Bertl (this is a serious question) 1140031272 M * eyck well, 2.6 is not mantained as stable app as of yet... which results in various problems when trying to put production loads on it, 1140031294 M * eyck for one - I've got 2.4 compaq proliant tools, I ain't got 2.6 ones.. 1140031302 M * eyck vserver on 2.6 is in state of flux.. 1140031313 M * eyck at least it was some time ago 1140031339 M * eyck I assume that latest announcments mean that this has changed? 1140031355 M * daniel_hozac how is vserver on 2.6 in a state of flux? 1140031361 M * eyck there is no openwall on 2.6 1140031368 M * Bertl hmm, well, 2.0.2 will be the third stable release (for 2.6 :) 1140031395 Q * gerrit Ping timeout: 480 seconds 1140031437 M * eyck yeah, last I checked you guys were trying to remove 'vserver sth enter' functionality..., such moves count as a no-no for production scenarios 1140031496 J * prae ~benjamin@sherpadown.net 1140031506 M * eyck and then, you're in a process of taking apart whole 2.0.x, in hopes of inclusion in mainline 1140031530 M * eyck which means there will be some changes while linus bitches around... 1140031554 M * eyck all and all - 2.0.x is great, and inclusion in mainline is even greater 1140031573 M * micah Bertl: ok, I've got most of the debian packaging ready for 2.0.2/2.1.1 release, give me a warning and the patch and I'll put it in place 1140031587 M * micah eyck: that sounds like the 2.1 development work, not 2.0.x 1140031659 M * eyck micah: really? ...oh well, in this case as soon as 2.6.x is ready I will give it another try 1140031689 M * micah eyck: when 2.6.x is ready? 1140031789 M * eyck when developers stop playing with it, 1140031815 M * eyck as in vserver - 1.2.x is ready ;), 2.0 is probably ready, 1140031902 M * Bertl hmm, well, I do not suggest 1.2.x to my customers, as 2.0.x has superceeded it in correctness and functionality 1140031938 M * Bertl similar like I would never suggest to use 2.2 kernels, although they are pretty stable now :) 1140031942 M * eyck good for you 1140031992 M * Bertl but it would be interesting to know how many 2.4 installations are out there, and more important, how many _new_ installation happen based on 2.4 1140032009 M * shuri i got 2.4 1140032011 M * eyck yeah, 2.0.4x kernels are way better then 2.2.x, 1140032017 M * eyck I don't recommend 2.2.x either 1140032033 M * shuri i recommend 1.0.x lol 1140032044 M * eyck Bertl: well, you can count me in on _new_ installation baed on 2.4 1140032054 M * eyck installations based. sorry. 1140032058 M * Bertl eyck: yeah, I knew that :) 1140032067 M * eyck 2 this week, 3 more next week 1140032171 M * daniel_hozac Bertl: webserver stats for the 2.4 patches? 1140032191 M * daniel_hozac should at least give you a rough idea. 1140032203 M * eyck probably not, 1140032222 M * eyck lot's of kids download newest stuff and inflate the stats 1140032241 M * daniel_hozac 2.4 isn't newest :) 1140032250 M * Bertl yeah, would have to remove the 10 hits per day from eyck, looking for the 1.2.12 release 1140032266 M * eyck well, I gotta keep current, 1140032268 M * daniel_hozac hehe. 1140032284 M * eyck can't afford to miss the 1.2.12 release 1140032308 M * daniel_hozac what would 1.2.12 have that 1.2.11-rc1 doesn't? 1140032362 M * eyck well, nicer version number for one, digits in growing succesion 1140032372 M * Bertl to be serious on the 1.2.11 release, there are two things which keep me from releasing it right now 1140032384 M * eyck yeah? 1140032415 M * Bertl 1) that I'd like to backport the fixes we did in the network stack from 2.6 1140032421 M * Bertl 2) that I do not want to spend much time on testing a dead branch 1140032434 M * eyck it's not dead, it's just resting. 1140032475 M * eyck ad 1 - what fixes? 1140032550 M * Bertl we did a few cosmetic and some not-so-cosmetic changes to the stack checks to avoid 'issues' observed on 2.4 1140032569 M * eyck any way of getting a list of those changes? 1140032605 M * Bertl yeah, probably by looking through the changelogs of all 2.6 releases and checking the patches, where avail 1140032642 M * eyck hmm, ok, thanks 1140033498 N * nokoya nokoyaz 1140033503 N * nokoyaz nokoya 1140035109 J * gerrit ~gerrit@c-67-160-130-59.hsd1.wa.comcast.net 1140035414 J * shedi ~siggi@inferno.lhi.is 1140035930 Q * flock Remote host closed the connection 1140036084 P * meandtheshell 1140036746 Q * liquid3649_ Remote host closed the connection 1140037084 J * Aiken ~james@tooax6-015.dialup.optusnet.com.au 1140038147 J * ntrs ~ntrs@68-188-37-15.dhcp.stls.mo.charter.com 1140038607 Q * lilalinux Remote host closed the connection 1140039080 J * mikeb ~baptiste@tigger.msbnetworks.net 1140039242 M * mikeb Having a strange problem - wondering if anyone else has seen it. I have a server runnign mostly FC2 vserver instances. They've been runnign great. kernel is 2.6.14.4 Vserver 2.0.1 Well, I decided to get an FC4 based vserver instance up and running. Was able to create the vserver, use yum and the vps rpms to get things going. RPMs install fine. Base system setups up great, vserver strts fine, etc. But I absolutely cannot set the passwords for user 1140039283 M * mikeb every time I use the passwd command, I enter the password twice and get passwd: System error No other logs or messages. /etc/shaodw updates with an MD5 hash as expected 1140039324 M * mikeb but you cannot login with SSH, etc My Google-fo failed me - the only other related mention of a problem like this was from a vserver user back in July in some old IRC chat logs (no solution there) 1140039346 M * mikeb Everythign else on the vserver works fine. Its very bizarre 1140039401 M * Bertl how did you enter the guest? 1140039410 M * mikeb vserver NAME enter 1140039439 M * Bertl and you are setting the password for an existing user, yes? 1140039450 M * mikeb yes - same error happens with root 1140039466 M * mikeb passwd reports that status as OK 1140039474 M * Bertl did you try after logging in via ssh? 1140039486 M * mikeb I can't login with ssh 1140039496 M * mikeb it fails to authenticate 1140039520 M * Bertl hmm, sounds like something is definitely wrong 1140039535 M * mikeb its wild. My FC2 guests are dandy - never had a problem 1140039558 M * mikeb I've recreated this guest 4 times now using different repos and different methods of getting the rpms in and the system off the groun d- happens every time 1140039576 M * mikeb and absolutely nothign in the logs 1140039595 M * Bertl sounds like an FC4 issue to me ... but let's check a few things 1140039656 M * Bertl first, check the guest and kernel for auditing 1140039818 N * ebiederm ebiederm_oO 1140040034 M * mikeb OK I've used linux for years and built kernels many times - how do you check for auditing? Are you referrign to selinux or something? 1140040069 M * Bertl # grep AUDIT .config 1140040069 M * Bertl # CONFIG_AUDIT is not set 1140040080 M * Doener Medivh: you had that problem, too, right? Do you remember your solution? 1140040101 M * mikeb Heh Medivh's chat log was the one I found 1140040130 M * mikeb Bertl: Yes, it was enabled during the build 1140040167 M * Bertl now check for uuid libs/entries in pam (guest) 1140040194 M * mikeb the ones that vps-pam commetns out or somethign different? 1140040200 Q * bonbons Quit: Leaving 1140040230 M * Bertl ah, there is a package which removes them? 1140040248 M * mikeb vps-pam comments out all the pam_loginuid.so entires in /etc/pam.d 1140040267 M * Bertl okay, so that should be no problem then ... 1140040294 M * mikeb ok - I see I have audit-0libs installed but the audit rpm was never isntalled 1140040298 M * mikeb in teh guest - should it be? 1140040315 M * Bertl let's try something else. what happens if you simply chroot() into the guest's dir and try to set the password? 1140040356 M * mikeb it works 1140040376 M * Bertl no error compared to the enter case? 1140040410 M * mikeb not on the password set, but ssh still fails. 1140040422 M * mikeb but passwd says all tokens updated successfully 1140040451 M * mikeb and gettign failed password in the secure log of the guest trying to ssh in 1140040457 M * Bertl okay, then please do an strace -fF -o passwd.trace for both cases 1140040457 M * mikeb (non priv userid of course) 1140040481 M * Bertl use an empty password or a very simple one to keep the log small 1140040604 M * Doener mikeb: did you disable SELinux stuff in the vserver config? /etc/selinux/config 1140040650 M * mikeb Doener: don't even have that directory. The selinux rpms weren't installed 1140040662 M * Doener ok, just took that from the fc3 guide 1140040666 M * mikeb are you referring to /etc/selinux in teh guest or on the host? 1140040709 M * Doener yeah, just noticed that i've still been reading the host section, sorry 1140040753 M * mikeb Bertl: OK - have both traces 1140040825 M * Bertl okay, pls upload them somewhere if possible 1140040913 M * mikeb http://www.msbnetworks.net/passwd.trace.good http://www.msbnetworks.net/passwd.trace.bad 1140040971 M * mikeb Hmm somethign in proc? 1140040972 M * mikeb readlink("/proc/self/exe", 0x7fffffb7f120, 4095) = -1 ENOENT (No such file or directory) 1140040981 M * mikeb since the host is FC2? 1140041073 M * Bertl no, definitely a pam issue 1140041143 M * Skram Hi All 1140041206 M * Bertl mikeb: hmm, but the /proc/self/exe looks strange indeed 1140041261 M * Bertl mikeb: what does 'll /proc/self/exe' say after you entered the guest? 1140041283 M * mikeb lrwxrwxrwx 1 root root 0 Feb 15 17:07 /proc/self/exe -> /bin/ls 1140041302 M * Bertl okay, so that seems to work 1140041380 M * Bertl but nevertheless, I think the 'error' is the pam reply 1140041405 M * SiD3WiNDR raaah 1140041411 M * SiD3WiNDR ICMP DoS in 2.6 1140041416 M * SiD3WiNDR kinky :( 1140041496 M * Bertl mikeb: could you upload the output of 'cat /etc/pam.d/passwd' somewhere? 1140041507 M * Bertl (inside the guest) 1140041576 M * mikeb http://www.msbnetworks.net/system-auth http://www.msbnetworks.net/passwd 1140041619 M * mikeb those are stock from teh rpm. In one iteration I tried authconfig but it didn't help and ended up hard coding to /lib/security instead of /lib64/security 1140041639 M * Bertl ah? x86_64? 1140041659 M * mikeb 1140041676 M * mikeb sorry forgot to include that initially 1140041683 M * Bertl hmm, and the guest is 64bit? 1140041688 M * mikeb all of it 1140041695 M * mikeb I checked every pkg yum installed 1140041721 M * Bertl what about util-vserver? 1140041759 M * mikeb util-vserver-0.30.207-0 1140041761 J * diogo ~diogo@143.107.240.112 1140041770 M * Bertl mikeb: I mean, is it 64bit too? 1140041772 M * diogo hello 1140041773 M * mikeb oh yes 1140041777 M * Bertl hey diogo! 1140041783 M * diogo hey Bertl ! 1140041841 M * diogo i got some vserver questions ! ;) 1140041849 M * Bertl mikeb: would it be hard to try with 0.30.210? 1140041854 M * diogo of course ! ;) 1140041861 M * Bertl diogo: let's hear! 1140041882 M * diogo i can get my syslog-ng to work 1140041893 M * Bertl excellent! :) 1140041895 M * mikeb Bertl: Nope - I had 209 build just hadn't gotten it installed. Give me a few 1140041905 M * diogo nope! 1140041909 M * diogo i cant get my syslog-ng to work 1140041914 M * Bertl :) 1140041917 M * Bertl how so? 1140041991 M * diogo syslog do not want to start because it dont get access to /proc/ 1140042054 M * Bertl syslog does not need access to proc, besides, depending on your patch version, you can work around by adding a context capability 1140042064 M * mikeb Bertl: I only see 30.209 on 13thfloor - am I in the wrong place? 1140042094 M * Bertl http://www.13thfloor.at/~ensc/util-vserver/files/alpha/ 1140042120 M * diogo Bertl: let me pvt the error mesage 1140042123 M * mikeb Thanks - I always forget to look there 1140042146 M * Bertl http://vserver.13thfloor.at/Stuff/MANDRAKE/util-vserver-0.30.210-1mdk.src.rpm 1140042171 M * Bertl diogo: that's not much :) 1140042185 M * diogo ;) 1140042195 M * Bertl well, as expected, two simple solutions: 1140042216 M * Bertl a) remove the /proc/kmsg entry from the config 1140042249 M * Bertl b) add the VXC_SYSLOG capability for the guest 1140042265 M * diogo where's this config file ? 1140042273 M * Bertl both will give the same result, as nothing will be logged from kmsg 1140042311 M * diogo okay ... 1140042315 M * diogo let me see 1140042352 M * Bertl /etc/syslog-ng.conf or so 1140042406 M * diogo source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); }; 1140042426 M * Bertl yep, that one, comment it out 1140042427 M * diogo can i take pipe("/proc/kmsg"); out 1140042434 M * diogo the whole line ? 1140042442 M * Bertl no, just the pipe part 1140042451 M * diogo okay , thanks ! 1140042461 M * Bertl you're welcome! 1140042491 M * diogo * Starting syslog-ng ... [ ok ] 1140042494 M * diogo * Starting syslog-ng ... [ ok ] 1140042496 M * Skram hey diogo ;) 1140042497 M * diogo thanks again ! ;) 1140042509 M * diogo hey Skram !! thank you too ! ;) 1140042548 M * Skram No Problem ;) 1140042582 M * Skram /24 is 64 ip's right? 1140042599 M * Bertl nope, 256(254) 1140042603 M * Skram Arg 1140042605 M * mikeb Bertl: I feel so stupid 1140042614 M * Skram is there a /## for 64? :( 1140042615 M * Bertl mikeb: hmm, why? 1140042619 M * Skram I dont think so, is there? 1140042625 M * mikeb I've had so many gotchas with a one or two tick old util-vserer :) 1140042628 M * Bertl Skram: ipcalc, and yes, /28 1140042629 M * mikeb .210 fixed it 1140042634 M * Skram Bertl: thanks 1140042636 M * mikeb at least it sets the password ok 1140042639 A * mikeb tries ssh 1140042648 M * Bertl Skram: oops sorry, /26 :) 1140042659 M * Skram so /26 IS 64 ips? 1140042660 M * Skram ill check 1140042667 M * Skram i forgot ipcalc, i was looking for ipcount 1140042676 M * mikeb boom - works. /me tatoos "Alwasy upgrade util-vserver when it doesn't work" to his forehead 1140042697 M * Bertl mikeb: but in mirror writing :) 1140042697 M * mikeb Bertl: Thanks! 1140042702 M * mikeb Bertl: of coruse 1140042706 M * Bertl mikeb: you're welcome! 1140042709 M * mikeb course even 1140042898 M * Skram etc/vservers/sentien-shells/interfaces/1/dev .. the ip is coming from the host's eth0... what do i put in that file? 1140042909 M * Skram eth0 or is it what it comes up as on the guest, in which case i want to put eth1 1140042913 M * Skram ? 1140042956 M * Bertl you want to 'reuse' an already assigned ip for the guest, then you want to touch 'nodev' and remove 'dev' 1140042964 M * Skram okay 1140042965 M * Skram also... 1140042966 M * Skram dnet: Failed to open device eth0 1140042969 M * Skram whats up with that? 1140042976 M * Bertl what's dnet? 1140042983 M * Skram done know 1140042991 M * Skram im trying to run nmap and it says that error 1140042993 M * Bertl me neither, when does it fail? 1140042998 M * Skram Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-02-15 22:35 Local time zone must be set--see zic manual page 1140043002 M * Skram dnet: Failed to open device eth0 1140043004 M * Skram QUITTING! 1140043011 M * Bertl on the guest? 1140043034 M * Skram Yeapps 1140043047 M * Bertl well, I guess nmap uses raw sockets 1140043060 M * Skram arg 1140043071 M * Skram \ 1140043071 M * Bertl you usually don't want that in a guest, but you can give CAP_NET_RAW for a test 1140043082 M * Skram sorry, but how do i do that? 1140043094 M * Bertl bcapabilities files 1140043098 M * Bertl *file even 1140043101 M * Skram also, this guest is owned by us (the owners of the host) so its not a big deal 1140043103 M * Skram okay lemme look 1140043131 M * Skram same error 1140043136 M * Skram do i need to restart the host? 1140043142 M * Bertl yup 1140043177 M * Skram host or guest? 1140043182 M * Skram i meant guest... 1140043188 M * Bertl yeah, the guest 1140043196 M * Skram Okay, thank gosh 1140044734 Q * cdrx Quit: Leaving 1140045249 M * michal` Bertl: ibm is watching you ;) 1140045275 M * Bertl michal`: should I be worried? :) 1140045288 M * michal` heh, i do not think so 1140045472 J * TrueLight ~kvirc@truelight.xs4all.nl 1140045486 M * Bertl welcome TrueLight! 1140045487 M * TrueLight Good afternoon all :) 1140045505 M * TrueLight I have kind of a weird problem, but that most people will have who join here :p 1140045522 M * TrueLight vrsetup keeps on telling me that the device doesn't exist, while it does... and it did work in the past, and I can't figure it out :) 1140045532 M * Skram I had someone from IBM open a sales ticket yesterday, still no reply tho. 1140045534 M * Skram Hrmm 1140045555 M * Skram And it doesnt seem to be any of the ibm people in here. 1140045558 M * Bertl TrueLight: first, what kernel/patch/tool versions? 1140045582 M * TrueLight Bertl: 2.01, x86_64, and... pff, good question ;) 1140045600 M * Bertl testme.sh will tell you :) 1140045634 M * TrueLight Where should that file be :p 1140045653 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh-0.15 1140045657 M * TrueLight Anyway, latest stable tools in Gentoo 1140045676 M * Bertl what is the vrsetup command line you use? 1140045715 M * TrueLight vrsetup /dev/vroot1 /dev/vg/vsdisk3 1140045737 M * TrueLight An other, unrelated, question, if I once set up a vroot (vroot0 in this case), is there any need to set it up again after a reboot? 1140045759 M * Bertl yup, as most things in the kernel, it's not persistant 1140045763 M * TrueLight (ps, the test thing didn't give me too much info :)) 1140045776 M * TrueLight and what happens if that isn't done for a long long time? :) 1140045793 M * Bertl well, the the device is not configured ... 1140045794 M * TrueLight (still, quotas seems to work just fine) 1140045800 Q * mkhl Quit: 1140045826 M * Bertl quota will work with or without, just certain quota commands require the device 1140045839 M * Skram can i upgrade my util-vservers even if my kernel is .14? 1140045860 M * TrueLight (I tried to figure out how this vroot / quota stuff works, but I failed... which doesn't happen often :p) 1140045889 M * Bertl TrueLight: does /proc/devices list vroot? 1140045890 M * TrueLight so, there is not a real need for the vroot to exist in order for the quota to work? I mean, what does it do more when the vroot is created then without? 1140045892 M * daniel_hozac configured correctly, util-vserver-0.30.210 _should_ (but apparently doesn't) work on 1.2.10. 1140045894 M * mugwump guh, new vpid thread from ibm 1140045907 M * TrueLight Bertl: no :s 1140045920 M * TrueLight (btw, the problem was created after an upgrade from 2.0 to 2.01) 1140045953 M * daniel_hozac grep CONFIG_BLK_DEV_VROOT .config 1140045956 M * Skram daniel_hozac: so thats a no to my question? 1140045959 M * Bertl TrueLight: well, you should probably curse the folks who said udev is better than devfs, then load the vroot module and be happy 1140045975 M * daniel_hozac Skram: that's a definite yes. 1140045987 M * TrueLight Bertl: I do that every day, cursing udev, because it gave me more problems then it makes things better... but that is too late now :) 1140045992 M * daniel_hozac util-vserver is packed with so much legacy stuff it's scary. 1140046006 M * TrueLight daniel_hozac: VROOT doesn't exist in .config 1140046013 M * Skram daniel_hozac: Okay, Good 1140046015 M * Skram hehe 1140046032 M * TrueLight Bertl: but how much harm does it do if the vroot doesn't point to anything real? For quotas, that is 1140046035 M * Bertl TrueLight: very interesting ... 1140046064 M * Bertl TrueLight: certain quota tools will fail inside ... that's it 1140046077 M * TrueLight The main stuff seems to work.. user and group quota shows up nicely 1140046140 N * mugwump SamVilain 1140046160 A * SamVilain will be commencing git/stgit tutorial in 90min 1140046161 M * TrueLight but why is there no VROOT in my config? It isn't even settable :) 1140046169 M * Skram how do i see what VServer version we are using 1140046178 M * Skram i mean vserver-utils 1140046179 M * Bertl TrueLight: that's the interesting part 1140046198 M * Skram * sys-cluster/util-vserver 1140046198 M * Skram Latest version available: 0.30.210-r1 1140046198 M * Skram Latest version installed: [ Not Installed ] 1140046200 M * Skram Weird. 1140046210 M * TrueLight Bertl: it is just a simple gentoo emerge :) Didn't touch it! 1140046239 M * TrueLight it was in 2.0 1140046241 M * TrueLight but it isn't in 2.01 1140046288 M * Bertl well, let me put it this way ... 1140046288 J * mkhl mkhl@200-148-41-222.dsl.telesp.net.br 1140046313 M * Bertl config BLK_DEV_VROOT 1140046325 M * Bertl is in 2.0.1, and it does not depend on anything 1140046363 M * TrueLight hmmz, it sure is there 1140046365 M * TrueLight even in Kconfig 1140046387 M * Bertl soo, why isn't it in .config? 1140046394 M * TrueLight Something clearly is making a boo-hoo 1140046420 M * daniel_hozac depends on QUOTACTL. 1140046447 M * TrueLight Which of course isn't there 1140046459 M * TrueLight In 2.0 it didn't depend on that 1140046461 M * TrueLight and there the problem is 1140046501 M * TrueLight And then indeed it does show up :) 1140046513 M * Bertl hmm, so how is your quota working without that? 1140046518 M * TrueLight Good good, thank you both, Bertl and daniel_hozac :) 1140046523 M * TrueLight Bertl: the VPS uses quota 1140046549 M * Bertl seems like I'm missing something here ... 1140046551 M * TrueLight Bertl: clearly it doesn't need kernel stuff to do it... 1140046563 M * TrueLight or the VPS just doesn't use stuff that needs the kernel parts :) 1140046571 M * TrueLight But clearly it was wrongly configured 1140046575 M * Bertl well, that is really amazing ... 1140046587 M * TrueLight :) It sure is, because the quota really worked! 1140046606 M * Bertl the interesting question now is, who enforces the quota? 1140046617 M * TrueLight Maybe the software itself 1140046621 M * TrueLight or maybe it was just fake 1140046643 M * TrueLight like the ftp daemon checks the quota before accepting a file for example 1140046692 M * TrueLight Btw, one more question, loadaverage... in the /proc/virtual I can see the loadaverage of the VPS itself, but inside a VPS /proc/loadavg shows the system loadavg... can that be configured? 1140046735 M * Bertl sounds like a bug, probably fixed already 1140046741 M * TrueLight It is in 2.01 1140046755 M * TrueLight but we will see in the next release :) 1140046759 M * daniel_hozac virt_load. 1140046771 M * TrueLight daniel_hozac: what do you mean? 1140046786 M * Bertl daniel_hozac: should be enabled by default, no? 1140046796 M * Bertl daniel_hozac: with recent tools, I mean 1140046828 M * daniel_hozac doesn't look like it... 1140046847 M * Bertl interesting ... well 1140046867 M * TrueLight ah, so if I just add it to flags, it should work :) 1140046880 M * Skram so how does it determine the vserver's load? 1140046882 P * stefani I'm Parting (the water) 1140046885 M * Bertl yup, as the 'other' virtualizations 1140046922 M * TrueLight it does show virt_uptime btw 1140046935 M * TrueLight What is on by default? 1140047031 M * TrueLight k, that works very nice, tnx again :) 1140047037 M * daniel_hozac hide_netif, virt_uptime, info_init. 1140047047 M * TrueLight k, tnx :) 1140047048 M * Skram what does hide_netif do? 1140047050 M * Skram ;) 1140047100 M * TrueLight k, now this server just needs a reboot, which I need to schedule.... if it didn't work, I will be back in a week ;) 1140047106 M * TrueLight got to go now :) Tnx for everything, you are nice people :) 1140047107 M * TrueLight bye :) 1140047124 M * daniel_hozac bye. 1140047130 M * Skram Tootles 1140047134 P * TrueLight