1141257762 J * dos000 ~dos000@wsp05974758wss.cr.net.cable.rogers.com
1141257844 M * dos000 howdy .. OMG .. i see there is good list of ppl nowadays. this room used to be much less not long ago
1141257876 M * dos000 i stoped a vserver from completing .. now i can't recreate a vserver with the same name. any idea what i should delete to get it going ?
1141258047 M * dos000 the vserver was getting built via dbootstrap. also i tried remving /etc/vserver/<name> and /opt/vserver/<name> but no help
1141258048 Q * jeeves Read error: Connection reset by peer
1141258338 M * Doener dos000: what error message do you get?
1141258708 Q * matta Ping timeout: 480 seconds
1141258856 M * dos000 Doener, /lib/util-vserver/vserver-build: line 206: -n: command not found
1141258869 M * Doener hmm
1141258925 M * Doener which util-vserver version is that?
1141258928 M * dos000 i have vutils 0.30.210 and vserver 2.1.0
1141258989 M * dos000 Doener, is there a lock in /tmp or var that is preventing this ?
1141259053 M * Doener I don't even have 206 lines in vserver-build...
1141259090 M * dos000 i did bash -x to execute it
1141259094 M * Doener anyway, there are some files in /var/run/vservers{,.rev}
1141259121 M * Doener checking if the context is still running might also be worth a try
1141259155 M * dos000 Doener, i stoped it before it pass debootstrap
1141259198 M * Doener maybe something decided to stay around?
1141259253 M * dos000 yea .. but what is it ! could it be debootstrap ?
1141259335 M * Doener well, what does vserver-stat say?
1141259420 M * dos000 CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
1141259420 M * dos000 0       36  48.7M  14.4M   0m09s11   0m02s37   2h26m10 root server
1141259475 Q * mkhl Quit: 
1141259545 M * dos000 ok .. it looks like i did not remove it at all from /etc/vserver/<name> but that error was crazy weird
1141259555 N * Bertl_zZ Bertl
1141259562 M * Bertl ahh, much better ... :)
1141259657 M * Bertl hey mugwump! why did thou bah?
1141259751 M * Bertl dos000: yes, that error keeps pooping up lately
1141259806 M * Bertl Doener: no idea where it comes from, last person reporting it had a separate LVM volume and was getting this too, switched to a new name and it 'suddenly' worked
1141260008 Q * FireEgl Ping timeout: 480 seconds
1141260029 M * dos000 wait it says something about /etc/vservers/.defaults/vdirbase/svj/var
1141260044 M * dos000 it keeps getting recreated
1141260070 M * dos000 btw this is what i use to create the guest ...
1141260085 M * dos000 vserver $VHOST build -m debootstrap -n $VHOST --hostname $VHOST --interface $IFACE:$VADDRESS/24 -- -d sarge -m $MIRROR -- --exclude=$REMOVE_PACKAGES
1141260120 M * Bertl ARGH!
1141260128 M * Bertl where does that line/ide come from?
1141260147 M * dos000 prolly from the step by step guide
1141260148 M * Bertl the '-n $VHOST' is wrong! it does not belong there IMHO
1141260149 J * matta ~matta@71.224.125.126
1141260176 M * dos000 ah !
1141260179 M * Bertl dos000: please point me to this example/howto!
1141260189 M * dos000 ok .. lemme try to find it
1141260195 M * Bertl (so that we can fix it up)
1141260263 J * FireEgl Atlantica@Atlantica.CJB.Net
1141260278 M * Bertl wb matta! FireEgl!
1141260285 M * FireEgl =)
1141260324 M * FireEgl You're like the friendliest guy on IRC Bertl. =)
1141260338 M * dos000 i would second that 
1141260535 M * Bertl well thanks, trying to help where possible ...
1141260698 M * Bertl (but I guess you folks were more referring to the greetings :)
1141261294 M * dos000 anyone has pointers to guest images for for latest fedora or centos ?
1141261295 J * Aiken ~james@tooax6-180.dialup.optusnet.com.au
1141261353 M * dos000 i am on debian .. i  am not sure you can do cross distribution guest but http://www.marlow.dk/site.php/tech/vserver got me thinking
1141261453 Q * gerrit Ping timeout: 480 seconds
1141261495 M * Bertl the guest distro does not depend on the host distro
1141261512 M * Bertl just debian makes it hard (somewhat impossible) to net-install rpm based distros
1141261617 M * anonc http://rpmstrap.pimpscript.net/
1141261633 M * Bertl anonc: yeah, know that, but there is no tool support yet
1141261700 M * anonc Bertl: fair enough
1141261812 M * dos000 what about the kernel ... does running the latest kernel unsures all the guests will work ?
1141261863 M * Bertl yep, as far as I know, all recent distros will work with 2.6 kernels, some really old (2.2 distros) will need some 'special' handling
1141261960 M * dos000 Bertl, what do you mean by tool support ? i mean rpmstrap needs a tool ?
1141261990 M * Bertl I'm talking about the 'vserver <name> build -m *' stuff
1141262023 M * Bertl i.e. if you use _whatever_ method to install a distro into a dir, you can use that for a Linux-VServer guest
1141262068 M * Bertl just create the config and skeleton with the skeleton build method and copy the dir (except for the proc, tmp and dev dirs) over to the skeleton
1141262271 M * Doener hm, how long should it take to change a password to a database once you know that you accidently made it public (incl. username)?
1141262324 M * Bertl roughly 3 seconds, except for mysql, there it will take 2 minutes :)
1141262403 M * Bertl Doener: why?
1141262463 M * Doener i told some company about just that, 10 hours ago... download still contains the user data and mysql server is still reachable
1141262664 M * dos000 Doener, you should give them a time passed which you will make it public as well ;-)
1141262842 J * cemil ~cemil@defiant.wavecon.de
1141263145 Q * cemil Remote host closed the connection
1141263472 M * dos000 i still gat the line 206 error ! 
1141263492 M * mugwump Bertl: hey there ... I was just doing some more work on developing the "vfs cleanup" patch.  should have something in an hour or two...
1141263574 M * Bertl mugwump: excellent, what is your opinion on Trond's veto?
1141263603 M * mugwump he only vetoed removing the lookup info ... just replied
1141263611 M * Bertl ah, reading up ...
1141263617 M * mugwump lookup "intent", which just needs a few bits
1141263644 M * Bertl already thought about that dummy/fake nd
1141263657 M * Bertl but I would like to avoid that at all costs for several reasons
1141263669 M * mugwump 1. it's a bunch of arse
1141263673 M * mugwump 2. ?? :)
1141263676 M * Bertl a) it does not contain the flags at all
1141263692 M * Bertl b) it might cause funny results at lower levels
1141263723 M * Bertl but the issue is, he vetoed to have a vfs_permission at all
1141263735 M * mugwump I missed that one
1141263753 M * Bertl "Redundant RPC calls have performance costs to the client"
1141263788 M * mugwump yes, he's vetoing removing the intent bits from the path, I think.  Not necessarily removing nameidata
1141263812 M * Bertl so, I read that as: we need that info in permission, as we do not want to have permission _and_ vfs_permission
1141263840 M * Bertl but I asked myself, if it isn't just vfs_permission what the nfs is looking for
1141264797 J * mkhl mkhl@200-148-41-49.dsl.telesp.net.br
1141265113 M * Doener i'm off to bed, good night!
1141265116 Q * Doener Quit: Leaving
1141265381 J * cemil ~cemil@defiant.wavecon.de
1141266015 Q * cemil Read error: Connection reset by peer
1141266550 M * dos000 it looks that line 206 was coming from the fact that i was creating a /home/vserver/<name>//var/cache/apt/archives before creating vserver with debootstrap
1141266571 M * dos000 whithout double slashes
1141266613 M * dos000 wonder why it cares .. i was trying to speed up the build so it will fetch the debs from the local archives
1141266643 M * Bertl i.c. well I guess it's some kind of bug, could you please report it on savannah?
1141266658 M * Bertl and, did you find where you got the -n option from?
1141266672 M * dos000 no .. just how to reproduce it
1141266745 M * Bertl ah well, at least something :)
1141267439 J * cemil ~cemil@defiant.wavecon.de
1141267556 M * Bertl wb cemil!
1141268281 Q * mkhl Quit: 
1141269115 Q * _mountie Ping timeout: 480 seconds
1141269145 Q * cemil Remote host closed the connection
1141269167 J * cemil ~cemil@defiant.wavecon.de
1141269295 J * _mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1141269932 Q * Aiken Read error: Connection reset by peer
1141270014 J * Aiken ~james@tooax6-180.dialup.optusnet.com.au
1141272819 M * mugwump Bertl: so, Trond seems to be ok with the idea, if it's an extra param and not just stuffed in the mask :)
1141272846 M * mugwump Except, perhaps not for access()
1141272847 M * mugwump hmm
1141272851 M * Bertl well, yeah, but we really don't want to pass nd info down (ultimately)
1141272876 M * Bertl IMHO permission() is inode based, no path there ...
1141272904 M * Bertl and as we see, 99% of the filesystems use it this way
1141272943 M * mugwump so, Trond is the NFS maintainer
1141272948 M * Bertl yep
1141272972 M * Bertl and he (basically) introduced the nd passing to permission some time ago
1141272989 M * Bertl which IMHO was and still is a hack
1141273057 Q * FireEgl Ping timeout: 480 seconds
1141273122 Q * cemil Remote host closed the connection
1141273749 Q * mnemoc Ping timeout: 480 seconds
1141274566 J * arnaud` ~arnaud@d213-103-193-46.cust.tele2.fr
1141274874 Q * al_ Ping timeout: 480 seconds
1141275663 J * FireEgl Atlantica@Atlantica.DollarDNS.Net
1141275884 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1141276605 J * f__ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141276642 Q * f__ Quit: 
1141276859 J * f__ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141277000 J * Hmmmm ~Hmmmm@221.135.51.19
1141277564 Q * matta Ping timeout: 480 seconds
1141278317 Q * comfrey Quit: Ex-Chat
1141278610 M * ebiederm Interesting shake out of the permission infrastructure.
1141278634 J * f_ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141278639 Q * f__ Read error: Connection reset by peer
1141278671 M * ebiederm Bertl mugwump  do you understand the RPC call issue that intents are designed to avoid?
1141278677 M * mugwump not really
1141278713 M * mugwump I think he's trying to avoid going through calling permission() twice or something like that
1141278736 M * ebiederm Well I only have the 10,000 foot view not the implementation experience but I think I can help.
1141278771 M * ebiederm lookup (which ultimately calls permission) is a helper function that is not directly exported from the kernel.
1141278834 M * ebiederm Lookup is called from open, stat, mknod and a few other systems calls.
1141278887 M * ebiederm If the lookup succeeds if the syscall is something like create it fails.  Otherwise the rest of the create operations happens.
1141278949 M * ebiederm On many network filesystems the exported operations more closely resemble the unix syscall interface and not the internal vfs implementation.
1141278976 M * ebiederm So you can do things like create in one RPC call instead of a lookup and then a create RPC call.
1141279015 M * ebiederm The purpose of the intent data is to allow network filesystems to do everything at create time.
1141279032 M * ebiederm err.  lookup time.
1141279060 M * ebiederm Allowing the other call in the vfs that does the rest of the create or whatever to be discared.
1141279120 M * ebiederm Does that help?
1141279162 M * mugwump that does clarify things a bit, yes
1141279246 M * mugwump I don't agree with the assertion that "the intent is nothing like a mask"
1141279309 M * Bertl ebiederm: wouldn't it be _much_ better to have some kind of vfs_permission() for checking at vfs layer, and a permission() which does the checks on inode layer?
1141279352 M * Bertl (the vfs_permission would have the required information)
1141279435 Q * f_ Quit: This computer has gone to sleep
1141279518 M * ebiederm The hard part is that with a newtork filesystem the filesystem server is has to do some of the permission checks.
1141279529 M * ebiederm So we can't do everything at the VFS level.
1141279564 M * mugwump also confusing things, is that NFS exports filesystems directly, not a VFS
1141279590 M * mugwump so, the protocol/client expects it to be just one FS
1141279605 M * ebiederm Looking at the intents, and permission.  It looks like the access syscall it what is being optimized.
1141279607 M * mugwump hence the convention of a /exports mount in the old days
1141279626 M * mugwump access = the (3) that Trond refers to
1141279761 M * ebiederm So it looks like the LOOKUP_ACCESS intent saves RPC calls when sys_access is called.
1141279835 M * ebiederm Bertl: I can see having a common code path possibly vfs_permission.  So long as there is a provision to allow network filesystems to do all of their work in one shot.
1141279888 M * Bertl well, let me put it this way ... I would suggest something like this:
1141279929 M * Bertl - have a wossname_permission(dentry, vfsmnt, mask) in _addition_ to the permission(inode, mask) 
1141279967 M * Bertl - if we are doing vfs stuff, i.e. vfs_permission() or file_permission(), and ->wossname_permission() is defined, call it
1141279979 M * Bertl - otherwise fall back to permission()
1141280003 M * Bertl - for the inode case (permission) just call ->permission() directly
1141280006 M * ebiederm mugwump:  The meaning was that the intent bits are defined separatly from the permission mask bits.  (So mixing them can get you into truble if you don't take a lot of care) 
1141280024 M * Bertl - for 90% of the existing filesystems, wossname_permission will be null
1141280095 M * ebiederm How is permission currently called?
1141280112 M * Bertl permission(inode, mask, nd)
1141280121 M * Bertl nd is in 95% NULL
1141280140 M * ebiederm Let me give an example and reask.
1141280151 Q * djudko Ping timeout: 480 seconds
1141280161 Q * djudko_ Ping timeout: 480 seconds
1141280167 J * djudko ~davej@bi01p1.nc.us.ibm.com
1141280178 J * djudko_ ~davej@bi01p1.nc.us.ibm.com
1141280201 M * ebiederm Currently for create we call into lookup with nameidata, (using the LOOKUP_CREATE intent).
1141280223 M * ebiederm If nameidata comes back filled out we skip the rest of the create steps.
1141280240 M * ebiederm If nameidata isn't filled out we do create the normal vfs way.
1141280278 M * ebiederm So for permission who calles it, and is there a path we can add that will allow us to skip most of the work?
1141280365 M * ebiederm As for a read only bit at the VFS level we should be able to test that before we call lookup or permission or any of the rest shouldn't we?  Because we know which mount point we are at?
1141280458 M * mugwump ok, so the nameidata isn't an INPUT but an OUTPUT parameter :)
1141280465 M * mugwump Love C
1141280473 M * Bertl no, definitely not
1141280488 M * Bertl lets follow a sys_create() shall we?
1141280496 M * mugwump or, rather, the intent is an input parameter, and the nameidata is output
1141280512 M * Bertl well, sys_mknod for example
1141280523 M * ebiederm mugwump: the intent of the nameidata is the output.
1141280531 M * ebiederm Ok.
1141280545 M * Bertl error = do_path_lookup(dfd, tmp, LOOKUP_PARENT, &nd);
1141280549 M * Bertl dentry = lookup_create(&nd, 0);
1141280561 M * Bertl (here nd is the output)
1141280587 M * Bertl -> lookup_hash()
1141280640 J * matta ~matta@71.224.125.126
1141280675 M * Bertl err = permission(inode, MAY_EXEC, nd);
1141280691 M * Bertl so, this will pass the nd_flags down
1141280731 M * Bertl and it would be replace by wossname_permission(dentry, vfsmnt, MAY_EXEC)
1141280735 M * Bertl *replaced
1141280786 M * Bertl I do not suppose the permission() will fill in the nd?
1141280811 M * Bertl (at least that would be the strangest api I've ever seen)
1141280842 M * ebiederm Digesting...
1141281118 M * ebiederm Ok.  The sys_mknod path needs work before it leverages intents.
1141281127 M * ebiederm sys_open O_CREATE doesn't.
1141281156 M * ebiederm However let's trace access.  the ACCESS intent.  I think that is closer to where we have problems with your approach.
1141281350 M * mugwump ouch, that syscall changes the uid/gid!
1141281388 M * mugwump anyway
1141281484 Q * matta Ping timeout: 480 seconds
1141281484 J * f_ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141281537 M * ebiederm I can see where the mess is because after doing the lookup we do an additional vfs_permission call.
1141281646 M * ebiederm However since nd is passed through I suspect a smart filesystem can skip the ->permission check.
1141281676 M * ebiederm What is the problem with modifying permission in namei.c?
1141281691 M * Bertl modify it how?
1141281720 M * mugwump http://xrl.us/j8cu, message 13
1141281804 M * ebiederm if (nd->mnt->mnt_flags & MNT_RDONLY) return -EROFS.
1141281821 M * mugwump "We need to
1141281822 M * mugwump split the "am I allowed to write to the fs" part out of permission()."
1141281832 M * Bertl ebiederm: are you kidding me?
1141281834 M * ebiederm why?
1141281838 M * ebiederm What is the problem?
1141281850 M * Bertl ebiederm: that is what I am suggesting for more than a year now
1141281872 M * ebiederm Does permission ever get called with a null nameidata?
1141281892 M * Bertl ebiederm: but Viro and HCH keep giving oracle style replies
1141281899 M * mugwump lots, especially from nfsd ;)
1141281906 M * Bertl ebiederm: permission() is called very often without nd
1141281932 M * ebiederm Ok.  so the test on the appripriate path simply becomes if (nd && nd->mnt->mnt_flags).
1141282009 M * ebiederm Looking up the reference you gave to previous conversations so I can see if I can understand the objections.
1141282232 M * mugwump Maybe Christoph refers to this: http://xrl.us/j9kx, message 17
1141282320 M * Bertl well, if you are talking about the 'upstream' part
1141282333 M * Bertl that is something which cannot be done without changing semantics
1141282425 M * Bertl (i.e. I already moved the checks up as far as possible, as Viro requested that)
1141282454 Q * f_ Quit: This computer has gone to sleep
1141282580 M * ebiederm I'm getting there.
1141282629 J * f_ ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141282648 M * ebiederm So far I am not seeing arguing against this just arguing for doing it very carefully.
1141282663 J * dothebart ~willi@xdsl-81-173-171-19.netcologne.de
1141282701 M * ebiederm The intent stuff really does play havoc with these checks though.
1141282742 M * mugwump Can't we just break that to make the code nicer to play with, then fix it at the end?
1141282758 M * ebiederm In the case where the filesystems do everything in their lookup method...
1141282769 M * ebiederm Hmmm.
1141282916 M * mugwump message 21 in that last thread I posted is certainly the one
1141282917 M * Hollow morning
1141282922 M * mugwump hi Hollow 
1141282969 M * mugwump Now I think I understand the “Once we're at it we can pair it with the "don't need to write to fs anymore"  even and get saner unmount/remount semantics. ”
1141282989 M * mugwump that comment confused the hell out of me :)
1141283049 Q * djudko Read error: Operation timed out
1141283059 J * djudko ~davej@129.33.1.37
1141283094 Q * tudenbart Ping timeout: 480 seconds
1141283137 M * mugwump "Doing that in one or even
1141283137 M * mugwump 3-4 patches would be insane even in 2.7; in 2.6 it's so out of question
1141283138 M * mugwump that it's not even funny. "
1141283160 M * Bertl interesting, it seems I never received that reply
1141283164 M * ebiederm So I see a couple of concernts.
1141283213 M * ebiederm 1) things the state of the MS_RDONLY flag changing under us during the call.
1141283222 M * ebiederm 2) Where to put the call.
1141283230 M * ebiederm Then I have my thoughts.
1141283242 Q * djudko_ Ping timeout: 480 seconds
1141283269 J * djudko_ ~davej@129.33.1.37
1141283274 M * ebiederm If sys_mknod is any example.  We tend to call lookup_parent, or something similar before we do any actual work.
1141283341 M * ebiederm So it looks like with some care we can test if the mount is read only before we ever do a lookup on that file.
1141283352 M * ebiederm Which prevents problems with dealing with intents that might create files.
1141283396 M * Bertl I'm fine with that, but it is unrelated to fixing --bind mounts, no?
1141283430 M * ebiederm And while we are at it moving the IS_RDONLY(inode) up make make some sense as wel.
1141283476 M * ebiederm Bertl: We have fs intents that will create files.
1141283561 M * ebiederm Basically It looks like we need to do the read only permission checks earlier than the current call to vfs_permission in the vfs.
1141283647 M * ebiederm I think Als point was something like if we have to change the VFS and move data around.  Let's change it to put the permission checks where they need to be.
1141283677 M * mugwump So, basically they're vetoing our patch until we clean up nearby turds
1141283691 M * ebiederm And placing the check right after LOOKUP_PARENT but before the create looks decidedly easy.
1141283694 M * Bertl ebiederm: well, then he pretty much failed to make that point :)
1141283849 M * ebiederm I think he was making two points at once.
1141283886 M * ebiederm The other was that changing permission is dangerous because it has a lot of callers and they expect permission to do what it does now.
1141283917 M * ebiederm But I'm not certain that is what Al was saying so far I have just skimmed that thread.
1141283942 M * Bertl I think I'm going to wait a month or two until I'm sufficiently motivated to do trial and error patching in this area again ...
1141284017 M * Bertl BME works fine and is already part of devel and stable, so it does what I actually want
1141284118 M * ebiederm The other difference is that it feels like Al was reading that as disabling filesystem write access, and not disabling write access at the VFS layer.
1141284162 M * ebiederm Note that per-mountpoint r/o will take pretty much the same amount of work -
1141284162 M * ebiederm propagating vfsmounts down to the IS_RDONLY checks only to have that reverted
1141284162 M * ebiederm when we lift the checks up would mean doing more or less the same twice. 
1141284226 M * ebiederm I think those three lines are the point of move the read only checks up higher and earlier in the VFS not down lower.
1141284400 M * mugwump http://xrl.us/j9k6  # don't worry, the feature should be going in 2 years ago
1141284501 M * Bertl yeah, and HCH has also done it _again_ last month
1141284517 M * ebiederm Viro big concern earlier was to kill the remount read-only races.
1141284583 M * mugwump Well, I don't mind helping them with that.  
1141284607 M * mugwump You've given a lot of good guidance there ebiederm, thanks
1141284625 M * Bertl yeah, oracle interpretation is always appreciated
1141284673 M * mugwump I wonder what happened to that e-mail.  Lost in the æther, I suppose
1141284713 M * ebiederm I'd volunteer to just do it.  But I have a few higher priorities.
1141284744 M * mugwump the vpid stuff?
1141284773 M * ebiederm mugwump: All of the namespaces.
1141284812 M * ebiederm I'm in the final stages of cleaning up /proc.  So I have a chance of making it workable.
1141284829 M * ebiederm The good news is my task_ref changes seem to be in -mm and working correctly now.
1141284852 M * ebiederm So I can go around killing uses if pids in the kernel, without any virtualization support merged.
1141284894 M * mugwump uses of pids I assume you mean
1141284905 M * ebiederm The debate for interfaces has moved to sysvipc patches, to avoid the deadlock on pspaces vs vpids :)
1141284913 M * ebiederm Yes uses of pids.
1141284988 M * mugwump ok, well then what I might do is save this IRClog for later reference, then polish up the simplified vserver patch (http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=shortlog;h=2.6.16-rc4-vsi)
1141285016 M * mugwump then go back and attack these VFS races
1141285035 M * ebiederm Among other things I have killed proc_lock in the task_struct. :)
1141285066 M * ebiederm Oh.  Question you might be able to help me brainstorm on.
1141285089 M * ebiederm What the heck access permissions should we have on /proc/<pid>/fd/<fd#> ?
1141285142 M * mugwump well, I'd expect /proc/<pid>/fd to be 700
1141285148 M * ebiederm Currently there is the uid must match the task uid unless CAP_DAC_OVERRIDE.
1141285168 M * ebiederm mugwump:  So that much is covered.
1141285189 M * mugwump /proc/<pid>/fd/<fd#>, well, I guess it would be the permissions of the 'actual' file.  Does that exist?
1141285201 M * ebiederm Yes we have that as well.
1141285220 M * ebiederm The question is what to do when the file is in another filesystem namespace.
1141285264 M * ebiederm mugwump: It works like a symlink so we should always get the inode permission checks.
1141285274 J * Viper0482 ~Viper0482@p54977161.dip.t-dialin.net
1141285306 M * mugwump oh, right, I see
1141285326 M * mugwump it's OK for it to be dangling, isn't it?  :)
1141285350 M * ebiederm mugwump: The kernel magically ties up the ends.
1141285375 M * ebiederm But we can return -EACCESS easily enough.
1141285379 M * mugwump ok, so when you stat or open it, you can teleport to the other namespace?
1141285390 M * ebiederm mugwump: You got it.
1141285401 M * ebiederm Although only for that file handle.
1141285413 M * mugwump but you can always sys_openat(fd, ...)
1141285449 M * mugwump heh, that's a nice way to escape namespace
1141285451 M * ebiederm Hmm.  That certainly works if it is a directory.  And older kernels give you fchdir().
1141285491 M * phreak`` morning Bertl, ebiederm, mugwump :)
1141285498 M * Bertl morning phreak``!
1141285549 M * ebiederm mugwump: There was a check in there to test if you were in the same or an outer chroot of the process (added before namespaces) to prevent this.  But it checked the processes and not the actual files.
1141285632 M * ebiederm So having a file open from before starting a chroot or a file that crosses namespaces gives processes with your uid the ability to escape.
1141285668 M * ebiederm Does vserver compltely kill the proc_check_chroot check?
1141285686 M * Bertl not completely, but almost
1141285695 J * matta ~matta@71.224.125.126
1141285723 M * ebiederm Bertl: Since you are being quite can you point me to the patch and I can compare notes?
1141285755 M * ebiederm Basically the /proc/<pid>/fd/<fd#> symlinks are the only cases where that test should matter..
1141285785 M * ebiederm Err makes any sense at all.
1141285797 M * ebiederm I have killed all other instances in -mm already. :)
1141285812 M * mugwump ebiederm: http://vserver.utsl.gen.nz/gitweb/?p=vserver.git;a=commitdiff;h=5bb91d60e6c89c1e8c3470c7339395c03232e12e
1141285838 M * mugwump that's from Bertl's 05_proc.diff, the -rc8 set
1141285844 M * mugwump er, 2.1.1-rc8 :)
1141285976 M * ebiederm Hmm.  I see that change but I don't see where the calls are removed, and I have yet to figure out the vserver diff release process yet.
1141285982 M * Bertl http://vserver.13thfloor.at/Experimental/split-2.6.16-rc4-vs2.1.1-rcX/06_proc.diff
1141286003 M * Bertl search for: proc_check_chroot
1141286015 M * Bertl it is the only relevant change
1141286035 J * phreak``_ ~phreak``@styx.xnull.de
1141286054 M * ebiederm Interesting I don't see any of the calls being removed?
1141286082 M * Bertl no, why would we?
1141286145 M * mugwump rightio, I'm off - catch you guys tomorrow!
1141286149 Q * phreak`` Ping timeout: 480 seconds
1141286164 A * mugwump waves &
1141286168 M * Bertl ebiederm: the check doesn't give any issues unless you are working _across_ contexts, e.g. from the spectator context
1141286172 M * Bertl mugwump: cya!
1141286202 M * ebiederm Bertl: Right it is fine except for exactly the case it applies to :)
1141286266 M * ebiederm What do you need it relaxed for in a spectator context?
1141286283 M * Bertl lsof for example
1141286323 M * ebiederm Ok.  That makes some sense.
1141286334 M * Bertl tx :)
1141286428 M * ebiederm So it looks like the two big users to worry about are lsof and fuser.
1141286447 M * ebiederm While at the same time not allowing leaks across contexts.
1141286468 M * Hollow FYI: there is an article about virtualization (including gentoo vserver) in the current (german) linux magazin
1141286530 M * ebiederm I wonder what interesting things I can do with the mount hash table.
1141286549 Q * yang Ping timeout: 480 seconds
1141286587 M * ebiederm Bertl: fixing that check gets even more interesting when it is applied properly to the file the fd is pointing at and not at the process.
1141286686 M * ebiederm Bertl: I fixed the check so it checks that the file is in your current chroot in -mm and people are now complaining. :)
1141286838 M * ebiederm Anyway Bertl have a good night.
1141286843 N * ebiederm ebiederm_zZ
1141286994 Q * gerrit Ping timeout: 480 seconds
1141287448 J * Smutje_ ~Smutje@xdsl-84-44-186-65.netcologne.de
1141287524 Q * f_ Quit: This computer has gone to sleep
1141287589 Q * Smutje Ping timeout: 480 seconds
1141287589 N * Smutje_ Smutje
1141287839 J * ||Cobra|| ~cob@146.50.22.204
1141287920 Q * matta Ping timeout: 480 seconds
1141288114 A * ||Cobra|| yop
1141288130 M * Bertl welcome ||Cobra||!
1141288139 M * ||Cobra|| hi Bertl 
1141288483 J * f_ ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141289803 J * VxJasonxV[A] ~jason@ip68-110-115-17.ph.ph.cox.net
1141290039 J * matta ~matta@71.224.125.126
1141290164 Q * VxJasonxV Ping timeout: 480 seconds
1141291484 Q * matta Ping timeout: 480 seconds
1141291560 Q * f_ Quit: This computer has gone to sleep
1141291821 M * Bertl k, off to bed now .. back later ...
1141291829 N * Bertl Bertl_zZ
1141292884 J * f_ ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141293069 Q * Hmmmm Quit: Ex-Chat
1141294380 J * matta ~matta@71.224.125.126
1141295317 J * jrc ~jrc@cpe.atm2-0-1051059.0x50a09f6a.bynxx11.customer.tele.dk
1141295321 N * jrc Wenix
1141295927 J * matt1 ~matta@71.224.125.126
1141296245 Q * matta Ping timeout: 480 seconds
1141296863 M * RoadRunnR hi all, i've added http://linux-vserver.org/SuseVserverHowTo to the Wiki, someone runnig a SuSE guest might want to review and add ....
1141297089 Q * Aiken Ping timeout: 480 seconds
1141297293 J * matta ~matta@71.224.125.126
1141297534 Q * f_ Quit: Leaving
1141297550 Q * matt1 Ping timeout: 480 seconds
1141299351 J * matt1 ~matta@71.224.125.126
1141299518 Q * matta Ping timeout: 480 seconds
1141299641 J * al_ ~arnaud@d213-103-26-184.cust.tele2.fr
1141299849 Q * arnaud` Ping timeout: 480 seconds
1141300179 Q * Hollow Ping timeout: 480 seconds
1141300555 Q * matt1 Ping timeout: 480 seconds
1141300609 J * Hollow ~hollow@home.xnull.de
1141300929 J * matta ~matta@71.224.125.126
1141300995 J * fwl ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141302010 Q * matta Ping timeout: 480 seconds
1141302869 J * matta ~matta@71.224.125.126
1141303387 Q * Hollow Remote host closed the connection
1141303395 J * Hollow ~hollow@home.xnull.de
1141304550 Q * matta Ping timeout: 480 seconds
1141304853 J * pflanze ~chris@84-73-63-56.dclient.hispeed.ch
1141304871 M * pflanze Hello
1141305200 J * matta ~matta@71.224.125.126
1141306820 J * matt1 ~matta@71.224.125.126
1141307117 J * Doener doener@i5387D439.versanet.de
1141307125 Q * matta Ping timeout: 480 seconds
1141307700 M * pflanze Does anyone understand namespaces or can point me to some docs?
1141307738 J * restill ~restill@c-24-11-171-10.hsd1.mi.comcast.net
1141307754 M * pflanze What I want to do is do a bind mount from the host into a running vserver.
1141307758 M * Doener pflanze: http://linux-vserver.org/Namespaces
1141307780 M * Doener you can't do bind mounts cross-namespace AFAIK
1141307813 M * Doener the new mount stuff in 2.6.15 should help though
1141307912 M * pflanze I'm running 2.6.15.4-vs2.0.2-rc5
1141307914 M * Hollow hm..
1141307930 M * Hollow vnamespace -e <xid> -- mount ....
1141307937 M * Doener Hollow: you do remember the terms for the new mount stuff?
1141307952 M * Doener Hollow: can't do a bind mount for new mounts with that
1141307969 A * pflanze checks..
1141307972 M * Doener oh well, for 'old' mounts it works... should've asked for that...
1141308008 J * Ne0 ~Ne0@gprs-pool-1-029.eplus-online.de
1141308044 M * Hollow Doener: http://phpfi.com/105165
1141308062 M * Hollow what are new mounts?
1141308074 M * Doener mounts created after the vserver was started
1141308094 M * Hollow ah.. well yeah
1141308102 M * Hollow you'd have to mount that in the namespace too
1141308140 M * Doener nothing you want to do for ext3 mounts with pflanze's kernel ;)
1141308275 J * asX ~LALA@L1413P01.dipool.highway.telekom.at
1141308308 M * Ne0 moo
1141308330 Q * asX Killed (FloodServ Warning, you have triggered a network protection. Stop flooding!)
1141308346 J * asX ~LALA@L1413P01.dipool.highway.telekom.at
1141308442 Q * Ne0 Killed (FloodServ Warning, you have triggered a network protection. Stop flooding!)
1141308495 Q * asX autokilled: Flooding the support channel..  Mail support@oftc.net if you feel this is in error
1141308528 M * pflanze ok cool, that's all I needed, at least right now, thanks.
1141308577 J * asX LALA@L1427P15.dipool.highway.telekom.at
1141308979 M * pflanze (hrm well I see, stuff mounted in the host context after the vserver startup can't be bind mounted. That would be about the next thing I wanted to do.)
1141309118 J * mnemoc ~amery@200.73.88.2
1141309134 Q * asX Quit: 
1141309285 Q * matt1 Ping timeout: 480 seconds
1141309550 M * harry should i put the vserver + grsec patch online ?
1141309560 M * harry as in, on vserver page?
1141309569 M * harry if yes: where?/how?
1141309609 M * mnemoc does it really work?
1141309655 M * mnemoc what about a grsec patch to apply over vserver?
1141309668 M * mnemoc instead of compound
1141309672 M * harry ?
1141309818 M * mnemoc ? to (1) or to (2) ?
1141309837 M * harry it works very well...
1141309845 M * harry so ? to 2 :)
1141310021 M * pflanze Doener: what's the issue with ext3?
1141310071 J * mkhl mkhl@200-153-181-60.dsl.telesp.net.br
1141310108 M * Doener mounting an ext3 fs in a namespace, will make it un-unmountable if all user processes in the namespace exit before the mount is unmounted
1141310133 M * Doener because the kjournald lives in that namespace and keeps it alive, but you loose access to the namespace
1141310134 M * mnemoc harry: by (2) i mean can you try to split your vserver+grsec patch to a grsec-for-vserver patch so we can easily try to apply it to newer vserver versions and easily update it to newer grsec versions?
1141310152 M * Doener pflanze: that is fixed in 2.6.16-rc5 and in more recent vserver patches
1141310183 M * Doener 2.0.2-rc6 to be exact
1141310190 M * pflanze ah, heh, thanks.
1141310191 M * Doener (and 2.1.1-rc7)
1141310203 M * harry mnemoc: think that will be quite hard
1141310216 M * harry since vserver changes a lot more than grsec
1141310246 M * mnemoc harry: but the 'conflict' places should be constant, or not?
1141310255 M * harry pretty constant, yes
1141310282 M * harry i should find a way to split them...
1141310321 M * harry hmm... come to think of it... not that hard
1141310419 M * mnemoc diffing trees could be easier
1141310420 Q * shedi Read error: Connection reset by peer
1141310509 M * harry mnemoc: the biggest problem is, i can only make grsec for vserver patches when grsec is applicable to that kernel
1141310510 M * mnemoc but there is 'interdiff' on diffutils
1141310557 M * mnemoc yes, and spender is not much fast releasing or open to open the development
1141310562 N * ebiederm_zZ ebiederm
1141310600 M * mnemoc he drops the cvs every random() days :\
1141310636 M * harry uhu
1141310777 M * mnemoc i want to move to rsbac, but i haven't had the time yet :\
1141310996 J * matta ~matta@c-68-32-239-173.hsd1.pa.comcast.net
1141311020 N * Bertl_zZ Bertl
1141311024 M * Bertl morning folks!
1141311034 M * harry hey Bertldude
1141311047 M * Bertl hey harrydude! :)
1141311344 J * shedi ~siggi@inferno.lhi.is
1141311351 M * Bertl wb shedi!
1141311390 M * Hollow hey dudes!
1141311393 M * Hollow ;)
1141311426 M * Hollow Bertl: any estimation for 2.0.2 final?
1141311472 M * Bertl haven't received any test reports for 2.0.2-rc* yet, so no idea :)
1141311472 Q * shedi Read error: Connection reset by peer
1141311538 M * Hollow ok, i'll do
1141311604 M * Bertl as usual, the folks will test when the release is there :)
1141311613 M * Hollow indeed
1141311620 M * SiD3WiNDR joel tests everything!
1141311620 M * Hollow should i sent the reports to the ML?
1141311628 M * SiD3WiNDR ;)
1141311656 M * Bertl Hollow: yes, please, but test with some guests too, just to make sure
1141311665 M * Hollow yup
1141311679 M * Bertl Hollow: and let me know what version of your tools is suited for the devel release
1141311706 M * Bertl (so that I can a) make a mandrake package, and b) upload them with the release)
1141311721 M * Hollow Bertl: bonbons is taking care of the 1.0.* branch, so have to wait for him if there are some outstanding bugs
1141311779 M * Hollow btw, there has been good progress for the C implementation of everything, i'm very confident on the next major branch (1.1)
1141312164 M * Bertl ah, okay, so I will bug him then ...
1141312401 M * restill Hey B.  
1141312422 M * restill went back to my old alias.  I was known as jeeves
1141312483 M * Bertl ah, wb restill, formerly known as jeeves, yet earlier known as restill :)
1141312499 M * restill lol, yea
1141312523 M * Bertl did too many folks ask you stuff as jeeves?
1141312540 M * Hollow jeeves: bug #18734
1141312542 M * Hollow *g*
1141312551 J * shedi ~siggi@inferno.lhi.is
1141312619 M * restill no, it is accually a flattering nick.  I was known in the office as the person to research stuff quickly on the net, but someone else also uses the nick and they have some shady habits.
1141312684 M * Hollow daniel_hozac: ping
1141312923 Q * mkhl Quit: 
1141312923 Q * shedi Read error: Connection reset by peer
1141313776 N * nokoya nokoyaz
1141313782 N * nokoyaz nokoya
1141313901 J * shedi ~siggi@inferno.lhi.is
1141314180 Q * shedi Read error: Connection reset by peer
1141314300 Q * fwl Quit: This computer has gone to sleep
1141314943 J * fwl ~fwl@83-215-237-2.seek.stat.salzburg-online.at
1141314952 J * shedi ~siggi@inferno.lhi.is
1141315389 Q * mef Ping timeout: 480 seconds
1141315507 M * Hollow Bertl: do i need something special for inode tagging?
1141315542 M * Hollow because the mount -o tagxid test fails
1141315551 M * Bertl is it enabled in the kernel?
1141315584 M * Hollow which option is it?
1141315598 M * Bertl one of the tagging options, sec
1141315612 M * Hollow CONFIG_TAGGING_ID24=y
1141315616 M * Bertl yup
1141315636 M * Bertl what does testme.sh (v15) report?
1141315648 M * Hollow all success
1141315702 M * Bertl yeah, fine *G* but as you know, I'm more interested in the info lines :)
1141315717 M * Bertl btw, you are testing 2.0.x? because there the tagging is:
1141315723 M * Bertl CONFIG_INOXID_UGID24=y
1141315753 M * Hollow currently 2.1, 2.0 is in the queue ;)
1141315759 M * Bertl k :)
1141315765 M * Hollow but hm.. with -v it reports, can't find /dev/data/test in fstab
1141315769 M * Hollow i'll try to add it
1141315825 M * Hollow ok, works
1141315829 M * Bertl great!
1141316845 P * restill Gotta do some work
1141317137 J * stefani ~stefani@superquan.apl.washington.edu
1141317142 M * daniel_hozac Hollow: pong
1141317158 M * Bertl hey daniel_hozac!
1141317161 M * Bertl welcome stefani!
1141317174 M * daniel_hozac hey Bertl!
1141317250 M * stefani hola 
1141317357 Q * fwl Ping timeout: 480 seconds
1141317358 J * f_ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141317571 M * ebiederm Yeah!  I finally figured out the sane set of permission checks to use on /proc/<pid>/fd symlinks.
1141317590 M * ebiederm ptrace_may_attach!
1141317631 M * Bertl excellent!
1141317780 M * harry open("defer", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 EACCES (Permission denied)
1141317783 M * harry write(2, "postsuper: fatal: scan_dir_push:"..., 73postsuper: fatal: scan_dir_push: open directory defer: Permission denied
1141317786 M * harry anyone?
1141317796 M * harry (when i start postfix in a vserver
1141317893 M * harry apt-get install --reinstall postfix gives some hostname Unknown host
1141317897 M * harry and  error setting permissions of `./usr/sbin/postdrop': Operation not permitted
1141317981 M * Bertl are you using tagxid?
1141317989 M * harry nooooooooooo idea
1141318003 M * Bertl okay, please upload the output of testme.sh somewhere
1141318016 A * harry looks for testme.sh... brb
1141318018 M * daniel_hozac disabled grsec? :)
1141318034 M * harry all succeeded
1141318046 M * Bertl okay, please upload the output of testme.sh somewhere :)
1141318060 M * harry http://pastebin.com/580358
1141318144 M * Bertl okay, you are sure you are not observing a grsec and/or grsec+vserver issue?
1141318152 M * harry no :)
1141318168 M * Bertl hmm, then I would suggest testing with just vserver patches
1141318176 M * Bertl so you get a feeling where to look ...
1141318338 A * harry trying on another server...
1141318564 J * mnemoc_ ~amery@200.73.88.6
1141318669 Q * mnemoc Ping timeout: 480 seconds
1141318669 N * mnemoc_ mnemoc
1141319077 M * harry i think i found it
1141319090 A * harry disables chroot restrictions in grsec completely
1141319101 M * harry disabled mounts, disabled chmod +s's
1141319107 M * harry so all normal failures
1141319110 M * harry afaik
1141319378 J * bonbons ~bonbons@83.222.39.180
1141319510 J * wally ~homebase@62.116.83.242
1141319703 J * mef ~mef@targe.CS.Princeton.EDU
1141320951 M * harry aleph06:~# vserver stdsarge start
1141320951 M * harry Starting internet superserver: inetd.
1141320951 M * harry Starting periodic command scheduler....
1141320951 M * harry aleph06:~# vserver stdsarge enter
1141320952 M * harry aleph06:/#   
1141320954 M * harry wtf?
1141320962 M * harry why is that one still named aleph??
1141320970 M * harry aleph06:/# cat /etc/hostname
1141320971 M * harry stdsarge
1141320977 M * harry why doesn't he go to ~
1141321061 M * Bertl bash?
1141321073 M * harry aleph06:/vservers# vserver stdserver enter
1141321073 M * harry stdserver:/# cd
1141321078 M * harry same here...
1141321085 M * harry why doesn't it start bash?
1141321211 M * Bertl it does start bash, but why should it source guest internal files?
1141321225 M * Bertl if you want to see 'guest' stuff, ssh into the guest
1141321264 M * harry i don't want to run ssh daemons on the guests
1141321363 M * harry right... time for sports... /me is going nuts over here
1141321519 Q * pzYsTorM Ping timeout: 480 seconds
1141321748 Q * ||Cobra|| Remote host closed the connection
1141322540 Q * Doener Quit: Leaving
1141322783 J * coocoon ~coocoon@p54A06E7F.dip.t-dialin.net
1141322796 M * coocoon hellö
1141322973 M * Bertl hellö?
1141323106 J * comfrey ~comfrey@h-64-105-87-234.sttnwaho.covad.net
1141323439 M * Bertl welcome comfrey!
1141323704 M * comfrey mornin Bertl.
1141323710 Q * al_ Remote host closed the connection
1141323711 M * comfrey and all
1141323742 M * comfrey what kind of network latency are folks seeing with vservers?
1141323753 M * comfrey is anyone running asterisk in a vserver?
1141323822 M * Bertl comfrey: you will see the same latency as on a normal linux system, and yes, there is a project with multiple virtualized asterisks ..
1141323858 M * comfrey ok, good to hear, and is it possible to run low latency vservers?
1141323896 M * Bertl define 'low latency vservers'
1141323924 M * coocoon bertl: hello some questions about fedora core 3 and 4 and network connection problems, debian vservers working fine, and also once there was a time that my fc vservers have connection to the internet too
1141323924 M * comfrey can the host run a low latency kernel
1141323949 M * Bertl coocoon: network connections are not related to the distro
1141323951 M * comfrey Bertl: with the vserver patches
1141323959 M * Bertl comfrey: (the guest distro that is)
1141323984 M * Bertl comfrey: you want to know if you can add lowlat patches to the mix?
1141323998 M * comfrey yeah, it that pushing things to far?
1141324063 M * coocoon bertl: i know sorry but i must deactivate some files in the init.d to prevent network probs mustn't i, so where can I ffind docs about it or which files must be deactivated or deleted
1141324097 M * coocoon bertl: or rc.d
1141324123 M * Bertl comfrey: it's probably untested, but I don't see many reason why it should not work when done properly
1141324135 J * uniq_ ~frode@dsl238-219.adsl.no
1141324142 M * Bertl coocoon: guests should start, although with error messages even if you do not cleanup anything
1141324148 M * Bertl welcome uniq_!
1141324159 M * comfrey Bertl: ok, i may get around to testing that sometime.
1141324169 M * uniq_ hi.
1141324175 M * comfrey Bertl: thanks
1141324210 M * Bertl comfrey: let us know how it goes ...
1141324210 M * uniq_ anyone tried to install ispconfig(.org) on a vserver? i've hard bind doesn't run well on vservers?
1141324224 M * Bertl uniq_: bind runs perfectly
1141324245 M * coocoon bertl: so there are no probs if there are error messages
1141324255 M * Bertl uniq_: just the false/broken security the bind folks try to use on linux systems do not work
1141324274 M * daniel_hozac coocoon: they're at most an annoyance.
1141324290 M * uniq_ ok.. then i'll have to investigate more. mine only listens on udp 32818.. 
1141324327 M * uniq_ thanks for fast replies :)
1141324346 M * daniel_hozac coocoon: plus, the utils should set up your guests properly.
1141324355 Q * Wenix Quit: leaving
1141324367 M * daniel_hozac (they disable everything but syslog, IIRC)
1141324383 M * Bertl uniq_: you're welcome! feel free to hang around and ask when you encounter issues!
1141324461 M * coocoon daniel_hozac: hello, weeks ago i asked for this problem then i changed something in the guest now i can't connect with fc also not with my fc images which i haven't change
1141324484 M * daniel_hozac coocoon: what would "something" be?
1141324508 M * coocoon daniel_hozac: i think about to reinstall my server but the other vservers have internet connection
1141324556 M * coocoon daniel_hozac: basically, chkconfig network off, rm -f /etc/rc[06].d/S01{halt,reboot} are the most important ones
1141324583 M * daniel_hozac yep.
1141324631 M * coocoon daniel_hozac: after that i have no connection with fc images
1141324711 Q * phreak``_ Quit: Reconnecting
1141324728 J * phreak`` ~phreak``@styx.xnull.de
1141324792 Q * michal` Ping timeout: 480 seconds
1141324808 M * daniel_hozac coocoon: and they have IP addresses? and correct settings for DNS? ping -I <guest's IP address> google.com from the host works ok?
1141324914 M * coocoon daniel_hozac:  yes all works fine, i will set up my system new
1141324926 M * coocoon daniel_hozac: thanx a lot
1141324929 M * coocoon if that
1141325046 M * coocoon daniel_hozac: does there exists a documentation for preventing annoyance error messages for fc and other distributions (for debian and gentoo there exists a lot)
1141325105 M * daniel_hozac for Fedora, just use vserver ... build and it'll do the Right Thing(tm).
1141325127 M * daniel_hozac i can't imagine Gentoo's baselayout-vserver having things like that...
1141325127 J * michal` ~michal@www.rsbac.org
1141325235 M * coocoon daniel_hozac: right sorry i mean ubuntu
1141325239 M * coocoon ;-)
1141325340 M * daniel_hozac can't really say anything about those. i've never used Debian or Ubuntu for vservers.
1141325387 M * coocoon daniel_hozac: thanx a lot at this time ;-)
1141325399 M * uniq_ Bertl: fyi. bind8 from debian works. bind9 had problems for some reason.
1141325432 M * daniel_hozac uniq_: BIND9 tries to be smart. you'll need to rebuild with either --disable-linux-caps or with a patch.
1141325448 M * daniel_hozac (http://linux-vserver.org/ProblematicPrograms)
1141325458 M * Bertl uniq_: just recompile it with linuxcaps disabled
1141325519 M * daniel_hozac no caps means no non-root+chroot though :)
1141325530 M * daniel_hozac (hmm, linux-vserver.org having problems?)
1141325539 M * Bertl seems so, investigating now
1141325556 M * uniq_ Bertl: i'll just use bind8 and don't recompile. using packages from the distro is one of my goals. to save time/money for administration. apt-get is my friend. But thanks for the tip :)
1141325786 Q * entroposcope Remote host closed the connection
1141325854 M * Hollow daniel_hozac: did you take a look at porting vlogin?
1141325879 M * daniel_hozac Hollow: no, sorry, been a bit preoccupied with school lately.
1141326070 M * coocoon can anyone explain me what that does mean "Create a default skeleton for your vserver's config (skel.conf)", from this document "SlackwareVserverHowto" http://linux-vserver.org/SlackwareVserverHowto
1141326085 M * Bertl seems jacques' host has some issues, the vserver partition was remounted ro
1141326110 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com
1141326141 J * shuri ~boafroid@64.235.209.226
1141326155 M * Hollow Bertl: it's very weird... under 2.0.2_rc10 i get "mount: you must specify the filesystem type" for 021 and 023
1141326166 M * Hollow but 002 (which should be the same command) works
1141326171 M * Hollow in testfs.sh
1141326182 M * Hollow and 2.1.1_rc10 works too
1141326185 M * Bertl let me verify that
1141326257 M * Hollow though
1141326260 M * Hollow hm..
1141326273 M * Hollow this may be because i changed the lines to use $MNT instead of $DEV
1141326408 M * Hollow ah yeah.. it works now.. i changed it for device mapper, but i found out how it works with $DEV...
1141326624 M * Hollow Bertl: ok, now for the rela issues: http://phpfi.com/105224
1141326627 M * Hollow *real
1141327175 Q * Viper0482 Quit: bin raus, 
1141327190 J * Viper0482 ~Viper0482@p54977161.dip.t-dialin.net
1141327352 J * tudenbart ~willi@xdsl-213-196-253-186.netcologne.de
1141327352 Q * dothebart Read error: Connection reset by peer
1141327360 M * Bertl Hollow: okay, looks good, everything fine except for jfs
1141327378 M * Hollow yup
1141327387 M * Bertl you should test with -tx (testfs)
1141327403 M * Bertl (easier to read)
1141327407 M * Hollow is the jfs fail expected?
1141327413 M * Bertl on stable, yes
1141327415 M * Hollow ok
1141327736 Q * comfrey Quit: Ex-Chat
1141327962 M * Hollow Bertl: should is test on x86 as well?
1141327982 M * Bertl that would be good
1141328359 M * Hollow Bertl: i've also tested guest startup & shutdown on x86_64, works like a charm
1141328410 M * Bertl excellent! thanks a lot!
1141328520 Q * ebiederm Ping timeout: 480 seconds
1141328522 M * Hollow if there are any special cases to test, just tell me
1141328531 M * Hollow i'm in testing mood :P
1141328549 M * Bertl ah, well, the limits could use a good testing (on devel)
1141328563 M * Bertl probably same is true for the virt_* infos
1141328586 M * Bertl (aside from the usual with and without init tests)
1141328617 M * Hollow ok, sounds more like a observation taking some hours or days to produce real world examples
1141328646 M * Hollow but i'll set up some test vservers on my box, so i can test around
1141328732 M * daniel_hozac derjohn: ping
1141328972 Q * f_ Quit: This computer has gone to sleep
1141329192 Q * Viper0482 Quit: bin raus, 
1141329546 J * comfrey ~comfrey@h-64-105-87-234.sttnwaho.covad.net
1141330279 Q * mnemoc Ping timeout: 480 seconds
1141330414 J * f_ ~fwl@83-215-237-1.seek.stat.salzburg-online.at
1141330717 Q * mef Remote host closed the connection
1141331575 Q * Hollow Remote host closed the connection
1141331710 Q * uniq_ Remote host closed the connection
1141332182 Q * Loki_muh Ping timeout: 480 seconds
1141332357 J * Loki|muh loki@satanix.de
1141332584 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1141332945 J * Smutje_ ~Smutje@xdsl-84-44-244-81.netcologne.de
1141333069 Q * Smutje Ping timeout: 480 seconds
1141333069 N * Smutje_ Smutje
1141333250 J * Aiken ~james@tooax6-012.dialup.optusnet.com.au
1141333554 J * Hollow ~hollow@home.xnull.de
1141333568 M * Hollow ok, all (positive) test results have been sent to the ML
1141333629 M * Bertl excellent! thanks a lot for testing!
1141333666 M * Hollow you're welcome!
1141333868 P * glen_ 
1141334305 M * matti Hollow: Did you try 2006.0?
1141334329 M * Hollow matti: there will be new vserver stages on the mirrors shortly
1141334344 M * matti Hollow: Maybe is some changelog available or maybe some release log? Or just some "what's new".
1141334375 M * matti Hollow: Hm... I try to use 2006.0 with hardened profile.
1141334390 M * Hollow hm, well, the profile has moved to default-linux/<arch>/vserver because of some nasty clashes... besides every package in the stage is up to date ;)
1141334394 M * matti Hollow: And... Almost every thing don't work as should be.
1141334396 M * Hollow for amd64 there were many bug fixes
1141334409 M * matti Hollow: I can even reporoduce SIGSEGV with --metadata :)
1141334427 M * Hollow never used hardened inside a guest
1141334432 M * matti No, no.
1141334444 M * matti I just start to make test from stage1 :)
1141334460 M * Hollow to test what?
1141334472 M * matti Upacked stage, chrooting... emerge --sync - SIGSEGV.
1141334504 M * matti Try once again... sync work well, but 70% of portage cache... and SIGSEGV :)
1141334505 M * Hollow with a stage1?
1141334509 M * matti Indeed.
1141334516 M * Hollow you should use stage3
1141334517 M * matti With 2005.1 everything is working :)
1141334525 M * Hollow stage1 is just used to bootstrap another system
1141334535 M * matti Hollow: I know.
1141334546 M * Hollow are you talking about the default 2006.0 stages?
1141334624 M * matti Hollow: I use Gentoo since 1.4...
1141334639 M * matti LOL
1141334653 M * Hollow great! but where is the segfault happening?
1141334716 M * matti >>> Updating Portage cache:   83%QA Notice: USE Flag 'apache2' not in IUSE for net-www/mod_scgi-1.2_alpha1 100%Segmentation fault
1141334720 M * matti LOL?
1141334729 M * matti This is a bit sick. 
1141334730 M * matti ;]
1141334746 M * Hollow trace? gdb?
1141334760 M * matti Hollow: I just unpack stage1 :) There's no gdb or strace...
1141334760 M * Bertl segfaults are in recently
1141334764 M * matti Hollow: :)
1141334775 M * matti Hollow: And... hey! 2005.1 works excellent :)
1141334785 M * Hollow which stage1?
1141334794 M * matti Hollow: I think, that 2006.0 is screwed somewhere...
1141334797 M * matti Hollow: Indeed.
1141334817 M * Hollow there is no 2006.0 stage *wonders*
1141334831 M * matti No?
1141334845 M * Hollow no, at least if you're talking about vserver :)
1141334880 M * matti No I am not :) I just ask ya, because y're the Gentoo developer ;-p
1141334904 M * matti Hollow: I even ask on #gentoo-hardened, but solar seems to have bad day as usual, and he is freakin up as usual...
1141334909 M * Hollow ah, ok... well, dunno
1141334919 M * Hollow especially with hardend i dunno :)
1141334940 M * matti Heh, I hate solar.
1141334944 M * matti Jesus.
1141335057 M * matti :)
1141335066 M * matti Neverming, sorry for nagging you :)
1141335070 M * matti Bertl: Hello!
1141335080 M * matti s/Neverming/Nevermind/
1141335199 M * Bertl hmm?
1141335245 M * Bertl it seems Jacques has strange methods of movin vservers :)
1141335254 M * Bertl anyway, linux-vserver.org is back now :)
1141335262 M * matti :)
1141335270 A * Hollow already wondered
1141335481 M * Hollow Bertl: is l-v.org and 13thfloor hosted at Jaques'?
1141335490 M * Bertl nope
1141335507 M * Bertl linux-vserver.org is, 13thfloor is hosted in vienna
1141335518 M * Hollow ok
1141335968 M * shuri 13thfloor of wich building?
1141335974 M * shuri :)
1141336025 M * Bertl shuri: a virtual one, of course :)
1141336038 M * shuri hehe
1141336068 M * shuri we live in a virtual world :)
1141336530 M * cehteh derjohn: congrats
1141336556 M * derjohn public? is this 'verbindlich' ?
1141336565 M * cehteh dunno :)
1141336602 M * derjohn so I will tell this closed audience: It looks like linux-vserver is accepted for a booth at linuxtag 2006 in Wiesbaden/Germany.
1141336620 Q * dos000 Read error: Connection reset by peer
1141336633 J * ebiederm ~eric@ebiederm.dsl.xmission.com
1141339292 Q * bonbons Quit: Leaving
1141339609 M * nox btw Bertl got your money for linuxtag04 now? (;
1141339654 M * mugwump ooo, maybe I should go to that
1141339818 M * Bertl nox: not that I know of ... 
1141339827 M * nox *grumpf*
1141339953 M * derjohn I tried to intervent, but nothing happend yet. but we'll see. besides that it's not a thing to discuss in public ... ( -> gossip ;)) 
1141339971 M * derjohn mugwump, hm It's a little far for you ;)
1141339984 M * mugwump und ich kann nicht Deutsch
1141340010 M * derjohn mugwump, und ich nicht neuseelaendisch ;) 
1141340045 M * derjohn mugwump, but i heared Sindarin is accepted meanwhile ;)
1141340067 M * mugwump Sindarin?  Is that a dialect of Mandarin?
1141340100 M * derjohn nox, it's Tolkiens language of the wood elves ;)
1141340153 M * nox hehe
1141340174 M * derjohn nox, you are from .de -> help us at linuxtag?
1141340211 M * nox derjohn: i gonna support cacert.org, was fulltimejob last year
1141340236 M * derjohn nox, funny, then you probably certed me :)
1141340247 M * derjohn btw: http://linux-vserver.org/linuxtag2006
1141340270 M * nox Bertl: you get vip assurance if you not already have one (;
1141340296 M * derjohn nox, we stay tuned if he is accepted for a tutorial 
1141340301 A * derjohn hopes so.
1141340314 A * derjohn thinks of Bertl as star-guest !
1141340396 M * nox last year there were problems with the money of the year before so Bertl resigned iirc
1141340479 M * derjohn nox, yup, I had a discussion with nils about that, I thought the problem would haven been solved already 
1141340489 M * derjohn nox, but it didnt
1141340517 Q * micah Remote host closed the connection
1141340724 Q * shuri Ping timeout: 480 seconds
1141340951 J * shuri ~boafroid@64.235.209.226
1141341393 Q * shuri Quit: Quitte
1141342245 Q * ebiederm Ping timeout: 480 seconds
1141342590 J * ebiederm ~eric@ebiederm.dsl.xmission.com
1141342823 P * stefani I'm Parting (the water)
1141343651 Q * ebiederm Quit: Leaving
1141343707 J * micah ~micah@69.90.134.205