1141085112 Q * ntrs Quit: Leaving 1141085999 J * matta ~matta@71.224.125.126 1141087509 M * harry wiiiii... vserver utils compiled and installed 1141087516 M * harry now bed... tomorrow: testing!!!!!!!!! ;) 1141088401 Q * matta Ping timeout: 480 seconds 1141088405 J * matta ~matta@71.224.125.126 1141088432 J * matt1 ~matta@71.224.125.126 1141088579 J * comfrey ~comfrey@h-64-105-87-234.sttnwaho.covad.net 1141088886 Q * matta Ping timeout: 480 seconds 1141089067 J * rick ~rick@3bier.xs4all.nl 1141089123 M * rick Is it possible to use Context disk limit and Context quota for shared filesystem, under kernel 2.6? 1141089663 M * mugwump that's kind of the whole point of it 1141089668 M * mugwump :) 1141089887 M * rick i can't find documentation for context quota under 2.6 1141089916 M * mugwump sorry, I misunderstood the question 1141089930 M * rick i have seen that the new vserver-utils support context quota 1141089937 M * rick k 1141090027 M * mugwump you might need to get a 2.1.x kernel for that, reading the http://linux-vserver.org/Release+FAQ 1141090038 N * Bertl_zZ Bertl 1141090042 M * mugwump hey Bertl 1141090054 M * rick thnx, i will look for it 1141090073 M * Bertl rick: context disk limits are supported, per context quota not yet 1141090093 M * Bertl rick: mainly because nobody really wanted it 1141090100 M * rick hmm 1141090153 M * Bertl nevertheless, if you need user/group quota inside a guest, you can get that without the context quota, you just have to put the guest on a separate partition (e.g. lvm) 1141090170 M * rick ok 1141090173 M * rick or use 2.4 1141090179 M * rick ? 1141090200 M * Bertl yeah, or sponsor/support/help with 2.6 context quota development :) 1141090208 M * rick :D 1141090375 M * rick i think lvm works for me, thnx guys 1141090388 M * Bertl you're welcome! feel free to hang around :) 1141090394 M * rick :) 1141090417 M * mugwump Bertl: did you like the extra splits and descriptions I made for your bme patch? 1141090450 M * Bertl mugwump: haven't checked in detail but looked fine, except for the missing Singed-off-by: part :) 1141090467 M * mugwump Ah, you mean they're not Signed-off-by: you? 1141090485 M * Bertl no, they are not signed off by anyone (except for the first :) 1141090556 M * mugwump ok, I assumed that the From: implied Signed-off-by: 1141090600 M * Bertl ah, well, they will not be included anyway (sorry for being so pessimistic about that :) 1141090766 M * mugwump I don't think there's much left to make it compliant, just really adding that helper macro and making sure that all the places that call permission() et al use the MNT_IS_RDONLY macro appropriately 1141090834 M * Bertl well, everybody just replies 'no, that's the wrong approach ... will look into it ... soon' see HCH/Viro 1141090857 Q * comfrey Read error: Connection reset by peer 1141090878 M * Bertl mugwump: you might want to read the replies, maybe you can figure what the folks want to do ... 1141090922 M * mugwump yeah, I did after preparing that latest set, and included links to what I thought were valid concerns you hadn't already fixed in my last e-mail to the list 1141091104 M * Bertl well, IMHO folks keep missing the point ... 1141091127 M * Bertl let's have a look at permission() shall we? 1141091131 M * mugwump sure 1141091160 M * Bertl I'm just taking 2.6.16-rc4-vs2.1.1-rc9 (as it contains the BME stuff) 1141091187 M * Bertl (should be similar to your tree) 1141091207 M * mugwump yes, the only addition will be the utime/touch stuff you previously excluded for autofs 1141091237 M * Bertl yup 1141091248 M * Bertl so we have (mask & MAY_WRITE) 1141091258 M * Bertl and if that is requested, we do: 1141091267 M * Bertl if ((IS_RDONLY(inode) || (nd && MNT_IS_RDONLY(nd->mnt))) 1141091290 M * Bertl now, where should we move that to? 1141091321 M * mugwump ok, so the assertion is made that this is the incorrect place to do "is the filesystem writable" stuff 1141091336 M * mugwump that permission() et al, is not VFS, but FS 1141091337 M * Bertl okay, let's make a fs_is_readonly() 1141091353 M * mugwump mnt or fs? 1141091365 M * Bertl make it vfs_readonly() or whatever 1141091381 M * mugwump that sounds better 1141091383 M * Bertl just assume it does a check on inode and nd 1141091400 M * Bertl (you have to check for the inode too, otherwise you miss special cases) 1141091418 M * Bertl so, now lets look where we could put that 1141091431 M * Bertl obviously we could stick it into permission :) 1141091441 M * Bertl but that would be just stupid, no? 1141091497 M * Bertl so let's look where permission is called ... 1141091508 M * mugwump well, I don't quite understand why permission() is not the VFS layer 1141091526 M * Bertl because each filesystem has .permission = xy 1141091548 M * Bertl and xy usually is xy_permission, which in turn calls permission() 1141091650 M * mugwump ok, well that seems reasonable then 1141091666 M * mugwump if it's on the FS vtable ... but then, what is that argument there for? 1141091730 M * Bertl http://pastebin.com/575973 1141091737 M * Bertl here are the callers of permission() 1141091768 M * Bertl let's look at the may_create() as example 1141091810 M * Bertl it does two basic checks, then simply returns permission() 1141091834 M * Bertl so, we could split that into 1141091847 M * Bertl vfs_readonly() -> return EROFS 1141091854 M * Bertl otherwise return permission() 1141091884 M * Bertl similar goes for may_delete() 1141091958 M * Bertl file_permission() already states that access checks should be done by vfs_permission() 1141091978 M * Bertl (but it still does permission()) 1141091982 M * mugwump I don't see do_open calling permission() 1141092032 M * Bertl ipc/mqueue.c 1141092040 M * Bertl static struct file *do_open(struct dentry *dentry, int oflag) 1141092046 M * Bertl if (permission(dentry->d_inode, oflag2acc[oflag & O_ACCMODE], NULL)) { 1141092049 M * mugwump oh, not the one in fs/block_dev.c 1141092055 M * Bertl there are several of them 1141092063 M * mugwump heh, lovin' it 1141092093 M * mugwump ok, so vfs_permission could very well do with that extra check 1141092095 M * Bertl so, we could redirect file_permission() to use vfs_permission() 1141092104 M * mugwump yes, ok 1141092122 M * Bertl and fixup vfs_permission to do vfs_readonly() check 1141092140 M * Bertl let's forget the nfs cases, as they are usually bogus :) 1141092154 M * mugwump well all the per-fs changes are in the last patch in my set 1141092177 M * mugwump didn't think you could get 10 distinct patches out of this did you? :) 1141092209 M * Bertl I did break it down by hunks once, so yes, I can imagine :) 1141092247 M * Bertl vfs_rename_dir() should be not a big deal either 1141092273 Q * matt1 Read error: Operation timed out 1141092274 M * Bertl it also checks with MAY_WRITE, so we could stick in an additional vfs_readonly check there too 1141092303 M * Bertl xattr_permission() 1141092322 J * Aiken_ ~james@tooax8-088.dialup.optusnet.com.au 1141092340 M * Bertl that is currently missing and nd checks ... 1141092344 M * Bertl *any 1141092366 M * mugwump it also doesn't have anything other than an inode 1141092383 M * Bertl yeah, so requires moving up ... 1141092405 M * Bertl -· xattr_permission() 1141092405 M * Bertl ¦-» vfs_getxattr() 1141092405 M * Bertl ¦-» vfs_removexattr() 1141092405 M * Bertl '-» vfs_setxattr() 1141092418 M * mugwump what's giving you those pretty diagrams? 1141092421 M * Bertl only vfs functions, yay! 1141092432 M * Bertl a small helper .. sec 1141092524 M * Bertl http://vserver.13thfloor.at/Stuff/cshelp 1141092536 M * Bertl requires a valid cscope index in the current kernel dir 1141092549 M * Bertl you can get that with cscope -kRp3 1141092567 M * Bertl cshelp -C 2 xattr_permission 1141092574 M * Bertl gives the tree above ... 1141092615 M * Bertl it's not blazing fast but efficient :) 1141092639 Q * Aiken Ping timeout: 480 seconds 1141092681 M * mugwump cool 1141092730 M * Bertl be careful though, cscope sometimes misses declarations 1141092747 M * Bertl (which is intentional, according to the developers) 1141092870 M * Bertl mugwump: okay, let me know when you are ready to continue :) 1141092927 M * mugwump sorry, some chargable work came by 1141092933 M * mugwump I'm back 1141092940 M * Bertl k, cya 1141092959 M * Bertl or does that mean, you're back _now_? 1141092981 M * mugwump I was gone for 5 minutes there, but I'm on-line now :) 1141093003 M * Bertl okay, so shall we continue? 1141093012 M * mugwump sure 1141093034 M * Bertl okay, let's look into those vfs_* functions 1141093066 M * Bertl vfs_getxattr() has dentry but no nd/vfsmnt 1141093096 M * Bertl but, lucky for us, xattr_permission() is the first check 1141093121 M * Bertl same for vfs_setxattr 1141093144 M * Bertl vfs_removexattr() is tricky 1141093162 M * Bertl we cannot move the vfs_readonly() check upwards there 1141093189 M * Bertl because we would change semantics here in case that ->removexattr doesn't exist 1141093219 M * Bertl let's ignore that for now and move on upwards .. 1141093270 M * mugwump right, if there is no ->removexattr we should return ESORRYNOXATTRSHEREBUDDY 1141093334 M * Bertl http://pastebin.com/576003 1141093362 M * Bertl nfs is ugly as usual, so let's look at setxattr() 1141093392 M * Bertl ah, setxattr already has the vfsmount (in our version) 1141093411 M * Bertl and look, we already do the if (MNT_IS_RDONLY(mnt)) 1141093414 M * Bertl check there 1141093445 M * Bertl so we would just rename that to vfs_readonly() and be done 1141093474 M * Bertl getxattr() is not really a problem, as it works on RO too 1141093496 M * mugwump can well vfs_readonly should take an inode *and* a mount 1141093508 M * mugwump s/can// 1141093520 M * Bertl well, that would be trickier 1141093543 M * Bertl but I think a dentry should be there in 99% of all cases 1141093586 M * mugwump oh, did I mean to say a dentry *and* a mount? 1141093594 M * Bertl anyway, except for removexattr(), where I already break the semantics, it would be fine to forget about the permission() checks 1141093709 M * Bertl so leaves us with __lookup_hash 1141093719 M * mugwump ok, I think the correct solution there would be to change vfs_removexattr to take a mnt 1141093719 M * Bertl the funny ipc do_open() 1141093735 Q * gerrit Ping timeout: 480 seconds 1141093747 M * Bertl and a few corner cases like module_init() 1141093807 M * Bertl now __lookup_hash() is not a big deal, as permission is called with MAY_EXEC 1141093819 M * Bertl (which is fine in regard to RO/atime) 1141093913 M * Bertl so, yes, it should be possible to do an mnt_readonly() check and probably we can also do an vfs_readonly(inode, nd) 1141093973 M * Bertl but I don't see a problem doing that later on, as it doesn't really change anything in the checks, no? 1141094028 M * Bertl something completely different would be to replace all permission() calls in vfs_*() by vfs_permission() 1141094029 M * mugwump what are you meaning by "later on", you mean "with a later patch in the same set" ? 1141094050 M * Bertl I mean, once somebody decides to clean that up :) 1141094076 M * mugwump yes, I think if something is on the vfs level it should be calling vfs_permission 1141094136 M * Bertl okay, so let's cook up a vfs_permission() change instead and try to submit that, yes? 1141094170 M * mugwump sounds good to me. 1141094181 M * Bertl good, you got some time? 1141094195 M * mugwump a couple of hours 1141094216 M * Bertl okay, let's attack it independantly and compare the results in, hmm, let's say an hour or so 1141094239 M * mugwump right-o 1141094249 M * Bertl (or whenever we are done :) 1141094253 A * mugwump goes to get some coffee 1141094261 M * ebiederm_zZ 1141094279 M * Bertl ebiederm_zZ: hmm, sleepwalking? 1141094309 M * Bertl mugwump: ah, based on 2.6.16-rc5, right? 1141094559 A * mugwump returns, with *green tea*! What is he, some kind of health freak? 1141094568 M * mugwump sure, rc5 is fine 1141094636 M * matti mugwump: Did ya watch IT Crowd? ;] 1141094743 M * mugwump matti: not yet, I have put it up internally. Maybe I should set it up in the meeting room tomorrow lunchtime 1141094754 M * mugwump on the projector 8-) 1141094760 M * matti :) 1141094990 M * mugwump heck, where would a two-arg vfs_readonly *go* ? 1141094999 M * mugwump not fs.h, not mount.h 1141095099 A * mugwump decides to put it in vfs.h 1141095119 Q * locksy Ping timeout: 480 seconds 1141095153 A * mugwump decides against that, on second thought 1141095217 M * Bertl mugwump: vfs_permission for now, forget about the vfs_readonly 1141095235 M * mugwump ok, sure :) 1141095237 M * Bertl we do not want to add additional checks yet, just prepare for that 1141095256 J * locksy ~locksy@mrtg.sisgroup.com.au 1141095781 J * mef_ ~mef@c-68-39-177-97.hsd1.nj.comcast.net 1141095801 Q * mef_ Quit: 1141095975 Q * locksy Ping timeout: 480 seconds 1141096841 Q * michal` Ping timeout: 480 seconds 1141096957 Q * Doener Quit: Leaving 1141096995 J * locksy ~locksy@mrtg.sisgroup.com.au 1141097136 J * michal` ~michal@www.rsbac.org 1141097283 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at 1141097614 M * mugwump hmm, I guess most things passing around a dentry should actually pass a nameidata struct 1141097638 M * Bertl well, yes, but for the xattr stuff that won't fly 1141097667 M * Bertl well, it won't work for all filep based calls ... 1141097676 M * mugwump right, I see 1141097810 M * mugwump dammit, where are junctive types when you need them 1141097841 Q * fwl Ping timeout: 481 seconds 1141097890 M * mugwump int vfs_permission( (struct nameidata * | struct vfsmnt *) context, int mask) 1141097957 M * mugwump I'm feeling this approach is getting stuck because vfs_permission wants the wrong things 1141098140 M * mugwump Is this valid? 1141098141 M * mugwump #define vfs_permission(mask, nd) (vfs_permission(mask, nd, NULL)) 1141098278 M * Bertl nope 1141098293 M * mugwump oh well 1141098309 M * mugwump I'm adding a vfs_fpermission for a permission() check with only a (struct file*) 1141098322 M * mugwump I can't see any way around that ... 1141098358 M * Bertl hmm .. why not pass dentry/vfsmount and have a single one? 1141098375 M * mugwump ok 1141098444 M * mugwump so, I've ended up with loads of arguments to vfs_permission; 1141098468 M * mugwump int vfs_permission(int mask, struct dentry *dent, struct vfsmount *mnt, struct struct inode* node) 1141098477 M * mugwump s/struct struct/struct/ :) 1141098504 M * mugwump so, also permission needs to take these two arguments 1141098534 M * mugwump so that it can pass it to SELinux and the inode->i_op->permission 1141098557 M * mugwump what a mess. 1141098798 M * mugwump argh, selinux has stupid globals 1141098840 M * mugwump hate 1141099063 M * mugwump hey, now file_permission can call vfs_permission 1141099067 M * mugwump :D 1141099179 M * mugwump security_inode_permission and security_file_permission could then collapse into a single function... hmm 1141099179 M * Bertl that's the wrong direction 1141099213 M * Bertl basically we should do the following (which seems somewhat contraproductive) 1141099225 M * Bertl - make permission() solely based on inode 1141099242 M * mugwump ok 1141099244 M * Bertl - make vfs_permission() use nameidata 1141099255 M * mugwump ok.. 1141099274 M * Bertl - add some kind of vfs_readonly(dentry, inode) 1141099311 M * Bertl - add some kind of vfs_readonly(dentry, vfsmnt) 1141099316 M * Bertl (forget the inode part) 1141099341 M * Bertl now this has a bunch of issues: 1141099365 M * Bertl a) permission() is used for filesystems too and uses the nd info (if present) 1141099393 M * Bertl (i.e. maybe adding nd to permission was a step in the wrong direction?) 1141099419 M * Bertl vfs_permission() will end up calling vfs_readonly() 1141099422 M * mugwump yes, I think so ... I blame SELinux, it has their grubby fingerprints all over it 1141099449 M * Bertl but most cases will use vfs_readonly() directly, as they cannot use vfs_permission() (mainly because of missing nd) 1141099525 M * mugwump but vfs_readonly does something quite different to vfs_permission 1141099527 M * Bertl so I ask myself, where is the point in having vfs_permission at all= 1141099635 M * Bertl okay, let's remove nd from *_permission first 1141099652 M * mugwump and probably permission(), too 1141099660 M * Bertl yep, that's the idea 1141099667 M * Bertl just vfs_permission shall keep that 1141099676 M * mugwump this impacts quite a few parts ... selinux, inode ops 1141099801 M * Bertl that's not a problem, as it seems the issue comes with fuse :) 1141099836 M * Bertl but I happily remove that 'addition' :) 1141100016 M * mugwump heck, most of the places calling permission() were setting nd to NULL anyway 1141100369 M * mugwump selinux shouldn't care, it wasn't using that parameter 1141100424 M * mugwump *nothing* was using that parameter :) 1141100448 M * Bertl not completely true .. but we get to that later 1141100536 M * mugwump ah, I didn't get to the i_op tables yet 1141100766 M * mugwump oh, that's whence your fuse comment came 1141100807 J * _mountie ~mountie@trb229.travel-net.com 1141101235 Q * mountie Ping timeout: 480 seconds 1141101477 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.16-rc5-vfs0.02.1.diff 1141101487 M * Bertl (first step, remove nd from permission) 1141101566 M * Bertl leaves us with three issues: 1141101599 M * Bertl nfs_permission() LOOKUP_ACCESS and LOOKUP_OPEN checks 1141101648 M * Bertl fuse_permission() LOOKUP_ACCESS checks 1141101698 M * Bertl and the vfs_permission() changes in namei.c 1141101794 M * Bertl I would suggest to merge the LOOKUP flags into the mask 1141101903 M * mugwump ok, I'm running out of time here, but in the morning I'll pick it up again. 1141101910 M * Bertl k 1141102756 M * mugwump mine's at http://vserver.utsl.gen.nz/patches/utsl/2.6.16-rc5-vsi/06-Bind-Mount-Extensions-VFSCleanup.diff 1141102778 M * Bertl okay, differences? 1141102792 M * mugwump the author, at least ;) 1141102807 A * mugwump diffs them 1141102853 M * Bertl updated the first patch in place 1141102865 M * Bertl and added a second one to fixup for the nd checks 1141102883 M * mugwump cool 1141102900 M * mugwump ok, you missed coda_ioctl_permission in fs/code/pioctl.c 1141102927 M * Bertl hmm, isn't that something different? 1141102929 M * mugwump oh, wait 1141102958 M * mugwump no, it assigns that function to the inode_permission i_op slot 1141102980 M * Bertl ah, okay, then I missed it :) 1141103076 M * mugwump did you get fs/jfs/jfs_acl? 1141103081 M * mugwump (.h) 1141103128 M * mugwump also security_inode_permission is only two args now, in fs/namei.c 1141103138 M * mugwump function exec_permission_lite 1141103192 M * mugwump did you see in fs/nfsd/nfsfh.c:nfs_permission(), it uses nd twice? once for LOOPUP_ACCESS, once for LOOKUP_OPEN 1141103201 M * mugwump s/LOOP/LOOK 1141103203 M * Bertl yup 1141103209 M * Bertl that is handled in the second patch 1141103231 M * mugwump I missed proc_permission 1141103248 M * mugwump and reiserfs_permission 1141103255 M * mugwump and smb_file_permission 1141103271 M * Bertl I guess we have it now ... updating again 1141103274 M * mugwump and fs/xfs/linux-2.6/xfs_iops.c 1141103310 M * mugwump there's a line of comment in include/linux/security that needs to be removed, that documents the extra param to inode_permission() 1141103328 M * mugwump and that's it 1141103332 M * Bertl is that in your patch? 1141103337 M * mugwump yep 1141103472 J * tudenbart ~willi@xdsl-213-196-226-66.netcologne.de 1141103475 M * Bertl okay, updated 1141103511 M * Bertl I will submit it as RFC vfs: cleanup of permission() 1141103517 M * Bertl is that okay? 1141103574 M * mugwump sounds great! 1141103580 M * Bertl Signed-off-by you and me? 1141103585 M * mugwump Yes 1141103594 M * Bertl okidokili ... 1141103789 Q * dothebart Read error: Connection reset by peer 1141103891 M * mugwump I didn't do anything for the second part, actually. But you can put Acked-by:, unless it's too late already 1141103929 M * Bertl np, still preparing something ... 1141104332 M * mugwump here, if you want a Signed-off-by:, import this hunk: http://pastebin.com/576161 :) 1141104389 M * mugwump argh, those bitmask operations are All Wrongâ„¢ 1141104400 M * mugwump #if (_LOOKUP_MASK & _ACCESS_MASK) != (_LOOKUP_MASK | _ACCESS_MASK) 1141104401 M * mugwump should be 1141104410 M * mugwump #if (_LOOKUP_MASK ^ _ACCESS_MASK) != (_LOOKUP_MASK | _ACCESS_MASK) 1141104421 M * mugwump is that paranoia? :) 1141104691 A * mugwump kungfus& 1141104696 M * Bertl hum .. well, it is ... too late :) 1141104739 M * Bertl but hey, it's an RFC, nothing final 1141104791 M * Bertl hmm, I forgot to cc you, shall I bounce the mails to you or will you get them via lkml? 1141104805 M * mugwump I can see them 1141104812 M * Bertl ah, great ... 1141104850 M * mugwump I mark threads I've been watching in a different colour, works almost as well as gnus scoring 1141104900 A * mugwump really goes this time & 1141104914 M * Bertl okay, have a good one! 1141105414 M * Hollow morning 1141105422 M * Bertl good morning Hollow! 1141105463 Q * FireEgl Quit: Bye... 1141105569 M * Hollow Bertl: regarding vreaper.. why don't you just kill the whole guest if init dies? 1141105578 M * Hollow (and maybe call vshelper) 1141105580 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at 1141105617 M * Bertl Hollow: sending a signal would be possible, but really zapping the context is not (yet) 1141105669 M * Hollow yeah, send SIGKILL to every process in the context 1141105728 M * Bertl we could do that, but what would be the advantage? 1141105788 M * Hollow well, dunno what vreaper does atm..? 1141105801 M * Bertl ah, okay :) 1141105802 M * Hollow just saw fix02 yesterday popping by.. 1141105824 M * Bertl well, as bonbons tried to explain yesterday 1141105840 M * Bertl this was all started by the observation that guest 1141105851 M * Bertl processes will not signal guest init when they die 1141105876 M * Hollow whom did they signal? real init? 1141105881 M * Hollow s/real/host/ 1141105881 M * Bertl (leading to various issues with init not restarting services) 1141105904 M * Bertl no, actually they did not signal anything, just got reaped by the host init 1141105914 M * Hollow ah 1141105918 J * Smutje_ ~Smutje@xdsl-84-44-246-172.netcologne.de 1141105938 M * Bertl now I introduced a quick hack to fix that, which opened a can of worms 1141106034 Q * Smutje Ping timeout: 480 seconds 1141106034 N * Smutje_ Smutje 1141106093 M * Bertl Hollow: but it should be fixed now .. 1141106110 M * Bertl will upload a final? patch shortly, and a new release later 1141106155 M * Hollow ok 1141106165 M * Bertl what it does now is the following: 1141106191 M * Bertl - on the INIT flag change, assign init and reaper 1141106192 J * _5hfifty ~shfifty@203-206-69-96.dyn.iinet.net.au 1141106201 M * Bertl welcome _5hfifty! 1141106208 M * Bertl Hollow: 1141106234 M * Bertl - when init or reaper exits, fall back to defaults 1141106253 M * Bertl - when processes (!= init/reaper) get reaped, use reaper 1141106277 M * Bertl later init and reaper might be set via commands as discussed 1141106282 M * Hollow the defaults would be? 1141106304 M * Bertl for init it is NULL, for the reaper it is child_reaper (host init) 1141106309 M * _5hfifty startkeylogger 1141106312 M * _5hfifty :( 1141106313 M * Hollow ok 1141106325 M * Bertl _5hfifty: lol 1141106365 M * Hollow but shouldn't init and reaper be the same process, theoretically? 1141106367 M * Bertl Hollow: example for init/exit: 1141106373 M * Bertl # vserver WWWW start 1141106377 M * Bertl [ 55.272534] vxD: vx_set_init(8f559000[#20],8f49eab0[#20,98,98]) 1141106377 M * Bertl [ 55.274985] vxD: vx_set_reaper(8f559000[#20],8f49eab0[#20,98]) 1141106384 M * Bertl # vkill -k 9 -p 1 -x 20 1141106387 M * Bertl [ 268.687757] vxD: vx_exit_init(8f559000[#20],8f49eab0[#20,98,98]) 1141106387 M * Bertl [ 268.690285] vxD: vx_set_reaper(8f559000[#20],81396ab0[#0,1]) 1141106409 P * _5hfifty 1141106450 M * Bertl Hollow: usually reaper and init will be one process 1141106473 M * Hollow but util-vserver made two out of it.. 1141106475 M * Hollow ;) 1141106895 M * Bertl yeah, somewhat, actually it's a process above init (but inside the guest) 1141106971 Q * Hunger jupiter.oftc.net europa.oftc.net 1141107176 M * Bertl Hollow: okay, the vreaper-feat02 and fix03 together should give a decent vreaper support 1141107191 M * Bertl http://vserver.13thfloor.at/Experimental/delta-vreaper-feat02.diff 1141107195 M * Bertl http://vserver.13thfloor.at/Experimental/delta-vreaper-fix03.diff 1141107218 M * Bertl any previous vreaper patches should be reverted :) 1141107249 M * Bertl will fix up an rc10 release after some sleep .. 1141107283 M * Bertl off to bed now .. have a good whatever everyone .. cya later! 1141107299 N * Bertl Bertl_zZ 1141107351 J * Hunger Hunger.hu@Hunger.hu 1141108005 J * anonc ~anonc@staffnet.internode.com.au 1141109155 J * FireEgl Atlantica@2001:5c0:84dc:: 1141110915 Q * fwl Quit: This computer has gone to sleep 1141110984 J * zal ~zalfarien@202.157.203.154 1141111024 M * zal ;-) 1141111051 J * fwl ~fwl@83-215-237-2.seek.stat.salzburg-online.at 1141112135 Q * teukka Read error: Connection reset by peer 1141112167 J * teukka ~tmatilai@backport.ri.fi 1141112492 P * zal Kopete 0.10 : http://kopete.kde.org 1141113922 J * meandtheshell ~markus@85-124-37-87.dynamic.xdsl-line.inode.at 1141115211 J * balbir ~balbir@59.145.136.1 1141115474 Q * shedi Quit: Leaving 1141115914 P * balbir Leaving 1141115932 J * matta ~matta@71.224.125.126 1141115946 J * balbir ~balbir@59.145.136.1 1141116217 Q * matta Read error: Connection reset by peer 1141116393 J * matta ~matta@71.224.125.126 1141116445 M * harry 2 people seem to have downloaded my latest patch, i advise to do it again, there were 2 includes missing in some grsec code making it not compile allways 1141116451 M * harry new patch is ok tough 1141117825 M * harry http://harry.ulyssis.org/vserver/testoutput 1141117859 M * harry is all that normal? (especially the jfs part) 1141117888 M * daniel_hozac no. 1141117984 M * daniel_hozac oh sorry, was looking at the first one. 1141117996 M * daniel_hozac the latter looks ok, assuming it's an old patch. 1141118012 M * harry 2.1.0 1141118016 M * daniel_hozac right. 1141118028 M * daniel_hozac might want to add -x too, to test tag* stuff. 1141118032 M * harry the first one is what they say the "old style" 1141118037 M * harry well... 1141118067 M * harry chattr: Inappropriate ioctl for device while reading flags on /usr/local/etc/vservers/.defaults/vdirbase/stdserver 1141118070 M * harry i got this before 1141118073 M * harry its reiserfs 1141118083 M * harry how do i enable attrs on it? 1141118091 M * harry (where is it documented? 1141118144 M * daniel_hozac http://www.google.com/search?q=site%3Alinux-vserver.org%20attrs%20reiserfs ;) 1141118182 M * harry so it's not documented on the site... 1141118341 M * harry gandalf:/vservers# umount stdserver/ -f 1141118341 M * harry umount2: Device or resource busy 1141118341 M * harry umount: /vservers/stdserver: device is busy 1141118341 M * harry umount2: Device or resource busy 1141118341 M * harry umount: /vservers/stdserver: device is busy 1141118344 M * harry grmbl... what now!? 1141118362 M * harry gandalf:/vservers# lsof |grep stdserver 1141118363 M * harry nothing 1141118371 M * daniel_hozac chcontext --xid 1 lsof 1141118481 M * harry gandalf:/proc# chcontext --xid 1 lsof|grep std 1141118483 M * harry nothing 1141118523 M * daniel_hozac is the context gone? 1141118532 M * harry how do i know? 1141118545 M * daniel_hozac ls -l /proc/virtual 1141118574 Q * bubulak Ping timeout: 480 seconds 1141118578 M * harry -r--r--r-- 1 root root 0 2006-02-28 10:03 info 1141118578 M * harry -r--r--r-- 1 root root 0 2006-02-28 10:22 status 1141118755 M * harry anyway... /me is right back... 1141118761 M * harry back in 20 mins or so 1141118790 J * shedi ~siggi@tolvudeild-204.lhi.is 1141119674 M * harry back! 1141119691 M * Wonka front! 1141120064 J * bubulak ~bubulak@cicka.wnet.sk 1141121067 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1141121547 Q * Duckx Ping timeout: 480 seconds 1141122127 J * Wenix ~jrc@cpe.atm2-0-1051059.0x50a09f6a.bynxx11.customer.tele.dk 1141122271 M * Wenix Hmm, I have a task, that from what I can see, wanders from context to context 1141122284 M * Wenix This is on: 2.6.15-vs2.1.0-gentoo-r1 1141122310 M * Wenix One moment, ps can see the task, the next moment it can't (on the guest) 1141122580 M * Wenix .. I'll try to collect some information on this 1141122729 J * Duckx ~duckx@195.75.27.158 1141122832 M * Wenix I can't seem to repeat it.. but bittorrent-curses was running with a 100% load on a guest - and on the guest it didn't always show up on "ps axf" or "top".. but on the host system, it was shown on the normal "top".. I didn't try ps 1141122869 M * Wenix .. now that its done downloading, everything is back to normal.. another 100% load task can't seem to repeat the behaviour 1141122985 Q * fwl Quit: This computer has gone to sleep 1141123383 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at 1141123554 Q * Aiken_ Ping timeout: 480 seconds 1141123620 J * lilalinux ~plasma@80.69.35.186 1141124517 Q * Duckx Ping timeout: 480 seconds 1141127201 J * florolf ~florolf@p549F475D.dip0.t-ipconnect.de 1141127205 M * florolf hi there 1141128111 J * Viper0482 ~Viper0482@p54976FE6.dip.t-dialin.net 1141128501 Q * click Ping timeout: 480 seconds 1141130715 J * click click@ti511110a080-5178.bb.online.no 1141131025 M * harry is there a page that describes how to remove a virtual server ? 1141131142 Q * matti Remote host closed the connection 1141131177 M * phreak`` harry: eh ? rm -rf /vserver/$name /etc/vserver/$name :) 1141131191 M * phreak`` harry: or what do you mean by "removing" ? 1141131195 M * waldi hmm, /me waits for -rc10 1141131208 M * harry phreak``: if that's all: then yes, that 1141131210 J * seeker77 ~seeker@231.4.77.83.cust.bluewin.ch 1141131220 M * harry but shouldn't it be documented somewhere??? 1141131236 M * seeker77 hi all, can someone point me to some docs on how to create a fedora core guest os on a debian host? 1141131389 M * phreak`` waldi: me too :) 1141131406 M * waldi phreak``: i need a xen-vserver kernel 1141131426 M * phreak`` harry: for what ?! :) everybody knows how to delete a directory .. and if that one isn't able to remember which directories he created, well :) 1141131444 M * phreak`` waldi: *ugh* good luck with fixing rejects ;) 1141131450 M * waldi phreak``: yep 1141131470 M * harry shouldn't be that hard... 1141131488 M * harry if anyone's interested, i've got a vserver + grsec patch 1141131501 M * harry for 2.6.14.7 (there is no grsec for later versions) 1141131502 M * waldi phreak``: i maintained the debian fork of the ibm kernels at 2.4 times, 6 linux releases and about 30 patches. so I know how to do such 1141131555 M * phreak`` waldi: well I used to maintain a grsec-vserver patch (for half a year or so), and fixing the rejects of grsec/vserver is quite hard .. :) 1141131569 M * harry phreak``: you think? 1141131607 M * waldi hmm, wasn't there problems with using samba within a vserver? 1141131608 A * harry did the merge in a few hours yesterday 1141131631 M * harry http://harry.ulyssis.org/vserver/ 1141131633 M * harry if you want 1141131685 M * waldi no need for grsec 1141131687 M * waldi i have xe 1141131690 M * phreak`` waldi: I had some, which forced me to move to the real host, yeah 1141131691 M * harry i tried 2.1.1-rc8 vserver... but with bme and other major patches it's very hard to backport 1141131722 M * waldi except that I managed to order too lees memory for the new servers 1141131782 M * waldi bah, I need some popcorn 1141131795 M * waldi phreak``: please define "some" 1141131839 M * seeker77 hey people, really no hints on installing fc4 as a guest to debian? 1141131856 M * waldi seeker77: use rootstrap 1141131875 M * waldi but installing rpm based dists without the installer is hard 1141131882 M * phreak`` waldi: i.e. not able to access the share :) 1141131897 M * waldi phreak``: okay 1141131934 M * phreak`` but that only occured on >=samba-3.0.20 1141132140 J * Duckx ~duckx@195.75.27.158 1141132161 M * seeker77 waldi: -m rootstrap returns 'Unknown build-method 'rootstrap' 1141132461 M * Wenix waldi: I run a Samba server inside vserver - no problems for me yet 1141132483 M * Hollow seeker77: bootstrap that is 1141132614 Q * _mountie Ping timeout: 480 seconds 1141132622 M * seeker77 bootstrap is neither accepted as a build-method. this can not be so difficult... can not someone point me to some usable documentation? 1141132641 N * Bertl_zZ Bertl 1141132643 J * _mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com 1141132646 M * Bertl morning folks! 1141133108 A * seeker77 if he asked the wrong way 1141133268 M * Bertl seeker77: -m debootstrap? 1141133361 M * seeker77 Bertl: unfortunately debootstrap only provides scripts for debian & ubuntu 1141133374 M * Bertl and you want to bootstrap what? 1141133391 M * seeker77 fc4 1141133401 M * Bertl but not with debootstrap? 1141133412 M * Bertl they are using yum or apt-rpm IIRC? 1141133443 M * seeker77 exactly, they're using yum. but i can not use the 'yum' build-method on a debian etch host system 1141133464 M * Bertl ah, well, that's a debian issue 1141133484 M * Bertl in this regard debian (or ubuntu?) is kind of limited 1141133500 M * Bertl it seems that folks did not manage to get yum/rpm/apt-rpm running on debian yet 1141133518 M * seeker77 yes, they think we should use alien 1141133519 M * Bertl while OTOH, debootstrap works quite fine on RPM based systems 1141133543 Q * balbir Quit: Leaving 1141133563 M * waldi on, not for 1141133579 M * Bertl and the rpmstrap stuff we did look at some time ago (just for a short moment) has not been investigated further yet 1141133656 M * waldi Bertl: what is the state of -rc10? *quengel* 1141133664 M * Bertl upcoming :) 1141133761 M * seeker77 Bertl: too bad, but i still would like to use vserver on my debian system. is there no way to do this? 1141133778 M * Bertl seeker77: sure, IMHO you have three options here: 1141133796 M * Bertl 1) create the initial guest image on an RPM based system, and just move it over 1141133819 M * Bertl 2) use a chroot with an RPM based system to install the guest 1141133840 M * Bertl 3) implement a build method suited for debian based on alien or whatever 1141133929 M * seeker77 ok... unfortunately none of those methods i can use right now (don't have either any rpm-based system available nor any coding skills). i think i just switch to vmware :-( thanks anyway 1141133973 M * Bertl you could download an existing image? 1141133981 M * seeker77 yes, that would be perfect! 1141133992 M * Bertl there were some some time ago ... let me check ... 1141134175 Q * bragon Ping timeout: 480 seconds 1141134177 M * Bertl seeker77: http://debian.marlow.dk/vserver/guest/ 1141134203 M * Bertl those are older ones, but you can use them for installing newer ones with approach 2 1141134238 M * Bertl or you could update them from inside, e.g. fc2 -> fc3 -> fc4 1141134324 M * seeker77 ok, that sounds good, thanks a lot Bertl 1141134330 M * Bertl you're welcome! 1141134336 M * phreak`` morning Bertl :) 1141134355 M * Bertl phreak``: hey! 1141134382 M * phreak`` Bertl: how's it going ?! :) 1141134396 M * Bertl fine, thanks, issue fixed :) 1141134396 M * phreak`` s/*/how are you/ 1141134483 Q * seeker77 Quit: Leaving 1141135283 J * Doener doener@i5387EC7C.versanet.de 1141135312 J * matti matti@linux.gentoo.pl 1141135959 M * Bertl hey Doener! matti! 1141135984 M * Doener hi Bertl 1141136154 M * tudenbart mjami. 1141136167 M * tudenbart just ate one. 1141136192 M * Doener 43254152 1141136593 M * matti Bertl: :))))))))) 1141136594 M * matti Doener: :) 1141136884 A * Wonka wants a subway sandwich 1141136945 M * Bertl hmm, now I'm hungry .... afk, brb :) 1141137141 A * Doener feels guilt 1141137148 M * Doener s/gult/guilty/ 1141137152 M * Doener dammit 1141137212 M * Bertl well, guilt was already fine :) 1141137653 M * florolf yay 1141137665 M * florolf linux-vserver up and running 1141137673 M * Bertl congrats! 1141137673 M * florolf *happy* 1141137677 M * florolf thanks ;) 1141140970 J * dreamist ~noway@64.186.48.15 1141140999 M * dreamist howdy all 1141141013 M * Bertl welcome dreamist! 1141141036 Q * ||Cobra|| Remote host closed the connection 1141141067 M * dreamist having some trouble building a vserver -- I assume I'm just being stupid... 1141141078 M * Bertl let's hear ... 1141141098 M * dreamist host machine is Centos 4.2 (with a downgraded yum as that appeared to cause breakage) 1141141135 M * dreamist I've created an LVM volume and mounted it on /vservers/pgdb0, which is where I'm trying to build into 1141141147 M * Bertl hmm, well, you should use a patched yum version on the host if you want to use yum for guest install 1141141162 M * dreamist but when I try to vserver build pgdb0, it barfs: 1141141183 M * dreamist [root@filer0 ~]# vserver pgdb0 build -n pgdb0 -m yum --hostname pgdb0.vs.weyco.com --interface eth0:192.168.3.16 --netmask 255.255.0.0 --initstyle sysv -- -d centos42 1141141202 M * dreamist . /etc/vservers/.defaults/vdirbase/pgdb0/lost+found 1141141207 M * dreamist . /usr/lib/util-vserver/functions: line 206: -n: command not found 1141141210 M * Bertl where do you have that line from? 1141141220 M * Bertl (because it's just wrong) 1141141226 M * dreamist sweet ;-) 1141141249 M * Bertl try: vserver pgdb0 build -m yum --hostname pgdb0.vs.weyco.com --interface eth0:192.168.3.16/16 --initstyle sysv -- -d centos42 1141141293 M * dreamist at this point I've lost track of where I got it.. but I'm sure it exists in some form or another in one of the howtos 1141141306 M * Bertl would be good to find and fix it 1141141314 M * dreamist vserver pgdb0 build -m yum --hostname pgdb0.vs.weyco.com --interface eth0:192.168.3.16/16 --initstyle sysv -- -d centos42 1141141321 M * dreamist . /etc/vservers/.defaults/vdirbase/pgdb0/lost+found 1141141326 M * dreamist . /usr/lib/util-vserver/functions: line 206: -n: command not found 1141141363 M * Bertl okay, probably not the only issue you have .. but let's check a few things 1141141402 M * dreamist I'm reasonably certain that if I try that build command with a different vserver name, it would work 1141141419 M * Bertl not necessarily, but you can try 1141141420 M * dreamist I think having /vservers/pgdb0 mounted as a different filesystem is confusing it 1141141431 M * Bertl what tools do you use? 1141141453 J * pagano ~pagano@lappagano.cnaf.infn.it 1141141453 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh-0.15 1141141472 M * Bertl (run that on the host as root and upload the output to pastebin.com or so) 1141141475 M * pagano hi all, 1141141477 M * Bertl welcome pagano! 1141141501 M * pagano hi bertl :) 1141141542 M * pagano a fast question, if i build a new vserver with 1141141589 M * pagano vserver 123 build ... 1141141608 M * pagano i haven't .config file 1141141610 M * dreamist bertl: output on pastebin.com 1141141630 M * pagano while if i use "newvserver -v --hostname ..." 1141141650 M * Bertl panthat's because newvserver is a debian tool and uses the legacy (old) format 1141141651 M * pagano i can find it in /etc/vservers/123.conf 1141141678 M * pagano ahhh k 1141141713 M * Bertl dreamist: looks fine, let's upload the output of 'vserver-info - SYSINFO' too please 1141141817 M * dreamist bertl: done.. 1141141857 M * Bertl hmm, maybe the tools are really confused by the mountpoint 1141141871 M * Bertl IIRC, the new release 0.30.210 fixed something in that regard 1141141896 M * Bertl so it might be worth giving it a try .. but first let's see what happens if we do: 1141141921 M * Bertl vserver pgdb0 build -m skeleton --hostname pgdb0.vs.weyco.com --interface eth0:192.168.3.16/16 --initstyle sysv 1141141954 M * pagano so, if i want to do a backup of my vserver, i do "tar -cf vserver.tar.gz /vserver/namevserver" 1141141957 M * dreamist my approach is to give each vserver (of any size) an LVM volume; is that reasonable approach, or am I being shortsighted in some way? 1141141984 M * pagano but about config file that i haven't anymore? 1141141990 M * Bertl dreamist: no, that is quite fine, as long as you do not want to share disk space between them 1141141992 M * dreamist same output as before 1141142008 M * Bertl pagano: you can easily recreate the config later, or just tar it up as well 1141142028 M * Bertl dreamist: okay, let's try with a different name 1141142041 M * Bertl (the skeleton will be quite small, just use test01 or so) 1141142060 M * dreamist vserver pgdb1 build -m skeleton --hostname pgdb1.vs.weyco.com --interface eth0:192.168.3.16/16 --initstyle sysv 1141142064 M * dreamist completed with no errors 1141142078 M * Bertl okay, so I'd suggest to update the tools and try again 1141142094 M * Bertl alternatively, if the issue really persists, you can do the following: 1141142113 M * Bertl - create the guest on the /vservers partition 1141142125 M * Bertl - mount the lvm somewhere 1141142136 M * Bertl - copy over the data (move) 1141142189 M * Bertl if it really persists, I'd ask you to file a bug report to savannah .. 1141142453 M * dreamist I should spend a day or so sometime soon and dig through the scripts so that I have a better idea of what they're doing; that'd probably help :-) 1141142492 M * Bertl definitely, but they are quite complex (--debug helps sometimes :) 1141142767 J * gerrit ~gerrit@129.33.1.37 1141142784 M * Bertl wb gerrit! 1141142882 M * RoadRunnR hi bertl 1141142909 M * Bertl hey RoadRunnR! 1141142945 M * RoadRunnR Bertl: i'm afraid i found something that looks like another socket or resource leak in 2.6.15.4-vs2.0.2-rc6 :-( 1141142970 M * RoadRunnR i can reliably reproduce it, but the test setup is rather complex 1141142991 M * Bertl let's hear (btw, we are at rc9, rc10 upcoming) 1141143042 M * RoadRunnR ok, testsetup, 2.6.15.4-vs2.0.2-rc6 + drbd + heartbeat 1141143105 M * RoadRunnR this http://pastebin.com/576821 testscript failes to stop the radius drbd volume, and in fact drbd will refuse to make it secondary until the db vserver is beeing stoped 1141143165 M * RoadRunnR stoping the db vserver will immediatly release the radius drbd volume 1141143201 M * Bertl yup, sounds reasonable 1141143202 M * RoadRunnR the strange thing is, i can umount the radius volume, but drbd will still see it as open 1141143214 M * Bertl which is true 1141143229 M * RoadRunnR this might be some strange interaction between drbd and vserver... 1141143233 M * Bertl you have been fooled by private namespaces :) 1141143246 M * Bertl the thing is the following: 1141143258 M * Bertl - you mount /dev/drbd2 /servers/radius 1141143285 M * Bertl - now you start a guest, which 'inherits' the namespace and so the mount 1141143307 M * RoadRunnR uhm, i see where this going 1141143307 M * Bertl - you start another one (db) which also gets a copy of the namespace 1141143322 M * RoadRunnR so, how can this be avoided? 1141143328 M * Bertl - now you stop the first one, the one mount goes away, the other stays 1141143342 M * Bertl well, it's actually simple and you have a few options there 1141143343 M * RoadRunnR i probably need to mount the volume inside the vserver then, right? 1141143358 M * Bertl a) put that mount into the guest's fstab 1141143364 M * phreak`` RoadRunnR: mount the drbd devices via the fstab *only* for the guest 1141143377 M * phreak`` (as Bertl pointed out in a.) 1141143380 M * Bertl b) enter the namespace after startup and remove the unwanted mounts 1141143408 M * Bertl c) remove the mount _after_ guest startup, but before second startup 1141143429 M * Bertl the fstab is the cleanest method IMHO 1141143454 M * phreak`` Bertl: not only in your opinion ;) 1141143457 M * RoadRunnR i think so too, b) and c) sound awfull, and i'm not sure it would work reliably with heartbeat 1141143506 M * RoadRunnR ahrgh, now i find the wiki entry for this problem .... 1141143541 M * dreamist RoadRunnR: which is the wiki page that covers it? 1141143541 M * Bertl yup, you are not alone :) 1141143600 M * RoadRunnR http://linux-vserver.org/advanced+DRBD+mount+issues 1141143623 M * dreamist thanks :-) 1141143630 M * pagano last question (for today) : 1141143661 M * pagano i have a debian sarge with vserver kernel 1141143661 N * ebiederm_zZ ebiederm_oO 1141143705 Q * Wenix Ping timeout: 480 seconds 1141143719 M * pagano can I install a linux distribution not very common ? 1141143729 M * pagano google don't help me 1141143741 M * RoadRunnR Bertl: about this private namespace think, i don't understand why a vserver inherits thinks that are outside of its scope, in this case the mounts it can not even access? 1141143755 M * pagano or linux-vserver is ready only for some distributions? 1141143758 M * Bertl pagano: basically you can run _any_ linux distro as guest 1141143772 M * Bertl pagano: and probably any distro for the host too 1141143787 M * RoadRunnR pagano: installing a distro that differs from the host into a vserver is difficult 1141143802 M * Bertl pagano: you just need an installation of your favorite guest distro 1141143810 M * pagano infact my little experience is only sage inside sarge 1141143828 M * Bertl pagano: yes, debian is a little limited in this regard 1141143842 M * RoadRunnR debian inside debian is ok, but installing a rpm based distro onto a debian system does not work 1141143849 M * pagano ah k 1141143852 M * Bertl pagano: on rpm based host systems you have install methods for rpm and debian based guests (network install) 1141143862 M * RoadRunnR (well it could, but you would first have to build some rpm tools) 1141143876 M * Bertl pagano: but once you have a guest image/data dir, then it is no problem with debian either 1141143918 M * pagano k tomorrow more question :) 1141143926 M * Bertl k, have fun! 1141143935 M * Bertl (and feel free to hang around) 1141143944 M * pagano thanks a lot for yoiur support and your patience 1141143954 M * Bertl you're welcome! 1141143962 M * pagano heehe ok Bert1, i will follow your suggest! 1141143964 Q * pagano Quit: 1141144324 M * dreamist when I use vrpm to install a .rpm, the package needs to be accessible by the guest (i.e. in it's /vservers directory somewhere) correct? 1141144331 T * Bertl http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc10 | 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 ;) 1141144349 M * Bertl rc10 is out (usual place) 1141144374 M * Bertl dreamist: nope, it must be reachable on the host 1141144380 M * RoadRunnR Bertl: any interresting changes in rc10? 1141144396 M * Bertl compared to what? 1141144404 M * RoadRunnR to rc9 1141144406 M * SiD3WiNDR rc9 ! ;) 1141144416 M * Bertl yup, the vreaper stuff was hopefully fixed 1141144432 M * Bertl and of course, it's rebased to 2.6.16-rc5 1141144661 M * RoadRunnR Bertl: sorry to ask again, but this really bugs me, about this private namespace thing, i don't understand why a vserver inherits things that are outside of its scope, in this case the mounts it can not even access? 1141144708 M * Bertl because there is no cleanup which is done yet, and the private namespaces (in mainline) work like that 1141144723 M * Bertl you can check that by entering the namespace with vnamespace 1141144772 Q * `DoM` Quit: Byez 1141144789 M * waldi *import* 1141144821 M * Bertl ah, yeah, forgot to ping you :) 1141144914 A * dreamist feels stupid today 1141144945 M * dreamist vrpm pgdb0 -- -ivh postgresql-libs-8.1.3-1PGDG.i686.rpm 1141144945 M * dreamist error: open of postgresql-libs-8.1.3-1PGDG.i686.rpm failed: No such file or directory 1141144993 M * waldi Bertl: so I can merge them with xen 1141145052 M * dreamist ah interesting.. I guess a vserver has to be shut down to use vrpm? 1141145071 M * Bertl IIRC, it is advised 1141145143 M * waldi at least it applies 1141145201 Q * shedi Quit: Leaving 1141145305 M * dreamist thats kind of inconvenient -- makes in place upgrading either require a maint. window, or internalized package management 1141145357 M * Bertl I'm pretty sure it can be done while the guest uis running too, just might require a few changes 1141145397 M * Bertl and of course, it might be a security issue 1141145664 M * dreamist will have to do some digging on it, cuz that would be handy 1141145667 M * phreak`` Bertl: thanks for the new _rc ;) 1141145694 M * Bertl phreak``: np 1141145942 Q * matta Ping timeout: 480 seconds 1141146314 M * waldi <<<<<<< local 1141146314 M * waldi #define MAXMEM ((unsigned long)__MAXMEM) 1141146314 M * waldi ======= 1141146314 M * waldi #define MAXMEM (__FIXADDR_TOP-__PAGE_OFFSET-__VMALLOC_RESERVE) 1141146314 M * waldi >>>>>>> remote 1141146316 M * waldi hihi 1141146376 J * bonbons ~bonbons@83.222.39.180 1141146449 M * Bertl welcome bonbons! 1141146459 M * bonbons Hello Bertl! 1141146476 M * bonbons New patch as I see... rc10 1141146504 M * Bertl yup, should fix the issues :) 1141146707 M * waldi Bertl: only one reject 1141146725 M * Bertl good, now for the arch part :) 1141146769 M * phreak`` Bertl: is the powerpc stuff also in _rc10 ? 1141146777 M * Bertl phreak``: it should be 1141146780 M * phreak`` (didn't check it) 1141146807 M * waldi Bertl: why do you need that page.h patch? 1141146836 M * Bertl the MAXMEM? 1141146848 M * waldi yes 1141146851 J * dothebart ~willi@xdsl-213-196-221-186.netcologne.de 1141146863 M * Bertl you can safely go for the xen version there 1141146875 M * waldi this is the only conflicting part between vserver and xen if I do real merging 1141146899 M * phreak`` Bertl: delta-powerpc-fix01.diff still ain't in there :) 1141146915 M * Bertl really? which one are you looking at? 1141146986 M * phreak`` http://vserver.13thfloor.at/Experimental/delta-powerpc-fix01.diff vs. diffstat | grep powerpc of http://vserver.13thfloor.at/Experimental/patch-2.6.15.4-vs2.1.1-rc10.diff (because its modifying arch/powerpc/kernel/asm-offsets.c) 1141147006 M * Bertl 2.6.15.4 has no powerpc IIRC := 1141147020 M * phreak`` sure it has :) 1141147032 M * Bertl hmm, thought that came in in 2.6.16-rc* 1141147041 M * Bertl (was previously ppc64 1141147043 M * phreak`` (at least I compiled it for the pSeries at work yesterday) :) 1141147115 M * Bertl okay, will add it now 1141147160 M * Bertl done 1141147173 M * waldi 2.6.15 have no ppc64 1141147180 M * Bertl next release candidate will have it for 2.6.15.4 too 1141147222 M * phreak`` waldi: eh ?! :) 1141147296 Q * tudenbart Ping timeout: 480 seconds 1141147306 M * waldi yes 1141147680 J * derjohn ~derjohn@80.69.37.19 1141147696 M * Hollow Bertl: when do you plan adding the switches for init/reaper? 1141147733 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net 1141147736 M * Bertl Hollow: in the next few days ... 1141147746 M * Bertl welcome derjohn! matta! 1141147754 A * waldi needs more processor power 1141148118 M * derjohn Bertl, drunken?? 1141148143 M * derjohn Bertl, sry ... I just translated matta, I thought I was meant ;) 1141148253 M * Bertl hehe 1141148301 M * Bertl derjohn: would only happen if they change the cola recipe ... 1141148338 M * Bertl (or matti mixes me something in the coffee :) 1141148340 M * derjohn well, in times of opencola you can change youself ;) 1141148399 M * derjohn Are there any unresovled issues with 2.1.1rc10 at the time? What was about this ext3 thing you alle were concerned about? 1141148409 M * Bertl okay, off for now .. back in the evening ... let me know how rc10 goes (bonbons, phreak``) 1141148431 M * Bertl derjohn: nope, looks good, all should be fine with rc10 1141148441 M * bonbons Bertl: will test it soon 1141148441 M * Doener derjohn: the mount stuff? my patch went into 2.6.16-rc5 1141148455 N * Bertl Bertl_oO 1141148471 M * phreak`` Bertl_oO: will do :) 1141148485 M * derjohn Doener, you outperformed Bertl? Congrats ;) 1141148501 M * derjohn Yes, so it affects 2.6.15 in any case? 1141148531 M * waldi seems to build 1141148649 M * Doener derjohn: the fix is also in the vserver patch since rc9 (or rc7?) IIRC, so everything prior to those is affected 1141148674 M * Doener regarding the outperforming, I was just lucky, Bertl did the real work 1141148687 M * derjohn does 2.1.1-rc10 ptach against 2.6.16-rc5 ? 1141148701 M * phreak`` derjohn: http://vserver.13thfloor.at/Experimental/patch-2.6.16-rc5-vs2.1.1-rc10.diff :) 1141148741 M * Doener it only matters if you do ext3 mounts inside the vserver's namespace anyway 1141148770 M * derjohn Should I be feared of 2.6.16? recently the kernel underwent to heavy changes .... does anyone of oyu use rc5 with vs in production? 1141148825 M * waldi yes 1141148867 M * matta hey Bertl 1141149782 M * waldi hmm, forgot one patch 1141150429 J * shuri_ ~boafroid@64.235.209.226 1141150710 Q * shuri Quit: Quitte 1141150739 J * djudko ~davej@129.33.1.37 1141151118 Q * fwl Read error: Operation timed out 1141151627 M * waldi Bertl_oO: it boots 1141151808 M * waldi testme succeeds 1141152135 J * comfrey ~comfrey@h-64-105-87-234.sttnwaho.covad.net 1141152329 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at 1141152422 J * Smutje_ ~Smutje@xdsl-87-78-1-38.netcologne.de 1141152529 Q * Smutje Ping timeout: 480 seconds 1141152529 N * Smutje_ Smutje 1141152807 J * shedi ~siggi@inferno.lhi.is 1141153197 Q * cthompson Quit: leaving 1141154292 Q * kilian Ping timeout: 480 seconds 1141154514 N * ebiederm_oO ebiederm 1141154549 Q * fh Quit: changing servers 1141154871 J * fh ~oftc@cheeto.net 1141155438 Q * matti Remote host closed the connection 1141155535 Q * Viper0482 Quit: bin raus, 1141155670 M * bonbons Hollow: ping 1141155672 M * mugwump Doener: what patch did you get in rc5? 1141155692 M * Doener the daemonize() one 1141155697 M * Hollow bonbons: pong 1141155731 M * bonbons Hollow: CAP_* in linux/capability.h is index of bit, not binary value... 1141155750 M * Hollow yup, i know... this is fixed in trun 1141155751 M * Hollow k 1141155779 M * Hollow also vserver.h in trunk contains all the defines if necessary 1141155788 M * bonbons ok, so updating my libvserver 1141155803 M * Hollow i.e. you don't need to include kernel headers in userspace 1141155831 M * bonbons yep 1141155861 M * Hollow bonbons: what do you think of this simple RPC interface for vcd: http://phpfi.com/104726 1141156024 M * bonbons For communication cli<->daemon? looks fine 1141156030 M * Hollow yup 1141156084 M * ebiederm mugwump: How comes your test harness? 1141156087 M * bonbons so the "arg" for RUN could be anything? 1141156109 M * mugwump ebiederm: the harness basically works, it's now just down to writing tests etc 1141156112 M * Hollow e.g. if you do "vcc start test" on the command line, you would do "RUN start test" 1141156151 M * Hollow of course certain command can not be available (such as login) 1141156161 M * ebiederm mugwump: Ok. So one small piece at a time. I wonder if ltp would be a useful set of test to import? 1141156204 M * mugwump ltp/ 1141156205 M * mugwump ? 1141156214 M * ebiederm The tests from the linux test project? 1141156286 M * bonbons what does not seem possible is to send over larger blocks of text/data (like e.g. output of command) 1141156315 M * mugwump ebiederm: I don't know, but I'd guess they're a bit out of scope for the vserver-specific testing I'm doing 1141156357 M * Hollow bonbons: well, for each line of output, one OUT line is sent to the client 1141156359 M * bonbons so there should also be a DATA command, and PASD , MISD 1141156394 M * Hollow hm 1141156405 M * Hollow the size thing seems like a good idea :) 1141156416 M * ebiederm mugwump: Ok. I wasn't certain what you wanted to achieve with your tests. 1141156416 J * kilian kk@projects.verfaction.de 1141156486 M * bonbons Hollow: Yep, it allows to pass anything, even \0, \n, \r &co, in either direction, an ABRT might be useful as well 1141156625 N * ebiederm ebiederm_oO 1141156700 M * Hollow bonbons: what would ABRT do? 1141156730 M * bonbons It would abort/interrupt a running operation 1141156789 M * Hollow hm, that would require async operation.. 1141156840 Q * FireEgl Ping timeout: 480 seconds 1141156918 M * Hollow bonbons: it's even simpler: http://phpfi.com/104735 ;) 1141156927 M * bonbons Yep, but it must not be always available, e.g. would only be available for a few long-lasting or even "offline" operations, this means adding a opt-id 1141156961 M * Hollow guess this is too much for now.. 1141157007 M * bonbons piping some data from vcc to other side? (stdin style) 1141157036 M * Hollow yup 1141157085 M * Hollow after a SET or RET line bytes are read for in/output 1141157123 M * Hollow any other command won't need larger amount of data 1141157130 M * Hollow or data with special chars 1141157210 M * bonbons ok end of command == ? \n? 1141157227 M * Hollow i'd say \n is ok 1141157392 M * Hollow i'll try to make a first approach for vcd and vce this week 1141157402 M * bonbons I'm fine with it, just thinking about some systems were \r or \r\n is the common case, just to make sure no guessing will need to happen 1141157452 M * bonbons I will try to get 1.0.4 branch reasonably stable 1141157453 M * Hollow well, it's \n and noone has to guess :P 1141157486 M * Hollow yeah, i first to push 1.1 asap, but it has to settle first, and many many lines of code are still missing 1141157495 M * Hollow s/first/first thought/ 1141157528 M * Hollow but it's good to have 1.0* brached... i've already cleaned the trunk from old scripts and man pages.. 1141157529 M * mugwump bonbons: what is that protocol for? 1141157594 M * bonbons yep, in addition, having 1.0.4 around and working can be useful to help in debugging of vcc/vcd 1141157636 M * bonbons mugwump: protocol between commandline util, and a daemon monitoring/managing guests 1141157666 M * Hollow bonbons, mugwump: well.. itÄs rather meant to be a backend for web panels or such 1141157685 M * Hollow or a remote GUI 1141157703 M * bonbons That's the ideal use for it :) 1141157768 M * bonbons so s/commandline/human interface/ 1141157870 M * Hollow we can easily do the parsing and use the vcc code for CALL without using execve at all 1141157891 M * Hollow just link all commans into vcd as well 1141157980 M * daniel_hozac Hollow: any reason you can't just go for XML-RPC or another RPC implementation already present? 1141157999 M * Hollow xml is bloated and hard to parse 1141158004 M * daniel_hozac yes, agreed. 1141158040 M * daniel_hozac it is really simple to use from high-level languages though. 1141158044 M * Hollow well, this interface is simple, but all we need, it shouldn't be more than 200 lines of code for the daemon 1141158077 M * Hollow so, i don't see the need to use another 10k lib for rpc 1141158107 M * Hollow s/daemon/parsing/ 1141158217 M * bonbons yep, that's the way I work too, when I have a service that offers a few basic ops, it just offers kind of command-line-interface trhough some kind of socket 1141158222 M * daniel_hozac i'm a big fan of NIH creations too. 1141158230 M * Hollow nih? 1141158234 M * daniel_hozac not invented here. 1141158250 M * daniel_hozac but for things like RPC, using existing things makes sense. 1141158303 M * Hollow another thing is dietlibc.. we have to build all libs on our own, we canÄt use existing libs compiled against glibc that easy 1141158328 M * Hollow or we'd have to punt dietlibc 1141158336 M * daniel_hozac hmm, yeah, true. 1141158426 M * Hollow that's also the reason why i created a lib with all that helper stuff instead of including tens of other libs in the surce 1141158453 M * Hollow just pick the functions needed and put them together 1141158468 M * Hollow makes dietlibc happy :P 1141158495 M * daniel_hozac hehe. 1141158512 Q * Doener Ping timeout: 480 seconds 1141158590 M * Hollow bonbons: btw.. i also added support for global config files to vc_cfg* so we can really set all configuration via vce/vcd whatever now 1141158645 M * bonbons global config files, what does "global" mean exactly? 1141158664 M * Hollow e.g. te default fstab, or the list of files to be unhided in /proc 1141158719 M * bonbons ok, global config = centralized config information 1141158720 M * Hollow if you don't specify a name (i.e. NULL) to the vc_cfg functions, you can operate on global config files 1141158741 M * Hollow e.g. the key procfs.unhide points to the config file for /proc 1141158764 M * bonbons is it one file per key, or how is information organized? 1141158778 M * Hollow yeah, every key is one file 1141158804 M * Hollow there was a mapping between keys and files, but i removed it, it's just useless overhead, and teh files are named like the keys 1141158840 M * Hollow i.e. /etc/vservers/procfs.unhide 1141158852 M * Hollow or /etc/vservers/test/vx.id 1141158862 M * Hollow the former = global 1141158866 M * Hollow the later = local 1141158938 M * Hollow and, since guest names should not contain a dot there can be no collisions between global keys and local dir names, because every key has a dot 1141158969 M * Hollow i should c&p that into some doc.txt :P 1141159202 M * bonbons I'm not so sure the one file per key is a good solution... 1141159247 M * Hollow i know.. it's util-vserver like ;) 1141159321 M * Hollow what would you prefer? 1141159326 M * bonbons Not because it's like this or that, but more for the overview + performance, 1-file config is slow if only 1 value is needed, but in case of daemon all/most values are needed 1141159399 M * bonbons I would prefer 1 file per group: "default", and one per "guest" which overrides default, optionaly with hierarchy (e.g group overrides default, guest overrides group) 1141159475 M * Hollow but it's harder to parse.. you have to introduce some format how values are stored for a specific group of keys and such things 1141159516 M * Hollow and the dependency tracking has to be included in the format as well (which could be handled like the gentoo profiles do it otherwsie) 1141159528 M * Hollow parent file with path 1141159545 M * Hollow so we could create stackable configs 1141159590 M * Hollow and imo the keys are so few and value of the keys os also pretty low, i don't think there's a impact we should worry about.. 1141159731 M * bonbons just keep that option in mind, so hide all the backend behind a nice header so it can be exchanged :) 1141159841 M * Hollow well, the list of valid keys can easily be obtained, and with the vc_cfg functions or the SET/GET functions of vcd the stuff if pretty good hidden imo, no? 1141159923 M * Hollow but i still like the idea of stackable profiles... i'll try to implement it tomorrow 1141159930 M * Hollow s/profiles/configs/ 1141160065 M * bonbons Hollow: libvserver[trunk] does not compile... 1141160088 M * bonbons fails on unknown 'flagsword' in network.c 1141160105 M * bonbons fails on unknown 'flagsword' in network.c (line 55) 1141160199 M * Hollow ah yeah.. sec 1141160234 M * Hollow fixed 1141160257 M * Hollow hm.. guess i'll order the new mac mini :) 1141160317 M * bonbons What features does it have? PPC or Centrino Signel/Duo? 1141160395 M * Hollow single or duo 1141160414 M * Hollow with front row :) 1141160783 Q * fwl Quit: This computer has gone to sleep 1141160965 M * daniel_hozac who buys a 32-bit computer in this day and age? :) 1141160987 M * mnemoc me :( 1141161022 M * mnemoc in fact i bought 6 pentium2 machines yesterday 1141161031 M * waldi why? 1141161045 M * mnemoc for the office where i work 1141161050 M * daniel_hozac i meant new. 1141161062 M * waldi daniel_hozac: notebooks 1141161080 M * bonbons daniel_hozac: my next should be a low-power 64bit one, probably the next turion, but I think AMD is just taking much to long to release their CPUs... 1141161103 M * daniel_hozac bonbons: you'd prefer public betas when it comes to processors? 1141161121 J * fwl ~fwl@83-215-237-1.seek.stat.salzburg-online.at 1141161159 M * bonbons daniel_hozac: nope, but as they show test-samples already half a year or even a year in advance... 1141161590 J * Aiken ~james@tooax6-149.dialup.optusnet.com.au 1141162956 J * FireEgl Atlantica@Atlantica.DollarDNS.Net 1141163006 P * meandtheshell 1141163336 M * bonbons Hollow: where does libvserver-1.0.2 implement sys_clone()? That part is no more in trunk... 1141163355 M * Hollow i moved it to lucid 1141163371 M * Hollow but trunk will be 1.1 1141163480 M * mugwump hey, ebiederm_oO, I see you got your procfs patch in -mm! nice work 1141164475 Q * fh Quit: changing servers 1141164651 J * mauro ~mauluz@host26-180.pool870.interbusiness.it 1141164745 J * fh ~oftc@cheeto.net 1141165366 Q * fwl Quit: This computer has gone to sleep 1141166253 M * bonbons Bertl_oO: with 2.6.16rc5-vs2.1.1rc10 I just checked if signals reach correct init - that's fine, rest of test will be for tomorrow... 1141166262 Q * bonbons Quit: Leaving 1141166414 N * Bertl_oO Bertl 1141166426 M * Bertl back now 1141166435 M * Bertl welcome mauro! 1141166458 M * mauro Bertl: thanks! 1141166639 M * waldi hi Bertl 1141167050 M * Bertl hey waldi! how's it going? 1141167068 M * waldi works 1141167076 M * waldi testme is green 1141167083 M * mauro Bertl: will you go to the cebit? 1141167109 M * Bertl unlikely 1141167164 Q * shuri_ Quit: Quitte 1141167366 M * comfrey geez i cant seem to get out via the network on a vserver on this one vserver instance 1141167410 M * comfrey i am natting it through 1141167448 Q * mauro Quit: bye bye! 1141167450 M * comfrey not sure where the issue is ... perhaps i will change it's internal ip 1141167464 J * mauro ~mauluz@host26-180.pool870.interbusiness.it 1141167536 M * comfrey that did it... hmm... 1141167714 Q * florolf Quit: 418, I'm a teapot. 1141168216 Q * matta Ping timeout: 480 seconds 1141168449 Q * brc Quit: No windows for this server 1141169051 Q * shedi Ping timeout: 480 seconds 1141170262 Q * mauro Quit: bye bye! 1141170622 J * shedi ~siggi@dsl-220-183.hive.is