1140480945 Q * lilalinux Remote host closed the connection 1140483440 Q * vrwttnmtu Quit: Leaving 1140485265 Q * azazel Quit: Client exiting 1140485602 Q * fernao Read error: Connection reset by peer 1140485680 Q * diogo Ping timeout: 480 seconds 1140485803 Q * pflanze Quit: [x]chat 1140486536 M * Bertl okay, I'm off to bed now .. have a nice one, and cya tomorrow! 1140486547 N * Bertl Bertl_zZ 1140486567 J * JavaUser ~JavaUser@S010600402b4f1585.vf.shawcable.net 1140486574 M * JavaUser hello 1140486640 Q * JavaUser Quit: 1140487226 M * Skram goodbye 1140487880 J * Aiken ~james@tooax6-243.dialup.optusnet.com.au 1140488137 Q * Doener Quit: Leaving 1140488201 Q * gerrit Ping timeout: 480 seconds 1140489535 Q * PotatoBob Remote host closed the connection 1140490520 Q * matta Ping timeout: 480 seconds 1140494752 J * matta ~matta@71.224.125.126 1140496430 M * mugwump my, setattr CLI is really ugly 1140496455 M * mugwump --iunlink-but-not-immutable # nice one, enrico 1140496468 M * mugwump especially given it doesn't even do what it says 1140497343 J * matt1 ~matta@71.224.125.126 1140497682 Q * matta Read error: Operation timed out 1140499308 M * daniel_hozac does what it's supposed to here. 1140499328 M * mugwump only if the file already has no bits set. 1140499359 M * daniel_hozac well, yeah. 1140499385 M * mugwump don't worry, I'm just moaning because the CLI was incompatibly changed between versions to stupid long names that require me to run the command twice 1140499622 M * daniel_hozac why would you need to run it twice? 1140499768 M * mugwump if you want to set just one bit 1140499781 M * mugwump you have to run it once to clear the other one 1140499927 M * daniel_hozac which bits would that be? 1140499952 M * mugwump oh, immutable and ili 1140499970 M * daniel_hozac ili? 1140499980 M * daniel_hozac chattr can set immutable. 1140500009 M * daniel_hozac as does setattr --iunlink --~iunlink-but-not-immutable ... 1140500022 M * mugwump ah, didn't try stacking them :) 1140500186 M * mugwump actually, that doesn't seem to work 1140500237 M * daniel_hozac works fine here. 1140500324 M * mugwump I'm on 0.30.208 1140500392 A * mugwump hmms 1140500421 M * daniel_hozac 0.30.209 and 0.30.210 both set just immutable. 1140500537 M * mugwump ok, then, it's my ancient utils then 1140500566 M * mugwump where "ancient" includes ubuntu breezy 1140500606 M * daniel_hozac hmm, isn't that the one with broken utils? 1140500739 M * mugwump dunno. I've been using 0.30.196 for a while on my main machine. 1140500766 M * mugwump wfm 1140500941 Q * brc Quit: No windows for this server 1140501082 J * shuri ~boafroid@64.235.209.226 1140501165 Q * shuri Quit: 1140501435 Q * Aiken Quit: Leaving 1140502109 M * daniel_hozac mugwump: which libvserver? Hollow's or util-vserver's? 1140502118 M * mugwump Hollow's 1140502131 M * daniel_hozac oh. 1140502136 M * mugwump problem? 1140502146 M * Hollow hm? 1140502163 M * daniel_hozac no, just wondering. 1140502212 M * Hollow just to get it right... you have util-vserver-0.30.208 and libvserver-x.x installed? 1140502319 M * mugwump yes, I think so. the Makefile.PL detects the headers around, or can be overridden by env. var 1140502350 M * mugwump I've been playing with libvserver 0.4 and 1.0.2 1140502351 M * Hollow well, you know that libvserver is incompatible with util-vserver? 1140502366 M * Hollow you can't install both at a time.. 1140502377 M * mugwump I have /usr/lib/libvserver.so.0 and .so.1 1140502408 M * Hollow yeah that's one of the old libvservers... but since 1.0 only a static lib is installed 1140502480 M * mugwump unless you don't have dietlibc? 1140502528 M * Hollow since 1.0 only dietlibc is supported, it will never link or install anything against glibc or shared libs 1140502554 M * mugwump can I ask why? 1140502582 M * Hollow yeah, it's a pita, and you don't really need libvserver as a shared lib 1140502610 M * Hollow i even tend to move libvserver back to vsever-utils tarball... 1140502649 M * mugwump ok, well, that means it will just make the Perl .so when it builds the extension 1140502660 M * Hollow which perl so? 1140502669 M * mugwump for Linux::VServer (just announced on list) 1140502727 M * Hollow hm 1140502737 M * mugwump I'll make sure my testbeds are clean for testing, anyway. what's there is just to whet interested party's appetites 1140502748 M * Hollow thing is... shared libraries are a pita with dietlibc 1140502857 M * mugwump ok, so I'll check it links in the functions from the .a files at the appropriate moment. 1140502893 M * Hollow are these pure syscall bindings or does it provide higher level functions too? 1140502917 M * mugwump for now, there will just be pure syscall bindings. Further abstraction can go into a different module 1140502928 M * Hollow ok, sounds good :) 1140502947 M * mugwump However structures passed to the syscalls may end up as objects. I've only really done three syscalls so far, it's basically all infrastructure 1140502948 M * Hollow i'm still planning doing this for ruby, but it's priority isn't very high ;) 1140503041 M * daniel_hozac SWIG? 1140503049 M * mugwump please don't use language like that in here 1140503056 M * mugwump think of the children 1140503085 M * Hollow heh 1140503100 M * daniel_hozac haha. 1140503183 M * mugwump seriously, though, I'm doing it in XS and Pure Perl because that's what I'm most familiar with. I would certainly be interested in co-operating in parallel efforts in Ruby or Python (to pick a couple of languages loved by SysAdmins) 1140503259 M * mugwump if somebody can bring some SWIG experience to the plate, that would be cool, too 1140503261 M * daniel_hozac i've been meaning to look into Python bindings. 1140503743 M * eyck hmm, sysadmins love perl, they might like ruby, but python is for twisted B&D folks 1140503790 M * Hollow :) 1140503968 M * mugwump well, anyway, the only think that's twisted B&D to me is huge sets of shell scripts 1140503970 M * eyck is there a different word for love as in 'your family' and as in 'love affair' in english? 1140504009 M * eyck mugwump: you're wrong, what you're reffering to, is anarchy running wild/anarchy gone wrong. 1140504102 M * Hollow off to school, cu later.. 1140504114 M * eyck B&D is not just a derogatory term, it actually means something.. and some people like it. 1140504130 M * mugwump love as in 'love affair' might be lust, but normally terms like 'love like a brother' or 'motherly love' must be used 1140504187 M * mugwump lust, or passion 1140504236 M * eyck mugwump: pity, because love as in 'family' would describe sysadmins relationships with perl perfectly... you love it, but did you have any choice in the matter? ;) 1140504272 M * eyck mugwump: hmm, lust is too specific, passion - better, but still not it, 1140504313 M * eyck ...then there are fruits of passion like ruby ;) 1140504321 M * eyck or hate - like python 1140504354 M * eyck hmm, usually hate wins in real world 1140504380 M * mugwump have some faith, it's not all so bad 1140504489 M * mugwump right, well, I'm off ... later folks, I'll look forward to announcements for Python and Ruby libvserver bindings tomorrow? ;) 1140504907 M * eyck good luck 1140511370 Q * shedi Quit: Leaving 1140512790 M * eyck hmm, 1140512808 M * eyck Bertl_zZ: is it possible to replace /dev/random with userspace-fed socket? 1140513011 J * oliwel ~oliwel@ldvpc07.ldv.e-technik.tu-muenchen.de 1140513027 A * oliwel waves hello to the crowd 1140513029 M * oliwel phreak``: knock 1140513030 M * cehteh eyck: i think for most applications yes, when they just open it and read 1140513039 M * phreak`` oliwel: yup :) 1140513056 M * cehteh dunno if that is wise from a security viewpoint 1140513920 J * bonbons ~bonbons@83.222.39.180 1140514553 J * shedi ~siggi@tolvudeild-204.lhi.is 1140514643 J * prae ~prae@ezoffice.mandriva.com 1140515331 J * lilalinux ~plasma@h1-gw.of.net-lab.net 1140516112 M * eyck cehteh: hmm, I'm thinking more about not loosing functionality, it would be easy for me to create such app, but virtualising /dev/random would probably eat a lot more resources, and not many people would get the benefits 1140516155 M * cehteh yep 1140516166 M * cehteh well not nessary .. 1140516205 M * cehteh i think making a real /dev/random readonly on the vservers should suffice 1140516226 M * cehteh there is kindof DoS when someone sucking the random pool empty 1140516269 M * eyck hmm, with /dev/random readonly, you would be able to suck it dry... 1140516285 M * cehteh but if you make a userland random generator the same would happen, likely only for the vserver but in turn it needs to gather entropy and stuck until there is enough 1140516286 M * eyck but you would not be able to replenish it from userspace.. not good. 1140516314 M * eyck cehteh: yeah, what I would want is - one vserver/guest not being able to suck dry entropy of the others 1140516327 M * cehteh well maybe vserver could add some quotas to /dev/random 1140516344 M * cehteh mhm or do that y a userspace daemon 1140516380 M * cehteh are there any ioctl's on /dev/random or is it only read/write? 1140516422 M * eyck there are ioctl, 1140516442 M * eyck but they are used for replenishing entropy pool 1140516698 M * eyck and I wouldn't give access to them to guests 1140516698 M * cehteh yeah 1140516698 M * cehteh i guess most things you do is just read some bytes 1140516698 M * eyck (with those ioctl you're able to feed non-random data to /dev/random, and then lie about how much randomness there is, resulting in non-high-quality randomness from your /dev/random) 1140516698 M * cehteh some multiplexer/quota daemon could handle that 1140516698 M * eyck yes, that's what I'm thinking 1140516698 N * ebiederm_oO ebiederm 1140516698 M * cehteh could be even easy to be done .. the only problem is that it requires more resourced just by itself 1140516698 M * ebiederm I suspect what is really wanted with /dev/random is not quotas so much as fair scheduling. 1140516698 M * cehteh mhm .. and maybe some programs check if /dev/random is a device file with the right major/minor .. 1140516698 M * cehteh at least a very cautionous programm should do that 1140516698 M * cehteh but thats just a guess 1140516698 M * ebiederm Something like you can suck /dev/random dry but if you do everyone else on the system has priority on the next bit of purely random data. 1140516698 M * cehteh define fair scheduling ... since it might be that some vservers will actually require much more random than others 1140516698 M * eyck I would prefer not sucking it dry at all ;) 1140516717 M * cehteh and one wants to define that .. else a vserver which normall schoudnt require much random is a base of attacking the others 1140516728 M * cehteh you cant avoid the sucking dry .. 1140516760 M * eyck I can. 1140516776 M * eyck I think.. 1140516788 M * cehteh no you cant .. since the entropy which is available is still limited 1140516936 M * cehteh unless you make some limits for the guest they will be able to suck it dry .. no mattter how fair you schedule 1140516936 M * eyck when one of guests sucks it almost-dry, you just block /dev/random for him - from his perspective it looks like pool is dry 1140516936 M * cehteh well the very best and most easiest thing is probably to add some good fast entropy sources 1140516936 M * cehteh and increase the entropy pool 1140516936 M * eyck but others still can use it 1140516936 M * cehteh yes that what i meant by limiting 1140516936 M * eyck ok 1140516936 M * cehteh i would define that in priority and bytes/second 1140516974 M * cehteh means my ssh login has high priority but not high bandwidth ... so i can always use it but that guest cant be used to suck the pool dry 1140517019 M * cehteh while ssl webservers have modereate pri and high bandwidth .. get as much entropy as possible but only if it is available 1140517020 M * cehteh and so on 1140517060 M * eyck hmm, those with high bandwidth requirements should be using /dev/urandom anyway... 1140517072 M * cehteh well .. as i saied .. before doing that i would try to get hardware entropy generators running as some new processors nad chipsets have that on board .. 1140517089 M * cehteh and/or install an audioentropyd and such things 1140517104 M * eyck you can still suck those dry 1140517106 M * SiD3WiNDR audioentropyd ? 1140517116 M * SiD3WiNDR what does that do, create entropy from the mic input? : 1140517117 M * SiD3WiNDR :) 1140517121 M * eyck SiD3WiNDR: yeah, 1140517121 M * cehteh yes 1140517133 M * ebiederm Part of using /dev/random is the knowledge that it is better to suffer from a DOS then to have data that is not truly random. 1140517143 M * cehteh requires a really cheap badass mircophone 1140517149 M * eyck SiD3WiNDR: in normal setup it results in 50Hz 'randomness' ;) 1140517152 J * tudenbart ~willi@xdsl-213-196-241-143.netcologne.de 1140517166 M * cehteh i agree with ebiederm ... 1140517183 M * Wonka cehteh: a diode would be better than a microphone, i think 1140517213 M * cehteh Wonka: whatever .. resistor .. anything which is noisy schould work 1140517216 M * SiD3WiNDR cool 1140517231 A * Wonka wants hardware RNGs in chipsets 1140517253 M * cehteh and the audioentropyd does some filtering/analyzing, not just cat /dev/pcm >/dev/random 1140517258 M * Wonka my ThinkPad's TPM has a RNG, but it's quite slow 1140517264 M * cehteh Wonka: most modern chipsets have that 1140517278 M * cehteh all recent intel chipsets for sure 1140517279 M * Wonka not the intel 8x0 here... 1140517291 M * Wonka at least, the linux drivers can't use it, if it has 1140517292 M * cehteh yes 1140517294 M * eyck I've got intel HW RNG in few servers... 1140517299 M * cehteh but no linux driver 1140517304 M * ebiederm Be very careful with hardware RNGs. If they won't give the schematics it is hard to see how to trust it. 1140517307 M * eyck they all feed '0x000x000x00..' stream 1140517338 M * cehteh ebiederm: thats why i like the audio thing .. its opensource and the technology is easy to understand 1140517362 M * cehteh recently i looked at that page, the creator has a videoentropyd now too 1140517379 M * Wonka i used some randomness analysis software to check it 1140517392 M * Wonka /dev/urandom is as random as the TPM's RNG 1140517398 M * cehteh but i think its somewhat hard to justify that your serverrack needs a webcam for each server :) 1140517415 M * Wonka sometimes better, sometimes worse. not much difference. 1140517433 M * cehteh urandom is pretty good for most applications 1140517488 M * cehteh even security related .. its almost impossible to exploit it with a guessable sequnece 1140517537 M * eyck Wonka: as far as I heard, randomness analysis software usually mark pseudo-random streams as more random then true-random streams 1140517592 Q * dothebart Ping timeout: 480 seconds 1140517609 M * cehteh you heared .. pi is less random than scientists thought ... 1140517618 M * cehteh dont use pi as random source :) 1140517645 M * eyck how about e? 1140517657 M * cehteh dunno 1140517671 M * eyck 'e - more random then intel hw rng' ;) 1140517701 M * Wonka eyck: as i said - they were nearly equally random 1140517712 M * cehteh mhm mknod /dev/random c 1 3 1140517714 M * Wonka "ent", it's kalled 1140517721 M * Wonka http://www.fourmilab.ch/random/ 1140517724 M * Wonka called, even 1140517739 M * cehteh i would guess that most apps/people wont tell the difference :) 1140517745 M * eyck well, /dev/urandom is quite often re-seeded from /dev/random, so it should be fairly random 1140517776 M * eyck but AFAIK normal pseudorandom sequences are usualy considered more random then true-random stuff. 1140517795 M * eyck /dev/random is not truly random, but sufficiently so 1140519071 N * Bertl_zZ Bertl 1140519078 M * Bertl morning folks! 1140519125 M * ebiederm Morning. 1140519203 M * Bertl ebiederm: hey, still up or already? 1140519240 M * ebiederm Good question. I kind of napped. 1140519258 M * ebiederm Not certain what is going on but since I can sleep I figured I might as well try to get something done. 1140519345 M * eyck napping rocks 1140519352 M * Bertl s/can/can't/ 1140519362 M * ebiederm Yep. 1140519367 M * ebiederm I can't spell either! 1140519376 M * Bertl well, so focusing on networking? 1140519399 M * Bertl (after Kirill want to look at that one?) 1140519481 A * Bertl .o( everybody and his dog has a blog - so does ovz now :) 1140519508 J * mnmr ~mnmr@mail.mertner.com 1140519542 M * SiD3WiNDR so, where's the linux-vserver blog! 1140519555 M * SiD3WiNDR "today I got up at 11:51. way early!" 1140519555 M * SiD3WiNDR ;) 1140519571 M * matti SiD3WiNDR: On my HDD. 1140519581 A * matti logs everything. 1140519587 M * SiD3WiNDR that's log, not blog :p 1140519598 M * SiD3WiNDR blog is when I can reach your hdd via http ;) 1140519601 M * matti Oh. 1140519607 M * Bertl welcome mnmr! 1140519609 M * matti Right ;-p 1140519610 A * SiD3WiNDR also logs everything 1140519612 M * matti Bertl: :* 1140519617 M * eyck hmm, so 'b' stands for 'http' ? 1140519640 Q * DuckMaster Ping timeout: 480 seconds 1140519640 Q * Duckx Ping timeout: 480 seconds 1140519642 M * eyck what's with the kisses? Bartl and matti are gay couple? 1140519645 M * ebiederm ovz has a blog? 1140519707 M * matti eyck: No, no. 1140519731 M * mnmr Hi all :) .. I'm currently on 2.6.15-vs2.1.0.4.. what's the current recommended upgrade path if I am to stick with the 2.1 line? 1140519731 M * eyck you're french then? 1140519742 M * matti eyck: No, from Poland as ya. 1140519811 M * ebiederm Right now I am rebasing my pspace work on my cleanup of /proc so I can be certain I did not miss something. 1140519813 M * matti eyck: This is just "yet another strange matti's behaviour" - too much IRC... And I need to try go outside firewall ;] 1140519814 M * Bertl mnmr: http://vserver.13thfloor.at/Experimental/patch-2.6.16-rc4-vs2.1.1-rc7.diff 1140519823 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.15.4-vs2.1.1-rc7.diff 1140519825 M * eyck so.. you want to be a gay couple, but he doesn't like you? 1140519833 M * matti eyck: Hehehe. 1140519837 M * eyck outside firewall - bad. 1140519840 M * eyck inside - good. 1140519844 M * matti eyck: Indeed. 1140519846 M * mnmr bertl: thanks, will try that one! 1140519878 M * Bertl mnmr: you're welcome! feel free to hang around! 1140519880 J * brc bruce@20151181056.user.veloxzone.com.br 1140519897 M * matti Bertl: I promise - I'll not kiss ya anymore ;] 1140519900 M * brc Bertl, alive ? 1140519912 M * matti eyck: Ya may not be confused anymore. 1140519913 M * matti ;] 1140519925 M * eyck I'm always confused 1140519934 M * mnmr bertl: will do :) 1140519941 M * eyck reality is too complicated...to many variables... 1140519967 M * matti eyck: Indeed. And day is too short - 24 h?? Who invented that??? I wish 48 h. 1140519967 M * Bertl brc: yup :) 1140519967 M * matti ;] 1140519971 M * brc Trying to use vdlimit on a partition that is not tagxid would maek all owner/group losts ? 1140519987 M * brc i forgot to mount -o tagxid 1140520019 M * Bertl brc: no, but depending on the tagging method, you will have 'funny' uid/gid numbers 1140520048 M * brc hm! All my owner/groups were lost 1140520052 M * brc after monting without tagxid 1140520057 M * matti Bertl: I finaly upgrade my desktop ;] 1140520069 M * matti Bertl: Pentium II 300 -> AMD Athlon 700 (Socket A). 1140520070 M * brc now i have 1140520071 M * brc -rwxr-xr-x 1 3204448256 2533359616 51724 Oct 2 13:34 cpio 1140520079 M * brc -rwxr-xr-x 1 3204448256 2533359616 4320 Sep 18 04:04 dmesg 1140520095 M * Bertl brc: yup looks good! 1140520104 M * Bertl matti: excellent! 1140520119 M * brc not good :( 1140520131 M * Bertl brc: just unmount, and mount with tagxid again 1140520143 M * brc i did that, but the groups were not back :( 1140520148 M * matti Bertl: :) 1140520150 M * brc any other trick ? 1140520153 M * brc i could use ? 1140520153 M * Bertl (means you are using uid24/gid24 tagging) 1140520170 M * Bertl brc: sure you did unmount and mount with tagxid? 1140520176 M * brc gonna do it agani 1140520188 M * Bertl (check in /proc/mounts) 1140520207 M * brc stopping vservers..... 1140520312 M * brc [root@server /]# umount /fs3 1140520318 M * brc [root@server /]# /bin/mount /dev/hdc1 /fs3 -o tagxid 1140520326 M * brc [root@server /]# mount | grep fs3 1140520330 M * brc /dev/hdc1 on /fs3 type ext3 (rw,tagxid) 1140520371 M * brc Weird, i think it solved the prboelm 1140520372 M * brc HEHE 1140520372 M * brc sec 1140520523 J * Duckx ~duckx@195.75.27.158 1140520534 J * DuckMaster ~duckx@195.75.27.158 1140520539 M * Bertl welcome DuckMaster! 1140520567 M * brc SolveD! NOw it is working! I love you bertl! :) 1140520646 M * Bertl well, you know the Donations Page, yes? :) 1140520677 M * brc sure, as soon as i start making money i will donate. at this time i am still negative . hehe 1140520736 M * Bertl so be it ... good luck then with making money :) 1140520758 M * brc need more 3 months 1140520759 M * brc :) 1140520814 M * mnmr can I ask an unrelated question here? my system "hangs" on startup during udev initialization (but continues when i press ctrl-c).. any ideas on what might be causing this? (gentoo, amd64) 1140520979 M * Bertl mnmr: ude issues 1140520983 M * Bertl *udev even 1140521030 M * mnmr bertl: that was helpful ;) 1140521054 M * Bertl well, the thing is, ude is very young 1140521078 M * Bertl the lkml folks insisted on dropping devfs (because it was said to be unfixable) 1140521104 M * Bertl now the users have more time watching udev crunching on their disks ... 1140521152 M * mnmr urgh.. well, udev is required by gentoo too, but having a server that stops on reboots is.. "interesting". 1140521156 M * Bertl if you find a way to debug what udev is doing and/or where it is 'hanging', it's probably easy to fix it ... 1140521157 M * ebiederm I would suggest getting the lasted version of udev. 1140521186 M * mnmr I'm on 0.79-r1 1140521214 M * ebiederm udev stop on reboot?? 1140521214 M * Bertl that's always a good idea ... 1140521214 M * Bertl 0.80 here :) 1140521217 M * mnmr will try 0.84 (I can see there are newer releases available).. 1140521264 M * mnmr ebiederm: yeah; stops while doing something; ctrl-c and the boot process continues. quite weird, but better than a total stop ;) 1140521288 M * Bertl yep, did you let it stay there for some while? 1140521316 M * Bertl I once had an udev which was running for roughly 15mins before it finished 1140521327 M * SiD3WiNDR I have a server that crashes on reboot, but that's after its broken power supply probably wrecked the motherboard :) 1140521328 M * bonbons mnmr: if you did add a sleep at end of udev initscript (to give udev some more time), whould that help? 1140521346 M * mnmr minutes.. (5 or so while testing).. now the server has been moved into prod so testing it is a bit more difficult.. 1140521372 M * mnmr bonbons: will try that if a newer version doesn't fix it. 1140521412 M * mnmr bertl: 15 mins is.. defect, at best. I refuse to wait that long for hw init, even if it means patching in devfs manually :) 1140521415 M * bonbons mnmr: I sometime had my block-devices not yet created by udev when the next initscript wanted to use them (mountfs) 1140521462 M * mnmr bonbons: but then, wouldn't the boot procedure fail entirely? everything works fine once I press ctrl-c to continue the boot process.. 1140521519 M * Bertl mnmr: I agree, and usually it doesn't take that long ... 1140521523 M * bonbons no, it wont fail because you accept the failed fsschecks, and the time you took to do so udev has finally created the dev nodes :) 1140521555 M * mnmr I'll let you know in an hour or two how it went (kernel+vs-patch+udev upgrade ;) ) 1140521588 M * mnmr bonbons: hmm.. could be. maybe I can edit the udev script to include an strace, so I can see what it's doing. 1140521682 M * bonbons mnmr: one or two seconds sleep time will probably give udevd enough time too 1140521693 M * ebiederm The one time I saw this I updated udev and the problem went away. 1140521747 M * mnmr sounds promising.. I'll be back with news - thanks for your help so far! 1140522807 M * Bertl okay, off for a while .. back later 1140522812 N * Bertl Bert_oO 1140523139 Q * Roey Quit: Leaving 1140523149 J * Roey ~katz@h-69-3-4-130.mclnva23.covad.net 1140523468 J * Smutje_ ~Smutje@xdsl-87-78-85-242.netcologne.de 1140523584 Q * Smutje Ping timeout: 480 seconds 1140523584 N * Smutje_ Smutje 1140524673 J * Suwak suwak@linux.gentoo.pl 1140525748 M * matti Suwak: Dude... Ya shouldn't spy on me ;-p It's so kinky. 1140525786 M * matti Suwak: Well, either way - walcome :-) 1140525915 M * Roey hi 1140525921 M * matti Hi Roey ;] 1140525930 M * Roey hey hey 1140525936 M * matti What's up? 1140525942 M * Roey matti, do you know anything about openvpn on vserver? 1140525949 M * Roey I've been whining about it here for a month no 1140525950 M * matti No. 1140525950 M * Roey n o 1140525951 M * Roey now 1140525952 M * Roey ok 1140525976 M * matti Roey: It is some difference with vserver and common linux? 1140525986 M * matti Roey: I mean - for openvpn point of view? 1140526005 M * Roey openvpn requires the ability to open and close ifaces 1140526008 M * daniel_hozac Roey: i assume you've read the mailing list archives? 1140526011 M * Roey the capability rather 1140526012 M * matti Roey: I only use IPSec (KAME). 1140526013 M * Roey daniel_hozac: oh hey 1140526024 M * Roey daniel_hozac: every week or so 1140526029 M * Roey daniel_hozac: is there anything new? 1140526038 M * daniel_hozac i was referring to the old threads on openvpn. 1140526070 M * Roey yeah I've read those. 1140526080 M * daniel_hozac so you should know exactly what is needed. 1140526090 M * Roey not completely 1140526095 M * Roey can you point me to the threads? 1140526101 M * Roey I read some old ones from two months ago I think 1140526102 M * Roey not sure 1140526114 M * Roey the most that i know is that it is on someone's todo list 1140526144 M * daniel_hozac what is? 1140526168 M * daniel_hozac http://archives.linux-vserver.org/200505/0238.html 1140526282 M * Roey thank you 1140526412 M * Roey daniel_hozac: I've discussed this with Bertl (who contributed to that thread there) and he says it's still a WIP 1140526417 M * Roey work in progress 1140526422 M * daniel_hozac ngnet, yes. 1140526441 M * daniel_hozac but OpenVPN already works within vservers, albeit in an insecure manner. 1140526454 M * ebiederm You are talking about me again :) 1140526462 M * daniel_hozac always ;) 1140526568 M * Wonka what about openvpn's mktun stuff? 1140526577 M * Roey ebiederm: hey Eric! 1140526590 M * Roey (when is ngnet expected?) 1140526591 M * daniel_hozac as long as you give the vserver /dev/net/tun, there's no problem. 1140526746 M * ebiederm I have code that works, but it needs to be separated into clean patches (hopefully soon). 1140526773 M * ebiederm Then it needs to be tested and looked at for a while before it is stable. 1140526796 M * ebiederm The implementation is one that should not be hard to maintain once it is merged but maintaining it out of tree could be a problem. 1140526814 M * ebiederm Basically it makes CAP_NET_ADMIN safe inside of a vserver or wherever... 1140526909 M * bonbons ebiederm: finally a real namespace for the network? 1140526944 M * ebiederm Getting there... 1140526954 M * ebiederm But thats what my current implementation is. 1140526993 M * Roey ok 1140526993 M * Roey ebiederm: where can I get a list of all the defined CAPabilities that a particular kernel version offers 1140526993 M * Roey ? 1140526993 J * Doener doener@i5387DCB2.versanet.de 1140526997 M * Roey hi Doener 1140527005 M * Doener morning 1140527026 M * daniel_hozac Roey: include/linux/capability.h 1140527029 M * Roey thanks 1140527043 M * Roey doh I don't have the linux headers 1140527047 M * Roey where can I see this online? 1140527048 M * bonbons ebiederm: does it also include iptables support for the guests (so that quest can handle their local firewall)? 1140527062 M * daniel_hozac Roey: you don't have a kernel source tree? 1140527064 M * Roey nope 1140527066 M * Roey debian stock 1140527109 M * ebiederm bonbons: Yes and no. The current patch doesn't because I was lazy and doing a proof of concept but iptables support is straight forward to add. 1140527143 M * Roey daniel_hozac: oh, wait, on the system where I have vserv running, lemme see. 1140527159 P * Suwak Beam me up, Scotty! 1140527208 M * bonbons ebiederm: fine :) anyhow, I will have to check what has changed for IPTables since the few last kernel releases, there were ots of changes in .14, .15 and upcoming .16 1140527218 M * Wonka ack ack ack 1140527233 M * Roey daniel_hozac: ok, found it! thanks 1140527259 M * Doener ah, daemonize patch made it into linus' tree :) 1140527269 M * ebiederm Yeah! 1140527273 M * daniel_hozac great! 1140527286 M * Wonka Roey: apt-get install linux-tree-2.6.15 or kernel-tree-2.6.8 or whatever ;) 1140527308 M * ebiederm Now we just need to update everything to use kthread instead of kernel_thread so we don't need to patch daemonize... 1140527324 M * Roey daniel_hozac: how long have CAPs existed in the Linux kernel? 1140527340 M * Wonka hm, what is this "daemonize patch"? 1140527343 M * Roey Doener: what's the 1140527344 M * Roey doh 1140527348 M * Roey Wonka: heh 1140527359 M * Doener http://lkml.org/lkml/2006/2/17/323 1140527364 M * Wonka i am not very into vserver or kernel development 1140527374 M * daniel_hozac Roey: 2.2? 2.0? i don't know. since way before i started using Linux. 1140527389 M * Roey Wonka: how did I know you were from Germany, heh :) where they pronounce Willy Wonka as Villy Vonka. That would crack up Americans, heh :) 1140527393 M * Roey daniel_hozac: really??? 1140527404 M * Roey daniel_hozac: for some reason it seems like a new thing to me 1140527404 M * Roey oh 1140527430 M * Roey daniel_hozac: maybe because there was thsi recent paper about getting Linux to be a Capabilities-based system? 1140527450 M * Doener Wonka, Roey: the problem was that mounting an ext3 fs in a separate namespace causes an unremovable mount if all userspace processes exit before you unmount the fs 1140527468 M * Wonka oh, not good 1140527485 M * Roey don't you want all the userspace processes to exit before the fs gets umounted? 1140527492 M * Roey for example, 1140527504 M * Roey I wouldn't want to umount in the middle of writing a file 1140527506 M * Doener usually the namespace would go away and thus causing an automagical unmount, but the kjournald for the mount was living in that namespace and kept it alive 1140527543 M * Doener Roey: well, if your last process takes care of unmounting, there's no problem, but you shouldn't have to do that 1140527563 M * Wonka i'd have thought all filesystems but / would be unmounted, / remounted ro, and then just shut off... 1140527587 M * daniel_hozac that's for host reboot. 1140527603 M * Doener Wonka: http://linux-vserver.org/Namespaces 1140527610 M * Wonka as i said, regarding vserver, i'm more of a user... 1140527661 M * Wonka i can resolve some patching difficulties, but not much more 1140527937 M * Bert_oO back now ... 1140527941 N * Bert_oO Bertl 1140528039 M * Doener hey Bertl 1140528122 M * Bertl Wonka: just for the record, the mainline issue is fixed in the latest linux-vserver patches 1140528131 M * Bertl hey Doener! 1140529054 M * waldi Bertl: what is CLONE_KTHREAD? 1140529130 M * Bertl a marker to tell kernel threads from userspace tasks 1140529148 M * waldi something is wrong, powerpc32 fails to build with missing this name 1140529161 M * waldi arch/powerpc/kernel/misc_64.S: Assembler messages: 1140529161 M * waldi arch/powerpc/kernel/misc_64.S:687: Error: undefined symbol `CLONE_KTHREAD' in operation 1140529168 M * waldi powerpc64 also 1140529217 M * Bertl ah, okay, probably changes with the restructuring ... 1140529243 M * Bertl as I have no ppc64, I do not test this too often ... and obviously plm didn't pick that up 1140529260 M * Bertl let me check it right now ... 1140529264 M * waldi thanks 1140529282 M * waldi my test machine is available if you want 1140529333 M * Bertl well, the cross compiling should do fine, but I'd appreciate a test report on the ML once it is working 1140529374 M * ebiederm Bertl: What does CLONE_KTHREAD do and if all kernel threads started as children of the keventd would we need it? 1140529376 M * waldi i'm just in the state of finaly merging that into the debian package 1140529447 M * Bertl ebiederm: IIRC, I already stated that it is not strictly required at all, as long as ther _is_ some identification of kernel threads (probably mm=init_mm is enough) 1140529485 M * ebiederm Right. 1140529496 M * ebiederm Just double checking to make certain I didn't miss something. 1140529516 M * Bertl that's fine, it's just soo much easier right now to do it this way :) 1140529520 Q * mkhl Ping timeout: 480 seconds 1140529582 M * Bertl waldi: what is your $ARCH you are using? powerpc or ppc64? 1140529587 M * ebiederm And a kernel thread identifier is trivial if all kernel threads are children of other kernel threads :) 1140529600 Q * phreak`` Read error: Connection reset by peer 1140529607 M * Bertl ebiederm: yup, once that happens, I'll remove it immediately 1140529664 M * waldi Bertl: powerpc 1140529673 M * waldi Bertl: ppc64 is deprecated since 2.6.15 1140529677 M * waldi err, removed 1140529705 M * waldi ppc will go away with .16 but is already not really used for most subarches 1140529723 M * Bertl yup, just saw it, how to get the 'proper' arch identifier for cross building? 1140529737 M * Bertl export ARCH=powerpc CROSS_COMPILE=ppc64-linux 1140529738 M * waldi power64-ibm-linux-gnu 1140529745 Q * meebey Ping timeout: 480 seconds 1140529746 M * Bertl make defconfig 1140529755 M * Bertl Can't find default configuration "arch/powerpc/configs/x86_64_defconfig" 1140529766 M * Bertl so it seems broken to me, no? 1140529777 M * waldi defconfig is broken in such cases, yes 1140529787 M * Bertl well, it was not broken before 1140529841 M * Bertl I wonder what gets expanded there ... 1140529873 M * ebiederm Looks like uname -m 1140529883 M * waldi hmm 1140529888 M * Bertl well, that would be definitely broken then 1140529895 M * waldi KBUILD_DEFCONFIG := $(shell uname -m)_defconfig 1140529902 M * waldi well, this is really broken 1140529946 M * ebiederm Especially given how much of ppc is used for embedded work and thus likely to be cross compiled. 1140529974 M * Bertl and the ppc64.defconfig is brooken too 1140529981 M * waldi hihi 1140530008 M * Bertl okay, you got a working .config for me? :) 1140530021 M * waldi no problem 1140530059 M * waldi http://137.250.31.225/linux/config 1140530074 M * Bertl huh? -maltivec 1140530084 M * Bertl is this a joke? 1140530087 M * waldi no 1140530118 M * Bertl but sure looks like one .. what does altivec do in the kernel? 1140530139 M * waldi raid6 uses altivec 1140530180 M * Bertl so we need it for every file which is compiled? 1140530202 M * waldi -maltivec only enabled access to altivec registers 1140530243 M * waldi and instructions 1140530245 M * Bertl but it seems that gcc-3.3.6 needs a special compile option to support that 1140530274 M * waldi they are not generated by gcc without some other options 1140530310 M * waldi at least in my kernel, it is -Wa,-maltivec, which is an option for the assembler 1140530333 M * Bertl you are right, let me rephrase that: 1140530370 M * Bertl binutils 2.16.91.0.5 seem to need a 'special' configure option to support that on ppc64 1140530383 M * waldi hmm, lets look 1140530402 A * waldi can't remember of any special option 1140530430 M * Bertl s/on/for/ 1140530430 M * Bertl or, alternatively, the make stuff (for ppc64) is more broken than assumed 1140530438 M * Bertl ah, I remember now 1140530453 M * Bertl ppc64 needs ppc32 tools too, what was the magic env option? 1140530502 M * Bertl CROSS32_COMPILE 1140530505 M * waldi --enable-targets= 1140530525 M * waldi no, this was binutils 1140530533 M * Bertl works now 1140530544 M * Bertl export ARCH=powerpc CROSS_COMPILE=ppc64-linux- CROSS32_COMPILE=ppc-linux- 1140530551 M * Bertl (this is the required magic) 1140530552 M * waldi maybe your assembler lacks support for ppc43 1140530556 M * waldi s/43/32/ 1140530562 M * waldi i only use biarch toolchains 1140530563 M * Bertl btw, I still have no idea why ppc64 requires 32bit tools 1140530577 M * waldi vdso 1140530592 M * Bertl IMHO the ppc64 gcc/binutils should understand -m32 or so, no? 1140530600 M * waldi only if enabled 1140530644 M * Bertl well, you probably would enable that no? I mean it's better than having two toolchains, right? 1140530656 M * waldi for binutils you need to specify --enable-targets=, gcc should always do it for ppc64 1140530858 M * Bertl are you going to submit a fix for the uname -m issue? 1140530899 M * waldi i have to find a solution first 1140530919 M * waldi it works if you work on powerpc, but there is no sensible default otherwise 1140530970 Q * romke Remote host closed the connection 1140530973 M * Bertl what about simply using ARCH or something like that when specified? 1140530988 J * romke ~romke@acrux.romke.net 1140531028 M * waldi ARCH is powerpc 1140531083 M * Bertl so an updated powerpc.defconfig would be nice, no? 1140531087 M * waldi hmm 1140531090 M * waldi seems so 1140531454 M * Bertl http://vserver.13thfloor.at/Experimental/delta-powerpc-fix01.diff 1140531461 M * Bertl (trivial fix, but compile tested :) 1140531476 M * waldi not include ? 1140531495 M * Bertl sched.h does not work with most .S files (unfortunately) 1140531502 M * waldi ah 1140531510 M * Bertl future restructuring might improve that 1140531519 M * waldi i wonder where the CLONE_VM is comming from 1140531544 M * Bertl good point, probably from a magic script ... checking now 1140531551 M * waldi ah, asm-offsets.h 1140531556 M * waldi s/h/c/ 1140531680 M * Bertl okay, expect a better fix shortly 1140531688 M * waldi okay 1140531733 J * trasher daniel@derichs.info 1140531795 M * trasher hi there - i've got some little problems. i started using linux-vserver a few days ago. now i've set up a vserver, when entering it i get "mesg: /dev/pts/0: Operation not permitted" 1140531798 Q * matt1 Read error: Operation timed out 1140531808 M * trasher it works.. but i am wondering about this error 1140531814 M * daniel_hozac trasher: use ssh to enter the guest. 1140531845 M * daniel_hozac or use Hollow's vlogin. 1140531865 M * trasher ok, but there's the next problem: ifconfig doesnt show up an ip.. do i have to set up the ip on the host? 1140531883 M * daniel_hozac use ip a ls. 1140531890 M * daniel_hozac ifconfig is old and broken. 1140531937 M * Bertl trasher: nevertheless, you can configure your guest to use the old-fashioned aliases, which will be seen by ifconfig 1140531969 M * trasher how do i do that? 1140531989 M * Bertl just add a file called 'name' to the interfaces/?/ dir 1140531991 M * DuckMaster Hy Bertl :) 1140532002 M * Bertl trasher: which contains, e.g. 'karli' 1140532015 M * Bertl the interface will then be created as eth0:karli 1140532020 M * trasher ok, i'll try. thanks 1140532032 M * trasher sorry for bothering you 1140532037 M * Bertl trasher: make sure to stop the guest first, then change, then start again 1140532051 M * Bertl trasher: no problem, feel free to hang around! 1140532055 M * trasher ;) 1140532145 M * trasher hm.. do u know which deb-package contains "ip"? 1140532162 M * trasher cant find it 1140532165 M * waldi iproute 1140532176 M * trasher oks 1140532179 M * Bertl waldi: okay reload 1140532199 M * waldi thats what I expect 1140532226 M * Bertl (also compile tested) 1140532270 M * Roey Bertl! 1140532271 M * Roey hi! 1140532292 M * trasher i get on the host when trying to ssh the vserver.. yes, i've set "ListenAddress" in sshd_config 1140532440 M * Bertl trasher: I assume you did not restart the sshd yet 1140532446 M * Bertl (on the host) 1140532467 M * Bertl (well, I hope you did set the ListenAddress on the host :) 1140532473 M * Bertl hey Roey! 1140532475 M * trasher doh.. you're right.. i forgot to set ListenAddress on the host 1140532494 M * Bertl trasher: you do not need the ListenAddress inside the guest 1140532502 M * trasher i see 1140532505 M * Bertl the guests are restricted to their subset of IPs 1140532518 M * trasher ok, very good 1140532523 M * trasher thanks very much ;) 1140532539 M * Bertl you're welcome! 1140532543 M * Bertl afk, brb 1140532947 J * mnmr_ ~mnmr@mail.mertner.com 1140532965 M * Bertl back now 1140532978 M * trasher is it possible to change the information being showed by /proc/cpuinfo? 1140533004 M * Bertl to what? 1140533086 M * trasher so.. i've had a UML vserver and i remember that it was not possible to show up information about the host system 1140533108 M * Bertl well, you can hide /proc/cpuinfo easily 1140533109 M * oliwel Hollow: ping ? 1140533112 M * trasher yeah.. UML is a different thing.. but that's the reason for asking this question 1140533227 M * waldi what do you want to hide? 1140533236 Q * mnmr Ping timeout: 480 seconds 1140533271 M * trasher the MHz 1140533273 M * trasher primary 1140533353 M * Bertl well, you can easily remove that line from the kernel 1140533403 M * waldi the user can always use a loop to estimate this 1140533480 M * Bertl arch/i386/kernel/cpu/proc.c 1140533505 M * trasher ok, so i've got to change this on the host side 1140533523 M * Bertl well, you can do a check there which only hides it for guests 1140533540 M * Bertl but as the guest has _no_ kernel running ... 1140533641 M * bonbons Bertl: this could eventually be "adjusted" if hard CPU limits reduce the available CPU time for a guest, same thing could be applied to memory information 1140533707 M * bonbons would just make calculation of usage values to intensive (to remain consistent, total in use > total available would not sound good) 1140533767 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net 1140533841 Q * mnmr_ Read error: Connection reset by peer 1140533910 M * Hollow oliwel: pong 1140533987 M * Bertl bonbons: just send me a function which calculates the MHz from the scheduler parameters 1140534051 M * Bertl i.e. f(interval,rate,interval2,rate2,min,max) -> MHz 1140534057 M * Bertl well, to be fair: 1140534058 M * ebiederm What is the problem with displaying Mhz to the user? 1140534058 M * Bertl i.e. f(interval,rate,interval2,rate2,min,max,sysmhz) -> MHz 1140534094 M * trasher i just dont want it 1140534161 M * ebiederm I guess not displaying Mhz could make sense. But calculating a fake Mhz could make things very confusing when debugging a system. 1140534162 M * bonbons Bertl: nerver looked inside the kernel in that corner... Ok, will think of such a function (once I know what interval/rate versus interval2/rate2 is, I guess min/max is for soft limits) 1140534173 J * mnmr ~mnmr@mail.mertner.com 1140534179 M * mnmr :) harmony ~ # /etc/init.d/vservers start 1140534179 M * mnmr * Unhiding /proc entries ... [ ok ] 1140534179 M * mnmr * Starting vservers of type 'default' ... 1140534179 M * mnmr error: Selected command not supported 1140534179 M * mnmr error: Selected command not supported 1140534181 M * mnmr make: *** [.angel.stamp] Error 1 1140534189 M * mnmr all my vservers are down! help! :) 1140534213 J * shuri ~boafroid@64.235.209.226 1140534246 M * mnmr what does it mean: "Selected command not supported".. I'm using 2.6.16-rc4 vs2.1.1-rc7 vserver-utils 1.0.3 1140534294 M * bonbons ebiederm: ideally should be a choice, full, restricted, none :), but it's more a nice to have thing 1140534333 M * mnmr HELP! 1140534338 M * mnmr anyone? 1140534342 M * Roey Bertl: hi, so I was wondering if you had anything new about openvpn on vserve. I think I annoy you with this question every week, but so far I have only seen some old threads on the mailing list about this to which you have contributed 1140534360 M * mnmr harmony ~ # vserver angel start 1140534360 M * mnmr error: Selected command not supported 1140534387 M * Bertl mnmr: let's start with testme.sh 1140534394 M * bonbons mnmr: there are a few issues with vserver-utils-1.0.3 ... did you compile it with dietlibc? 1140534408 M * mnmr nope, should i? 1140534415 M * ebiederm bonbons: I guess in general I just don't like virtualization. 1140534416 M * mnmr 1.0.2 has same result. 1140534420 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh-0.15 1140534425 M * mnmr where's testme.sh? 1140534429 M * mnmr ah :) 1140534446 M * Bertl run it on the host as root, upload the output to some pastebin service (e.g. pastebin.com) 1140534459 M * Bertl (or pastebin.ca if com is not working) 1140534467 M * mnmr Linux-VServer Test [V0.15] Copyright (C) 2003-2006 H.Poetzl 1140534467 M * mnmr chcontext failed! 1140534467 M * mnmr Try '/usr/sbin/vcontext -h' for more information 1140534467 M * mnmr invalid option `nid'. 1140534467 M * mnmr Try 'chbind --help" for more information. 1140534467 M * mnmr chbind failed! 1140534469 M * mnmr Linux 2.6.16-rc4-vs2.1.1-rc7 #1 Tue Feb 21 15:11:33 CET 2006 x86_64 1140534469 M * mnmr Ea 0.30.209 236/glibc (DSa) 1140534471 M * mnmr VCI: 0002:0001 236 030001f6 (TbLgnP) 1140534471 M * mnmr --- 1140534526 M * Hollow oliwel: s/1.20/1.12/ 1140534547 M * Bertl mnmr: well, you need newer tools, get 0.30.210, compile it with dietlibc and it should work 1140534575 M * mnmr util-vserver instead of vserver-utils? 1140534675 M * bonbons mnmr: I have reasonably working vserver-utils, can provide a diff against 1.0.3 if you want, otherwise you are probably better of with util-vserver by now 1140534727 M * bonbons and testme.sh is probably depending on util-vserver... 1140534730 M * Hollow hm, i should update vserver-utils trunk 1140534735 M * Hollow bonbons: right 1140534766 M * mnmr that's probably where I messed up.. installed vserver-utils, thus breaking my util-vserver.. 1140534773 M * mnmr compiling :) 1140534816 M * Hollow i should add a switch to configure... --enable-util-vserver-breakage 1140534817 M * Hollow :P 1140534846 M * bonbons Hollow: how many changes do you have pending to trunk? A bug-fix to 1.0.3 might but good as well (especially related to vattr, vmount and vexec if I remember well) 1140534873 M * mnmr woohoo.. it's working again. phew! 1140534878 A * waldi needs a pam_vserver 1140534882 M * Hollow hm, i started massive work on 1.1 already... and many things are already in the trunk 1140534902 M * mnmr just spent 4 days setting up the new server, so was a bit nervous there for a moment ;) .. whom should I send the book to? ;) 1140534924 M * Hollow which book? 1140534930 M * mnmr waldi: try openldap :) 1140534951 M * mnmr hollow: a wishlist book.. u tell me ;) 1140534952 M * bonbons last time I checked (2-3 days ago) I didn't really get an overview 1140534956 M * waldi mnmr: no, only for session 1140535011 M * eyck pam_vserver? 1140535029 M * eyck what book? 1140535031 M * Hollow mnmr: i guess someone else has to take the credit .. ;) i didn't help you much ;) 1140535053 M * waldi eyck: a variant of pam_chroot 1140535053 M * mnmr bertl: testme.sh reports lots of successed too, now :) 1140535076 M * mnmr hollow: I'll have a look at bertl's :) 1140535112 M * eyck bertl wrote a book? 1140535121 M * eyck it's all so confusing.. 1140535140 M * mnmr eyck: lol.. donationware, me buying bertl one from amazon.. 1140535164 M * eyck oh, ok 1140535169 M * Hollow bonbons: i'll commit my stuff in a minute, so you can take a look 1140535213 M * bonbons ok, will look at it once I'm done refactoring my SQL monsters 1140535565 M * oliwel Hollow: cheers - so after some testing I assume that baselayout 1.20 is really screwed 1140535739 M * Hollow oliwel: but it's still 1.12 1140535785 M * Hollow and i know that start-stop-daemon of 1.12 is screwed, but it is in ~arch, so don't expect it to work 1140535836 M * Hollow and i guess we won't start debugging of 1.12 until the normal one is released 1140535846 M * Hollow it just changes too much 1140535857 M * Bertl okay, off now, back in the evening ... 1140535869 N * Bertl Bertl_oO 1140535911 M * oliwel Hollow: 1.12...äh sory yes :) 1140535926 M * oliwel You know its screwed - ok that explains it all ;) 1140535934 M * Hollow bonbons: i commited libvserver and vserver-utils 1140535936 M * oliwel Should really stop to use 86 ,) 1140535960 M * bonbons ok, updating... 1140535995 M * Hollow bonbons: i also split some common lib functions of libvc and some of libowfat to http://dev.croup.de/repos/lucid/trunk/ 1140536037 M * bonbons ok, so that one is new dep (to be fetched as well) 1140536045 M * Hollow it replaces libowfat 1140536120 M * Hollow yeah, we have three parts.. libvserver for the syscall, l(ib)ucid for the common things (i'll probably use them elsewhere, so i splitted them), and vserver-utils 1140536323 M * bonbons ok, and libvserver/vserver-utils have configure-options for place to look for the libs (not seen)? or do I need to get it through with LDFLAGS/CFLAGS? 1140536367 M * Hollow well, they should be in your library path 1140536376 M * Hollow vserver-utls looks for both 1140536444 M * bonbons I mean to get htem finding the right version (as long as I don't install them system-wide) 1140536460 J * mnmr_ ~mnmr@mail.mertner.com 1140536467 M * Hollow hm, they are static libs only.. 1140536487 M * Hollow probably we need to include a version in the headers 1140536556 M * bonbons that's a useful feature to detect version-mismatches in a clean manner 1140536699 M * Hollow also, in src/tools i'm not sure if the names are good, and if they should be installed in pkglibdir or in sbindir 1140536708 Q * oliwel Quit: Chatzilla 0.9.69.1 [Firefox 1.5.0.1/2006021510] 1140536834 Q * mnmr_ Quit: Trillian (http://www.ceruleanstudios.com 1140536864 M * bonbons names are 'dx', 'nx', 'ns', 'ix', 'vr', 'vx'? 1140536905 Q * mnmr Ping timeout: 480 seconds 1140536999 M * bonbons as long as there are no clashes with other well-known utils it should not hurt (though a common prefix might help lvs_, lvs-, vs_, vs-) 1140537108 M * Hollow i looked in the debian package database, and found no clashes 1140537115 Q * DuckMaster Ping timeout: 480 seconds 1140537115 Q * Duckx Ping timeout: 480 seconds 1140537203 M * bonbons fine, so chances of a clash are really small :) 1140537219 M * derjohn any issues with: 2.6.15-amd64-vs2.1.0.5.1 #1 Sun Feb 5 03:44:52 CET 2006 x86_64 GNU/Linux. I think I just lost a directory within a guest .. dunno why 1140537245 M * derjohn ah, ye, its XFS .... 1140537267 J * mnmr ~mnmr@mail.mertner.com 1140537376 M * daniel_hozac derjohn: maybe you removed it :) 1140537402 J * DuckMaster ~duckx@195.75.27.158 1140537407 M * daniel_hozac derjohn: can you see it from the host? 1140537412 J * Duckx ~duckx@195.75.27.158 1140537460 M * derjohn daniel_hozac, well, hm .. i recreated the directory within the guest and then looked from the host .. i should have done vice-versa ... 1140537476 A * derjohn slaps himself 1140537480 M * daniel_hozac well, if you were able to recreate it, i guess it was gone already. 1140537508 M * derjohn I'll investigate further... 1140537533 M * derjohn vxW: xid=127 did lookup hidden ffff81003ef85128[#0,4026532354] ?/proc/mdstat? 1140537546 M * derjohn nothing strange? 1140537716 M * derjohn does th host logs all ocurrences of lookups to hidden proc entities? 1140537725 M * daniel_hozac it should. 1140538290 P * mnmr 1140538418 Q * shedi Quit: Leaving 1140538907 J * stefani ~stefani@superquan.apl.washington.edu 1140539239 J * Collide ~Usuario@host110.200-45-180.telecom.net.ar 1140539241 P * Collide 1140539246 Q * shuri Quit: Quitte 1140539535 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com 1140540373 J * joebullhead ~joebullhe@209.149.59.202 1140541837 J * gerrit ~gerrit@129.33.1.37 1140542741 J * Viper0482 ~Viper0482@p54974FEE.dip.t-dialin.net 1140544056 Q * prae Quit: Execute Order 69 ! 1140544067 M * joebullhead Anybody got vserver and munin hints? Anytime I enable munin on host or guest the load goes way up. Even just host munin checking only munin-node on the host. Otherwise the server is lightly loaded. 1140544121 M * joebullhead Started out with a dedicated munin and nagios guest. Since then have been trying to run down the load issue. 1140544186 M * daniel_hozac what is causing the load? (what does strace say about the running process(es)?) 1140544198 M * joebullhead Load goes up during the munin cron job with the updates 1140544230 M * joebullhead So they are not long lived processes. Just during the host polling and updates. 1140544246 M * daniel_hozac and munin does not cause said spikes on a regular Linux box? 1140544267 M * joebullhead nope. I'm moving from a uml setup that doesn't have the issue either. 1140544365 M * daniel_hozac with the exact same configuration for munin? 1140544442 M * joebullhead pretty darn close since it is replacing the original. 1140544486 Q * mire Quit: Leaving 1140544571 M * daniel_hozac so if you stop all vservers etc. and run just the host, the host munin will cause the spikes, but this does not happen if you boot a non-vserver kernel? 1140544586 M * joebullhead The reports and cron jobs ( the main munin program) is on a completely different machine/OS etc. From a debian uml on a p4/2.4 to a vserver ( or now host) on a dual opteron ubuntu-server. 1140544701 M * joebullhead Couldn't do that till this morning as the vservers are in production. Have another server setting up now that is a host kernel but no vservers defined or started. But only have the node-server installed so far. Installing a test munin now. Only the node polled from the other machine didn't show any issues. 1140544743 M * joebullhead I will be able to test a non-vserver kernel if this current test shows issues. 1140544757 J * the_hydra ~a_mulyadi@61.94.222.239 1140544798 M * daniel_hozac are you polling several guests at the same time? 1140544808 M * joebullhead Was curious if anyone had seen this since I had seen a discussion that munin/rrd didn't really give good info for vserver guest instances ( load, bandwidth, etc) 1140544853 M * daniel_hozac load should be accurate as long as you have virt_load. 1140544860 M * daniel_hozac bandwidth i assume won't be. 1140544969 J * mire ~mire@80-166-222-85.COOL.ADSL.VLine.verat.net 1140545673 M * derjohn daniel_hozac, FYI you bind patch did apply to 9.2.4 cleanly 1140545678 M * joebullhead virt_load? I'm ignorant there 1140547032 M * matti http://www.networkworld.com/community/?q=node/4630 1140547104 M * eyck jobs 1140547940 M * daniel_hozac joebullhead: virt_load in /etc/vservers//flags will virtualize the load averages. 1140547949 M * daniel_hozac derjohn: good. 1140547995 M * joebullhead daniel_hozac: thanks 1140548095 Q * Duckx Ping timeout: 480 seconds 1140548095 Q * DuckMaster Ping timeout: 480 seconds 1140548387 J * DuckMaster ~duckx@195.75.27.158 1140548508 J * Duckx ~duckx@195.75.27.158 1140548997 J * fwl ~fwl@83.215.237.1 1140549085 J * McWebber McWebber@68.56.250.87 1140549098 P * McWebber 1140549360 J * shuri ~boafroid@64.235.209.226 1140549502 Q * Hollow Remote host closed the connection 1140549508 J * Hollow ~hollow@home.xnull.de 1140550777 J * LiamH ~none@healy.washington.dc.us 1140551042 Q * fwl Quit: This computer has gone to sleep 1140551353 M * mugwump Does anyone know if the IPC filesystem requirements care about what the VFS is doing? 1140551672 J * alexx ~alexx@proxy.ikse.net 1140551745 M * ebiederm IPC filesystem? 1140551966 M * mugwump well, ipc is backed by shmfs 1140551996 M * ebiederm One aspect of it. 1140552056 M * ebiederm There are pieces that the VFS plays in the proper operation of tmpfs. 1140552077 M * ebiederm It shouldn't care about any of the mount logic except for finding the appropriate filesystem. 1140552115 M * mugwump I guess the question is more around, if you have two processes with seperate filesystem namespaces, can they send IPC messages to each other? 1140552174 M * ebiederm so posix shared memory yes. 1140552210 M * ebiederm posix messague queues as implemented in mqueue.c probably but I'm not that familiar with it. 1140552223 M * ebiederm SYSVIPC skips that part of the vfs. 1140552249 M * Hollow Doener: around? 1140552549 M * LiamH I'm trying to setup vserver for the first time, in Debian unstable amd64. Following instructions for instance creation http://deb.riseup.net/vserver/create-instance/, I get after issuing the vserver command "I: usage: [OPTION]... [ [